Aktif-Aktif vs. Aktif-Pasif

Panduan Arsitektur Ketersediaan Tinggi

Active-Active dan Active-Passive adalah dua konfigurasi arsitektur yang berbeda untuknode server dalam klaster ketersediaan tinggiArsitektur Active-Active mengacu pada kedua server yang dihidupkan dan memproses data. Active-Passive sangat berbeda karena hanya satu server yang aktif memproses data, dan server sekunder menunggu dalam keadaan tidak aktif untuk mengambil alih kendali jika server aktif mengalami kegagalan.

Sistem Ketersediaan Tinggi dan Komponen Inti

Ketersediaan tinggiIntinya adalah menghilangkan titik kegagalan tunggal, yang berarti bahwa, jika terjadi masalah pada node tertentu, node lain tersedia untuk mengambil alih pekerjaan tersebut.

Komponen-komponen kunci dari sistem yang memiliki ketersediaan tinggi:

• simpul inti pemrosesan utama dengan memori dan daya.
• simpul inti pemrosesan siaga dengan memori dan daya.
• tautan komunikasi antara dua komponen inti
• penyimpanan di tingkat lokal atau dibagi antara komponen inti

Arsitektur Aktif-Aktif

Dalam arsitektur Active-Active, dua server identik dijalankan secara bersamaan, keduanya aktif, masing-masing mampu memproses transaksi. Transaksi dapat ditangani oleh salah satu server.

Manfaat Arsitektur Aktif-Aktif

Kedua server selalu aktif, berbeda dengan konfigurasi lain yang memiliki node yang tidak digunakan dalam operasi normal. Potensi manfaatnya adalah sebagai berikut:

• Skalabilitas, terutama dengan menggunakan platform cloud, menjadikan masalah penggunaan puncak sebagai sesuatu yang sudah ketinggalan zaman.
• Beban kerja server dapat diseimbangkan sehingga tidak ada satu server pun yang kelebihan beban.
• Secara keseluruhan, terjadi peningkatan throughput untuk jumlah perangkat keras yang sama.

Skalabilitas

Pada platform cloud, arsitektur Active-Active sangat mudah diskalakan. Misalnya, AWS AutoScale dapat digunakan untuk menambahkan lebih banyak instance EC2 sesuai permintaan agar klaster dapat berkembang untuk menangani lonjakan data.

Penyeimbangan beban

Load balancer dapat disediakan di hulu node untuk mengirim transaksi ke server dengan beban lebih ringan, memastikan lalu lintas seimbang di seluruh klaster untuk menjamin throughput item kerja yang tinggi.

Kasus Penggunaan Aktif-Aktif

Data dalam jumlah besar, pemrosesan tipe transaksional, dan aplikasi yang dihosting pada banyak node paling cocok untuk konfigurasi aktif/aktif. Berikut beberapa contohnya:

• Sistem basis data multi-node yang terdistribusi secara global
• pemrosesan data matematika untuk aplikasi waktu nyata
• data besar/gudang data
• hosting situs web dengan trafik tinggi
• jaringan telekomunikasi dan SMS

Arsitektur Aktif-Pasif

Dalam arsitektur Aktif-Pasif, lingkungan klaster menggunakan dua server. Satu server akan ditugaskan untuk berada dalam mode aktif, melakukan pemrosesan. Server lainnya akan berada dalam mode siaga, tidak melakukan pemrosesan data apa pun, tetapi siap untuk mengambil alih jika terjadi gangguan.failoverdari node aktif atau yang dikeluarkan penggunaperalihandari node aktif.

Manfaat Arsitektur Aktif-Pasif

Karena hanya satu server yang aktif pada satu waktu, satu server menikmati waktu henti (tetap menyala, tetapi dalam mode siaga, pada dasarnya hanya menangani kebutuhan penyalinan data dari unit aktif, siap mengambil alih kendali jika diperlukan, tetapi tidak benar-benar memproses pekerjaan aktif apa pun). Potensi manfaatnya adalah sebagai berikut:

• Kebutuhan daya yang berkurang untuk klaster tersebut.
• Umur pakai perangkat keras yang lebih panjang – komponen akan bertahan lebih lama jika beroperasi dengan beban yang lebih ringan dan tidak terus-menerus dipaksa hingga batas kemampuannya.
• Kebutuhan pendinginan berkurang, dan tagihan listrik lebih rendah karena penggunaan pendinginan yang lebih sedikit.
• Tampilan sumber daya yang disederhanakan – sumber daya akan aktif pada node aktif.
• Load balancer tidak diperlukan.

Efektivitas Biaya dari Sistem Aktif-Aktif vs. Sistem Aktif-Pasif

Karena hanya setengah dari daya pemrosesan klaster yang dimanfaatkan untuk pekerjaan sebenarnya, biaya keseluruhan perangkat keras lebih tinggi untuk jumlah pemrosesan yang dapat dilakukan dalam konfigurasi aktif-pasif, sehingga sedikit kurang hemat biaya dibandingkan konfigurasi aktif-aktif.

Manajemen yang Disederhanakan

Sumber daya akan aktif pada node aktif – tidak ada tebakan node mana yang saat ini secara aktif menampung sumber daya tertentu.

Kasus Penggunaan Aktif-Pasif

Sistem-sistem penting yang harus tetap berfungsi dengan minim kehilangan data, seperti:

• sistem pemrosesan keuangan
• sistem ritel backend
• solusi pemulihan bencana
• basis data relasional
• Ketersediaan tinggi dengan biaya yang dikurangi untuk perusahaan kecil hingga menengah.
• sistem lama yang membutuhkan solusi hosting sederhana

Active-Active vs. Active-Passive dalam Solusi Pemulihan Bencana

Peran Aktif-Aktif vs. Aktif-Pasif

Sistem Pemulihan Bencana (DR) Aktif-Aktif diimplementasikan pada node yang tersebar secara geografis, yang keduanya menangani lalu lintas produksi. Jika salah satu node mengalami gangguan, beban kerja akan dialihkan ke sistem yang masih beroperasi.Waktu istirahatdan gangguan terhadap pengguna hampir tidak terdeteksi, meskipun pemrosesan beban kerja mungkin turun ke tingkat yang lebih rendah dari biasanya jika satu sistem mengalami gangguan.

Sistem Pemulihan Bencana (DR) Aktif-Pasif mengimplementasikan sebuahsolusi pemulihan bencanaDengan demikian, sistem siaga akan mengambil alih jika sistem utama mengalami kegagalan. Akan terjadi sedikit waktu henti pada transisi aktivitas jika terjadi kegagalan pada node aktif, tetapi tingkat beban kerja seharusnya tidak berbeda ketika node siaga mengambil alih dari sistem aktif yang lama.

Integrasi dengan Sistem Redundan

Menerapkan Pemulihan Bencana menggunakan sistem redundan adalah strategi untuk menyediakan kemampuan mengalihkan aktivitas ke sistem cadangan yang tersinkronisasi, di mana data berada pada tingkat yang sama seperti pada sistem aktif lama, dan sistem aktif baru dapat beroperasi dalam waktu singkat. Pertimbangan redundansi juga harus mencakup redundansi perangkat keras, redundansi jalur komunikasi, dan redundansi perangkat lunak (melalui ketersediaan tinggi) ketika memilih untuk menerapkan sistem redundan.

Memilih Antara Arsitektur Aktif-Aktif vs. Aktif-Pasif untuk Bisnis Anda

Faktor-faktor yang Perlu Dipertimbangkan

Memilih arsitektur yang tepat untuk bisnis Anda bergantung pada faktor-faktor seperti:

• biaya, termasuk biaya cloud berkelanjutan jika ingin menggunakan node yang dihosting di cloud.
• Sistem yang sangat penting untuk misi, atau sistem dengan data transaksional yang tinggi?
• Kesabaran pengguna untuk menerima sedikit waktu henti sesekali, persyaratan kinerja – misalnya, sanksi FCC karena ketidakpatuhan terhadap waktu operasional?
• Penyebaran geografis node dan penyimpanan untuk latensi yang lebih rendah, dan kemampuan untuk menambah node sesuai kebutuhan untuk mengakomodasi permintaan puncak.

Persyaratan Kinerja dan Waktu Operasional

Kewajiban terkait kinerja dan waktu operasional bisnis harus ditetapkan sebelum memutuskan arsitektur yang akan digunakan.

Bagi bisnis yang menyediakan layanan dengan waktu operasional (uptime) dalam angka tiga sembilan (99,9%) yang hanya memungkinkan 8 jam waktu henti (downtime) per tahun, hal ini tentu dapat dicapai dengan Active-Passive, asalkan failover dilakukan dengan cepat dan sistem dipantau serta dipelihara dengan baik.Waktu aktif empat angka sembilan (99,99%), sebagian besar berada dalam ranah sistem Aktif-Aktif.

Tingkat pemrosesan transaksi juga perlu dipertimbangkan. Jika diharapkan tingkat transaksi data kontinu yang besar, konfigurasi Active-Active mungkin lebih cocok.

Aktif-Aktif vs. Aktif-Pasif: Arsitektur Mana yang Tepat untuk Bisnis Anda?

Baik sistem aktif-aktif maupun aktif-pasif memiliki kegunaannya masing-masing. Sebagai sebuah organisasi, Anda mungkin ingin menempatkan sistem-sistem penting yang tidak boleh mengalami gangguan pada sistem arsitektur aktif-aktif. Untuk sistem lain yang dapat mentolerir gangguan sesekali, aktif-pasif mungkin merupakan pilihan yang tepat. Perpaduan teknologi mungkin tepat untuk mencakup semua sistem. Perusahaan memiliki banyak pilihan yang sesuai dengan kebutuhan mereka: bisnis yang lebih besar dan tersebar dapat memperoleh manfaat dari fleksibilitas sistem aktif-aktif yang dihosting di cloud, sementara perusahaan yang lebih kecil dapat menikmati kesederhanaan dan penghematan biaya dari pengaturan aktif-pasif. Ada solusi untuk semua orang.

Jika Anda sedang mengevaluasi Active-Active vs. Active-Passive untuk strategi ketersediaan tinggi Anda,minta demountuk melihat bagaimana SIOS dapat membantu Anda merancang arsitektur yang tepat untuk bisnis Anda.

Penulis: Paul Scrutton, Insinyur Sistem Perangkat Lunak di SIOS

Direproduksi dengan izin dariSIOS

Menjaga Keamanan Bangunan: Ketersediaan Tinggi dalam Sistem Pemeliharaan dan Keamanan

Dalam episode iniTFiR: Mari Bicara, pembawa acara Swapnil Bhartiya berbicara dengannyaDave Bermingham, Direktur Kesuksesan Pelanggan di SIOS Technology, tentang mengapa ketersediaan tinggi dan ketahanan sangat penting bagipemeliharaan bangunan dan sistem keamananBermingham menjelaskan bagaimana sistem-sistem ini berbeda dari, tetapi sering berinteraksi dengan, teknologi bangunan lainnya, dan mengapa pengoperasian tanpa gangguan sangat penting untuk keselamatan penghuni dan fungsionalitas bangunan. Percakapan ini mengeksplorasi bagaimana organisasi dapat menyeimbangkan keamanan dengan aksesibilitas, peran teknologi baru seperti AI, pembelajaran mesin, dan IoT dalam meningkatkan keandalan, dan praktik terbaik untuk memastikan ketersediaan sistem melalui redundansi, pemantauan, dan perencanaan risiko.

Penulis: Beth Winkowski, Hubungan Masyarakat SIOS Technology Corp.

Direproduksi dengan izin dariSIOS

Merancang Ketersediaan Tinggi Melalui Modularitas dan Abstraksi

Sejauh ini, seri ini telah mengeksplorasi persamaan antara desain teknis dan retorika. “Retorika” dari solusi teknis, strategi mengkomunikasikan makna dan tujuan, disajikan melalui pola dan konsep desain. Pola dan konsep desain tersebut berfungsi sebagai fondasi konseptual, di mana makna tersebut diterjemahkan ke dalam bentuk terapan ketika dipraktikkan selama implementasi.

Seperti yang telah dibahas sebelumnya, keberlanjutan dan integritas dari hal inilandasan konseptualsangat penting untuk memastikan bahwa solusi selalu terjaga pada standar yang kondusif untuk pemeliharaan, peningkatan, dan keandalan jangka panjang. Eksternalfaktor-faktor yang memengaruhi desain suatu solusiHal ini menantang tujuan untuk menjunjung tinggi landasan konseptual yang dikemukakan dalam desain suatu solusi. Faktor-faktor eksternal ini dapat bertentangan dengan prinsip-prinsip yang ada, dan oleh karena itu, alat, aplikasi, dan platform yang digunakan dalam suatu solusi harus dipilih dengan cermat.

Pada bagian ketiga dan terakhir dari seri blog ini, modularitas dan abstraksi akan dieksplorasi sebagai cara untuk menetapkan batasan dan memastikan bahwa proyek-proyek dengan cakupan luas dapat terus menuai manfaat dari desain yang terstruktur dengan baik dan memiliki landasan retorika yang kuat.

Prinsip-prinsip Desain Ketersediaan Tinggi: Mengapa Modularitas dan Abstraksi Penting

Sebelum membahas modularisasi dan abstraksi sebagai strategi, penting untuk memahami mengapa hal-hal ini perlu diterapkan. Secara umum, dengan sebuah analogi, seorang pembicara yang mencoba meyakinkan audiensnya untuk menyetujui rencananya mungkin perlu terlebih dahulu menguraikan beberapa poin dasar. Dengan demikian, setiap pilar dasar argumennya dikemukakan dan dibenarkan.

Pembicara pertama-tama harus membangun dasar “A menyiratkan B” dan “C menyiratkan D”, yang kemudian dapat digunakan untuk membentuk argumen “B dan D menyiratkan E”. Strategi ini memastikan bahwa penalaran di mana “A menyiratkan B” tidak saling mencemari dan mengurangi poin terpisah “C menyiratkan D”. Strategi ini sering digunakan karena memungkinkan setiap komponen argumen pembicara untuk berdiri sendiri. Jika argumen “C menyiratkan D” cacat, argumen tersebut dapat diperbaiki sementara argumen “A menyiratkan B” tetap valid.

Alasan di balik struktur ini sama dengan alasan mengapa sistem teknis bersifat terdesentralisasi – masalah dalam sistem titik penjualan dapat diperbaiki tanpa perlu memperluas upaya perbaikan ke basis data, API, arsitektur jaringan, dan sebagainya. Strategi yang disebutkan di atas, tentu saja, mengacu pada konsep modularitas dan abstraksi.

Modularitas dalam Arsitektur Ketersediaan Tinggi

Pertama, membahas modularitas, ini adalah praktik menciptakan sistem dari komponen-komponen yang mandiri. Dalam pengertian retorika, argumen “A menyiratkan B” dan “C menyiratkan D” hanyalah modul-modul penalaran yang dirangkai menjadi argumen secara keseluruhan.

Secara teknis, komponen yang dimodularisasi (seperti sistem point of sale pada contoh sebelumnya) memungkinkan masalah diatasi sepenuhnya di dalam modul tempat masalah tersebut berasal. Setiap modul dalam solusi bertindak sebagai blok bangunan, dan masalah dalam satu blok bangunan dapat diselesaikan tanpa membongkar seluruh solusi.

Abstraksi sebagai Strategi untuk Desain Infrastruktur yang Dapat Diperluas

Berkaitan erat dengan modularitas adalah “abstraksi”. Abstraksi adalah praktik untuk memastikan bahwa desain solusi keseluruhan bersifat independen dan tidak bergantung pada desain modul-modul yang membentuk solusi keseluruhan tersebut.

Lebih lanjut, abstraksi sebagai strategi desain juga menyatakan bahwa setiap modul bersifat independen dan tidak bergantung pada desain modul lainnya. Ketika suatu solusi dirancang untuk menggunakan elemen-elemen yang diabstraksikan, elemen-elemen ini dapat digunakan kembali dan diterapkan dalam kasus penggunaan yang memungkinkan pemahaman diperluas di seluruh proyek.

Merancang Ketersediaan Tinggi yang “Tidak Mengganggu”

Ketika desain dibangun dari komponen modular, batasan-batasan akan digambar. Batasan-batasan ini memastikan bahwa setiap modul dapat “tidak mengganggu” modul-modul lainnya. Ketika komponen-komponen tersebut diabstraksikan, isi setiap modul dapat dipahami dengan lebih mudah.

Pada gilirannya, batasan-batasan tersebut berfungsi sebagai struktur yang memungkinkan pemahaman desain, dan abstraksi di dalam batasan-batasan ini berfungsi sebagai titik masuk untuk memahami dasar-dasar kasus penggunaan. Struktur yang disediakan melalui modularitas dan abstraksi mencerminkan peran retorika dalam menyediakan kerangka kerja yang memungkinkan pemahaman tujuan.

Mengelola Arsitektur Jaringan Kompleks dengan Solusi HA Modular

Seiring dengan pengembangan solusi teknis untuk mengatasi masalah yang lebih kompleks, kebutuhan akan kerangka kerja yang solid dalam desain solusi tersebut juga meningkat. Arsitektur jaringan, yang seringkali merupakan puncak dari banyak solusi yang kompleks dengan sendirinya, berfungsi sebagai contoh fantastis dari masalah yang semakin kompleks dan kebutuhan yang semakin besar akan kerangka kerja yang solid dalam desain. Lebih jauh lagi, arsitektur jaringan seringkali mengalami pertumbuhan yang berkelanjutan karena harus menyerap jaringan sistem yang luas yang berkontribusi pada tujuan bisnis yang berkembang.

Sebagai lapisan tambahan di atasnya, arsitektur solusi kemudian harus menerapkan solusi untukKetersediaan Tinggi dan/atau Pemulihan BencanaHal ini menciptakan titik rawan bagi munculnya konflik desain, tetapi dapat dengan mudah diatasi dengan strategi modularisasi dan abstraksi.

Menerapkan Modularitas dan Abstraksi dengan Perangkat Lunak Ketersediaan Tinggi SIOS

Manfaat dariPerangkat lunak Ketersediaan TinggiHal ini dapat dicapai tanpa beban kerumitan dan solusi yang rumit. SIOS LifeKeeper, sebagai contoh alat Ketersediaan Tinggi yang sesuai dengan desain, dibuat sedemikian rupa sehingga prinsip-prinsip operasinya dapat menyatu dengan mulus dengan lingkungan tempat ia digunakan.

LifeKeeper bersifat modular, karena tidak memaksakan persyaratan di luar sistem yang dilindungi LifeKeeper. LifeKeeper juga memfasilitasi abstraksi komponen infrastruktur menjadi elemen-elemen yang lebih kecil – sistem yang bekerja sama untuk memastikan ketersediaan dikelompokkan ke dalam sebuah “cluster”.

Melalui abstraksi ini, retorika lingkungan tetap kuat – memahami susunan satu klaster meletakkan dasar untuk memahami semua klaster. Lapisan desain dapat dipahami sesuai tujuannya; tidak perlu tanda bintang dan pertimbangan khusus tentang bagaimana implementasi berbeda di seluruh desain. Karena klaster bertindak secara independen dari klaster lain atau komponen solusi eksternal, batasan dapat ditarik di mana elemen desain dari setiap lapisan masing-masing terkandung, menghindari konflik dengan lapisan infrastruktur lainnya.

Membangun Infrastruktur Tangguh Jangka Panjang dengan SIOS Protection Suite

Seperti halnya perangkat lunak atau alat lainnya,SIOS Protection Suite(SIOS LifeKeeper dan/atau SIOS DataKeeper) memengaruhi desain lingkungan tempat mereka digunakan. Meskipun pola-pola ini diperkenalkan karena adanya lingkungan yang dilindungi oleh LifeKeeper dan DataKeeper, SIOS LifeKeeper dan SIOS DataKeeper dengan cermat memilih pola-pola yang digunakan untuk memastikan bahwa pola-pola ini memungkinkan abstraksi dan modularitas dalam solusi secara keseluruhan. Sebagai hasil dari abstraksi berlapis yang dimungkinkan oleh LifeKeeper dan DataKeeper, pengenalan utilitas ini memfasilitasi integrasi dengan infrastruktur TI yang mempertahankan kohesi dalam desain solusi.

Sebagai hasil dari pola desain yang digunakan, klaster yang dilindungi oleh SIOS Protection Suite (LifeKeeper dan/atau DataKeeper) membentuk elemen abstrak dan modular yang terintegrasi dengan mulus ke dalam desain dan solusi yang ada. LifeKeeper dan DataKeeper melakukan lebih dari sekadar menyederhanakan administrasi sistem tunggal atau masing-masing klaster; LifeKeeper dan DataKeeper bekerja dengan prinsip-prinsip yang berlaku dalam sebuah implementasi.

Pembuatan infrastruktur menjadi lebih sederhana dan efisien karena penggunaan SIOS Protection Suite memungkinkan metode yang mudah untuk memahami peran sistem dalam desain, sekaligus menyediakan metode sederhana untuk mengimplementasikan Ketersediaan Tinggi dan Pemulihan Bencana. Administrator dapat menggunakan LifeKeeper dan DataKeeper sebagai alat untuk meningkatkan kemampuan mereka dalam memahami, mengoperasikan, dan meningkatkan solusi untuk tahun-tahun mendatang.

Lihat bagaimana ketersediaan tinggi dapat mendukung desain infrastruktur Anda—tanpa menambah kerumitan.Minta demo hari ini!

Penulis: Philip Merry, CX Software Engineer di SIOS

Direproduksi dengan izin dariSIOS

Peran Penting Lingkungan QA dan Produksi dalam Ketersediaan Tinggi

Untuk tim TI yang mengelola aplikasi modern danMempertahankan ketersediaan yang tinggiMeskipun meluncurkan pembaruan bisa menjadi tantangan, bagian integral untuk mencapai keandalan adalah pemisahan lingkungan Jaminan Kualitas (QA) dan produksi. Meskipun mungkin tampak seperti praktik sepele, hal ini penting untuk mendeteksi potensi masalah dan menanamkan kepercayaan pada tugas pemeliharaan.

Lingkungan QA sebagai Tempat Pengujian untuk Ketersediaan Tinggi

Lingkungan QA berfungsi sebagai replika dari lingkungan produksi. Ini menyediakan lingkungan uji coba (sandbox) tempat fitur baru, perubahan konfigurasi, dan patch dapat diuji secara menyeluruh. Selain pengujian fungsional, lingkungan QA memungkinkan validasi proses, pengukuran kinerja, pengujian beban, dan validasi keamanan.

Ini adalah aktivitas penting untuk mengidentifikasi hambatan, kerentanan, atau masalah integrasi sebelum hal tersebut berdampak pada pengguna akhir atau membahayakan lingkungan Anda. Untuk sistem terdistribusi atauarsitektur awanLingkungan QA dapat membantu mensimulasikan latensi jaringan, penundaan replikasi basis data, dan kasus-kasus ekstrem operasional lainnya yang dapat mengganggu operasional bisnis jika tidak diuji.

Lingkungan Produksi dan Pengalaman Pengguna Akhir

Lingkungan produksi adalah tempat pengguna akhir bergantung pada sistem untuk berkinerja secara konsisten. Setiap waktu henti atau kegagalan yang tidak direncanakan dapat memiliki konsekuensi bisnis langsung, mulai dari hilangnya pendapatan hingga kerusakan reputasi.

Dengan memisahkan lingkungan produksi dari pengembangan dan pengujian yang sedang berlangsung, tim TI dapat memastikan stabilitas operasional. Lingkungan produksi yang dikonfigurasi dengan benar harus mencakup hal-hal berikut.strategi redundansi, mekanisme failover, dan alat pemantauan yang telah divalidasi melalui pengujian di lingkungan QA sebelum diterapkan.

Transisi yang Lancar Melalui Alur Implementasi yang Terstruktur

Ketersediaan tinggi tidak hanya tentang menjaga sistem tetap berjalan. Ini juga dapat mencakup membuat pembaruan dapat diprediksi. Lingkungan QA dapat mendukung alur kerja penerapan yang terstruktur, memungkinkan berbagai strategi seperti peluncuran bertahap dan rilis biru-hijau. Prosedur pengembalian (rollback), yang telah divalidasi sebelumnya di QA, memungkinkan tim untuk pulih dengan cepat jika masalah tak terduga muncul. Pendekatan terstruktur membuat pembaruan dapat diprediksi dan membantu menjaga kepercayaan pelanggan.

Manfaat Operasional dari Pemisahan Lingkungan QA dan Produksi

Memiliki lingkungan QA dan produksi yang terpisah juga dapat mendukung kepatuhan, kesiapan audit, dan koordinasi antar tim. Batasan yang jelas antara pengujian dan sistem yang berjalan dapat membantu tim operasional dan pengembangan berkolaborasi secara efisien. Hal ini juga membantu menyediakan kerangka kerja yang dapat diulang untuk pemantauan, pemecahan masalah, danperencanaan pemulihan bencana.

Lingkungan QA dan Produksi dalam Strategi Ketersediaan Tinggi

Lingkungan QA dan produksi memainkan peran penting dalam menjaga agar sistem berjalan lancar. Dengan memisahkan lingkungan, melakukan pengujian secara menyeluruh, dan mengelola penyebaran dengan hati-hati, tim TI dapat mengurangi waktu henti, mempertahankan ketersediaan tinggi, dan membuat transisi antar pembaruan menjadi lancar. Praktik-praktik ini membantu memastikan sistem tetap andal dan tangguh seiring perkembangannya.

Siap meningkatkan ketersediaan tinggi di seluruh lingkungan QA dan produksi?Minta demountuk melihat bagaimana SIOS membantu tim menerapkan pembaruan dengan percaya diri dan menjaga agar sistem penting tetap berjalan.

Penulis: Tristan Allen, Associate Customer Experience Software Engineer di SIOS Technology

Diterbitkan ulang dengan izin dari SIOS .

Bahaya Mematikan, Menghidupkan Kembali: Berpikir dalam Ketersediaan Tinggi

“Matikan, lalu hidupkan kembali.” Siapa pun yang pernah berpengalaman memecahkan masalah komputer pasti pernah mendengar saran ini. Saran ini terkenal sebagai solusi teknologi yang paling umum, dan mampu mengubah siapa pun menjadi ahli pemecah masalah TI. Masalahnya adalah, ini sebenarnya bukanlah solusi sebenarnya; ini hanya kebetulan menyelesaikan sebagian besar masalah. Dengan mematikan dan menghidupkannya kembali, kita dengan cepat dapat kembali beroperasi, tetapi kita tidak pernah benar-benar mengetahui apa masalah sebenarnya sejak awal.

Mengapa “Mematikan dan Menghidupkan Kembali” Berisiko dalam Sistem Ketersediaan Tinggi

Selain itu, dalam dunia ketersediaan tinggi, “mematikannya” bisa menjadi masalah besar. Bahkan hanya beberapa menit sajawaktu hentiHal ini bisa menjadi masalah besar bagi perusahaan yang harus memastikan infrastruktur kritis mereka tetap beroperasi. Karena itu, sebagai tim dukungan teknis di SIOS, kami jarang memberikan saran teknis yang terkenal buruk ini, tetapi kami memiliki versi kami sendiri.

Banyak yang telah menghubungi dukungan teknis di SIOS untukWindows DataKeeperJika mengalami masalah mirroring, Anda mungkin akan disarankan untuk menjalankan perintah “cleanupmirror.” Dalam situasi yang tepat, perintah ini sangat bagus untuk membantu seseorang mengatasi masalah besar dengan cepat. Perintah ini pada dasarnya menghapus konfigurasi mirror dan semua sisa-sisa yang mungkin ada, sehingga kita dapat membuat mirror baru, bebas dari masalah apa pun yang sebelumnya mengganggunya. Perlu dicatat bahwa ini sebenarnya tidak menghapus data apa pun, hanya replikasi antar sistem.

Perintah ini tidak memerlukan waktu henti, tetapi berarti sistem tidak akan memiliki ketersediaan tinggi hingga proses sinkronisasi ulang mirror selesai. Ini adalah salah satu langkah pemecahan masalah andalan kami dalam dukungan teknis, tetapi seperti “matikan, lalu hidupkan kembali,” terkadang hal ini dapat menyembunyikan masalah mendasar yang lebih serius, dan terkadang bisa berlebihan.

Hari ini, saya ingin membahas salah satu kasus di mana menjalankan cleanupmirror berhasil mengatasi masalah mendesak bagi pelanggan, tetapi hampir membuat kami melewatkan masalah yang cukup serius, yang dapat memengaruhi banyak pelanggan, namun memiliki solusi dan perbaikan yang sangat mudah.

Masalah Mirroring DataKeeper di Dunia Nyata Selama Migrasi

Ketika tim dukungan bergabung, pelanggan sudah cukup lama mencoba mengatasi masalah ini, dan mereka mulai panik. Mereka sedang melakukan upaya terakhir mereka.peralihanPengujian sedang dilakukan sebagai bagian dari migrasi mereka ketika mirroring DataKeeper mulai mengalami masalah. Pada titik ini, infrastruktur penting mereka mengalami gangguan, dan mereka khawatir hal itu akan mulai memengaruhi bisnis mereka. Ini adalah situasi yang sangat menegangkan, tetapi untungnya, para insinyur dukungan di sini melakukan pekerjaan yang sangat baik. Mereka menyeimbangkan tekanan, ketergesaan, dan kebutuhan untuk menemukan solusi yang baik, dan menjalankan perintah “cleanupmirror” yang sudah teruji dan terbukti, diikuti dengan pembuatan ulang mirror agar berfungsi dengan baik. Mereka menyelamatkan pelanggan dari kesulitan, dan semua orang melanjutkan pekerjaan. Untungnya, mereka juga meminta pelanggan untuk mengirimkan log, “sebagai tindakan pencegahan.”

Catatan dalam kasus ini agak membingungkan. Catatan tersebut menunjukkan bahwasebuah volume telah diubah ukurannyaNamun, pelanggan mengklaim bahwa mereka tidak melakukan aktivitas pengubahan ukuran apa pun selama panggilan tersebut. Terkadang pelanggan lupa menyampaikan informasi penting, jadi kami mengira mungkin mereka lupa menyebutkan detail tersebut dalam panggilan, tetapi pengubahan ukuran tersebut tidak masuk akal. Perubahan ukurannya sangat kecil, dan terjadi pada semua volume secara bersamaan dengan peralihan pertama. Tidak masuk akal bagi pelanggan untuk mengubah ukuran terabyte drive besar mereka dengan mengurangi kurang dari satu gigabyte sekaligus, tepat pada saat yang bersamaan dengan peralihan pertama, jadi kami menyelidiki lebih dalam. Ternyata drive target sedikit lebih besar daripada drive sumber, dan ada masalah pada produk kami terkait cara penanganan ukuran drive yang tidak sesuai.

Mengidentifikasi Akar Penyebab Mencegah Terulangnya Waktu Henti

Setelah kami menemukan solusinya, kami menyadari bahwa yang dibutuhkan untuk menyelesaikan masalah ini hanyalah melanjutkan mirroring. Ini adalah operasi umum, cepat, dan mudah yang hanya membutuhkan beberapa detik untuk memperbaiki masalah sepenuhnya. Tidak perlu sinkronisasi ulang berhari-hari sebelum kami kembali memiliki ketersediaan tinggi. Selain itu, setelah kami menemukan masalah ini, perbaikannya sangat cepat dan mudah untuk diimplementasikan pada versi produk berikutnya.

Ternyata pelanggan tersebut memiliki skenario migrasi yang unik, yang mengharuskan mereka untuk membuat target sedikit lebih besar, karena menyamakan ukurannya tidak mungkin dilakukan. Mereka masih memiliki beberapa sistem yang belum dimigrasikan, dan jika kami hanya menyelesaikan kasus ini dengan “cleanupmirror,” mereka akan menghadapi masalah ini setiap kali. Karena kami menemukan akar penyebabnya, kami dapat memberi mereka solusi cepat dan mudah, dan bahkan tindakan pencegahan yang lebih cepat yang dapat mereka lakukan sebelum menjalankan peralihan pertama. Kami juga dapat mempublikasikan solusi, sehingga pelanggan berikutnya yang mengalami masalah ini dapat menyelesaikannya dalam hitungan menit.

Mengapa Analisis Akar Penyebab Penting dalam Ketersediaan Tinggi?

Jadi, apa masalah besar dengan “matikan, lalu hidupkan kembali”? Itu menyembunyikan akar permasalahan. Jadi, apakah itu berarti Anda tidak boleh menggunakannya sama sekali? Itu masih merupakan salah satu saran teknologi terbaik yang ada. Seringkali, Anda sebenarnya tidak perlu tahu apa akar permasalahannya, dan mematikan lalu menghidupkannya kembali akan membantu Anda keluar dari masalah dengan sangat cepat.

Hal terpenting bagi seorang profesional TI adalah, ketika Anda tidak perlu segera keluar dari situasi sulit dan memiliki waktu luang untuk menyelidiki terlebih dahulu, Anda harus melakukannya. Jika tidak, Anda harus kembali lagi nanti dan melihat log untuk mencoba mencari tahu apa yang terjadi.

Jadi, silakan matikan dan hidupkan kembali sesuka hati Anda. Jadilah pesulap yang memecahkan satu masalah dalam hitungan menit, dan buat semua orang bertanya-tanya bagaimana Anda melakukannya. Tapi… sesekali… luangkan waktu untuk kembali dan mencari tahu mengapa Anda perlu mematikan dan menghidupkannya kembali… dan pertimbangkan kemungkinan bahwa mungkin ada solusi yang lebih mudah.

Untuk mempelajari lebih lanjut tentang bagaimana SIOS DataKeeper dan solusi ketersediaan tinggi dapat membantu Anda menghindari masalah tersembunyi seperti ini,minta demodari tim kami hari ini.

Penulis: Carter Chandler, CX Associate, Insinyur Perangkat Lunak di SIOS Technology

Direproduksi dengan izin dariSIOS