SAP pada Praktik Terbaik Ketersediaan Tinggi Azure

SAP pada Praktik Terbaik Ketersediaan Tinggi Azure

Hari-hari sederhana HA & DR telah berlalu

Hari-hari sederhana HA & DR telah berlalu

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:

1. 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.

2. 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.

3. 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.

4. 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).

5. 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

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:

1. Verifikasi – dari perspektif aplikasi – bahwa data pada node sumber valid dan konsisten
2. Cadangkan sistem file pada sumbernya (yang merupakan sumber cermin)
3. Jalankan /opt/LifeKeeper/bin/lkbackup -c untuk mencadangkan konfigurasi LifeKeeper di kedua node
4. 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).
   1. Di panel kanan LifeKeeper GUI, klik kanan pada sumber daya DataKeeper yang sedang dalam pelayanan.
   2. Klik Sedang dalam perbaikan dari menu munculan sumber daya.
   3. 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.
   4. Sebuah kotak informasi muncul menunjukkan hasil sumber daya yang diambil dari layanan. Klik Selesai.

5. Verifikasi bahwa semua sumber daya tidak berfungsi dan sistem file tidak terpasang
   1. Gunakan perintah cat /proc/mdstat pada sumber untuk memverifikasi bahwa tidak ada cermin yang dikonfigurasi

2. Gunakan perintah mount pada sumber untuk memastikan sistem file tidak lagi terpasang
3. Gunakan /opt/LifeKeeper/bin/lcdstatus -q pada sumber untuk memastikan semua sumber daya OSU.

6. 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).

7. Hapus hierarki dengan sistem file dan sumber cermin. Klik kanan pada /mnt/sps dan pilih Delete Resource Hierarchy.

8. Pada sumbernya, lakukan 'mount <device> <directory>' pada sistem file.

Contoh: mount /dev/sdb1 /mnt/sps

9. Melalui GUI buat ulang cermin dan sistem file melalui yang berikut ini:
   1. Kit Pemulihan: Replikasi Data

2. Jenis Switchback: Cerdas
3. Server: Node sumber
4. Jenis Hierarki: Replikasi Sistem File yang Ada
5. Mount Point yang ada: <pilih titik mount Anda>. Ini adalah /mnt/sps untuk contoh ini.
6. Tag Sumber Daya Replikasi Data: <Ambil default>
7. Tag Sumber Daya Sistem File: <Ambil default>
8. File Bitmap: <Ambil default>
9. Aktifkan Replikasi Asinkron: Ya

10. Setelah dibuat, Anda dapat Memperluas cermin dan hierarki sistem file:
    1. Server target: Node target
    2. Jenis Switchback: Cerdas
    3. Prioritas Templat: 1
    4. Prioritas Target: 10

11. Setelah pemeriksaan pra-perpanjangan selesai, pilih berikutnya diikuti dengan nilai-nilai ini:
    1. Disk target: <Pilih disk target untuk mirror>.Ini adalah /dev/sdb1 dalam contoh kita.
    2. Tag Sumber Daya Replikasi Data: <Ambil default>
    3. File Bitmap: <Ambil default>
    4. Jalur Replikasi: <Pilih jalur replikasi di lingkungan Anda>
    5. Mount Point: <Pilih titik mount di lingkungan Anda>.Ini adalah /mnt/sps dalam contoh kita.
    6. Tag Akar: <Ambil default>

Ketika resource "extend" selesai pilih "Finish" dan kemudian "Done".

12. 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.

13. 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

Menjelaskan Perbedaan Halus tapi Penting Antara Switchover, Failover, dan Recovery

Menjelaskan Perbedaan Halus tapi Penting Antara Switchover, Failover, dan Recovery

Ketersediaan tinggi adalah spesialisasi dan seperti kebanyakan spesialisasi, ia memiliki kosakata dan terminologinya sendiri. Pelanggan kami biasanya sangat berpengetahuan tentang TI tetapi jika mereka belum pernah bekerja di lingkungan HA, beberapa terminologi HA umum kami dapat menyebabkan cukup banyak kebingungan – bagi mereka dan bagi kami. Mereka terdengar sederhana tetapi dengan makna yang sangat spesifik dalam konteks HA. Tiga istilah ini dibahas di sini – swithover, failover, dan recovery.

Apa itu Peralihan? ?

Peralihan adalah dimulai oleh pengguna tindakan melalui ketersediaan tinggi (HA) solusi pengelompokan antarmuka pengguna atau CLI. Dalam peralihan, pengguna secara manual memulai tindakan untuk mengubah sumber atau server utama untuk aplikasi yang dilindungi. Dalam skenario peralihan yang khas, semua aplikasi dan dependensi yang berjalan dihentikan secara berurutan, dimulai dengan aplikasi induk dan diakhiri ketika semua turunan/dependensi dihentikan. Setelah aplikasi dan dependensinya dihentikan, mereka kemudian dimulai ulang secara teratur di server utama atau sumber yang baru ditunjuk.

Misalnya, jika Anda memiliki sumber daya Alpha, Beta, dan Gamma. Resource Alpha bergantung pada resource Beta dan Gamma. Sumber Daya Beta tergantung pada sumber daya Gamma.Dalam peristiwa peralihan, sumber daya Alpha dihentikan terlebih dahulu, diikuti oleh Beta, dan akhirnya Gamma.Setelah ketiganya dihentikan, peralihan terus membawa sumber daya ke status operasional di server yang dimaksud.Proses dimulai dengan sumber daya Gamma, diikuti oleh Beta, dan akhirnya operasi start up selesai untuk sumber daya Alpha.Secara tradisional, operasi peralihan membutuhkan lebih banyak waktu karena sumber daya harus dihentikan dengan cara yang anggun dan teratur. Peralihan sering dilakukan ketika ada kebutuhan untuk memperbarui versi perangkat lunak sambil mempertahankan waktu aktif, melakukan pekerjaan pemeliharaan (melalui peningkatan berkelanjutan) pada node produksi utama, atau melakukan pengujian DR.

Takeaway kunci: Jika tidak ada kegagalan untuk menyebabkan tindakan, maka itu adalah peralihan

Apa itu Failover?

Operasi failover biasanya merupakan tindakan yang dimulai oleh non-pengguna sebagai respons terhadap kerusakan server atau reboot yang tidak terduga/tidak direncanakan. Pertimbangkan skenario cluster HA dengan dua node, Node A dan Node B.Dalam skenario ini, semua aplikasi penting Alpha, Beta, dan Gamma dimulai dan beroperasi di Node A. Dalam skenario ini, failover adalah apa yang terjadi ketika Node A mengalami reboot yang tidak terduga/tidak direncanakan, matikan, hentikan, atau panik. Setelah perangkat lunak HA mendeteksi bahwa Node A tidak lagi berfungsi dan tersedia secara operasional dalam cluster (seperti yang ditentukan oleh solusi), itu akan memicu operasi failover untuk memulihkan akses aplikasi kritis, sumber daya, layanan, dan dependensi pada node cluster yang tersedia , Node B dalam hal ini.Dalam skenario failover, karena Node A telah mengalami crash (atau kegagalan langsung simulasi lainnya) tidak ada proses untuk berhenti pada Node A, dan akibatnya setelah tindakan deteksi dan pagar yang tepat telah diproses, Node B akan segera memulai proses pemulihan sumber daya. Seperti dalam kasus peralihan, proses dimulai dengan sumber daya Gamma, diikuti oleh Beta, dan akhirnya operasi pengaktifan selesai untuk sumber daya Alpha. Secara tradisional, operasi failover membutuhkan waktu lebih sedikit daripada switchover. Hal ini karena pengolahan kegagalan tidak memerlukan sumber daya apa pun untuk dihentikan (atau dihentikan) pada node primer (dalam-layanan atau aktif) sebelumnya.

Takeaway Kunci: Kegagalan terjadi sebagai respons terhadap kegagalan sistem.

Apa Pemulihan ?

Peristiwa pemulihan mudah dikacaukan dengan failover. Peristiwa pemulihan terjadi ketika proses, server, jalur komunikasi, disk, atau bahkan sumber daya cluster gagal dan perangkat lunak ketersediaan tinggi beroperasi sebagai respons terhadap kegagalan yang diidentifikasi. Sebagian besar solusi perangkat lunak HA mampu melakukan berbagai cara untuk menangani peristiwa pemulihan. Metode yang paling menonjol meliputi:

1. Restart dengan anggun secara lokal, lalu restart dengan anggun pada remote
   1. Restart selalu dicoba secara lokal, jika pemulihan berhasil tidak ada tindakan lebih lanjut yang terjadi. Jika restart lokal gagal, operasi berikutnya terjadi
   2. Jika restart lokal gagal, sumber daya dipindahkan dengan anggun ke node jarak jauh
2. Restart dengan anggun secara lokal, lalu restart paksa pada remote
   1. Restart selalu dicoba secara lokal, jika pemulihan berhasil tidak ada tindakan lebih lanjut yang terjadi.Jika restart lokal gagal operasi berikutnya terjadi.
   2. Sumber daya dipindahkan ke simpul jarak jauh dengan memagari simpul utama
3. Restart paksa pada remote
   1. Restart tidak pernah dicoba secara lokal
   2. Sumber daya selalu dipaksa ke node cluster berikutnya yang tersedia seperti yang dijelaskan dalam metode 2b.
4. Restart server paksa, tidak ada failover jarak jauh
   1. Restart selalu dicoba secara lokal
   2. Jika restart lokal gagal, node utama dimulai ulang untuk mencoba memulihkan layanan.
   3. Sumber daya tidak akan gagal ke sistem jarak jauh
5. Restart lokal berbasis kebijakan, lalu jarak jauh
   1. Kebijakan dapat mengatur jumlah percobaan ulang sebelum upaya pemulihan jarak jauh terjadi

Karena banyaknya variasi dalam kebijakan pemulihan, mudah untuk melihat peristiwa pemulihan yang menyerupai perilaku peralihan. Hal ini sering terjadi pada metode 1 dan 5. Dalam skenario ini, aplikasi dan layanan dihentikan secara tertib sebelum dimulai pada node jarak jauh. Metode 2 dan 3, pelanggan akan sering melihat perilaku yang mirip dengan failover. Dalam metode 2 dan 3, server utama dimulai ulang atau dipagari oleh perangkat lunak HA yang menciptakan perilaku yang dapat diamati mirip dengan failover.Metode 4 biasanya merupakan opsi yang jarang digunakan, tetapi merupakan gabungan dari peralihan dan kegagalan.Metode 4 dimulai dengan penghentian aplikasi dan layanan dengan anggun, diikuti dengan memulai ulang aplikasi dan layanan (seperti peralihan). Namun, jika restart lokal aplikasi dan layanan gagal, sistem akan dimulai ulang (seperti failover), tetapi tanpa benar-benar gagal ke node cluster jarak jauh. Meskipun jarang, Metode 4 sering digunakan dalam kasus di mana terdapat klaster yang tidak seimbang, atau digunakan dengan metodologi berbasis kebijakan.

Takeaway kunci: Peristiwa pemulihan tergantung pada metode yang dipilih. Terminologi HA antara vendor adalah area di mana istilah umum dapat memiliki arti yang berbeda. Saat Anda menerapkan dan memelihara solusi klaster Anda dengan aplikasi perusahaan, pastikan Anda memahami persyaratan penyedia solusi untuk failover, switchover, dan pemulihan.Dan, saat Anda melakukannya, pastikan Anda tahu apakah restoran akan meletakkan saus di samping (dalam piring), atau di samping (kentang tumbuk Anda) Diperbanyak dengan izin dari SIOS