Opsi untuk Saat Tingkat Layanan Cloud Publik Gagal

Mengelola Biaya Cloud untuk Aplikasi dengan Ketersediaan Tinggi

Biaya Cloud untuk Aplikasi dengan Ketersediaan Tinggi

Segera setelah kontrak dengan penyedia layanan cloud, tagihan tiba yang menyebabkan guncangan stiker. Ada tuduhan tak terduga dan tampaknya berlebihan. Mereka yang bertanggung jawab tampaknya tidak dapat menjelaskan bagaimana ini bisa terjadi. Situasi ini mendesak karena jumlahnya mengancam untuk menghancurkan anggaran TI kecuali perubahan penghematan biaya dilakukan segera. Jadi bagaimana kita mengelola Biaya Cloud untuk Aplikasi yang Ketersediaan Tinggi? Guncangan stiker layanan cloud ini sering disebabkan oleh aplikasi basis data mission-critical. Terutama ini cenderung menjadi yang paling mahal karena berbagai alasan. Aplikasi ini perlu dijalankan 24/7. Mereka membutuhkan redundansi, yang melibatkan replikasi data dan penyediaan instance server siaga. Replikasi data membutuhkan perpindahan data, termasuk lintas jaringan area luas (WAN). Dan menyediakan ketersediaan tinggi dapat menghasilkan biaya yang lebih tinggi untuk melisensikan Windows untuk mendapatkan Clustering Failover Windows Server (dibandingkan menggunakan open source Linux), atau untuk lisensi Enterprise Edition dari SQL Server untuk mendapatkan Grup Ketersediaan Selalu Ada. Sebelum menawarkan saran untuk mengelola Biaya Cloud untuk Aplikasi dengan Ketersediaan Tinggi, penting untuk dicatat bahwa tujuannya di sini bukan untuk meminimalkan biaya-biaya tersebut. Melainkan untuk mengoptimalkan harga / kinerja untuk setiap aplikasi. Dengan kata lain, adalah tepat untuk membayar lebih banyak ketika menyediakan sumber daya untuk aplikasi yang membutuhkan waktu kerja dan kinerja throughput yang lebih tinggi. Penting juga untuk dicatat bahwa infrastruktur cloud hybrid — dengan aplikasi yang berjalan secara keseluruhan atau sebagian di cloud pribadi dan publik — kemungkinan akan menjadi cara terbaik untuk mencapai harga / kinerja yang optimal.

Memahami Model Bisnis Dan Harga Penyedia Layanan Cloud

Pengalaman guncangan stiker menunjukkan perlunya memahami secara menyeluruh bagaimana harga layanan cloud dan mengelola Biaya Cloud untuk Aplikasi yang Ketersediaan Tinggi. Hanya dengan demikian layanan yang tersedia dapat digunakan dengan cara yang paling hemat biaya. Semua penyedia layanan cloud (CSP) mempublikasikan harganya. Kecuali ditentukan dalam perjanjian layanan, harga itu terus berubah. Semua sumber daya berbasis perangkat keras, termasuk komputasi fisik dan virtual, penyimpanan, dan layanan jaringan, pasti memiliki biaya langsung atau tidak langsung. Ini semua didasarkan sampai batas tertentu pada ruang, daya, dan pendinginan yang dikonsumsi sistem ini. Untuk perangkat lunak, open source umumnya gratis. Tetapi semua sistem operasi komersial dan / atau perangkat lunak aplikasi akan dikenakan biaya lisensi. Dan harus diingatkan sebelumnya bahwa beberapa perizinan perangkat lunak dan model penetapan harga bisa sangat rumit. Jadi pastikan untuk mempelajarinya dengan cermat. Selain biaya dasar untuk perangkat keras dan perangkat lunak, ada potensi biaya à la carte untuk berbagai layanan bernilai tambah. Ini termasuk ketentuan keamanan, keseimbangan beban, dan perlindungan data. Mungkin juga ada biaya "tersembunyi" untuk I / O untuk penyimpanan atau di antara layanan mikro terdistribusi, atau untuk pemanfaatan puncak yang jarang terjadi selama "semburan." Karena setiap CSP memiliki model bisnis dan harga yang unik, diskusi di sini harus digeneralisasi . Dan, secara umum, sumber daya yang paling mahal melibatkan komputasi, perizinan perangkat lunak, dan perpindahan data. Bersama-sama mereka dapat mencapai 80% atau lebih dari total biaya. Pergerakan data mungkin juga menimbulkan biaya WAN terpisah yang tidak termasuk dalam tagihan dari CSP. Penyimpanan dan jaringan dalam infrastruktur CSP biasanya merupakan sumber daya yang paling murah. Solid state drive (SSDs) biasanya berharga lebih dari media pemintalan berdasarkan per-terabyte. Tetapi SSD juga memberikan kinerja yang superior, sehingga harga / kinerjanya mungkin sebanding atau bahkan lebih baik. Dan walaupun memindahkan data kembali ke perusahaan bisa jadi mahal, memindahkan data dari perusahaan ke cloud publik biasanya dapat dilakukan dengan biaya gratis (terlepas dari biaya WAN yang terpisah).

Merumuskan Strategi Untuk Mengoptimalkan Harga / Kinerja

Menutup Biaya Cloud untuk Aplikasi yang Ketersediaan Tinggi membutuhkan pemeriksaan yang cermat. Berikut adalah beberapa saran untuk mengelola pemanfaatan sumber daya di cloud publik dengan cara yang dapat menurunkan biaya sambil mempertahankan tingkat layanan yang sesuai untuk semua aplikasi. Ini termasuk yang membutuhkan misi kritis, waktu kerja tinggi dan throughput. Secara umum, ukuran-kanan adalah prinsip dasar untuk mengelola pemanfaatan sumber daya untuk harga / kinerja yang optimal. Ketika Willie Sutton konon bertanya mengapa dia merampok bank, dia menjawab, "Karena di situlah uang itu berada". Di cloud, uang berada dalam sumber daya komputasi, sehingga harus menjadi prioritas tertinggi untuk ukuran-kanan. Untuk aplikasi baru, mulailah dengan konfigurasi mesin virtual minimal untuk sumber daya komputasi. Tambahkan inti CPU, memori dan / atau I / O hanya sesuai kebutuhan untuk mencapai kinerja yang memuaskan. Semua mesin virtual untuk aplikasi yang ada pada akhirnya harus berukuran tepat. Mulailah dengan yang paling mahal harganya. Kurangi alokasi secara bertahap sambil memantau kinerja terus-menerus hingga mencapai pengembalian yang menurun. Perlu dicatat bahwa risiko utama yang terkait dengan pengukuran-ukuran-kanan adalah potensi untuk kekurangan-ukuran. Namun itu dapat menghasilkan kinerja yang sangat buruk. Sayangnya, cara terbaik untuk menilai kinerja aktual aplikasi adalah dengan beban kerja produksi, menjadikan dunia nyata tempat yang tepat untuk ukuran yang tepat. Untungnya, cloud memitigasi risiko ini dengan membuatnya dengan mudah mengubah ukuran konfigurasi berdasarkan permintaan. Jadi ukuran kanan agresif di mana dibutuhkan. Namun bersiaplah untuk bereaksi cepat dalam menanggapi setiap perubahan. Penyimpanan, berbeda langsung dengan komputasi, umumnya relatif murah di cloud. Tapi hati-hati menggunakan penyimpanan murah, karena I / O mungkin menimbulkan biaya yang terpisah — dan mahal — pada beberapa layanan. Jika demikian, gunakan teknologi yang berpotensi meningkatkan kinerja yang berpotensi lebih hemat biaya seperti penyimpanan bertingkat, caching, dan / atau database dalam memori, jika tersedia, untuk mengoptimalkan pemanfaatan semua sumber daya. Lisensi perangkat lunak dapat menjadi pengeluaran yang signifikan baik untuk cloud privat maupun publik. Untuk alasan ini, banyak organisasi bermigrasi dari Windows ke Linux, dan dari SQL Server ke database komersial dan / atau open source yang lebih murah. Tetapi untuk aplikasi yang sistem operasinya "premium" dan / atau perangkat lunak aplikasi dijamin, periksa berbagai CSP untuk melihat apakah ada model penetapan harga yang mungkin menghemat penghematan untuk konfigurasi yang diperlukan. Akhirnya, semua CSP menawarkan diskon, dan kombinasi dari ini kadang-kadang dapat mencapai penghematan hingga 50%. Contohnya termasuk pra-bayar untuk layanan, membuat komitmen layanan, dan / atau memindahkan aplikasi ke wilayah lain.

Membuat Dan Menegakkan Kontrol Penahanan Biaya

Penyediaan sendiri untuk layanan cloud mungkin populer dengan pengguna. Tetapi tanpa kontrol yang tepat, kenyamanan ini membuatnya terlalu mudah untuk memanfaatkan sumber daya secara berlebihan, termasuk yang paling mahal harganya. Mulailah upaya untuk mendapatkan kontrol yang lebih baik dengan memanfaatkan sepenuhnya alat pemantauan dan manajemen yang ditawarkan semua CSP. Ini tentu saja akan menghadapi kurva pembelajaran. Karena alat CSP mungkin sangat berbeda dari, dan berpotensi lebih canggih daripada, yang digunakan di cloud pribadi. Salah satu alat penahanan biaya yang lebih berguna melibatkan penandaan sumber daya. Tag terdiri dari pasangan kunci / nilai dan metadata yang terkait dengan sumber daya individual. Dan beberapa bisa sangat terperinci. Misalnya, setiap mesin virtual, bersama dengan CPU, memori, I / O, dan sumber daya yang dapat ditagih lainnya yang digunakannya, mungkin memiliki tag. Tag berguna lainnya mungkin menunjukkan aplikasi mana yang berada dalam lingkungan produksi versus pengembangan, atau ke pusat biaya atau departemen mana masing-masing ditugaskan. Secara kolektif, tag ini dapat merupakan pemanfaatan total sumber daya yang tercermin dalam tagihan. Organisasi yang menggunakan banyak layanan cloud publik mungkin juga dilayani dengan baik untuk membuat skrip. Sertakan memuat informasi dari semua alat pemantauan, manajemen, dan penandaan yang tersedia ke dalam spreadsheet atau aplikasi serupa untuk analisis terperinci dan penggunaan lainnya, seperti pengembalian tagihan, kepatuhan, dan tren / anggaran. Idealnya, informasi dari semua CSP dan cloud pribadi akan dinormalisasi untuk dimasukkan dalam pandangan holistik untuk memungkinkan optimalisasi harga / kinerja untuk semua aplikasi yang berjalan di seluruh cloud hybrid.

Menangani Kasing Kasus Penggunaan Terburuk: Aplikasi Ketersediaan Tinggi

Selain alasan yang dikutip dalam pengantar mengapa aplikasi ketersediaan tinggi sering kali paling mahal, ketiga CSP utama — Google, Microsoft, dan Amazon — setidaknya memiliki beberapa keterbatasan terkait ketersediaan tinggi. Contohnya termasuk failover yang biasanya dipicu hanya oleh pemadaman zona dan bukan oleh banyak kegagalan umum lainnya; contoh master hanya mampu membuat replika failover tunggal; dan penggunaan event log untuk mereplikasi data, yang menciptakan "replikasi lag" yang dapat mengakibatkan pemadaman sementara selama failover. Tak satu pun dari batasan ini yang tidak dapat diatasi, tentu saja — dengan anggaran yang cukup besar. Tantangannya adalah menemukan solusi umum dan hemat biaya untuk menerapkan ketersediaan tinggi di awan publik, pribadi, dan hibrid. Di antara solusi yang paling fleksibel dan terjangkau adalah kluster failover jaringan area penyimpanan (SAN). Solusi ketersediaan tinggi ini diimplementasikan sepenuhnya dalam perangkat lunak yang dibuat khusus untuk dibuat. Seperti yang tersirat dari namanya, sekelompok server dan penyimpanan yang tidak berbagi apa-apa dengan failover otomatis di seluruh jaringan area lokal dan / atau WAN untuk memastikan ketersediaan tinggi pada tingkat aplikasi. Sebagian besar solusi ini memberikan kombinasi replikasi data tingkat blok waktu-nyata, pemantauan aplikasi berkelanjutan, dan kebijakan pemulihan failover / failback yang dapat dikonfigurasi. Beberapa kluster failover SAN-less yang lebih kuat juga menawarkan kemampuan canggih. Misalnya optimasi WAN untuk memaksimalkan kinerja dan meminimalkan pemanfaatan bandwidth, dukungan kuat untuk Edisi Standar SQL Server yang lebih murah. Dan jangan lupa peralihan manual penugasan server primer dan sekunder untuk pemeliharaan terencana, dan kemampuan untuk melakukan pencadangan rutin tanpa mengganggu aplikasi.

Mempertahankan Perspektif Yang Tepat

Saat mencoba beberapa saran ini di cloud hybrid Anda, berusahalah untuk menjaga tagihan CSP bulanan dalam perspektif yang tepat. Dengan cloud publik, semua biaya muncul dalam satu faktur. Sebaliknya, total biaya untuk mengoperasikan cloud pribadi jarang disajikan dengan cara yang begitu lengkap dan terkonsolidasi. Dan jika ya, total biaya itu juga dapat menyebabkan guncangan stiker. Latihan yang berguna, oleh karena itu, mungkin untuk memahami semua biaya dalam pengoperasian cloud pribadi — tidak menerima apa pun yang diberikan — seolah-olah itu adalah bisnis mandiri seperti penyedia layanan cloud. Maka tagihan-tagihan dari CSP untuk aplikasi-aplikasi penting Anda mungkin tampaknya tidak begitu mengejutkan. Artikel dari www.dbta.com

Tantangan dalam Ketersediaan Tinggi Untuk Aplikasi Misi-Penting di SME

Mengelola Pemulihan Real-Time dalam Pemadaman Awan Besar

Mengelola Pemulihan Real-Time Dalam Pemadaman Awan Besar

Bencana terjadi, membuat kenyataan downtime tiba-tiba. Tetapi ada hal-hal yang dapat dilakukan oleh semua pelanggan untuk bertahan hidup dari pemadaman cloud apa pun. Banyak hal terjadi. Kegagalan — besar dan kecil — tidak bisa dihindari. Apa yang tidak bisa dihindari adalah periode downtime yang diperpanjang. Pertimbangkan hari ketika awan Azure Wilayah Microsoft Tengah Selatan AS mengalami kegagalan yang dahsyat. Sebuah badai ganas menyebabkan serangkaian masalah yang akhirnya meruntuhkan seluruh pusat data. Dalam apa yang oleh beberapa orang disebut "Hari Azure Cloud Jatuh dari Langit," kebanyakan pelanggan offline, tidak hanya selama beberapa detik atau menit, tetapi untuk satu hari penuh. Beberapa offline selama lebih dari dua hari. Sementara Microsoft sejak itu telah menangani banyak masalah yang menyebabkan pemadaman, insiden itu akan lama diingat oleh para profesional TI. Itu berita buruknya. Berita baiknya adalah: Ada hal-hal yang bisa dilakukan pelanggan Azure untuk bertahan hidup dari hampir semua gangguan. Itu bisa dari satu server gagal ke seluruh pusat data menjadi offline. Faktanya, pelanggan Azure yang menerapkan ketersediaan tinggi dan / atau ketentuan pemulihan bencana, lengkap dengan replikasi data real-time dan failover otomatis yang cepat, dapat berharap tidak mengalami kehilangan data, dan sedikit atau tidak ada downtime ketika bencana terjadi. Lihat juga: Nutanix melihat cloud perusahaan memenangkan perlombaan cloud

Mengelola Pemadaman Awan

Artikel ini membahas empat opsi untuk menyediakan perlindungan pemulihan bencana (DR) dan ketersediaan tinggi (HA) dalam konfigurasi cloud hybrid dan Azure murni. Dua opsi khusus untuk database Microsoft SQL Server, yang merupakan aplikasi populer di Azure cloud; dua opsi lainnya adalah agnostik aplikasi. Keempat opsi, yang juga dapat digunakan dalam berbagai kombinasi, dibandingkan dalam tabel dan termasuk:

• Layanan Azure Site Recovery (ASR)
• Contoh SQL Server Failover Cluster dengan Ruang Penyimpanan Langsung
• SQL Server Selalu Di Ketersediaan Grup
• Perangkat Lunak Failover Clustering pihak ketiga

RTO dan RPO 101

Sebelum menjelaskan keempat opsi, perlu memiliki pemahaman dasar tentang dua metrik yang digunakan untuk menilai efektivitas ketentuan DR dan HA: Sasaran Waktu Pemulihan dan Sasaran Titik Pemulihan. Mereka yang akrab dengan RTO dan RPO dapat melewati bagian ini. RTO adalah durasi pemadaman maksimum yang dapat ditoleransi. Aplikasi pemrosesan transaksi online umumnya memiliki RTO terendah, dan aplikasi yang sangat kritis sering memiliki RTO hanya beberapa detik. RPO adalah periode maksimum di mana kehilangan data dapat ditoleransi. Jika tidak ada kehilangan data yang dapat ditoleransi, maka RPO adalah nol. RTO biasanya akan menentukan jenis perlindungan HA dan / atau DR yang dibutuhkan. Waktu pemulihan yang rendah biasanya menuntut ketentuan HA yang kuat yang melindungi terhadap kegagalan sistem dan perangkat lunak yang rutin, sementara RTO yang lebih lama dapat puas dengan ketentuan DR dasar yang dirancang untuk melindungi terhadap bencana yang lebih luas, tetapi jauh lebih jarang terjadi. Replikasi data yang digunakan dengan ketentuan HA dan DR dapat menciptakan kebutuhan untuk tradeoff potensial antara RTO dan RPO. Dalam lingkungan LAN latensi rendah, di mana replikasi dapat disinkronkan, kumpulan data primer dan sekunder dapat diperbarui secara bersamaan. Hal ini memungkinkan pemulihan penuh terjadi secara otomatis dan dalam waktu nyata, sehingga memungkinkan untuk memenuhi waktu pemulihan yang paling menuntut dan tujuan titik pemulihan (masing-masing beberapa detik dan nol) tanpa ada tradeoff yang diperlukan. Di seberang WAN, sebaliknya, memaksa primer untuk menunggu sekunder untuk mengkonfirmasi penyelesaian pembaruan untuk setiap transaksi akan berdampak buruk pada kinerja. Untuk alasan ini, replikasi data dalam WAN biasanya tidak sinkron. Ini dapat menciptakan tradeoff antara mengakomodasi RTO dan RPO yang biasanya menghasilkan peningkatan waktu pemulihan. Inilah alasannya: Untuk memenuhi RPO nol, proses manual diperlukan untuk memastikan semua data (misalnya dari log transaksi) telah sepenuhnya direplikasi pada sekunder sebelum kegagalan dapat terjadi. Upaya ekstra ini memperpanjang waktu pemulihan, dan itulah sebabnya konfigurasi seperti itu sering digunakan untuk DR dan bukan HA.

Layanan Pemulihan Situs Azure (ASR)

ASR adalah penawaran DR-as-a-service (DRaaS) Azure. ASR mereplikasi mesin fisik dan virtual ke situs Azure lain, berpotensi di wilayah lain, atau dari instance lokal ke cloud Azure. Layanan ini memberikan pemulihan yang cukup cepat dari pemadaman sistem dan situs, dan juga memfasilitasi pemeliharaan yang direncanakan dengan menghilangkan waktu henti selama pemutakhiran perangkat lunak bergulir. Seperti semua penawaran DRaaS, ASR memiliki beberapa keterbatasan, yang paling serius adalah ketidakmampuan untuk mendeteksi dan gagal secara otomatis dari banyak kegagalan yang menyebabkan downtime tingkat aplikasi. Tentu saja, inilah mengapa layanan ini dikarakterisasi sebagai untuk DR dan bukan untuk HA. Dengan ASR, waktu pemulihan biasanya 3-4 menit tergantung, tentu saja, pada seberapa cepat administrator dapat secara manual mendeteksi dan merespons masalah. Seperti dijelaskan di atas, kebutuhan untuk replikasi data tidak sinkron di WAN selanjutnya dapat meningkatkan waktu pemulihan untuk aplikasi dengan RPO nol.

Contoh SQL Server Failover Cluster dengan Ruang Penyimpanan Langsung

SQL Server menawarkan dua opsi HA / DR-nya sendiri: Mesin Virtual Failover Cluster (dibahas di sini) dan Grup Ketersediaan Selalu Aktif (dibahas berikutnya). FCI memberikan dua keuntungan: Fitur ini tersedia dalam Edisi Standar SQL Server yang lebih murah, dan tidak tergantung pada penyimpanan bersama seperti halnya cluster HA tradisional. Keuntungan yang terakhir ini penting karena penyimpanan bersama tidak tersedia di cloud — dari Microsoft atau penyedia layanan cloud lainnya. Pilihan populer untuk penyimpanan di Azure cloud adalah Storage Spaces Direct (S2D), yang mendukung berbagai aplikasi, dan dukungannya untuk SQL Server melindungi seluruh instance dan bukan hanya database. Kelemahan utama S2D adalah bahwa server harus berada dalam satu pusat data tunggal, membuat opsi ini cocok untuk beberapa kebutuhan HA tetapi tidak untuk DR. Untuk perlindungan multi-situs HA dan DR, replikasi data yang diperlukan harus disediakan oleh pengiriman log atau solusi pengelompokan failover pihak ketiga.

SQL Server Selalu Di Ketersediaan Grup

Sementara Always On Availability Groups adalah penawaran SQL Server yang paling mampu untuk HA dan DR, itu membutuhkan lisensi Enterprise Edition yang lebih mahal. Opsi ini dapat memberikan waktu pemulihan 5-10 detik dan titik pemulihan detik atau kurang. Itu juga menawarkan sekunder dibaca untuk query database (dengan lisensi yang sesuai), dan tidak menempatkan batasan pada ukuran database atau jumlah instance sekunder. Konfigurasi Always On Availability Groups yang menyediakan perlindungan HA dan DR terdiri dari pengaturan tiga simpul dengan dua node dalam satu Set Ketersediaan atau Zona, dan yang ketiga di Azure Region terpisah. Satu batasan penting adalah bahwa hanya database yang direplikasi dan bukan seluruh instance SQL, yang harus dilindungi oleh beberapa cara lain. Selain menjadi penghalang biaya untuk beberapa aplikasi database, pendekatan ini memiliki kelemahan lain. Khusus untuk aplikasi memerlukan departemen TI untuk mengimplementasikan ketentuan HA dan DR lainnya untuk semua aplikasi lainnya. Penggunaan beberapa solusi HA / DR dapat secara substansial meningkatkan kompleksitas dan biaya (untuk perizinan, pelatihan, implementasi dan operasi yang sedang berlangsung), menjadikan ini alasan lain mengapa organisasi semakin memilih menggunakan solusi pihak ketiga agnostik aplikasi.

Perangkat Lunak Failover Clustering pihak ketiga

Dengan desain aplikasi-agnostik dan platform-agnostik, perangkat lunak failover clustering mampu memberikan solusi HA dan DR lengkap untuk hampir semua aplikasi di lingkungan cloud pribadi, publik, dan hybrid. Ini termasuk untuk Windows dan Linux. Menjadi agnostik aplikasi menghilangkan kebutuhan untuk memiliki ketentuan HA / DR yang berbeda untuk aplikasi yang berbeda. Menjadi platform-agnostik memungkinkan untuk memanfaatkan berbagai kemampuan dan layanan di Azure cloud, termasuk Fault Domains, Kumpulan dan Zona Ketersediaan, Pasangan Wilayah, dan Pemulihan Situs Azure. Sebagai solusi lengkap, perangkat lunak ini mencakup, sekurang-kurangnya, replikasi data waktu-nyata, pemantauan berkelanjutan yang mampu mendeteksi kegagalan pada tingkat aplikasi, dan kebijakan yang dapat dikonfigurasi untuk failover dan failback. Sebagian besar solusi juga menawarkan berbagai kemampuan bernilai tambah yang memungkinkan cluster failover untuk memberikan waktu pemulihan di bawah 20 detik dengan kehilangan data minimal atau tidak ada sama sekali untuk memenuhi hampir semua kebutuhan HA / DR.

Menjadikannya Nyata

Keempat opsi, apakah beroperasi secara terpisah atau bersamaan, dapat memiliki peran untuk dimainkan dalam membuat kontinum perlindungan DR dan HA lebih efektif dan terjangkau untuk spektrum penuh aplikasi perusahaan. Ini termasuk dari mereka yang dapat mentolerir beberapa kehilangan data dan periode waktu henti yang panjang, hingga mereka yang membutuhkan pemulihan waktu nyata untuk mencapai lima hingga 9 waktu kerja dengan kehilangan data yang minimal atau tidak sama sekali. Untuk selamat dari pemadaman cloud berikutnya di dunia nyata, pastikan bahwa ketentuan DR dan / atau HA apa pun yang Anda pilih dikonfigurasikan dengan setidaknya dua node yang tersebar di dua situs. Pastikan juga untuk memahami seberapa baik ketentuan memenuhi waktu pemulihan masing-masing aplikasi dan tujuan titik pemulihan. Serta segala keterbatasan yang mungkin ada, termasuk kebutuhan akan proses manual yang diperlukan untuk mendeteksi semua kemungkinan kegagalan, dan memicu kegagalan dengan cara yang memastikan kesinambungan aplikasi dan integritas data.

Tentang Jonathan Meltzer

Jonathan Meltzer adalah Direktur, Manajemen Produk, di SIOS Technology. Ia memiliki lebih dari 20 tahun pengalaman dalam manajemen produk dan pemasaran untuk perangkat lunak dan produk SaaS yang membantu pelanggan mengelola, mengubah, dan mengoptimalkan sumber daya manusia dan sumber daya TI mereka. Direproduksi dari RTinsight

Pemanfaatan Dinamis – Ketersediaan Tinggi Yang Lebih Terjangkau, Dorong Migrasi Ke Awan

Pemanfaatan Dinamis Akan Membuat Ketersediaan Tinggi Lebih Terjangkau, Mendorong Migrasi Lebih Lanjut ke Cloud

Penyediaan berdasarkan permintaan di cloud bukanlah hal baru. Apa yang akan menjadi baru adalah opsi yang lebih hemat biaya untuk ketersediaan tinggi dan pemulihan bencana dalam konfigurasi cloud hibrid dan murni publik. HA dan DR atas permintaan seperti itu akan meningkatkan pemanfaatan sumber daya secara dinamis yang tersebar di antara banyak pusat data dan wilayah geografis, dan menjadikan pencapaian tingkat layanan tinggi lebih terjangkau untuk lebih banyak aplikasi.

Baik HA dan DR membutuhkan redundansi untuk memastikan pemulihan yang cepat dan andal dari kegagalan.

HA failover clustering mereplikasi lingkungan operasional penuh dari VM primer, termasuk CPU, memori dan sumber daya penyimpanan, dalam VM sekunder. Semua data kemudian juga direplikasi secara real-time ke sekunder, yang tetap menganggur kecuali dan sampai primer gagal. Memiliki satu atau lebih VM sekunder yang sepenuhnya redundan menciptakan sebuah cluster yang secara efektif berada dalam kondisi swa-uji terus-menerus, dengan demikian memastikan bahwa ia dipersiapkan untuk kegagalan otomatis dan cepat.

Konfigurasi DR dasar, sebaliknya, tidak memiliki kemampuan yang diperlukan untuk failover cepat

Pertimbangkan Pemulihan Situs Azure, misalnya. Microsoft memposisikan ASR sebagai DR-sebagai-layanan. Dan pasar DRaaS yang berkembang sekarang mencakup penawaran dari hampir selusin penyedia. Dengan ASR, VM primer direplikasi ke sekunder di wilayah Azure lain, atau dari instance lokal ke cloud Azure. Tetapi data tidak direplikasi secara real-time. Layanan tidak dapat mendeteksi dan mengatasi secara otomatis dari berbagai penyebab downtime tingkat aplikasi.

Masalah yang mendasarinya

Banyak titik kegagalan potensial tidak tercakup oleh DRaaS dan layanan ketersediaan cloud lainnya. Secara umum, hilangnya layanan terdeteksi. Tetapi kesalahan karena aplikasi atau perangkat lunak OS, serta kegagalan dalam sumber daya diskrit seperti jaringan atau penyimpanan tidak terdeteksi. Sebagai akibatnya, layanan aplikasi dapat terganggu – berpotensi untuk jangka waktu yang lama – tanpa terdeteksi oleh fasilitas pemulihan cloud sendiri.

SIOS DataKeeper dan SIOS Protection Suite dari SIOS Technology

Ketika ketersediaan tinggi sangat penting, deteksi kesalahan komprehensif sangat penting untuk menghindari downtime tingkat aplikasi. Tujuan ini mudah dicapai dengan teknologi cluster failover yang dibangun khusus, seperti SIOS DataKeeper dan SIOS Protection Suite dari SIOS Technology, yang mampu secara otomatis mendeteksi berbagai penyebab downtime baik dalam perangkat lunak maupun sumber daya fisik dan virtual yang mendasarinya. Cluster khusus perangkat lunak ini berlapis di atas awan untuk menyediakan solusi HA / DR lengkap yang mencakup replikasi data, pemantauan tingkat aplikasi terus-menerus, dan kebijakan pemulihan failover / failback yang dapat dikonfigurasi.

Penawaran DRaaS

Perangkat lunak pengelompokan Failover dapat dikonfigurasi untuk HA atau DR saja, atau untuk kombinasi HA dan DR. DR biasanya memiliki VM siaga di wilayah lain dalam konfigurasi yang disebut sebagai GeoCluster. Seperti penawaran DRaaS, keterbatasan bandwidth WAN menyebabkan beberapa "keterlambatan replikasi" untuk data, dan berpotensi hilangnya beberapa data di bawah skenario kegagalan tertentu. Tetapi tidak seperti DRaaS, kelas kegagalan yang luas dideteksi secara otomatis di platform cloud dan tingkat aplikasi, dan dapat segera diperbaiki untuk memastikan kesinambungan layanan. Sementara failover clustering, dengan kemampuannya untuk meminimalkan titik pemulihan dan sasaran waktu pemulihan (RPO / RTO), memberikan perlindungan layanan yang komprehensif dibandingkan dengan DRaaS, kebutuhan untuk mengonfigurasi sepenuhnya sumber daya yang berlebihan dan tidak terpakai masih mahal. Untungnya, masalah ini sedang ditangani oleh teknik manajemen klaster yang muncul yang dapat mengatur pemulihan penuh melalui alokasi sumber daya yang dinamis pada saat kegagalan.

Pendekatan Baru

VM siaga, saat beroperasi dalam mode siaga, hanya dikonfigurasikan dengan sumber daya yang diperlukan untuk menangani peran minimalnya dari target replikasi data untuk VM primer. Ketika kegagalan terjadi, cluster segera dan secara dinamis mengkonfigurasi ulang VM siaga dengan komplemen lengkap sumber daya yang diperlukan untuk memberikan tingkat kinerja yang diperlukan untuk peran operasional penuh dari VM primer. Pemanfaatan dinamis ini memungkinkan perlindungan HA dan DR untuk mendapatkan manfaat dari penghematan biaya yang signifikan tanpa mengorbankan ketersediaan dan keandalan manfaat pengelompokan.

Kesimpulan

Cluster HA failover dan DRaaS, baik yang beroperasi secara terpisah atau bersama-sama, dapat berperan untuk membuat kontinum perlindungan HA dan DR lebih terjangkau untuk spektrum penuh aplikasi perusahaan – dari mereka yang dapat mentolerir hilangnya data dan periode perpanjangan downtime, bagi mereka yang membutuhkan RPO nol (tanpa kehilangan data) dan RTO kurang dari lima menit di bawah semua skenario kegagalan yang mungkin terjadi.