SIOS SANless clusters - SIOS SANless clusters High-availability Machine Learning monitoring

November 26, 2022	Buat Rencana Pemulihan Bencana Untuk Aplikasi Kritis Buat Rencana Pemulihan Bencana Untuk Aplikasi Kritis Aplikasi penting bisnis dapat berupa apa saja mulai dari server database Anda, hingga server database Anda GETAH infrastruktur. Ini adalah aplikasi yang diandalkan oleh bisnis Anda. Organisasi tidak mampu untuk menurunkan aplikasi ini. Di episode ini, kami duduk bersama Dave Bermingham , Direktur Kesuksesan Pelanggan di Teknologi SIOS , untuk membahas bagaimana membangun beton pemulihan bencana strategi untuk aplikasi kritis bisnis. Buat Rencana Pemulihan Bencana Untuk Aplikasi Kritis Direproduksi dengan izin dari SIOS
November 23, 2022	SAP pada Praktik Terbaik Ketersediaan Tinggi Azure SAP pada Praktik Terbaik Ketersediaan Tinggi Azure Dalam video berikut, Bala Anbalagan, arsitek senior SAP untuk Microsoft dengan pengalaman 20 tahun di SAP, menjelaskan praktik terbaik untuk mengonfigurasi ketersediaan tinggi guna melindungi solusi SAP di Azure. Dia juga meninjau kesalahan yang sering dilakukan saat mengimplementasikan solusi HA di cloud dan faktor utama yang harus diketahui pengguna saat mengonfigurasi SIOS LifeKeeper. Mengonfigurasi Solusi Ketersediaan Tinggi SAP di Cloud Bala menjelaskan bahwa setiap pengguna SAP harus ingat bahwa a ketersediaan tinggi solusi sangat diperlukan, terutama di cloud. Setiap penyedia cloud perlu membuat perubahan di lingkungan mereka. Meskipun mereka memiliki tingkat layanan yang tinggi untuk infrastruktur perangkat keras mereka, akan ada periode waktu henti singkat yang dapat membuat sistem SAP Anda benar-benar mati. Penting juga bagi pengguna untuk mengonfigurasi SAP HA dengan benar. Tujuan utama penginstalan solusi HA adalah untuk melindungi dari downtime, tetapi jika Anda tidak melakukannya dengan benar, Anda hanya membuang-buang waktu dan uang, terlepas dari cloud tempat Anda menjalankannya. Penting untuk mengikuti aturan konfigurasi penyedia cloud Anda. Jika Anda salah mengonfigurasi HA atau gagal menguji failover dan failback, ini dapat menyebabkan gangguan bisnis saat Anda tidak menduganya – khususnya selama periode pemanfaatan tinggi. Penjaga Kehidupan SIOS dapat mendeteksi kesalahan selama proses konfigurasi. Misalnya, mengirim peringatan jika Anda hanya mengonfigurasi satu saluran komunikasi, karena Anda selalu menginginkan saluran komunikasi yang berlebihan, atau koneksi jaringan sekunder, di antara node di kluster HA. Jika Anda menggunakan Penjaga Data SIOS , itu juga akan menampilkan peringatan jika ada yang salah dengan konfigurasi selama proses replikasi. Apa yang membuat konfigurasi SIOS mudah? SIOS memiliki proses konfigurasi yang cukup mudah. Pada dasarnya, Anda hanya perlu LifeKeeper diinstal di setiap node cluster Anda dan Anda menggunakan berbagai jenis modul kit pemulihan khusus aplikasi (ARK) SIOS (yang disertakan dengan LifeKeeper) tergantung pada aplikasi yang ingin Anda pulihkan. Selain itu, prosesnya sangat mudah diikuti dengan GUI langsung – kecerdasan sudah ada di dalamnya, dan Anda tidak perlu mengubah detail GUI. Secara otomatis mendeteksi sebagian besar informasi, semakin menyederhanakan proses penyiapan. Mengetahui ARK mana yang akan digunakan dan cara menggunakannya penting dalam proses konfigurasi. ARK adalah modul perangkat lunak yang menyediakan kecerdasan khusus aplikasi untuk perangkat lunak LifeKeeper. SIOS menyediakan ARK terpisah untuk aplikasi yang berbeda. Misalnya, untuk SAP HANA, Anda menginstal SIOS SAP HANA ARK untuk mengaktifkan LIfeKeeper untuk mengotomatiskan langkah-langkah konfigurasi, mendeteksi kegagalan, dan mengelola failover yang andal untuk SAP HANA sembari mempertahankan praktik terbaik SAP. Kesalahan Terbesar dalam Menerapkan HA untuk SAP di Azure Pengguna biasanya menerapkan HA untuk solusi SAP di Azure dengan proses yang sama seperti yang mereka lakukan di lingkungan lokal. Mereka perlu mengubah pola pikir mereka. Selalu pastikan untuk mengikuti rekomendasi yang diberikan oleh cloud provider, yaitu membaca dokumen dan menyimpan parameter sesuai anjuran cloud provider. Kesalahan umum lainnya adalah menambahkan terlalu banyak kerumitan. Beberapa pelanggan memasukkan semuanya ke dalam satu cluster, tetapi cluster harus dipisahkan untuk server yang berbeda. Membuat cluster terlalu besar menambah kerumitan yang tidak perlu dan potensi risiko. Pengujian menyeluruh dalam setiap aspek sangat penting dalam hal pengelompokan HA. Menguji konfigurasi HA sebelum ditayangkan serta secara berkala (dan sering) adalah hal terbaik yang dapat Anda lakukan untuk mencegah waktu henti yang tidak terduga. Belajar lebih tentang SAP ketersediaan tinggi praktik terbaik dalam video di bawah atau hubungi kami untuk informasi selengkapnya tentang menerapkan ketersediaan tinggi dan pemulihan bencana untuk aplikasi penting Anda di cloud. Direproduksi dengan izin dari SIOS
November 20, 2022	Hari-hari sederhana HA & DR telah berlalu Hari-hari sederhana HA & DR telah berlalu Membolak-balik saluran TV, saya tersandung pada adegan dalam film "He's Just Not That Into You" dengan Drew Barrymore, mengatakan apa yang sebagian besar dari kita rasakan di tahun 2022 tentang Teknologi dan terutama ketersediaan tinggi dan pemulihan bencana: "Saya merindukan hari-hari ketika Anda memiliki satu nomor telepon dan satu mesin penjawab dan satu mesin penjawab itu memiliki satu kaset dan satu kaset itu memiliki pesan dari seorang pria atau tidak. Dan sekarang Anda hanya perlu berkeliling memeriksa semua portal berbeda ini hanya untuk ditolak oleh tujuh teknologi berbeda. Ini melelahkan.” Terkadang, tidakkah Anda berharap hanya ada satu cloud atau bahkan mungkin tidak ada platform cloud; satu DB berjalan di satu OS; dan hanya aplikasi ujung depan yang perlu dikhawatirkan. Tapi, dunia telah berubah dan bergerak lebih cepat, dan menjadi lebih rumit.Kemajuan teknologi, dampak dari merger dan akuisisi, serta meningkatnya selera dan kecepatan masyarakat kita selama 24/7, dengan miliaran konsumen yang mencari kesepakatan terbaru dan pengalaman terbaik, berarti hari-hari sederhana telah berlalu. 4 kebenaran keras tentang ketersediaan Anda Solusi Anda tidak sesederhana yang Anda pikirkan Tentu saja lingkungan perusahaan Anda tidak sederhana.Anda memiliki sistem dan aplikasi lawas, jenis yang sudah ada hampir sejak kartu berlubang.Anda memiliki sistem baru, dibuat untuk aplikasi dan database generasi baru.Selain itu, Anda memiliki solusi yang dibuat satu dekade lalu untuk menjembatani kesenjangan atau rentang waktu antara bermigrasi dari satu platform ke platform lainnya, tetapi terlepas dari upaya terbaik Anda, sistem ini tetap ada. Ditambah dengan tantangan ini adalah kumpulan sistem dan sumber daya TI yang berkembang dari merger dan akuisisi Perusahaan U. Menyampaikan HA tidak sesederhana yang Anda pikirkan di era baru. Arsitektur yang buruk adalah masalah yang lebih besar dari yang Anda sadari Sebagai Wakil Presiden Pengalaman Pelanggan, kami telah melihat kerusakan yang disebabkan oleh arsitektur yang buruk.Meskipun penerapan perangkat lunak HA pasti dapat membantu meningkatkan ketersediaan aplikasi dan database, perangkat lunak HA tidak akan pernah sepenuhnya mengatasi persyaratan yang tidak lengkap, jaringan yang buruk, kurangnya perangkat keras yang berlebihan, atau komponen arsitektur lainnya yang hilang.Tim kami pernah bekerja dengan pelanggan untuk memperbaiki lingkungan berukuran kecil yang membuat sistem mereka tidak stabil selama waktu pengoperasian puncak.Karena arsitektur mereka yang buruk, yang mencakup ketidakstabilan jaringan dan perangkat keras, tim mereka sering kesulitan untuk memulihkan diri dari masalah downtime yang dapat dihindari.Untuk mendapatkan solusi yang lengkap dan sehat, sangat tersedia, dan tangguh, Anda perlu menerapkan perangkat lunak yang hebat sebagai bagian dari arsitektur yang baik. Admin Anda membutuhkan lebih banyak bantuan daripada yang mereka akui Mengembangkan solusi HA tangguh tingkat perusahaan dengan ketersediaan tinggi, dibangun di atas arsitektur yang solid dengan kemampuan untuk berkembang bukanlah proses yang sederhana.Merancang dan merancang ketahanan, aplikasi, dan ketersediaan data tidak semudah mengambil sekotak campuran kue dari rak.Lemparkan berbagai alat, proses dari tim yang berbeda, campuran SLA, dan jenis OS, aplikasi, database, dan platform dan Anda memiliki resep untuk membutuhkan bantuan. Baru-baru ini, saya mewawancarai seorang veteran 20 tahun yang bekerja di lingkungan dukungan perusahaan.Dia menggambarkan berapa banyak dari rekan-rekannya, dan bahkan dirinya sendiri, belum mampu menangani beban mempertahankan ketersediaan perusahaan kritis.Admin Anda, tidak hanya membutuhkan bantuan ketika mereka sudah bangun sejak jam 2 pagi berurusan dengan bencana, multi-sistem, multi-aplikasi, runtuhnya pusat data yang hampir selesai, tetapi juga dalam kerja keras sehari-hari ketersediaan perusahaan di salah satu yang paling era teknologi yang kompleks yang pernah ada. Solusi Anda mungkin tidak tersedia sebanyak yang Anda pikirkan “Sementara penyedia cloud publik biasanya menjamin beberapa tingkat ketersediaan dalam perjanjian tingkat layanan mereka, SLA tersebut hanya berlaku untuk perangkat keras cloud.” Ada banyak alasan lain untuk downtime aplikasi yang tidak dicakup oleh SLA penyedia cloud, termasuk: Masalah perangkat lunak dan bug Kesalahan manusia Kegagalan perangkat lunak Sistem atau aplikasi hang Sebagai VP Pengalaman Pelanggan, kami telah melihat satu atau dua hal, termasuk serangan denial of service yang disebabkan oleh gagal keluar dalam rutinitas rekursi, kelelahan sistem, karantina perangkat lunak keamanan aplikasi yang sehat, kritis, kepanikan kernel, dan mesin virtual yang secara acak menyalakan ulang.Jika strategi HA Anda hanya mengandalkan SLA hypervisor Anda, solusi Anda mungkin tidak tersedia sebanyak yang Anda kira. Anda perlu melindungi aplikasi penting dengan perangkat lunak pengelompokan yang dapat memantau dan mendeteksi masalah, merespons masalah dengan andal, dan jika perlu memindahkan operasi ke server siaga untuk memastikan bahwa produk dan layanan Anda tetap andal dan tersedia saat dan di mana pun dibutuhkan. Pusat data tunggal kami telah menjadi serangkaian platform cloud, yang mencakup lusinan pusat data.Aplikasi kerja sigung kami telah menjadi bagian dari perkumpulan solusi front end, middleware, dan backend kritis yang harus kami kelola di Windows, Linux, dan beberapa varietas * Nix yang berbeda.Pawai teknologi berarti bahwa kita ketersediaan tinggi telah menjadi lebih kompleks dan membutuhkan arsitektur yang lebih baik.Ini juga berarti bahwa tim kita membutuhkan lebih banyak bantuan untuk mengelola semuanya, dan jika kita tidak berhati-hati, itu bisa berarti kita tetap rentan dan terekspos.Manakah dari empat kebenaran yang paling banyak dihadapi tim Anda? Cassius Rhue, Pengalaman Pelanggan VP Direproduksi dengan izin dari SIOS
November 15, 2022	Apa yang Dilakukan Driver Baru di SIOS LifeKeeper untuk Windows Untuk Anda? Apa yang Dilakukan Driver Baru di SIOS LifeKeeper untuk Windows Untuk Anda? Membuat perlindungan data di lingkungan bersama dan tanpa SAN menjadi lebih kuat di tahun-tahun mendatang. Apa Coca-Cola, KitKat, SalesForce, dan SIOS LifeKeeper untuk Windows memiliki kesamaan?Berikut adalah beberapa petunjuk: Coca-Cola meluncurkan kembali kampanye menggunakan desain ulang produk dari merek ikoniknya untuk beradaptasi dengan masa depan, khususnya untuk fokus pada tema sosial. Kit-Kat mengganti nama candy bar-nya di Inggris untuk memperingati dan merayakan booming media sosial, YouTube, dan gelombang teknologi umum, serta memanfaatkan kekuatan merek OS Android (KitKat). Salesforce mengubah produk dasarnya untuk menciptakan antarmuka yang lebih ramping, lebih modern, dan lebih cepat untuk melayani kebutuhan pelanggannya. Perusahaan-perusahaan ini membuat peningkatan signifikan pada produk, layanan, dan solusi ikonik mereka untuk melayani pelanggan mereka dengan lebih baik, beradaptasi dan mempersiapkan masa depan, dan memanfaatkan kekuatan mereka.Dengan cara yang sama, SIOS telah membuat peningkatan dramatis pada produk SIOS LifeKeeper untuk Windows kami. Sebelum LifeKeeper untuk Windows versi 8.9.0, fungsi penyimpanan bersama, termasuk pagar I/O serta identifikasi dan manajemen drive ditangani oleh driver NCR_LKF.Dimulai dengan rilis SIOS LifeKeeper untuk Windows versi 8.9.0, SIOS Technology Corp. mendesain ulang arsitektur driver penyimpanan bersama. Dimulai dengan rilis saat ini, driver NCR_LKF telah dihapus dan diganti dengan driver SIOS ExtMirr, mesin di belakang replikasi penyimpanan tanpa SAN dari SIOS DataKeeper / SIOS DataKeeper Cluster Edition. Lima manfaat signifikan dari perubahan arsitektur NCR_LKF di SIOS LifeKeeper untuk Windows: Pengemudi yang lebih modern Driver ExtMirr menyediakan driver filter yang lebih modern untuk mengelola fungsionalitas penyimpanan bersama.Sementara driver NCR_LKF berfokus pada "menyalakan lampu" dan "keamanan data", arsitektur driver tertinggal dari driver yang lebih modern.Driver ExtMirr mempertahankan perlindungan data tersebut, sekaligus lebih kompatibel, lebih modern, dan lebih mudah didukung di versi OS Windows yang lebih baru. Pagar I/O yang lebih kuat Pengemudi yang digunakan dalam SIOS DataKeeper dan SIOS DataKeeper Cluster Edition menyertakan arsitektur pagar yang kuat. Sementara driver NCR_LKF mampu menahan I/O, driver baru ini lebih tangguh dan telah diuji di lingkungan SAN dan tanpa SAN. Pagar I/O yang ditingkatkan memanfaatkan kunci volume dan informasi kepemilikan node dalam volume yang dilindungi. Integrasi dan kompatibilitas yang lebih ketat. Memanfaatkan pagar I/O untuk driver ExtMirr yang digunakan dalam produk DataKeeper berarti solusi LifeKeeper untuk Windows meningkat dalam integrasi dengan lini produk DataKeeper.Driver ExtMirr juga termasuk yang terbaru Penandatanganan driver Microsoft dan bekerja mulus dengan Sistem Operasi yang menerapkan penandatanganan driver dan Boot Aman. Administrasi lebih mudah Driver ExtMirr memberi pelanggan dan administrator sekumpulan besar utilitas baris perintah untuk mendapatkan dan mengelola status volume.Perintah emcmd asli untuk kedua produk SIOS DataKeeper. Mereka sekarang dapat digunakan untuk administrasi yang lebih mudah dengan konfigurasi volume bersama SIOS LifeKeeper. Pelanggan dan mitra yang memanfaatkan penyimpanan bersama dan konfigurasi yang direplikasi dengan LifeKeeper untuk produk Windows kini memiliki seperangkat alat baris perintah untuk diketahui dan digunakan. Alat emcmd menggantikan volume.exe, volsvc, dan alat driver filter NCR_LKF serupa sebelumnya untuk administrasi (mengunci, membuka kunci, dll). Pembaruan dan perbaikan yang lebih sering Dengan penambahan driver ExtMirr ke dalam SIOS LifeKeeper untuk Windows, konfigurasi penyimpanan bersama, serta konfigurasi replikasi, kini akan mengalami peningkatan dalam pembaruan, fitur baru, dan perbaikan. Sementara driver NCR_LKF menyediakan fondasi yang kokoh dan basis yang stabil untuk pagar I/O, beralih ke driver ExtMirr berarti pelanggan akan melihat kekuatan dan stabilitas yang sama, dengan pembaruan yang lebih cepat untuk dukungan produk baru Menyelaraskan dua produk ke satu driver mungkin tidak sama mencoloknya dengan pembaruan SalesForce Classic ke Lightning, tetapi menambahkan fungsionalitas yang signifikan, meningkatkan kekuatan dan umur panjang solusi SIOS DataKeeper dan SIOS LifeKeeper, dan akan membuat perlindungan data di lingkungan bersama dan tanpa SAN menjadi lebih kuat untuk tahun-tahun mendatang. Cassius Rhue, Pengalaman Pelanggan VP Direproduksi dengan izin dari SIOS
November 11, 2022	Cara membuat ulang sistem file dan sumber daya mirror untuk memastikan informasi ukuran sudah benar Cara membuat ulang sistem file dan sumber daya mirror untuk memastikan informasi ukuran sudah benar Saat bekerja dengan clustering ketersediaan tinggi (HA), penting untuk memastikan bahwa konfigurasi semua node dalam cluster sejajar satu sama lain. Konfigurasi 'cermin' ini membantu meminimalkan titik kegagalan pada kluster, memberikan standar perlindungan HA yang lebih tinggi. Sebagai contoh, kami telah melihat situasi di mana mirror-size diperbarui pada node sumber tetapi informasi yang sama tidak diperbarui pada node target. Ketidakcocokan ukuran mirror mencegah LifeKeeper memulai node target dalam failover. Di bawah ini adalah langkah-langkah yang disarankan untuk membuat ulang sumber cermin pada node target dengan informasi ukuran yang sama dengan sumber: Langkah: Verifikasi – dari perspektif aplikasi – bahwa data pada node sumber valid dan konsisten Cadangkan sistem file pada sumbernya (yang merupakan sumber cermin) Jalankan /opt/LifeKeeper/bin/lkbackup -c untuk mencadangkan konfigurasi LifeKeeper di kedua node Keluarkan semua sumber daya dari layanan.Dalam contoh kita, sumber daya dalam layanan pada node sc05 dan sc05 adalah sumber dari mirror (dan sc06 adalah sistem target/target dari mirror). Di panel kanan LifeKeeper GUI, klik kanan pada sumber daya DataKeeper yang sedang dalam pelayanan. Klik Sedang dalam perbaikan dari menu munculan sumber daya. Kotak dialog akan mengonfirmasi bahwa sumber daya yang dipilih akan dihentikan layanannya. Ketergantungan sumber daya apa pun yang terkait dengan tindakan dicatat dalam dialog. Klik Lanjut. Sebuah kotak informasi muncul menunjukkan hasil sumber daya yang diambil dari layanan. Klik Selesai. Verifikasi bahwa semua sumber daya tidak berfungsi dan sistem file tidak terpasang Gunakan perintah cat /proc/mdstat pada sumber untuk memverifikasi bahwa tidak ada cermin yang dikonfigurasi Gunakan perintah mount pada sumber untuk memastikan sistem file tidak lagi terpasang Gunakan /opt/LifeKeeper/bin/lcdstatus -q pada sumber untuk memastikan semua sumber daya OSU. Di GUI LifeKeeper hancurkan ketergantungan antara sumber daya IP (VIP) dan sumber daya sistem file (/mnt/sps).Klik kanan pada sumber daya VIP dan pilih Hapus Ketergantungan. Kemudian, pilih sumber daya Sistem File (/mnt/sps) untuk Tag Sumber Daya Anak. Ini akan menghasilkan dua hierarki, satu dengan sumber daya IP (VIP) dan satu lagi dengan sumber daya sistem file (/mnt/fs) dan sumber daya cermin (datarep-sps). Hapus hierarki dengan sistem file dan sumber cermin. Klik kanan pada /mnt/sps dan pilih Delete Resource Hierarchy. Pada sumbernya, lakukan 'mount <device> <directory>' pada sistem file. Contoh: mount /dev/sdb1 /mnt/sps Melalui GUI buat ulang cermin dan sistem file melalui yang berikut ini: Kit Pemulihan: Replikasi Data Jenis Switchback: Cerdas Server: Node sumber Jenis Hierarki: Replikasi Sistem File yang Ada Mount Point yang ada: <pilih titik mount Anda>. Ini adalah /mnt/sps untuk contoh ini. Tag Sumber Daya Replikasi Data: <Ambil default> Tag Sumber Daya Sistem File: <Ambil default> File Bitmap: <Ambil default> Aktifkan Replikasi Asinkron: Ya Setelah dibuat, Anda dapat Memperluas cermin dan hierarki sistem file: Server target: Node target Jenis Switchback: Cerdas Prioritas Templat: 1 Prioritas Target: 10 Setelah pemeriksaan pra-perpanjangan selesai, pilih berikutnya diikuti dengan nilai-nilai ini: Disk target: <Pilih disk target untuk mirror>.Ini adalah /dev/sdb1 dalam contoh kita. Tag Sumber Daya Replikasi Data: <Ambil default> File Bitmap: <Ambil default> Jalur Replikasi: <Pilih jalur replikasi di lingkungan Anda> Mount Point: <Pilih titik mount di lingkungan Anda>.Ini adalah /mnt/sps dalam contoh kita. Tag Akar: <Ambil default> Ketika resource "extend" selesai pilih "Finish" dan kemudian "Done". Di GUI LifeKeeper, buat ulang ketergantungan antara sumber daya IP (VIP) dan sumber daya sistem file (/mnt/sps). Klik kanan pada sumber daya VIP dan pilih Buat Ketergantungan.Pilih /mnt/sps untuk Tag Sumber Daya Anak. Pada titik ini mirror harus melakukan sinkronisasi ulang penuh dari ukuran sistem file. Di GUI LifeKeeper di panel kanan GUI LifeKeeper, klik kanan pada sumber daya VIP. Pilih "Dalam Layanan" untuk memulihkan sumber daya IP (VIP), pilih sistem sumber tempat cermin dalam layanan (sc05 dalam contoh kami) dan verifikasi bahwa aplikasi dimulai ulang dan IP dapat diakses. Direproduksi dengan izin dari SIOS