Panduan Dukungan SIOS Enterprise: Apa yang Dicakup oleh Paket Anda

Apa Saja yang Termasuk dalam Paket Dukungan SIOS Enterprise Anda?

Berikut beberapa kiat singkat tentang apa yang tercakup dan tidak tercakup dalam dukungan tingkat perusahaan, dan ke mana harus mencari informasi tambahan berdasarkan tiga skenario umum.

Dukungan 24/7 untuk Waktu Henti Sistem Kritis

Skenario 1: Sistem Mati Setelah Jam Kerja

Tim Joan: Sekarang pukul 7 malam EST pada hari Minggu. Peralihan rutin antar node klaster SIOS LifeKeeper seharusnya berjalan lancar. Namun, sesuatu yang tidak terduga terjadi, mengakibatkan kegagalan peralihan. Terlepas dari semua upaya tim untuk menyelesaikan masalah, klaster tetap mati. Joan membutuhkan bantuan, tetapi dia tidak yakin apakah paket dukungan teknis SIOS-nya mencakup akhir pekan atau berapa lama waktu yang dibutuhkan untuk menghubungi petugas dukungan melalui telepon.

Pelanggan yang telah membeli (atau memperbarui) dukungan tingkat Enterprise mereka sebelum terjadi insiden memiliki akses untuk menerima dukungan 24 jam sehari, 7 hari seminggu. Dukungan ini mencakup akhir pekan dan hari libur untuk menangani Masalah Kritis. Masalah Kritis berarti sistem atau aplikasi produksi yang tidak berfungsi, di mana data Pelanggan tidak dapat diakses menggunakan Program SIOS. Untuk semua masalah Prioritas 1 (kritis), di mana operasi normal mengakibatkan hilangnya akses ke data produksi Anda, SIOS memberikan waktu respons 2 jam.

Jika Joan memiliki dukungan Enterprise yang valid, dia dapat menghubungi tim dukungan SIOS, dan masalahnya di luar jam kerja akan ditangani.

Dukungan Instalasi dan Konfigurasi

Skenario 2: Bantuan Instalasi Diperlukan

Tim Scott: Sekarang pukul 4 sore EST hari Kamis. Persetujuan untuk proyek infrastruktur baru telah selesai, termasuk konfigurasi ketersediaan tinggi yang diperlukan untuk aplikasi dan data penting. Pada pertemuan awal, para pemangku kepentingan menggeser tanggal peluncuran. Akibatnya, tim perlu memasang dan mengkonfigurasi sistem dengan cepat untuk menghindari gangguan layanan. Tim Scott tahu cara mengkonfigurasi aplikasi dan server, tetapi mereka ingin memastikan bahwa mereka memasang solusi HA dengan benar. Mereka membutuhkan bantuan, tetapi Scott tidak yakin apakah paket dukungan mereka mencakup bantuan untuk kesalahan instalasi.

Karena tim Scott sedang dalam fase implementasi, proyek infrastruktur baru ini melibatkan sistem yang belum divalidasi atau berhasil dioperasikan. Jika tim Scott memiliki dukungan SIOS Enterprise level yang valid, ia akan memiliki akses ke dokumentasi produk SIOS dan petunjuk instalasi. Namun, bantuan instalasi dan konfigurasi tidak tercakup dalam dukungan Enterprise Scott, tetapi ia dapat menghubungi perwakilan penjualan SIOS-nya untuk mengatur layanan instalasi Profesional berbayar. Layanan ini akan memastikan bahwa tim Scott mendapatkan bantuan yang mereka butuhkan untuk menginstal, mengkonfigurasi, dan memvalidasi klaster mereka dengan benar. SIOS menyediakan berbagai macamlayanan profesionalDirancang untuk membantu pelanggan menerapkan, mengelola, dan memelihara lingkungan HA mereka dengan cepat dan hemat biaya.

Analisis Akar Penyebab (RCA) Setelah Failover

Skenario 3: Dukungan RCA Pasca-Failover

Tim Amol: Sekarang pukul 2 pagi EST hari Selasa. Sebuah peringatan telah dikirimkan ke seluruh tim aplikasi di AjaxBjax Corp. Klaster yang melindungi sistem aplikasi paling penting perusahaan sedang melakukan failover. Amol memeriksa dasbor aplikasi dan menemukan bahwa failover berhasil dan semua aplikasi berfungsi. Namun, Amol tahu bahwa manajemen akan menginginkan beberapa penjelasan dan jaminan. Amol ingin memastikan bahwa semua layanan aplikasi aktif dan berfungsi, tetapi dia tidak yakin apakah rencana dukungan mereka mencakup hal ini.

Tim Amol sedang mencari RCA (Analisis Akar Penyebab) dan keyakinan bahwa sistem mereka akan terus beroperasi. Data Amol dapat diakses, dan aplikasinya berfungsi penuh. Sistemnya bukan server produksi yang mengalami gangguan kritis, maupun masalah P1. Namun, jika AjaxBjax Corp memiliki dukungan Enterprise yang valid untuk cluster mereka, mereka dapat menghubungi tim dukungan SIOS untuk mendapatkan panduan sepanjang waktu (US East), Senin hingga Jumat, untuk masalah RCA. Panggilan Amol pukul 2 pagi akan dialihkan ke salah satu pusat dukungan SIOS yang berpengalaman, di mana tim akan mulai bekerja sama dengan Amol.

Pertanyaan Tambahan Tentang Menghubungi Dukungan SIOS

Amol dan Joan dapat menghubungi dukungan melalui Saluran Bantuan Dukungan (AS: 877.457.5113; Internasional: +1.803.808.4270) dengan cakupan yang termasuk dalam Dukungan Perusahaan mereka. Scott dapat menerima bantuan yang dibutuhkannya, bukan dari tim Dukungan, tetapi melalui pembelian layanan untuk membantu konfigurasi dan instalasi. Tetapi bagaimana dengan skenario lain, di mana Scott, Amol, Joan, dan yang lainnya dapat menemukan informasi lebih lanjut tentang tingkat dukungan dan detail dukungan mereka? Atau apakah produk mereka telah mencapai fase pemeliharaan atau dukungan diperpanjang?

Jika Anda memerlukan informasi tambahan mengenai perjanjian dukungan Anda, Anda dapat merujuk pada Perjanjian Dukungan Teknis SIOS (TSA), yang disertakan dalam setiap pesanan. TSA juga mudah diakses di situs web kami.situs unduhan, dan dapat diminta melalui email ke Tim Dukungan SIOS disupport@us.sios.comSelain itu, jadwal produk dan informasi tingkat dukungan dapat ditemukan secara online di [tautan].Siklus Hidup Produkhalaman.

Pelanggan yang sudah mengetahui apa saja yang tercakup dalam paket mereka, tetapi membutuhkan bantuan terkait suatu masalah, jawaban atas pertanyaan umum, analisis akar penyebab, perangkat lunak terbaru, atau petunjuk untuk informasi lebih lanjut dapat membuka kasus baru melaluiPortal Dukungansitus web atau melalui email ke Kotak Masuk Dukungan disupport@us.sios.comSetelah kasus Anda dibuat, tim akan berupaya memberikan respons dan solusi tepat waktu.

Penulis: Cassius Rhue, Wakil Presiden, Pengalaman Pelanggan

Direproduksi dengan izin dariSIOS

Mengapa Lingkungan Sandbox Sangat Penting untuk Ketersediaan Tinggi

Meyakinkan Manajemen untuk Berinvestasi pada Infrastruktur Non-Produksi

Meyakinkan manajemen untuk berinvestasi dalam infrastruktur non-produksi bukanlah pekerjaan yang mudah. ​​Jika ditangani secara asal-asalan, diskusi mengenai klaster pengujian tambahan atau lingkungan sandbox dengan cepat berubah menjadi keluhan tentang membayar dua kali lipat untuk suatu lingkungan (infrastruktur, perangkat lunak, sumber daya TI, aplikasi, dan lisensi), dan tuduhan bahwa pengujiangugusan“menghasilkan pendapatan nol”. Diskusi biaya meluas menjadi campuran pernyataan bahwa pencadangan, DevOps, dan buku panduan perangkat lunak telah membuat lingkungan pengujian menjadi usang.

Namun, biaya karena tidak memiliki replika persis dari lingkungan produksi Anda untuk pengujian seringkali jauh lebih tinggi daripada biaya klaster pengujian tambahan. Biaya tambahan ini seringkali muncul dalam bentuk gangguan yang tidak direncanakan, data yang rusak, perbaikan darurat, dan tim teknik yang kelelahan.

10 Pertanyaan untuk Membantu Membenarkan Lingkungan Sandbox

Jika Anda kesulitan mendapatkan persetujuan anggaran untuk lingkungan sandbox yang layak, ajukan 10 pertanyaan ini kepada tim kepemimpinan Anda. Pertanyaan-pertanyaan ini akan mengalihkan percakapan dari biaya cluster duplikat ke nilai memastikan bisnis terhindar dari kerugian.

1. Berapa sebenarnya biaya yang ditimbulkan oleh waktu henti (downtime) bagi organisasi kita?

Mulailah dari inti permasalahannya. Jika sebuah implementasi gagal dan klaster HA produksi mati, berapa biaya yang harus ditanggung organisasi? Berapa kerugian yang kita alami per jam? Berapa tingkat pengeluaran perusahaan kita per unit bisnis?

Pertanyaan ini menggeser percakapan dari pernyataan yang samar ke biaya per menit dari pendapatan yang hilang, gaji karyawan yang menganggur selama pemadaman, dan biaya kerusakan reputasi yang lebih sulit diukur. Jika pemadaman produksi menelan biaya $300.000 per jam, mencegah hanya satu pemadaman selama empat jam setiap tahunnya dapat menghemat $1,2 juta. Dengan angka bisnis yang nyata, ROI dari penerapan sandbox untuk mengurangi risiko pemadaman yang mahal menjadi sangat jelas.

2. Berapa banyak kegiatan pemeliharaan yang kita lakukan setiap bulan?

Sederhana saja: frekuensi sama dengan paparan risiko. Paparan risiko sama dengan biaya tambahan. Jika Anda menerapkan pembaruan, patch, atau perubahan konfigurasi setiap minggu, Anda mempertaruhkan segalanya sebanyak 52 kali dalam setahun. Kembali ke pertanyaan 1: Berapa biaya yang harus ditanggung organisasi akibat satu jam waktu henti karena pembaruan patch yang buruk? Sekarang kalikan angka tersebut dengan frekuensi pemeliharaan Anda.

Seperti yang diingatkan Tristan Allen, Associate Software Engineer di SIOS, kepada pelanggan, sandbox yang merupakan replika dari lingkungan produksi menyediakan lingkungan yang sangat berharga “di mana fitur baru, perubahan konfigurasi, dan patch dapat diuji secara menyeluruh. Di luar pengujian fungsional, lingkungan QA memungkinkan validasi proses, benchmarking kinerja, pengujian beban, dan validasi keamanan. Ini adalah aktivitas penting untuk mengidentifikasi hambatan,kerentananatau masalah integrasi sebelum masalah tersebut berdampak pada pengguna akhir atau membahayakan lingkungan Anda.”

Kecepatan perilisan dan pembaruan pemeliharaan meningkatkan kebutuhan akan jaring pengaman.

3. Seberapa yakin kita untuk menerapkannya ke lingkungan produksi?

Apakah tim selalu menahan napas setiap kali mereka melakukan pembaruan di lingkungan produksi? Berapa kali kita mendengar ungkapan, “Itu hanya perubahan satu baris”? Kesalahan “off by one” dan “null pointer” adalah perubahan kecil yang secara historis menyebabkan waktu henti yang besar. Seberapa yakin Anda dengan kemampuan tim Anda untuk memastikan paket yang baru diimplementasikan bebas dari kesalahan pengkodean, kesalahan logika, masalah arsitektur, ketidakkompatibilitas pihak ketiga, atau kesalahan urutan?

Seberapa yakin tim Anda dengan kesehatan Anda?lingkungan produksiJika lingkungan produksi Anda rentan, klaster sandbox memungkinkan Anda untuk memvalidasi proses penerapan itu sendiri, secara signifikan mengurangi biaya dan tekanan dari pengembalian darurat, serta memvalidasi perbaikan sebelumnya.

4. Seberapa besar toleransi risiko kita dalam menerapkan patch keamanan langsung di lingkungan produksi?

Patch keamanan adalah hal yang mutlak, tetapi terkadang patch tersebut bertentangan dengan pustaka atau konfigurasi yang sudah ada. Menerapkan patch kernel atau pembaruan basis data langsung ke lingkungan produksi adalah sebuah pertaruhan.

Sebagai VP Pengalaman Pelanggan, kami bekerja langsung dengan pelanggan untuk mengembalikan pembaruan kernel yang diterapkan langsung ke lingkungan produksi. Meskipun pembaruan tersebut memperbaiki satu masalah, pembaruan itu memiliki efek samping yang tidak terduga yang sangat berdampak pada lapisan penyimpanan, menyebabkan kebuntuan, kerusakan aplikasi, dan hambatan lainnya.

Jika Anda kesulitan membenarkan penggunaan kluster QA penuh, tanyakan kepada tim manajemen Anda: Apakah kita bersedia mengambil risiko aplikasi bisnis kritis untuk menerapkan patch keamanan? Sandbox memungkinkan Anda untuk menerapkan patch ini di lingkungan yang identik terlebih dahulu, memastikan bahwa “memperbaiki” keamanan tidak “merusak” bisnis. Selain patch, sandbox memungkinkan Anda untuk menyebarkan aplikasi dan pembaruan baru untuk mengeksplorasi kerentanan atau risiko keamanan yang mungkin muncul.

5. Apa dampak finansial dan operasional dari korupsi data?

Waktu henti (downtime) bersifat sementara; kehilangan data bisa bersifat permanen. Perubahan yang tidak kompatibel pada penyimpanan yang mendasarinya, kesalahan logika aplikasi, atau masalah pada driver perangkat dapat secara diam-diam merusak data dengan cara yang tidak langsung terlihat. Apakah Anda ingin lingkungan produksi Anda menjadi tempat di mana Anda menemukan bahwa pembaruan pada alat pencadangan Anda berarti Anda tidak lagi dapat mencadangkan atau memulihkan data aplikasi penting Anda?

Pada saat Anda menyadari kesalahan dalam produksi, Anda mungkin sudah berminggu-minggu terperangkap dalam data yang rusak. Atau Anda mungkin mengalami krisis dan menyadari bahwa cadangan Anda tidak dapat dipulihkan pada perangkat lunak yang baru diperbarui. Sandbox memungkinkan Anda untuk menjalankan pengujian integritas data, migrasi data, pembaruan skema, perubahan driver, dan bahkan skenario perangkat lunak replikasi terhadap salinan data nyata, memastikan bahwa jika data hilang atau rusak, hal itu terjadi di lingkungan yang aman, bukan di lingkungan yang menagih pelanggan Anda.

6. Mampukah kita membiarkan integrasi pihak ketiga gagal tanpa menimbulkan pemberitahuan?

Aplikasi Anda kemungkinan besar bergantung pada API, otentikasi pihak ketiga, aplikasi pihak ketiga, atau bentuk ketergantungan lainnya. Hal-hal ini berperilaku berbeda di bawah beban dan terutama di lingkungan terklaster.

Perubahan yang tidak kompatibel sering kali muncul bukan dari kode Anda, tetapi dari bagaimana kode Anda berinteraksi dengan infrastruktur. Jika suatu perubahan berfungsi di laptop pengembang tetapi gagal ketika didistribusikan ke tiga node, itu adalah gangguan yang menghentikan bisnis. Sandbox menangkap bug “berfungsi di mesin saya” sebelum mencapai pelanggan.

7. Seberapa siapkah kita menghadapi skenario pemulihan bencana (DR) yang sebenarnya?

Sebagian besar organisasi memilikiRencana Pemulihan Bencana (DR)Secara teori, rencana yang belum diuji hanyalah sebuah hipotesis. Satu-satunya cara untuk memvalidasi strategi DR adalah dengan menjalankannya, mensimulasikan kegagalan total situs atau peristiwa kerusakan data. Tanpa klaster sandbox, pengujian rencana DR Anda mengharuskan Anda untuk menargetkan lingkungan produksi Anda. Hal ini menimbulkan risiko, biaya, logistik yang berbahaya, dan waktu henti.

Tanpa klaster sandbox, Anda harus sengaja menonaktifkan sistem penghasil pendapatan untuk memverifikasi apakah sistem tersebut dapat diaktifkan kembali. Hal ini membutuhkan koordinasi besar-besaran antara tim jaringan, penyimpanan, basis data, dan aplikasi. Biaya untuk upaya ini di lingkungan produksi mirip dengan biaya penggunaan meteran air pada sistem yang bocor.

Selain waktu henti (downtime), proses pengujian skenario DR di lingkungan produksi hanya menimbulkan risiko dan kompleksitas. Risikonya meliputi bekerja dengan data langsung dan memastikan kepatuhan yang ketat terhadap semua langkah perlindungan data. Kompleksitasnya biasanya bukan pada proses failover—melainkan pada proses pemulihan. Setelah berhasil melakukan failover ke situs sekunder atau node cadangan, mengembalikan klaster produksi ke keadaan semula (failback) merupakan operasi yang kompleks dan berisiko tinggi.

Ingatkan manajemen bahwa biaya pembuatan sandbox akan memungkinkan tim Anda untuk mensimulasikan kegagalan besar dan menjalankan prosedur pemulihan penuh selama jam kerja tanpa memengaruhi pengguna. Tim dapat bekerja sama untuk menyempurnakan “Buku Panduan Operasional”, menemukan dan menyelesaikan kekurangan proses dengan aman, dan berlatih secara menyeluruh sehingga ketika bencana nyata terjadi, tim menjalankan rutinitas yang terkoordinasi dengan baik daripada eksperimen pertama yang berbahaya.

9. Bagaimana cara kami menerima vendor baru dan melatih tim yang sudah ada?

Organisasi-organisasi yang luar biasa memiliki proses orientasi TI untuk anggota tim baru, vendor, dan penyedia layanan. Organisasi-organisasi ini memahami bahwa kerangka kerja orientasi yang terstruktur dengan baik sangat penting bagi anggota tim baru. Mereka menghargai dan memprioritaskan pembuatan sistem manajemen pembelajaran dan budaya yang kaya akan sumber daya komprehensif yang membantu pendatang baru memahami lingkungan HA (High Availability) kritis yang akan mereka kelola, pelihara, dan perbarui. Mereka juga memahami nilai pembelajaran berkelanjutan dan pendekatan proaktif untuk menjaga keterampilan tim tetap tajam.

Tanpa sistem sandbox yang merupakan replika langsung dari lingkungan produksi, proses onboarding TI Anda harus memanfaatkan klaster produksi Anda. Itu berarti lulusan baru perguruan tinggi tersebut harus belajar cara menjalankan sistem produksi.manajemen patchPerangkat lunak keamanan, dan pembaruan aplikasi dalam lingkungan HA pada sumber pendapatan utama perusahaan. Ketika mereka menemukan bagian yang tidak jelas dalam buku panduan, atau yang secara kebetulan hilang, biaya produktivitas dan risiko kerusakan reputasi bagi mereka dan bisnis dapat sangat merugikan.

Dalam mengadvokasi lingkungan sandbox, tekankan sifat dari proses onboarding berkelanjutan bagi vendor, mitra, dan penyedia layanan terkelola, serta risiko jika tidak ada tempat bagi individu dan tim tersebut untuk mempelajari bisnis atau mengeksplorasi prosedur. Jika organisasi Anda tidak memiliki sistem sandbox, pertimbangkan untuk mengajukan beberapa pertanyaan kepada pimpinan Anda:

• Ke mana anggota tim baru kita akan pergi untuk memahami lingkungan yang akan mereka kelola, pelihara, dan perbarui?
• Bagaimana mereka akan menjaga agar keterampilan mereka tetap mutakhir?
• Sistem apa yang kita gunakan untuk melakukan onboarding tim berikutnya dengan benar bila diperlukan?

10. Apakah biaya asuransi alat bantu dengar lebih murah daripada biaya bencana?

Terakhir, mari kita bahas masalah yang paling penting: biaya peralatan dan perlengkapan.

Ketersediaan Tinggiperangkat lunak pengelompokandan biaya komputasi terkait tidaklah gratis. Namun, bandingkan biaya tahunan lisensi dan infrastruktur sandbox dengan biaya satu kali kejadian downtime besar, rollback, atau kehilangan data. Dalam hampir setiap skenario, biaya pencegahan akan jauh lebih murah daripada biaya penanganannya.

Lingkungan Sandbox Merupakan Investasi Kelangsungan Bisnis

Seperti yang disimpulkan Tristan Allen, Associate Software Engineer di SIOS, dalam blognya:

Lingkungan QA dan produksiMemainkan peran penting dalam menjaga agar sistem berjalan lancar. Dengan menjaga lingkungan tetap terpisah, melakukan pengujian secara menyeluruh, dan mengelola penerapan dengan hati-hati, tim TI dapat mengurangi waktu henti, mempertahankan ketersediaan tinggi, dan membuat transisi antar pembaruan menjadi lancar.

Jika tim manajemen Anda kesulitan memahami manfaat dari lingkungan sandbox penuh, cobalah mengajukan beberapa pertanyaan berikut kepada mereka. Dengan mengajukan pertanyaan-pertanyaan ini, Anda mengalihkan diskusi dari percakapan biaya yang terlalu disederhanakan menuju dialog yang terfokus terkait dengan hal tersebut.kelangsungan bisnis, sehingga memudahkan manajemen untuk menandatangani persetujuan pos anggaran tersebut. Klaster sandbox bukanlah barang mewah; ini adalah aset mitigasi risiko bagi bisnis.

Minta demountuk melihat bagaimana SIOS membantu Anda mengurangi risiko downtime dengan solusi ketersediaan tinggi dan pemulihan bencana yang tangguh.

Penulis: Cassius Rhue, Wakil Presiden Pengalaman Pelanggan di SIOS

Direproduksi dengan izin dariSIOS

Mewarisi DataKeeper

Apa Artinya Mewarisi Lingkungan DataKeeper

Konsep warisan seringkali mengingatkan kita pada aset yang diwariskan dari satu individu ke individu lainnya. Webster dan kamus lainnya mendefinisikan warisan sebagai:

Warisan terdiri dari aset, properti, dan terkadang utang yang ditinggalkan oleh orang yang meninggal, yang dibagikan kepada ahli waris melalui surat wasiat, perwalian, atau hukum pewarisan tanpa wasiat negara bagian. Biasanya termasuk uang tunai, real estat, saham, obligasi, barang pribadi (perhiasan, mobil), dan kepentingan bisnis.”

Dalam dunia TI, pewarisan memiliki sentuhan digital. Ketika seorang Administrator Sistem mewarisi sebuah klaster yang menggunakan alat-alat seperti…Penjaga DataMereka tidak berurusan dengan aset berwujud seperti perhiasan atau properti, melainkan sumber daya digital—bayangkan konfigurasi, peran, dan sumber daya volume kritis. Dan meskipun warisan ini diharapkan merupakan hasil dari seseorang yang pensiun dari perusahaan atau menerima promosi yang layak, kita akan berharap itu bukan karena seseorang beralih ke “pusat data BESAR di langit.” (Ya, humor adalah mekanisme penanggulangan bagi para profesional TI!)

Jadi, jika Anda beruntung mendapatkan klaster 1×1 yang sudah ada dengan peran SQL Server dan sumber daya DataKeeper Volume terkait, dari mana Anda harus memulai? Langkah-langkah apa yang harus Anda ambil untuk memastikan proses orientasi dan transfer pengetahuan yang lancar?

Untuk membantu memandu transisi tersebut, berikut beberapa pertanyaan kunci yang harus Anda ajukan kepada diri sendiri atau Tim Manajemen Anda:

Pertanyaan Administrasi Akun

Detail Manajer Akun

• Siapakah Manajer Akun yang saat ini bertanggung jawab atas akun ini?
  • Apa saja detail kontak mereka (email, telepon, dll.)?

Informasi Perizinan

• Bagaimana status perjanjian lisensi, kontrak, dan perpanjangan Anda?
• Apakah ada masa berlaku lisensi atau tenggat waktu perpanjangan yang perlu diperhatikan?
• Di mana saya dapat mengakses portal perizinan, dan apakah saya memiliki kredensial yang diperlukan?

Pertanyaan Administrasi DataKeeper

Memahami Lingkungan

• Menilai infrastruktur yang ada saat ini, termasukKlaster Failover Windows Serverpengaturan, server, penyimpanan, dll.
• Beban kerja dan aplikasi apa saja yang saat ini dilindungi oleh DataKeeper?

Konfigurasi dan Manajemen

• Pelajari konfigurasi DataKeeper.
  • Jenis pencermian Asinkron dan Sinkron apa yang digunakan?
  • Bagaimana konfigurasi node klaster?
  • Penyimpanan apa yang dibutuhkan?

Pemeliharaan dan Pembaruan Perangkat Lunak

• Bagaimana cara tetap mendapatkan informasi terbaru tentang rilis, patch, dan pembaruan untuk DataKeeper?

Pengujian Failover dan Pemulihan

• Sesekali, uji failover untuk memastikan konfigurasi HA dan DR berfungsi sebagaimana mestinya.
• Apakah data yang dicerminkan konsisten dan dapat dipulihkan jika terjadi bencana?

Memahami Kepemilikan dan Ketergantungan Sumber Daya

Setelah Anda memahami sebanyak mungkin tentang warisan Anda, langkah selanjutnya adalah mulai merawat apa yang telah diberikan kepada Anda, seperti yang digambarkan dalam ilustrasi di atas. Ketika “mewarisi” kepemilikan suatuKlaster SQL ServerOleh karena itu, sangat penting untuk mengidentifikasi dan berkomunikasi dengan semua tim lintas fungsi yang terdampak oleh administrasi klaster. Beberapa area kunci, karena jumlahnya banyak, yang perlu difokuskan meliputi:

Tim SQL Server atau Aplikasi

• Mendapatkan pemberitahuan proaktif tentang setiap perubahan yang direncanakan pada nama atau instance SQL Server.
• Diberi tahu tentang penyisipan atau operasi SQL besar yang dapat memengaruhi kinerja klaster.
• Berikan detail mengenai lokasi file basis data, cadangan, dan snapshot.

Tim Jaringan

• Komunikasikan rencana untuk memindahkan peran SQL atau sumber daya terkait ke jaringan yang berbeda.
• Bagikan informasi tentang alamat IP baru atau perubahan terkait jaringan lainnya yang dapat memengaruhi operasi klaster.

Tim Penyimpanan

• Berhati-hatilah saat melakukan perubahan pada volume Sumber dan Target (misalnya, mengubah ukuran, memformat, atau menambahkan partisi) karena hal ini dapat berdampak pada replikasi DataKeeper.
• Apakah bandwidth yang tersedia mencukupi untuk mirror yang ada?
  • Apakah Anda dapat berkolaborasi dengan Tim Jaringan untuk memastikan bandwidth mencukupi, terisolasi dari aplikasi lain untuk menghindari hambatan?

Mengapa Runbook Penting dalam Lingkungan DataKeeper:

Runbook merupakan bagian penting dari kelancaran operasional dan memberikan solusi yang baik untuk lingkungan yang menggunakan DataKeeper, bagi administrator klaster dan teknologi terkait. Idealnya, runbook yang dirancang dengan baik harus menjadi “dokumen hidup” yang berkembang seiring waktu, mencerminkan perubahan dalam infrastruktur, alur kerja, dan praktik terbaik. Jika administrator sebelumnya telah melakukan uji tuntas, runbook Anda seharusnya memiliki cakupan komprehensif di area berikut:

• Perbaikan/Pemecahan Masalah:Menangani masalah yang diketahui, yang dapat berada di mana saja dalam “stack,” misalnya, Lapisan Fisik hingga Lapisan Aplikasi.
• Alur kerja:Menerapkan perangkat lunak dan mengelola operasi klaster sehari-hari secara rutin.
• Pemeliharaan:bagaimanamanajemen patchdilakukan, pencadangan basis data, dll.
• Dukungan vendor:bagaimanahubungi SIOSMicrosoft, AWS, dan penyedia lainnya
  • Yang terpenting, kapan harus “menghubungi” mereka?

Poin-Poin Penting untuk Mewarisi DataKeeper

Blog ini menyoroti beberapa poin penting untuk menavigasi transisi tersebut, termasuk administrasi akun, kepemilikan sumber daya, kolaborasi lintas fungsi, dan nilai dari runbook. **Namun, penting untuk dicatat bahwa ini hanyalah beberapa pertimbangan di antara banyak hal lain yang mungkin berada di luar cakupan diskusi ini. Setiap lingkungan unik, dan administrasi klaster yang sukses membutuhkan pemahaman menyeluruh tentang infrastruktur, dependensi, dan alur kerja spesifik yang terlibat.**

Nikmati “warisan” Anda . . .

Jangan habiskan semuanya di satu tempat…

Minta demountuk melihat bagaimana SIOS DataKeeper dapat membantu menyederhanakan administrasi klaster dan mendukung ketersediaan tinggi.

Penulis: Greg Tucker, Insinyur Dukungan Produk Senior di SIOS

Direproduksi dengan izin dariSIOS

Ketersediaan Tinggi vs. Toleransi Kesalahan: Perbedaan Utama Dijelaskan

Ketersediaan Tinggi (High Availability) vs. Toleransi Kesalahan (Fault Tolerance) adalah perbandingan umum ketika mengevaluasi desain sistem yang dapat digunakan bersama untuk menciptakan infrastruktur yang selalu aktif dan berfungsi. Tujuan dari Ketersediaan Tinggi adalah untuk memastikanwaktu henti minimalSedangkan tujuan dari toleransi kesalahan adalah untuk memungkinkan infrastruktur tetap berjalan meskipun terjadi kegagalan.

Apa itu Ketersediaan Tinggi?

Ketersediaan TinggiBerfungsi sebagai cara untuk memastikan waktu henti minimal dengan menjamin bahwa sistem akan beroperasi setidaknya selama 99% dari waktu. Hal ini dicapai melalui pemantauan terus-menerus terhadap kesehatan infrastruktur.

Ketersediaan Tinggi bisa tiga (99,9%), empat(99,99%), atau lima (99,999%) angka sembilan. Setiap angka sembilan mewakili perkiraan waktu aktif infrastruktur. Standarnya adalah 99,99%, di mana perkiraan waktu henti per tahun adalah 52,60 menit.

Perangkat lunak sepertiSIOS LifeKeeper dan DataKeeperMenyediakan ketersediaan tinggi 99,99% melalui pemantauan dan pencegahan waktu henti yang lama dengan mengotomatiskan failover dan mereplikasi data.

Apa itu toleransi kesalahan?

Tujuan dariToleransi KesalahanTujuannya adalah untuk menghilangkan satu titik kegagalan guna memastikan infrastruktur tetap berjalan jika terjadi kegagalan. Hal ini mencegah terjadinya downtime dan kehilangan data.

Toleransi kesalahan dapat dicapai melalui deteksi kesalahan, penyeimbangan beban, dan/atau layanan mikro. Misalnya, jika terjadi lalu lintas tinggi yang masuk ke jaringan, penyeimbangan beban diterapkan untuk mengalihkan lalu lintas ke server lain, mencegah kegagalan yang disebabkan oleh beban berat.

Perbandingan Biaya Ketersediaan Tinggi vs. Toleransi Kesalahan

Dalam perbandingan Ketersediaan Tinggi vs. Toleransi Kesalahan, infrastruktur toleransi kesalahan biasanya lebih mahal daripada infrastruktur ketersediaan tinggi karena peningkatan jumlah perangkat lunak dan perangkat keras yang digunakan. Memelihara infrastruktur yang terus berjalan dan mengalami waktu henti yang hampir negligible akan membutuhkan lebih banyak redundansi perangkat keras dan perangkat lunak.

Kasus Penggunaan Ketersediaan Tinggi

Ketersediaan Tinggi dalam Layanan Keuangan

Bank bertujuan untuk mempertahankan ketersediaan yang tinggi agar memungkinkan pemrosesan yang berkelanjutan.finansialtransaksi. Untuk melakukan hal tersebut, lingkungan tipikal membutuhkan basis data dan konfigurasi yang memungkinkan failover jika terjadi kegagalan.

Ketersediaan Tinggi untuk Layanan Streaming

Layanan streaming, terutama siaran langsung, bertujuan untuk menyediakan konten audio dan/atau video secara terus menerus untuk mempertahankan penggunanya. Hal ini, pada gilirannya, memberikan pengalaman yang lancar bagi pengguna, memungkinkan mereka untuk terus menggunakan dan mengoperasikan produk tersebut.

Kasus Penggunaan Toleransi Kesalahan

Toleransi Kesalahan dalam Pelayanan Kesehatan

Banyak perangkat penting yang digunakan di rumah sakit, seperti sistem pendukung kehidupan, ventilator, mesin dialisis, dan lain-lain, selalu beroperasi 24 jam sehari, 7 hari seminggu. Hal ini untuk memastikan pasien mendapatkan perawatan penyelamatan jiwa tanpa gangguan.

Toleransi Kesalahan untuk Situs Web

Situs web, seperti platform e-commerce, yang memiliki lalu lintas tinggi akan menampung berbagai bagian situs di beberapa server. Jika terjadi kegagalan pada salah satu server, situs tersebut akan tetap berjalan dan dapat diakses.

Kesimpulan: Ketersediaan Tinggi vs. Toleransi Kesalahan

Jika kita melihat perbandingan antara High Availability dan Fault Tolerance, jelas bahwa keduanya memiliki tujuan yang berbeda. Fault tolerance bertujuan untuk memastikan waktu operasional yang tidak terganggu jika terjadi kegagalan. Sementara itu, High Availability bertujuan untuk meminimalkan waktu henti melalui pemulihan yang cepat.

Saat organisasi mengevaluasi ketersediaan tinggi versus toleransi kesalahan, SIOS membantu menyederhanakan jalan menuju waktu operasional yang lebih kuat dan pemulihan yang lebih cepat.Minta demo untuk mempelajari lebih lanjut.

PengarangAlexus Gore, Insinyur Perangkat Lunak Pengalaman Pelanggan di SIOS Technology Corp.

Direproduksi dengan izin dariSIOS

Perencanaan Kelangsungan Bisnis untuk Ketersediaan Tinggi dan Pemulihan Bencana

Mengapa Setiap Bisnis Membutuhkan Strategi untuk Kelangsungan Bisnis dan Ketersediaan Tinggi

Bisnis modern bergantung pada aplikasi dan data untuk beroperasi. Ketika sistem tersebut mengalami gangguan, dampaknya bisa langsung terasa, memengaruhi produktivitas, pendapatan, dan kepercayaan pelanggan. Itulah mengapa organisasi membutuhkan strategi Kelangsungan Bisnis dan Ketersediaan Tinggi yang kuat untuk memastikan sistem-sistem penting tetap beroperasi bahkan ketika infrastruktur gagal.

Dengan menggabungkan infrastruktur yang tangguh dengan solusi ketersediaan tinggi yang peka terhadap aplikasi, bisnis dapat meminimalkan waktu henti dan menjaga konsistensi.waktu aktifselama gangguan yang tak terduga.

Apa Itu Rencana Kelangsungan Bisnis?

Kesinambungan bisnis mengacu pada kemampuan suatu organisasi untuk mempertahankan operasional selama dan setelah terjadi gangguan. Kegagalan dapat terjadi karena berbagai alasan, termasuk masalah perangkat keras, bug perangkat lunak, serangan siber, atau bencana alam.

Tanpa rencana keberlanjutan bisnis, bahkan pemadaman singkat pun dapat mengganggu layanan dan menyebabkan kemunduran operasional yang besar. Rencana keberlanjutan bisnis yang kuat memastikan aplikasi, sistem, dan data penting tetap dapat diakses saat paling dibutuhkan.

Komponen Utama dari Rencana Kelangsungan Bisnis

Rencana keberlangsungan bisnis yang umum mencakup:

• Penilaian risiko untuk mengidentifikasi potensi ancaman.
• Analisis dampak bisnis untuk menentukan sistem-sistem kritis.
• Rencana komunikasi untuk karyawan dan pemangku kepentingan
• Prosedur pemulihan untuk sistem dan aplikasi TI
• Pengujian rutin untuk memvalidasi proses pemulihan.

Komponen-komponen ini membantu organisasi mempersiapkan diri menghadapi gangguan sebelum gangguan tersebut terjadi.

Penjelasan Ketersediaan Tinggi

Ketersediaan Tinggi (HA)Mengacu pada perancangan sistem yang tetap beroperasi bahkan ketika komponen mengalami kegagalan. Hal ini sering dicapai melalui pengelompokan (clustering), redundansi, dan failover otomatis yang mengalihkan beban kerja ke sistem siaga.

Alat ketersediaan tinggi tingkat aplikasi dapat memantau aplikasi tertentu dan secara otomatis memulai ulang atau mengalihkan aplikasi tersebut jika terjadi kegagalan, sehingga mengurangi waktu henti dan menjaga kesinambungan layanan.

Pentingnya Manajemen Uptime

Manajemen waktu aktif yang efektif memerlukan pemantauan terus-menerus dan desain infrastruktur yang proaktif. Organisasi harus melacak kesehatan sistem dan memastikan sistem cadangan siap mengambil alih ketika terjadi masalah.

Praktik umum manajemen waktu aktif (uptime) meliputi:

• Memantau kesehatan aplikasi dan server.
• Menerapkan redundansi di seluruh sistem
• Mengotomatiskan proses failover
• Memastikan penerapan patch dan pembaruan yang konsisten.

Praktik-praktik ini membantu menjaga agar sistem-sistem yang sangat penting untuk misi tetap tersedia.

Manfaat Ketersediaan Tinggi dalam Bisnis

Ketersediaan tinggi memberikan beberapa manfaat utama:

• Mengurangi waktu henti untuk aplikasi penting.
• Peningkatan pengalaman pelanggan dan keandalan.
• Pemulihan lebih cepat dari kegagalan
• Ketahanan operasional yang lebih besar

Bagi organisasi yang bergantung pada layanan digital, menjaga ketersediaan tinggi sangat penting untuk kelangsungan bisnis.

Perencanaan Pemulihan Bencana

Apa itu Pemulihan Bencana TI?

Meskipun ketersediaan tinggi berfokus pada meminimalkan waktu henti selama kegagalan lokal,Pemulihan bencana TImenangani insiden yang lebih besar seperti pemadaman pusat data atau gangguan regional.

Strategi pemulihan bencana memastikan sistem dan data dapat dipulihkan dengan cepat setelah terjadi peristiwa besar.

Langkah-langkah untuk Mengembangkan Rencana Pemulihan Bencana yang Efektif

Efektifperencanaan pemulihan bencanabiasanya meliputi:

1. Mengidentifikasi aplikasi dan infrastruktur penting.
2. Menentukan tujuan pemulihan seperti RTO dan RPO.
3. Menerapkan sistem pencadangan dan replikasi
4. Mendokumentasikan prosedur pemulihan
5. Menguji skenario pemulihan secara berkala

Langkah-langkah ini membantu organisasi pulih dengan cepat dan menghindari waktu henti yang berkepanjangan.

Penyeimbangan Beban untuk Kinerja dan Keandalan

Load balancing mendistribusikan beban kerja ke beberapa server untuk meningkatkan kinerja dan keandalan. Dengan menyebarkan lalu lintas ke seluruh sistem, organisasi mencegah server individual menjadi kelebihan beban.

Jenis-jenis Teknik Penyeimbangan Beban

Teknik penyeimbangan beban yang umum meliputi:

• Distribusi permintaan secara bergilir (round-robin).
• Perutean koneksi paling sedikit
• Distribusi lalu lintas geografis
• Perutean berdasarkan pemeriksaan kesehatan

Load balancing mendukung ketersediaan tinggi dengan memastikan lalu lintas dapat secara otomatis beralih ke sistem yang sehat ketika server mengalami kegagalan. Hal ini meningkatkan kinerja dan keandalan bagi pengguna.

Strategi Replikasi Data

Replikasi data memastikan bahwa data penting tersedia di beberapa lokasi. Jika suatu sistem atau situs tidak tersedia, salinan data lain dapat digunakan untuk memulihkan operasional.

Strategi replikasi data yang umum meliputi:

• Replikasi sinkron untuk perlindungan waktu nyata
• Replikasi asinkron untuk lingkungan terdistribusi

Replikasi snapshot untuk pencadangan berkala

Praktik Terbaik untuk Menerapkan Replikasi Data

Untuk memastikan replikasi yang andal:

• Mereplikasi data di berbagai infrastruktur atau wilayah yang berbeda.
• Selaraskan replikasi dengan tujuan pemulihan.
• Pantau kinerja replikasi.
• Uji proses failover secara berkala.

Praktik-praktik ini membantu memastikan ketersediaan data saat terjadi gangguan.

Memperkuat Kelangsungan Bisnis dan Ketersediaan Tinggi

Strategi yang kuat untuk Kelangsungan Bisnis dan Ketersediaan Tinggi membantu organisasi menjaga aplikasi penting tetap berjalan, bahkan selama kegagalan yang tidak terduga. Menggabungkanarsitektur ketersediaan tinggiPerencanaan pemulihan bencana, teknik penyeimbangan beban, dan strategi replikasi data menciptakan lingkungan TI yang tangguh.

Perusahaan harus secara teratur mengevaluasi strategi ketersediaan tinggi dan pemulihan bencana mereka. Menerapkan solusi ketersediaan tinggi tingkat aplikasi, failover otomatis, dan sistem replikasi yang kuat dapat secara signifikan mengurangi waktu henti dan melindungi operasi penting.

Perkuat perencanaan kesinambungan bisnis Anda dengan solusi ketersediaan tinggi SIOS yang dirancang untuk meminimalkan waktu henti, mengotomatiskan failover, dan menjaga agar aplikasi penting tetap berjalan.Minta demoHari ini.

Pengarang: Ben Roy, Spesialis Pemasaran di SIOS

Direproduksi dengan izin dariSIOS