Satu-satunya cara terbaik untuk menyebarkan kuorum/saksi

Satu-satunya cara terbaik untuk menyebarkan kuorum/saksi

Selama pertemuan baru-baru ini, pelanggan mengajukan pertanyaan tentang Ketersediaan Tinggi (HA) dan kebutuhan kelayakan kuorum/saksi. Pertanyaan mereka adalah, “Apa cara terbaik untuk menyebarkan kuorum/saksi?” Jawaban atas pertanyaan mereka sederhana, tidak ada satu pun cara terbaik untuk menerapkan kuorum.Untuk memahami alasannya, mari kita mulai dengan mendefinisikan tiga hal utama: apa yang dimaksud dengan sumber saksi, sumber kuorum, dan skenario otak terbelah.

Apa itu otak terbelah?

Dalam lingkungan cluster normal, aplikasi yang dilindungi berjalan pada node utama di cluster.Jika terjadi kegagalan aplikasi pada node utama tersebut, perangkat lunak pengelompokan memindahkan operasi aplikasi ke node sekunder atau remote, yang mengambil peran utama. Pada waktu tertentu, hanya ada satu simpul utama.

Split brain adalah suatu kondisi yang terjadi ketika anggota cluster tidak dapat berkomunikasi satu sama lain, tetapi dalam keadaan berjalan dan beroperasi, dan kemudian mengambil kepemilikan sumber daya bersama secara bersamaan. Akibatnya, Anda memiliki dua pengemudi bus yang memperebutkan kemudi.Otak terbelah, karena sifatnya yang merusak, dapat menyebabkan kehilangan data atau kerusakan data dan sebaiknya dihindari melalui penggunaan fungsi anggar, kuorum, saksi, atau kuorum/saksi untuk arbitrase klaster.

Di sebagian besar manajer klaster, kuorum dipertahankan ketika:

1. Semua server dapat melihat status yang sama untuk semua rekan cluster dan saksi
2. Semua server dapat melihat status yang sama untuk semua rekan cluster, meskipun bukan saksinya
3. Semua server dapat melihat sumber saksi, meskipun tidak satu sama lain, dan menghindari skenario otak terbelah

Di sebagian besar manajer klaster, kuorum hilang ketika:

1. Server tidak dapat melihat semua rekan cluster dan server saksi
2. Server tidak dapat melihat sebagian besar rekan cluster, meskipun mereka dapat melihat server saksi
3. Server tidak dapat mengakses atau mempertahankan akses ke sumber daya kuorum untuk berhasil menengahi keanggotaan kuorum dan akses sumber daya

Apa itu sumber daya saksi (atau server)?

Sumber daya saksi adalah server, titik akhir jaringan, atau perangkat yang digunakan untuk mencapai dan mempertahankan kuorum ketika sebuah cluster memiliki jumlah anggota yang genap.Sebuah cluster dengan jumlah anggota ganjil, menggunakan mayoritas cluster, tidak perlu menggunakan sumber daya saksi karena semua anggota server cluster menengahi keanggotaan mayoritas.

Apa yang dimaksud dengan kuorum dan sumber kuorum?

Sumber daya kuorum adalah sumber daya (perangkat, sistem, penyimpanan blok, penyimpanan file, berbagi file, dll) yang berfungsi sebagai sarana untuk arbitrase status dan keanggotaan cluster.Di beberapa manajer klaster, kuorum adalah sumber daya di dalam klaster yang membantu atau diperlukan untuk setiap status klaster dan keputusan keanggotaan klaster.Di manajer klaster lain, kuorum berfungsi sebagai pemutus ikatan untuk menghindari perpecahan otak.

Lebih dari Satu Cara untuk Menyebarkan Kuorum

Mengingat sifat kritis kuorum, arsitektur HA sangat penting untuk menyebarkan sumber daya kuorum/saksi dengan benar, dan untungnya (atau sayangnya) tidak ada satu pun , cara terbaik untuk menerapkan kuorum.Ada beberapa faktor yang dapat membentuk cara di mana saksi dan sumber-sumber kuorum Anda berperilaku.Faktor-faktor ini meliputi:

1. Apakah penerapan Anda akan dilakukan di tempat, cloud, atau hybrid

Menyebarkan di pusat data lokal di mana perangkat penyimpanan tambahan, seperti penyimpanan saluran serat, perangkat atau koneksi kontrol daya, atau perangkat stonith tradisional hadir akan memberi pelanggan opsi tambahan untuk fungsi kuorum dan saksi yang mungkin tidak berada di cloud.Demikian pula, lingkungan cloud dan hibrid menghadirkan perbedaan dalam hal apa yang dapat diterapkan dan kuorum kasus penggunaan apa yang diterapkan untuk dicegah. Selain itu, persyaratan dan perbedaan latensi dapat membatasi jenis perangkat dan sumber daya apa yang tersedia untuk konfigurasi kuorum/saksi.  

2. Tujuan pemulihan Anda

Tujuan pemulihan juga penting untuk dipertimbangkan saat merancang dan merancang sumber daya kuorum dan saksi Anda.Dalam contoh dua cluster node (node A dan node B), ketika node A mengalami kehilangan konektivitas ke node B, apa prioritas tertinggi untuk pemulihan. Jika sumber saksi/kuorum berada dalam jaringan yang sama dengan simpul A, ini dapat mengakibatkan simpul A tetap online, tetapi terputus dari klien, sementara simpul B tidak dapat menilai kuorum dan pengambilalihan.Demikian juga, jika perangkat kuorum hanya hidup di wilayah, pusat data, atau jaringan dengan node B, kehilangan dapat mengakibatkan kegagalan sumber daya ke jaringan atau pusat yang mati atau jauh dari node utama yang berfungsi dan beroperasi.

3. Redundansi Pusat Data (atau Wilayah) yang Tersedia Dalam Infrastruktur Anda

Redundansi pusat data atau wilayah juga merupakan faktor penting dalam topologi HA Anda dengan kuorum/saksi. Jika pusat data Anda hanya memiliki dua tingkat redundansi, Anda harus memahami keseimbangan antara penempatan kuorum/saksi di pusat data yang sama dengan node cluster utama atau standby. Jika pusat data memiliki lebih dari dua tingkat redundan, seperti zona ketersediaan ketiga atau akses ke wilayah kedua, opsi ini akan memberikan tingkat redundansi yang lebih tinggi untuk cluster.

4. Persyaratan Pemulihan Bencana

Memahami persyaratan pemulihan bencana Anda yang sebenarnya juga merupakan faktor utama dalam desain Anda. Jika perangkat lunak manajer klaster Anda memerlukan akses ke kuorum/saksi untuk memulihkan dari pemadaman pusat data total (atau kegagalan wilayah), maka Anda harus memahami dampak ini pada desain Anda.Banyak paket perangkat lunak ketersediaan tinggi memiliki alat atau metode untuk skenario ini, tetapi jika perangkat lunak Anda tidak, desain dan penempatan kuorum/saksi Anda mungkin perlu mengakomodasi kenyataan ini.

5. Jumlah Anggota Dalam Cluster, dan Lokasi Mereka

Server kuorum/saksi tambahan biasanya tidak diperlukan ketika cluster berisi jumlah node yang ganjil.Namun, jika hanya menggunakan dua node dalam sebuah cluster atau menggunakan node DR yang tidak selalu tersedia dapat mengubah arsitektur Anda.Sebagai Wakil Presiden Pengalaman Pelanggan, saya telah bekerja dengan pelanggan yang telah menerapkan tiga arsitektur simpul, tetapi untuk penghematan biaya, mereka mengotomatiskan penghentian berkala server ketiga.

6. Sistem Operasi dan Manajer Cluster

Faktor terakhir yang disebutkan dalam kuorum/saksi adalah pengelola klaster dan sistem operasi.Tidak semua perangkat lunak HA dan manajer cluster sama dalam hal penyebaran kuorum/saksi atau arbitrase status kuorum.Beberapa perangkat lunak pengelompokan memerlukan disk bersama untuk arbitrase, yang lain lebih fleksibel memungkinkan pembagian (NFS, SMB, EFS, File Azure, dan S3).Menyadari apa yang dibutuhkan manajer klaster Anda, dan mode yang didukungnya terkait dengan kuorum (mayoritas sederhana, saksi, berbagi file, dll.) tidak hanya akan memengaruhi apa yang Anda terapkan, tetapi juga bagaimana Anda menerapkannya.

Satu-satunya cara terbaik untuk menyebarkan server kuorum/saksi adalah dengan memahami definisi vendor Anda tentang kuorum/saksi dan opsi yang tersedia, mengetahui kebutuhan Anda, mempertimbangkan keterbatasan atau peluang yang disajikan oleh pusat data Anda (atau lingkungan cloud) dan merancang solusinya yang memberikan sistem kritis Anda tingkat perlindungan tertinggi terhadap otak terbelah, kegagalan palsu, dan waktu henti.

-Cassius Rhee, Wakil Presiden, Pengalaman Pelanggan

Mengukur dan Meningkatkan Performa Throughput Tulis di GCP Menggunakan SIOS DataKeeper untuk Windows

Mengukur dan Meningkatkan Performa Throughput Tulis di GCP Menggunakan SIOS DataKeeper untuk Windows

Latar belakang

Postingan ini berfungsi untuk mendokumentasikan temuan saya di GCP terkait performa penulisan ke disk yang direplikasi ke GCP. Tapi pertama-tama, beberapa informasi latar belakang. Seorang pelanggan menyatakan keprihatinannya bahwa DataKeeper menambahkan sejumlah besar overhead ke kinerja tulis mereka saat menguji dengan cermin sinkron antara Google Zones di wilayah yang sama. Tes asli yang mereka lakukan adalah dengan file bitmap pada drive C, yang merupakan SSD persisten. Dalam konfigurasi ini mereka hanya mendorong sekitar 70 MBps. Mereka mencoba merelokasi bitmap ke disk GCP ekstrem, tetapi performanya tidak meningkat.

Memindahkan Bitmap ke SSD Lokal

Saya menyarankan agar mereka memindahkan bitmap ke SSD lokal, tetapi mereka ragu-ragu karena mereka percaya disk ekstrim yang mereka gunakan untuk bitmap memiliki latensi dan throughput yang sama baiknya atau lebih baik daripada SSD lokal, jadi mereka ragu itu akan membuat perbedaan. Selain itu, menambahkan SSD lokal bukanlah tugas sepele karena hanya dapat ditambahkan saat VM awalnya disediakan.

Memilih Jenis Instance

Saat saya mulai menyelesaikan tugas saya, hal pertama yang saya temukan adalah tidak semua jenis instans mendukung SSD lokal. Misalnya, E2-Standard-8 tidak mendukung SSD lokal. Untuk pengujian pertama saya, saya memilih jenis instans C2-Standar-8, yang dianggap “dioptimalkan untuk komputasi”. Saya memasang SSD persisten 500 GB dan mulai menjalankan beberapa tes kinerja tulis dan dengan cepat menemukan bahwa saya hanya bisa membuat disk menulis sekitar 140MBps daripada kecepatan maksimal 240MBps. Pelanggan mengkonfirmasi bahwa mereka melihat hal yang sama. Itu membingungkan, tetapi kami memutuskan untuk melanjutkan dan mencoba jenis instance yang berbeda.

Jenis instans kedua yang kami pilih adalah N2-Standar-8. Dengan jenis instans ini, kami dapat mendorong disk ke kecepatan throughput maksimum 240 MBps saat tidak mereplikasi disk. Saya memindahkan bitmap ke SSD lokal yang telah saya sediakan dan mengulangi tes yang sama pada mirror sinkron (DataKeeper v8.8.2) dan mendapatkan hasil yang ditunjukkan di bawah ini.

Hasil

Parameter uji diskspd diskspd.exe -c96G -d10 -r -w100 -t8 -o3 -b64K -Sh -LD:data.dat diskspd.exe -c96G -d10 -r -w100 -t8 -o3 -b8K -Sh -LD:data .dat diskspd.exe -c96G -d10 -r -w100 -t8 -o3 -b4K -Sh -LD:data.dat

MBps

Data

Kesimpulan

Ukuran tulis 64k dan 4k semuanya dikenakan overhead yang dapat dianggap sebagai "dapat diterima" untuk replikasi sinkron. Ukuran tulis 8k tampaknya menimbulkan jumlah overhead yang lebih signifikan, meskipun latensi rata-rata 3,183 ms masih cukup rendah.

-Dave Bermingham, Direktur, Keberhasilan Pelanggan Direproduksi dengan izin dari SIOS

Bagaimana COVID-19 Mempengaruhi Ketersediaan Tinggi

Bagaimana COVID-19 Mempengaruhi Ketersediaan Tinggi

Dibandingkan dengan teman, keluarga, dan mereka yang membutuhkan perawatan, rawat inap, atau perawatan intensif, gejala COVID saya ringan. Ini kemungkinan merupakan hasil dari kesehatan yang cukup baik, baik dosis vaksin, suntikan booster, maupun deteksi dini dan pengobatan.Dan, hati saya untuk setiap keluarga yang kehilangan orang yang dicintai karena aspek apa pun dari pandemi ini, dan untuk semua orang yang kehilangan kesempatan dan momen spesial.Saat saya dan beberapa anggota tim SIOS kami pulih dari COVId-19, kami ingin membagikan lima hal yang mungkin dihadapi Tim TI Anda saat mereka memerangi COVID dan waktu henti perusahaan, dan lima hal yang dapat Anda lakukan untuk membantu mereka.

Lima Kekhawatiran COVID Menghadapi Tim IT

1. Kekhawatiran dan Ketakutan Pribadi dan Keluarga

   Awalnya, gejala saya hampir tidak terlihat, sedikit iritasi di tenggorokan, dan sedikit drainase sinus, yang saya diagnosa sendiri sebagai alergi musiman.Tetapi ketika masalahnya memburuk, disertai dengan batuk yang parah, saya menjadi khawatir.Tentu saja, kita semua ingin berpikir bahwa kinerja dan tanggung jawab kerja kita tetap tidak berubah, tetapi kenyataannya mungkin sedikit lebih sulit untuk dinilai. Meskipun tes awal negatif, saya terus mengembangkan gejala yang akhirnya memengaruhi kemampuan saya untuk bekerja, meningkatkan masalah kesehatan pribadi saya, dan menimbulkan sejumlah ketakutan. Jika tim Anda terkena dampak langsung COVID-19, pahami bahwa mereka kemungkinan besar menghadapi kekhawatiran, ketakutan, dan kekhawatiran pribadi di samping tantangan kesehatan nyata yang dapat memengaruhi jadwal, tugas, dan aktivitas mereka. Kekhawatiran masing-masing anggota tim kemungkinan juga berurusan dengan kekhawatiran yang lebih besar, yaitu kekhawatiran tentang keluarga.Selama sakit saya, untungnya, anak-anak saya semua tetap sehat.Namun, istri saya tidak seberuntung itu.Dia jatuh sakit tiga hari setelah gejala saya dan tetap sakit lebih lama dan dengan gejala dan kemunduran yang lebih parah.Meskipun kami memiliki keuntungan berupa unit keluarga besar, pengemudi remaja berlisensi, dan mobil tambahan yang tidak dikemudikan oleh orang tua yang positif COVID, tim Anda mungkin tidak memiliki kemewahan ini.Dan bahkan jika mereka melakukannya, itu tidak memberi mereka kebebasan dari kekhawatiran atau mengurangi jumlah waktu dan energi mental yang mereka butuhkan untuk membersihkan rumah, menjaga anak-anak mereka di sekolah dan sehat, dan berurusan dengan peraturan, mandat, dan kontak dekat. masalah.Belum lagi masalah pendapatan dan pengeluaran.Anggota tim menghadapi masalah pribadi dan keluarga mungkin mengalami kesulitan berkonsentrasi, pemarah, dan kesulitan memenuhi tenggat waktu dan jadwal.

2. FODO – Takut Mengecewakan Orang Lain

   Bahkan tanpa penyakit COVID-19, bisnis di seluruh dunia merasakan dampak dari tenaga kerja yang lebih kecil.Peristiwa yang dengan tepat digambarkan sebagai “Pergeseran Besar”, “Pengunduran Diri Hebat”, atau “Perombakan Hebat” telah secara dramatis membentuk kembali tenaga kerja, termasuk yang berurusan dengan HA, membuat tim dengan lebih sedikit orang untuk melakukan tugas-tugas penting. Defisit anggota tim ini dapat membuat mereka yang mengidap COVID melawan Fear of Disappointing Others (FODO).Anggota tim yang sakit mungkin terus mencoba bekerja karena kesetiaan kepada tim atau takut mengecewakan bos, rekan kerja, atau pemangku kepentingan.FODO ini sering menyebabkan pekerja yang sudah berfungsi di lingkungan yang stres (lihat #1 dan 2 di atas) untuk berusaha mempertahankan tingkat aktivitas sebelum COVID. Meskipun heroik, itu juga kontraproduktif dengan pemulihan pribadi dan profesional.

3. Kelelahan

   Saat saya terus menghadapi gejala COVID-19, salah satu masalah terbesar yang terus saya hadapi adalah kelelahan.Awalnya, kelelahan yang didorong oleh FODO itu membuat saya tidak bisa istirahat dan pemulihan yang cukup.Karena saya telah melihat bagaimana tim kami kekurangan tenaga dan menyaksikan orang lain mencoba melawan penyakit mereka untuk memenuhi permintaan, saya mencoba melakukan hal yang sama.Tapi, tanpa peringatan saya mendapati diri saya terkuras, bukan di penghujung hari, tetapi selama beberapa waktu sepanjang hari.Bagi saya, memulai hari sebelum jam 5 pagi dan terus fokus pada pekerjaan, tugas, strategi, dan masalah personalia selama 8 hingga 12 jam adalah hal biasa.(Kita bisa berdebat nanti jika itu sehat). Sekarang beberapa orang merasa ingin mendaki Everest sebelum jam 8 pagi.Saran terbaik yang saya terima adalah dari seorang teman dan rekan kerja yang berkata, “Jangan melawannya. Saat tubuhmu berkata istirahat, istirahatlah!”

4. Kabut Otak

   Sekitar waktu yang sama ketika saya mulai merasa sakit, seorang rekan berbagi bahwa mereka merasa seperti berada dalam kabut setelah serangan mereka dengan gejala COVID. Seperti saya, mereka divaksinasi lengkap dan gejala serta durasinya ringan. Padahal, mereka sebenarnya tidak pernah dinyatakan positif.Namun demikian, mereka menghabiskan berhari-hari dengan apa yang kami berdua sebut sebagai "kabut otak". Pengalaman yang kami gambarkan sebagai kelambatan untuk mengingat detail, rasa mengetahui jawabannya, tetapi kurang ketajaman mental yang entah bagaimana berbeda dari kelelahan fisik dan kelelahan mental.Dalam beberapa kasus, ini muncul sebagai respons yang lebih lambat untuk sebuah pertanyaan, jeda dalam penekanan tombol, atau penundaan sebelum lampu menyala di dalam ruangan.

5. Pemulihan Gagal

   Lima hari setelah COVID, saya bangun dari istirahat malam dengan perasaan lebih baik dari sebelumnya. Saya melompat ke rutinitas rutin saya dan pada siang hari menemukan bahwa saya belum sepenuhnya pulih.Sebaliknya saya menghabiskan sedikit energi yang diperoleh dengan tidur nyenyak malam sebelumnya.Mencoba melawan kelelahan ini menciptakan kemunduran baru dalam pemulihan saya.Hari berikutnya saya merasa lebih buruk dari sebelumnya.Penderitaan dari pemulihan yang gagal dan kekhawatiran tentang bagaimana menghindari lebih banyak kemunduran ditambahkan ke kelelahan dan kabut saya.

Jadi, apa yang harus dilakukan oleh tim TI, pemangku kepentingan, dan manajer ketika tim mereka mengalami masalah dengan COVID-19.

Lima Cara untuk Membantu Tim IT Memerangi COVID

1. Berlatih Empati

   Ingatlah bahwa COVID memengaruhi setiap orang dan keluarga secara berbeda.Beberapa rekan kerja dan administrator Anda akan mengalami masalah kecil, tanpa gejala, dan tanpa komplikasi.Sementara yang lain, orang tua tunggal, keluarga multi-generasi, atau keluarga dengan anak-anak atau orang-orang yang rentan akan memiliki lebih banyak masalah dan kekhawatiran.Ketahuilah bahwa virus juga berdampak pada setiap orang secara unik.Bahkan di dalam keluarga saya sendiri, gejala saya dan gejala istri saya berbeda.Sementara saya mengalami kelelahan yang lebih besar, dia mengalami lebih banyak sakit kepala. Bersabarlah untuk rekan kerja yang mungkin menghadapi kabut otak, menyulap jadwal kerja, merawat orang tersayang yang sakit, atau menghadapi segudang masalah terkait COVID.

2. Menilai kebutuhan

   Berbeda dengan flu atau flu biasa, pemulihan COVID tidak teratur. Seorang anggota tim mungkin muncul di tempat kerja suatu hari merasa jauh lebih baik dan tinggal di rumah sakit pada hari berikutnya. Bisnis Anda masih memiliki kebutuhan dan persyaratan teknis untuk ketersediaan tinggi dan pemulihan bencana.Namun, dengan orang yang masuk dan keluar dari ketersediaan karena sakit, pastikan untuk memahami peran dan tanggung jawab saat ini yang dibutuhkan dalam tim.Ketika seseorang sakit, pastikan untuk menilai peran mereka, dampaknya terhadap tim, tingkat tanggung jawab mereka terhadap infrastruktur, dll. Anda mungkin juga perlu menilai siapa di dalam tim atau organisasi yang dapat memberikan liputan jika terjadi peristiwa waktu henti yang kritis.

3. Prioritaskan masalah

   Bantu tim Anda dengan memprioritaskan masalah utama.Dalam keadaan normal, tim TI Anda menyeimbangkan lusinan permintaan mulai dari yang sepele (keyboard USB) hingga yang kritis (masalah yang terkait dengan waktu henti, ancaman keamanan, atau masalah penyimpanan).Meskipun mungkin terlihat jelas bagi Anda dan tim, pemangku kepentingan lain mungkin perlu memahami status tim TI dan bagaimana operasi akan ditangani hingga kembalinya ke staf yang lebih "normal" terjadi.

4. Pastikan Proses Anda mutakhir

   Saat anggota tim bertukar masuk dan keluar, sangat penting bahwa proses pemeliharaan dan manajemen TI selalu diperbarui.Proses ini akan membantu setiap anggota tim melayani perusahaan Anda secara efektif dan efisien saat melakukan tugas yang bukan merupakan tanggung jawab normal mereka. Ini juga akan mengurangi jumlah waktu yang dibutuhkan setiap anggota tim untuk meneliti status sistem yang mereka cakup sementara rekan kerja memulihkan diri.

5. Beri Orang Waktu

   Saya bergegas kembali ke rutinitas lebih dari yang seharusnya, hanya untuk menderita konsekuensi kemunduran dan kelelahan yang lebih besar pada hari berikutnya.Sebagai pemimpin atau kontributor individu dalam sebuah tim, pastikan untuk memberi diri Anda dan tim Anda waktu untuk "kembali normal."

Saat pandemi berlanjut, kita semua berharap untuk masa depan yang sangat menyerupai keadaan normal, termasuk lebih sedikit penyakit, ketakutan, dan kekhawatiran.Sementara itu, menjadi lebih sadar akan kekhawatiran yang dihadapi anggota tim Anda selama penyakit dan pemulihan COVID akan sangat membantu Anda secara proaktif mempersiapkan dan mengatasi badai saat ini.Selain itu, pelajaran utama yang dipetik dari pandemi ini dapat diterapkan di sejumlah organisasi lain, kehidupan karyawan, dan masalah global.

Direproduksi dengan izin dari SIOS

Cara Mendapatkan Hasil Maksimal dari Panggilan Dukungan Teknis Anda

Dua Kebenaran dan Kebohongan: Memahami Kebenaran Sejati Tentang Ketersediaan

Dua Kebenaran dan Kebohongan: Memahami Kebenaran Sejati Tentang Ketersediaan

Kami memainkan dua kebenaran dan kebohongan di acara perusahaan tahun lalu. Permainan melibatkan mengajukan dua pernyataan yang benar dan satu pernyataan yang tidak benar untuk melihat apakah Anda bisa menipu kebanyakan orang. Pemenang mengajukan ide-ide yang semuanya tampak dapat dipercaya atau tidak dapat dipercaya, tergantung pada sejarah pribadi Anda. Inilah yang dikatakan:

1. Saat tumbuh dewasa, kampung halaman saya tidak memiliki lampu lalu lintas.
2. Kakek-nenek saya bertemu di kelas dua dan menikah di usia remaja.
3. Setelah lulus, saya kuliah di universitas luar negeri yang bergengsi di Georgia sebelum pindah kembali ke rumah untuk kuliah di universitas negeri.

Saya tumbuh dalam komunitas kecil tanpa lampu lalu lintas, sehingga tampaknya mungkin, tetapi saya skeptis. Saya pernah mendengar cerita tentang orang-orang yang bertemu di usia dini, dan menikah di usia remaja, jadi itu mungkin tetapi juga salah satu yang mungkin ingin saya tandai. Yang ketiga juga tampaknya benar, tetapi saya bertanya-tanya siapa yang akan pindah dari universitas luar negeri yang bergengsi kembali ke kota asal tanpa lampu lalu lintas untuk kuliah di perguruan tinggi negeri. Untuk apa yang tampak seperti selamanya, seluruh kelompok beralasan dan merenungkan mana dari tiga pernyataan yang bohong.Dan, sepertinya tidak ada yang bisa melihatnya. Beberapa dari kami beralasan bahwa jika kampung halaman tidak memiliki lampu lalu lintas, apakah benar-benar ada universitas juga?Beberapa orang berpendapat bahwa kecil kemungkinannya dia kuliah di universitas luar negeri yang bergengsi, mengingat usianya, tahun-tahun di perusahaan itu, dan berbagai gelar.Setelah musyawarah akhir putusan itu, dua kebenaran itu nomor satu dan nomor dua.Kebohongan itu nomor tiga.

Dengan semua informasi yang berputar-putar tentang Ketersediaan Tinggi , Anda mungkin merasa seperti sedang memainkan permainan "Dua Kebenaran dan Kebohongan". Tergantung di mana Anda melihat, Anda mungkin menemukan pernyataan tentang ketersediaan yang tampaknya dapat dipercaya, tetapi tidak sepenuhnya benar saat Anda menggali lebih dalam.Misalnya, pernyataan yang diterima secara luas berikut ini sebenarnya tidak benar:

1. Ketersediaan penyimpanan adalah semua yang diperlukan untuk ketersediaan tinggi

   Aplikasi membutuhkan akses ke data agar efektif dan efisien.Basis data Anda perlu memiliki akses ke penyimpanan jika Anda ingin berhasil menjalankan perusahaan Anda.Aplikasi perusahaan Anda yang lain juga harus memiliki akses ke file konfigurasi, penyimpanan data, dan direktori log transaksi dan kesalahan agar dapat digunakan.Namun, sementara penyimpanan yang andal, mudah diakses, dan berkinerja sangat penting untuk semua sistem perusahaan, situs web, database, aplikasi, dan interkoneksi, penyimpanan yang tersedia saja tidak cukup untuk ketersediaan tinggi.Ada lebih banyak komponen yang membentuk arsitektur ketersediaan tinggi yang sehat, andal, dan tangguh daripada sekadar penyimpanan.

2. Ketersediaan platform adalah semua yang diperlukan untuk ketersediaan tinggi

   Dengan perkembangan dan pertumbuhan komputasi awan yang berkelanjutan, banyak perusahaan yang mencari ketersediaan tinggi bingung dengan konsep ketersediaan platform.Ketersediaan platform, kadang-kadang disebut sebagai ketersediaan sistem atau ketersediaan infrastruktur terkait dengan waktu platform (perangkat keras, jaringan, OS, dan komponen terkait) dapat diakses dan memberikan layanan TI yang diinginkan.Aplikasi dan database mutlak membutuhkan komputasi, memori, penyimpanan, dan sumber daya jaringan untuk beroperasi dengan baik dan efisien.Setiap layanan atau fungsi di pusat data Anda memerlukan tempat yang andal untuk menjalankan logikanya, dan tanpa platform yang mendasarinya, operasi ini tidak mungkin dilakukan.Karena itu, banyak yang menganggap bahwa ketersediaan platform adalah yang dibutuhkan untuk ketersediaan tinggi. Sebagai VP of Customer Experience, saya telah membantu pelanggan dan mitra memahami kesenjangan antara platform yang tersedia dan aplikasi, database, dan konektivitas klien yang tersedia.Dalam percakapan tersebut, kami telah membahas contoh nyata dari platform yang tidak menunjukkan waktu henti atau masalah layanan, sementara secara bersamaan aplikasi perusahaan yang berjalan di dalam pusat data atau infrastruktur cloud tersebut tidak tersedia, tidak stabil, atau tidak dapat diakses oleh klien karena masalah non-platform.

Jadi Apa Kebenaran Sejati?

Ketika rekan kerja kami membagikan tiga pernyataannya, kami semua salah.Kampung halamannya adalah komunitas kecil, perbatasannya disangga oleh kota-kota besar dengan lampu lalu lintas, tetapi kotanya sendiri tidak memilikinya sendiri. Dan, ternyata, dia lulus lebih awal dan pergi ke institut teknologi luar negeri yang terkenal dan bergengsi di Georgia, sebelum rindu kampung halaman dan pindah ke universitas negeri di kampung halamannya.Jadi kebohongannya adalah tentang kakek-neneknya.Meskipun mereka mungkin atau mungkin tidak bertemu pada usia dini, mereka pasti tidak bertemu di kelas dua.

Kebenaran tentang ketersediaan tinggi adalah bahwa ketersediaan penyimpanan dan ketersediaan platform atau infrastruktur tidak cukup dengan sendirinya.Untuk menciptakan infrastruktur ketersediaan tinggi yang paling kuat, tersedia, tangguh, dan andal, Anda juga harus menyertakan solusi tingkat komersial untuk menyediakan pemantauan, peringatan, dan pemulihan yang sadar aplikasi.Anda juga ingin solusi tersebut mengetahui kemampuan ketersediaan tinggi penyimpanan Anda, memiliki kesadaran yang kuat tentang nuansa dan kesenjangan infrastruktur, dan memiliki kemampuan untuk memanfaatkan praktik terbaik di seluruh arsitektur untuk membantu aplikasi, database, dan layanan Anda mencapai tujuan bisnis Anda.