SLA Ketersediaan: FT, Ketersediaan Tinggi, dan Pemulihan Bencana – Mulai dari mana

SLA Ketersediaan: FT, Ketersediaan Tinggi, dan Pemulihan Bencana – Mulai dari mana

Wajar untuk mengatakan bahwa di era modern ini di mana banyak aspek kehidupan kita didorong oleh teknologi, kita hidup di dunia yang sangat instan.Misalnya, dengan mengklik tombol, pesanan bahan makanan mingguan kami tiba di depan pintu kami.Kami dapat langsung membeli tiket untuk acara atau perjalanan.Atau bahkan akhir-akhir ini, pesan mobil baru tanpa harus pergi ke mana pun di dekat ruang pamer dan berurusan dengan wiraniaga yang memaksa. Kita dimanjakan dalam dunia kenyamanan ini.

Tapi mari kita pikirkan semua vendor dan penyedia layanan yang harus mendukung tingkat layanan ini.Mereka harus mempertahankan tingkat investasi yang tinggi untuk memastikan bahwa infrastruktur dasar mereka (dan khususnya infrastruktur TI mereka) dibangun dan dioperasikan sedemikian rupa sehingga mereka dapat mendukung harapan "selalu aktif" ini.Aplikasi dan database harus selalu berjalan, untuk memenuhi permintaan pelanggan dan memaksimalkan produktivitas dan pendapatan perusahaan.Pentingnya kelangsungan bisnis TI sama pentingnya dengan sebelumnya.

Banyak konsep ketersediaan TI yang beredar seperti toleransi kesalahan (FT) , ketersediaan tinggi (HA) dan pemulihan bencana (DR) .Tapi ini bisa menimbulkan pertanyaan lebih lanjut.Apa perbedaan antara konsep ketersediaan ini?Manakah dari mereka yang tepat untuk infrastruktur saya?Bisakah mereka digabungkan atau dipertukarkan? Langkah pertama dan terpenting untuk inisiatif ketersediaan apa pun adalah membuat perjanjian tingkat layanan (SLA) aplikasi/ketersediaan basis data yang jelas.Ini kemudian menentukan pendekatan ketersediaan yang paling sesuai.

Apa itu SLA?

Sampai batas tertentu, kita semua tahu apa itu SLA, tetapi untuk diskusi ini, mari kita pastikan bahwa kita semua berada pada gelombang yang sama. Ketersediaan SLA adalah kontrak antara penyedia layanan dan pengguna akhir mereka yang menentukan tingkat yang diharapkan dari aplikasi/database uptime dan aksesibilitas vendor adalah untuk memastikan dan menguraikan hukuman yang terlibat (biasanya keuangan) jika tingkat layanan yang disepakati tidak bertemu.Di dunia TI, SLA ditempa dari dua ukuran kekritisan untuk bisnis – Recovery Time Objectives (RTO) dan Recovery Point Objectives (RPO).Sangat sederhana, RTO mendefinisikan seberapa cepat kita membutuhkan operasi aplikasi untuk dipulihkan jika terjadi kegagalan. RPO menentukan seberapa terkini data kami jika terjadi skenario pemulihan. Setelah Anda dapat mengidentifikasi metrik ini untuk aplikasi dan database Anda, ini akan menentukan SLA Anda.SLA diukur sebagai persentase, jadi misalnya, Anda mungkin menemukan istilah seperti 99,9% atau 99,99% tersedia.Ini adalah ukuran berapa menit waktu aktif dan ketersediaan yang akan dijamin oleh TI untuk aplikasi pada tahun tertentu. Secara umum, lebih banyak perlindungan berarti lebih banyak biaya. Oleh karena itu, penting untuk memperkirakan biaya waktu henti selama satu jam untuk aplikasi atau database dan menggunakan SLA ini sebagai alat untuk memilih solusi yang masuk akal secara bisnis.

Setelah memiliki SLA, kami dapat membuat keputusan bisnis tentang jenis solusi mana – FT, HA, DR, atau kombinasinya – yang merupakan pendekatan yang paling sesuai untuk kebutuhan ketersediaan kami.

Apa itu Toleransi Kesalahan (FT)?

FT memberikan ketersediaan SLA yang sangat mengesankan di 99,999%.Dalam istilah dunia nyata, solusi FT akan menjamin tidak lebih dari 5,25 menit waktu henti dalam satu tahun.Pada dasarnya, dua server identik dijalankan secara paralel satu sama lain, memproses transaksi di kedua server pada saat yang sama dalam konfigurasi aktif-aktif dalam apa yang disebut sebagai proses "lockstep". Jika server utama gagal, server sekunder melanjutkan pemrosesan, tanpa gangguan apa pun pada aplikasi atau kehilangan data apa pun.Pengguna akhir tidak akan menyadari bahwa telah terjadi kegagalan server.

Ini terdengar fantastis!Ini terdengar luar biasa!Mengapa kita membutuhkan yang lain?Tapi tunggu dulu… sehebat suara FT di atas kertas, ada beberapa peringatan yang perlu dipertimbangkan.

Proses "lockstep" adalah binatang yang aneh.Ini sangat rewel tentang jenis perangkat keras server yang dapat dijalankannya, terutama dalam hal prosesor.Daftar kompatibilitas perangkat keras yang terbatas ini memaksa solusi FT untuk duduk di ujung yang lebih tinggi dari braket biaya, yang bisa sangat banyak mencapai ratusan ribu dolar pada saat Anda memasukkan dua atau lebih cluster FT dengan dukungan dan layanan terkait.

Kerentanan Kesalahan Perangkat Lunak

Solusi FT juga dirancang dengan mempertimbangkan toleransi kesalahan perangkat keras dan tidak terlalu memperhatikan potensi kesalahan aplikasi.Ingat, solusi FT menjalankan transaksi dan proses yang sama secara bersamaan, jadi jika ada kesalahan aplikasi di server utama, ini juga akan direplikasi di server sekunder.

Apa itu Ketersediaan Tinggi (HA)?

Untuk sebagian besar SLA, FT terlalu mahal untuk dibeli dan dikelola untuk kasus penggunaan rata-rata.Dalam kebanyakan kasus, solusi HA adalah pilihan yang lebih baik. Mereka memberikan tingkat perlindungan yang hampir sama dengan biaya yang lebih murah.Solusi HA memberikan SLA 99,99% yang setara dengan sekitar 52 menit waktu henti dalam satu tahun, dengan menerapkan secara Aktif-Siaga.SLA yang dikurangi diperkenalkan karena ada periode kecil waktu henti di mana server Aktif harus beralih ke server Siaga sebelum operasi dilanjutkan.Oke, ini tidak mengesankan seperti solusi FT, tetapi untuk sebagian besar persyaratan TI, HA memenuhi SLA, bahkan untuk aplikasi superkritis seperti sistem CRM dan ERP.

Sama pentingnya, solusi Ketersediaan Tinggi lebih agnostik aplikasi, dan juga dapat mengelola failover server jika terjadi kegagalan aplikasi serta kegagalan perangkat keras atau OS. Mereka juga memungkinkan lebih banyak fleksibilitas konfigurasi.Tidak ada daftar kompatibilitas perangkat keras seperti FT yang harus ditangani, karena pada sebagian besar kesempatan mereka akan berjalan pada platform apa pun di mana OS yang mendasarinya didukung.

Bagaimana Disaster Recovery (DR) cocok dengan gambar?

Seperti FT dan HA, DR juga dapat digunakan untuk mendukung fungsi bisnis yang penting. Namun, DR dapat digunakan bersama dengan FT dan HA.Toleransi Kesalahan dan Ketersediaan Tinggi difokuskan pada pemeliharaan waktu aktif di tingkat lokal, seperti dalam pusat data (atau zona ketersediaan cloud).DR mengirimkan situs atau pusat data redundan ke failover jika terjadi bencana di pusat data utama.

Apa artinya semua itu?

Pada akhirnya, tidak ada pendekatan ketersediaan yang salah atau benar untuk diambil.Ini bermuara pada kekritisan proses bisnis yang Anda coba lindungi dan ekonomi dasar dari solusi.Dalam beberapa skenario, itu tidak masalah.Misalnya, jika Anda menjalankan pembangkit listrik tenaga nuklir, saya akan merasa lebih nyaman bahwa operasi kritis dilindungi oleh sistem FT. Mari kita hadapi itu, Anda mungkin tidak ingin ada gangguan dalam layanan di sana.Namun untuk sebagian besar lingkungan TI, waktu kerja kritis juga dapat diberikan dengan HA pada titik harga yang jauh lebih mudah dicerna.

Bagaimana memilih: FT, HA dan DR?

• Pertama dan terpenting, pahami operasi bisnis Anda secara mendetail dan identifikasi biaya waktu henti.
• Setelah SLA Anda ditetapkan, pertimbangkan biaya solusi ketersediaan pilihan dengan biaya setiap potensi waktu henti.
• Saat memilih solusi ketersediaan Anda, lihat kemudahan penerapan dan penggunaan, karena ini juga akan memengaruhi TCO keseluruhan dari solusi ketersediaan.

Sistem TI kuat, tetapi mereka bisa salah pada saat yang paling tidak nyaman. FT, HA, dan DR adalah polis asuransi Anda untuk melindungi Anda saat mengirimkan SLA kepada pelanggan di dunia yang serba instan dan nyaman ini.

Direproduksi dengan izin dari SIOS

Cara Menghindari Kemacetan IO: Panduan Penempatan Log Intent DataKeeper untuk Penerapan Cloud Windows

Cara Menghindari Kemacetan IO: Panduan Penempatan Log Intent DataKeeper untuk Penerapan Cloud Windows

Untuk memastikan kinerja aplikasi yang optimal, saat menerapkan Penjaga Data SIOS penting untuk menempatkan catatan niat (file bitmap) pada disk latensi terendah yang tersedia, menghindari kemacetan IO. Di AWS, GCP, dan Azure, disk latensi terendah yang tersedia adalah drive ephemeral. Namun, di Azure, perbedaan antara menggunakan drive singkat vs SSD Premium minimal, jadi tidak perlu menggunakan drive singkat saat menjalankan DataKeeper di Azure. Namun, di AWS dan GCP, sangat penting untuk memindahkan log maksud ke drive singkat, jika tidak, throughput tulis akan terpengaruh secara signifikan.

Saat memanfaatkan disk ephemeral untuk file bitmap, ada tradeoff. Sifat drive fana adalah bahwa data yang disimpan di dalamnya tidak dijamin persisten. Bahkan, jika instance cloud dihentikan dari konsol, drive ephemeral yang terpasang ke instance akan dibuang dan drive baru dipasang ke instance. Dalam proses ini file bitmap dibuang dan file bitmap baru yang kosong diletakkan di tempatnya.

Ada skenario tertentu di mana jika file bitmap hilang, sinkronisasi ulang lengkap akan terjadi. Misalnya, jika server utama a Cluster tanpa SAN r dimatikan dari konsol, kegagalan akan terjadi, tetapi ketika server kembali online, sinkronisasi ulang lengkap akan terjadi dari sumber mirror baru ke sumber lama. Ini terjadi secara otomatis, sehingga pengguna tidak perlu melakukan tindakan apa pun dan node aktif tetap online selama periode sinkronisasi ulang ini.

Ada skenario lain di mana penempatan file bitmap juga dapat memengaruhi kinerja. Misalnya, jika Anda mereplikasi drive NVMe, Anda perlu membuat partisi kecil pada drive NVMe untuk menyimpan file bitmap. Aturan umum adalah bahwa file bitmap harus berada di disk latensi tercepat dan terendah yang tersedia di instans. Itu juga harus ditempatkan pada disk yang tidak dikenakan pajak terlalu banyak dengan operasi IO lainnya.

Informasi tentang cara memindahkan log maksud dapat ditemukan di Dokumentasi DataKeeper . Informasi tambahan tentang bagaimana log maksud digunakan dapat ditemukan di Dokumentasi DataKeeper .

Direproduksi dengan izin dari SIOS

Platform Media Terkemuka Melindungi SAP S/4 HANA Penting di AWS EC2 Cloud

Platform Media Terkemuka Melindungi SAP S/4 HANA Penting di AWS EC2 Cloud

SIOS Dipilih Berdasarkan Sertifikasi dan Validasi untuk SAP, Amazon Web Services dan Red Hat Linux

Organisasi media terkemuka ini menjangkau hampir semua orang dewasa di Singapura setiap minggu. melalui jangkauan terluas platform media di negara ini, mencakup digital, televisi, radio, media cetak dan media luar rumah dan lebih dari 50 produk dan merek dalam empat bahasa (Inggris, Mandarin, Melayu dan Tamil).

Lingkungan

Perusahaan menggunakan Aplikasi SAP S/4 HANA dan database HANA untuk menggerakkan operasi di seluruh organisasi, menyatukan operasi di berbagai departemen. Mereka menjalankan aplikasi dan database penting ini di lingkungan Red Hat Linux di pusat data lokal mereka. Melindungi sistem penting ini dari waktu henti dan bencana adalah prioritas utama bagi tim TI organisasi ini.

Tantangan

Tim TI organisasi media menyadari bahwa mereka dapat mewujudkan penghematan biaya yang signifikan dengan memindahkan aplikasi SAP dan database HANA ke cloud AWS EC2. Namun, agar migrasi berhasil, mereka membutuhkan solusi ketersediaan tinggi (HA) dan pemulihan bencana (DR) yang akan "mengangkat dan menggeser" dengan lanskap SAP yang ada ke AWS tanpa gangguan.

Evaluasi

Tim TI perusahaan menginginkan solusi HA/ DR yang dapat mereka andalkan untuk memenuhi SLA ketersediaan 99,99% mereka di cloud. Solusi tersebut perlu disertifikasi oleh SAP dan AWS dan mendukung sistem operasi Red Hat Linux. Terakhir, untuk memastikan mereka dapat memberikan perlindungan DR penuh untuk beban kerja kritis ini, mereka membutuhkan solusi pengelompokan yang akan melakukan failover di beberapa zona ketersediaan AWS (AZ). Arsitek AWS Solution merekomendasikan agar organisasi menggunakan SIOS LifeKeeper untuk perangkat lunak pengelompokan Linux. Tim TI perusahaan memiliki waktu yang singkat untuk menyelesaikan proyek dan perlu memilih vendor HA yang dapat memenuhi persyaratan mereka tanpa menghambat kemajuan mereka.

Solusinya

Mereka memilih SIOS LifeKeeper karena tidak hanya memenuhi semua kriteria kami, tetapi juga karena tim SIOS diatur dengan sangat cepat, memungkinkan mereka untuk menjaga proyek migrasi cloud mereka sesuai jadwal. SIOS Lifekeeper disertifikasi oleh AWS dan SAP untuk ketersediaan tinggi di lingkungan cloud Red Hat dan AWS EC2. Solusi SIOS juga memenuhi kriteria utama lainnya karena mampu mereplikasi dan menyediakan redundansi di seluruh zona ketersediaan AWS Tim TI organisasi terkesan dengan tim dukungan lokal khusus SIOS yang siap menjawab pertanyaan dan memberikan dukungan 24 jam sehari, 7 hari seminggu. Organisasi saat ini memiliki lima pasang kluster failover menggunakan SIOS LifeKeeper untuk Linux untuk melindungi aplikasi S/4 HANA dan SAP HANA yang berjalan di beberapa zona ketersediaan di AWS EC2.

Hasil

Ketersediaannya dapat diandalkan, kami tidak mengalami downtime yang diperpanjang sejak menggunakan perangkat lunak Dengan memungkinkan pelanggan ini untuk memigrasikan beban kerja penting ini ke cloud tanpa mengorbankan HA/DR atau kinerja aplikasi, SIOS memungkinkan kami untuk mencapai penghematan biaya yang signifikan," katanya. Kemudahan SIOS LifeKeeper dari Mediacorp bahkan lebih menghemat dengan meminimalkan waktu admin TI.

Direproduksi dengan izin dari SIOS

Lindungi Sistem dari Waktu Henti

Lindungi Sistem dari Waktu Henti

Dalam lingkungan bisnis saat ini, organisasi bergantung pada aplikasi, database, dan Sistem ERP seperti SAP, SQL Server, Oracle, dan lainnya. Aplikasi ini menyatukan dan merampingkan operasi bisnis Anda yang paling penting. Ketika mereka gagal, mereka membebani Anda lebih dari sekadar uang. Sangat penting untuk melindungi sistem yang rumit ini dari waktu henti.

Ketersediaan Tinggi & Pemulihan Bencana yang Terbukti

SIOS memiliki 20+ tahun pengalaman dalam ketersediaan tinggi dan pemulihan bencana .SIOS tahu tidak ada satu solusi yang cocok untuk semua. Sistem data saat ini adalah kombinasi dari lingkungan on-premise, cloud publik, cloud hybrid, dan multi cloud. Aplikasi itu sendiri dapat menciptakan lebih banyak kerumitan. Tetapi mengonfigurasi perangkat lunak cluster open-source bisa melelahkan, memakan waktu, dan rentan terhadap kesalahan manusia.

SIOS memiliki solusi yang menyediakan ketersediaan tinggi dan pemulihan bencana untuk aplikasi penting. Solusi ini telah dikembangkan berdasarkan pengalaman dunia nyata kami, di berbagai industri dan kasus penggunaan. Produk kami meliputi: SIOS DataKeeper Cluster Edition untuk Windows dan SIOS LifeKeeper untuk Linux atau Windows. Aplikasi canggih ini memberikan perlindungan failover. Kit Pemulihan Aplikasi yang disertakan dengan LifeKeeper mempercepat waktu konfigurasi aplikasi dengan mengotomatiskan konfigurasi dan memvalidasi input.

Perlindungan Sistem Lokal, di Cloud atau di Lingkungan Hibrida

SIOS memberikan perlindungan yang Anda butuhkan untuk aplikasi penting bisnis dan mengurangi kerumitan pengelolaannya, baik di tempat, di cloud, atau di lingkungan cloud hybrid. Pelajari lebih lanjut tentang kami di video di bawah ini atau hubungi kami untuk mempelajari lebih lanjut tentang ketersediaan tinggi dan pemulihan bencana untuk aplikasi penting bisnis Anda.

Direproduksi dengan izin dari SIOS

Cara Mencapai Ketersediaan Tinggi di Cloud Menggunakan WSFC

Cara Mencapai Ketersediaan Tinggi di Cloud Menggunakan WSFC

Microsoft Windows Server menyertakan perangkat lunak Windows Server Failover Clustering (WSFC) untuk memastikan ketersediaan aplikasi penting. Di lingkungan lokal, node utama dan node siaga di cluster terhubung ke penyimpanan bersama yang sama. Namun, infrastruktur ini tidak dapat dibawa langsung ke cloud. Penyimpanan bersama yang mencakup sistem utama dan siaga sangat penting di WSFC, tetapi penyimpanan bersama tidak dapat digunakan dengan layanan cloud publik seperti IaaS (Infrastructure as a Service) di AWS, Azure, atau Google Cloud.

Penyimpanan Bersama yang Terpisah Secara Geografis untuk WSFC Tidak Tersedia di Cloud

Saat memigrasikan aplikasi lokal ke cloud, perusahaan lebih memilih untuk memindahkan seluruh infrastruktur mereka ke cloud, termasuk WSFC, tanpa mengubah proses operasi lokal. Hal ini memungkinkan mereka untuk meminimalkan gangguan dengan menerapkan keterampilan dan pengetahuan WSFC yang sama di cloud.

Server yang membentuk cluster dibagi menjadi node utama – tempat aplikasi berjalan – dan node siaga. Perangkat lunak WSFC memonitor aplikasi dan node server untuk memastikan mereka beroperasi. Jika WSFC mendeteksi sesuatu yang salah dengan node utama, itu akan mengalihkan operasi aplikasi ke node siaga dalam proses yang disebut "failover".

Dalam lingkungan WSFC, server utama dan server siaga terhubung ke penyimpanan bersama – biasanya penyimpanan yang disebut penyimpanan SAN (Storage Area Network) atau penyimpanan iSCSI-SAN.

Untuk operasi failover dari server utama ke server siaga, tautan jaringan harus dialihkan sehingga server siaga dapat membaca dari dan menulis ke SAN yang biasanya membaca dari dan menulis ke server utama. Dengan cara ini, dimungkinkan untuk memulai kembali layanan dalam waktu singkat, memungkinkan server siaga untuk mengakses data yang sama dengan node utama dan memenuhi Recovery Point Objectives (RPO) yang rendah.

Lihat konten terkait: Dasar-dasar Pemulihan Bencana .

Namun, saat memigrasi WSFC ke cloud, SAN tidak tersedia. Misalnya, Anda tidak dapat menautkan Amazon Web Services (AWS) dan Microsoft Azure ke beberapa node (server) untuk digunakan sebagai penyimpanan bersama. Hal yang sama berlaku untuk IaaS untuk layanan cloud lainnya.

Dimungkinkan untuk membangun konfigurasi klaster HA berdasarkan WSFC tanpa penyimpanan bersama, tetapi memerlukan keterampilan yang sangat canggih, seperti membuat program Anda sendiri untuk memulihkan data pada node siaga. Operasinya rumit dan tidak mudah untuk memverifikasi ketika sebuah insiden terjadi.

Perangkat Lunak Replikasi Data Memecahkan Masalah

Untuk memperbaiki masalah ini, Anda dapat menginstal replikasi data perangkat lunak yang dikhususkan untuk cluster HA – seperti SIOS DataKeeper Cluster Edition – dan menyinkronkan penyimpanan di antara server lokal. Data pada disk lokal dari node primer dan standby disinkronkan secara real-time menggunakan replikasi tingkat blok berbasis host. Dengan metode ini, Anda tidak memerlukan penyimpanan bersama. Sebagai gantinya, Anda dapat membangun konfigurasi klaster HA menggunakan WSFC yang sudah dikenal tanpa mengganggu proses yang sudah ada.

Dengan DataKeeper, node yang disinkronkan muncul sebagai SAN di layar manajemen WSFC (Failover Cluster Management). Jika manajer operasi Anda telah menggunakan WSFC, mereka akan memerlukan sedikit atau tanpa pelatihan dengan pendekatan ini.

Ketersediaan Tinggi di Cloud Melampaui HA Lokal dengan SIOS DataKeeper dan WSFC

Edisi Cluster DataKeeper adalah add-on perangkat lunak yang terintegrasi dengan mulus dengan Windows Server Failover Clustering (WSFC) untuk menambahkan replikasi sinkron atau asinkron berbasis host yang dioptimalkan kinerja. Jika klaster HA mengalami malfungsi, WSFC akan mengatur operasi failover ke node siaga dan mengakses penyimpanan bersama seolah-olah itu adalah penyimpanan bersama. Mekanisme sederhana ini memungkinkan untuk pindah ke AWS tanpa mengubah operasi sistem yang ada.

Tanpa mengorbankan operasi WSFC yang sudah dikenal, dimungkinkan untuk menjamin ketersediaan tinggi di cloud menggunakan DataKeeper yang setara atau lebih baik daripada di tempat ketersediaan tinggi . Keuntungan dari konfigurasi cluster ini adalah sangat sederhana dan dapat dengan mudah diterapkan ke lingkungan cloud apa pun.

Integrasi Tanpa Batas dengan WSFC

SIOS DataKeeper Cluster Edition terintegrasi secara mulus dengan dan memperluas Windows Server Failover Clustering (WSFC) dengan menyediakan mekanisme replikasi data berbasis host yang dioptimalkan kinerja. Sementara WSFC mengelola cluster perangkat lunak, SIOS melakukan replikasi data untuk mengaktifkan perlindungan bencana dan memastikan nol kehilangan data dalam kasus di mana cluster penyimpanan bersama tidak mungkin atau tidak praktis, seperti di cloud, virtual, dan lingkungan penyimpanan kinerja tinggi.

Direproduksi dengan izin dari SIOS