| Mei 21, 2022 |
Panduan Evaluasi SIOS Protection Suite untuk Linux untuk Lingkungan AWS Cloud |
|||||||||||||||||||||
| Mei 16, 2022 |
Kinerja Azure Shared Disk Dengan Zone Redundant Storage (ZRS) |
| Penyimpanan Lokal Redundan (LRS) | Penyimpanan Berlebihan Zona (ZRS) | |
| Tulis IOPS | 5099.82 | 4994.63 |
| Latensi Rata-rata | 7.830 | 7.998 |
Tes DiskSpd yang saya jalankan menggunakan parameter berikut.
diskspd -c200G -w100 -b8K -F8 -r -o5 -W30 -d10 -Sh -L testfile.dat Saya menulis ke disk P30 dengan ZRS dan P30 dengan LRS terpasang ke Standar DS3 v2 (4 vcpus, memori 14 GiB ) jenis contoh. ZRS P30 bersama juga dilampirkan ke instans identik di AZ berbeda dan ditambahkan sebagai penyimpanan bersama ke aplikasi klaster kosong.
Overhead 2% tampaknya merupakan harga yang wajar untuk dibayar agar data Anda didistribusikan secara sinkron di dua AZ. Namun, saya bertanya-tanya apa yang akan terjadi jika Anda memindahkan aplikasi berkerumun ke node jarak jauh, secara efektif menempatkan disk Anda di satu AZ dan instans Anda di AZ yang berbeda.
Berikut adalah hasilnya.
| Penyimpanan Lokal Redundan (LRS) | Penyimpanan Berlebihan Zona (ZRS) | ZRS saat menulis dari remote AZ | |
| Tulis IOPS | 5099.82 | 4994.63 | 4079.72 |
| Latensi Rata-rata | 7.830 | 7.998 | 9.800 |
Dalam skenario itu saya mengukur peningkatan latensi tulis 25%. Jika Anda mengalami kegagalan total pada AZ, penyimpanan dan instans akan dialihkan ke AZ sekunder dan Anda tidak akan mengalami peningkatan latensi ini sama sekali. Namun, skenario kegagalan lain yang tidak seluas AZ dapat membuat aplikasi terklaster Anda berjalan di satu AZ dengan Azure Shared Disk Anda berjalan di AZ yang berbeda. Dalam skenario tersebut, Anda ingin memindahkan beban kerja yang dikelompokkan kembali ke node yang berada di AZ yang sama dengan penyimpanan Anda sesegera mungkin untuk menghindari overhead tambahan.
Microsoft mendokumentasikan cara memulai failover akun penyimpanan ke wilayah yang berbeda saat menggunakan GRS, tetapi tidak ada cara untuk secara manual memulai failover akun penyimpanan ke AZ yang berbeda saat menggunakan Penyimpanan Zona Redundan. Anda harus memantau instans kluster failover untuk memastikan Anda diberi tahu setiap kali beban kerja kluster pindah ke server lain dan berencana untuk memindahkannya kembali segera setelah aman untuk melakukannya.
Anda dapat menemukan diri Anda dalam situasi ini secara tak terduga, tetapi itu juga pasti akan terjadi selama pemeliharaan terencana dari server aplikasi berkerumun saat Anda melakukan pembaruan bergulir. Kesadaran adalah kunci untuk membantu Anda meminimalkan jumlah waktu penyimpanan Anda bekerja dalam keadaan terdegradasi.
Saya berharap di masa depan Microsoft mengizinkan pengguna untuk memulai failover manual dari disk ZRS sama seperti yang mereka lakukan dengan GRS. Alasan mereka menambahkan fitur ke GRS adalah untuk menempatkan kekuasaan di tangan pengguna jika kegagalan otomatis tidak terjadi seperti yang diharapkan. Dalam kasus Zone Redundant Storage, saya dapat melihat orang-orang yang ingin mencoba menyatukan penyimpanan dan aplikasi, memastikan keduanya selalu berjalan di AZ yang sama, mirip dengan cara solusi replikasi berbasis host seperti SIOS DataKeeper melakukannya.
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