Tujuh Keterampilan Yang Dibutuhkan Tim Anda jika Anda Menggunakan Sumber Terbuka dengan Ketersediaan Tinggi

Di ranah Ketersediaan Tinggi (HA) ada keterampilan penting tertentu yang dibutuhkan tim Anda jika Anda memutuskan untuk menggunakan sumber terbuka. Sumber terbuka menurut definisi menunjukkan perangkat lunak yang tersedia secara bebas untuk digunakan.

Saat ini, ada banyak implementasi komersial dari cluster ketersediaan tinggi untuk banyak sistem operasi yang disediakan oleh vendor seperti Microsoft dan SIOS Technology Corp. Solusi komersial ini menyediakan pemantauan sumber daya, manajemen ketergantungan, kebijakan failover dan cluster, dan beberapa bentuk manajemen yang telah dikemas dan diberi harga.Alternatif untuk implementasi komersial adalah beberapa opsi open source yang juga memberi perusahaan kesempatan untuk menyediakan ketersediaan tinggi untuk perusahaan mereka.

Karena perusahaan terus mencari pengoptimalan, penghematan biaya, dan potensi kontrol yang lebih ketat, semakin banyak perusahaan dan pelanggan juga mempertimbangkan untuk pindah ke solusi ketersediaan sumber terbuka.

Berikut tujuh keterampilan yang mungkin dibutuhkan tim Anda untuk pindah ke Open Source HA:

1. Keterampilan coding

Dalam banyak kasus, kurangnya dukungan yang dikemas dan dipaketkan untuk aplikasi perusahaan berarti bahwa tim Anda harus dapat mengembangkan solusi untuk melindungi komponen, memperbaiki masalah dengan komponen yang dibundel, atau menulis konektor aplikasi untuk memastikan kesadaran aplikasi ditangani dengan benar.Banyak orang dapat menulis skrip, tetapi tim Anda perlu mengetahui cara membuat dan mematuhi praktik dan standar pengembangan yang baik.Dasar-dasar ini mencakup hal-hal seperti:

• Persyaratan Desain dan Arsitektur
• Ulasan Desain
• Tinjauan Kode / Kode dan Tes Unit (lebih disukai otomatis)

2. Pengetahuan tentang lingkungan teknologi

Banyak aplikasi perusahaan memerlukan integrasi dengan beberapa sistem untuk menyediakan ketersediaan tinggi yang memenuhi Perjanjian Tingkat Layanan (SLA) dan Sasaran Tingkat Layanan (SLO).Tim Anda akan membutuhkan kesadaran aplikasi yang mendalam dan pengetahuan tentang lingkungan teknologi untuk membangun perlindungan dan solusi untuk integrasi ini dengan beberapa sistem perusahaan.Anda membutuhkan orang-orang yang mengetahui seluk beluk aplikasi kritis, lingkungan teknologi untuk aplikasi tersebut, jaringan, perangkat keras, hypervisor, dan pemahaman tentang ketergantungan lingkungan dan aplikasi.Anda juga memerlukan anggota tim yang memahami arsitektur, fitur, dan batasan dari rangkaian teknologi HA yang ingin Anda gunakan dari komunitas Open Source. Pertimbangkan seberapa banyak dari area berikut yang diketahui dan dipahami oleh tim Anda:

• Pengiriman data dan komunikasi node
• Kegagalan node
• Manajemen aplikasi
• Pemulihan sistem dan mulai ulang
• Logging dan pesan
• Ketahanan dan perlindungan data

3. Pengetahuan proses bisnis

Anda membutuhkan seseorang untuk memahami kebutuhan bisnis Anda, dan proses bisnisnya.Tim Anda membutuhkan profesional yang memahami bisnis perusahaan dan proses yang mendorongnya.Tim Anda perlu mengetahui dan memahami berapa banyak anggaran yang tersedia untuk dibelanjakan untuk mengembangkan solusi, seberapa besar risiko yang bersedia diambil oleh bisnis, dan cara mengumpulkan persyaratan tambahan yang mungkin tidak terucapkan atau tidak ditentukan.

Tim juga perlu mengetahui, atau mempekerjakan seseorang yang tahu bagaimana mengubah persyaratan bisnis tersebut menjadi persyaratan perangkat lunak dan bagaimana mengelola proses yang menghasilkan solusi ketersediaan tinggi minimum yang layak untuk membuahkan hasil yang memenuhi kebutuhan bisnis, kecepatan bisnis, dan cocok dengan proses bisnis.

4. Pengalaman dengan OS, Aplikasi dan Infrastruktur

Jika Anda ingin semuanya terbuka, tim Anda akan membutuhkan pengalaman memahami Sistem Operasi, Aplikasi, dan Infrastruktur.Anda perlu memahami berbagai siklus rilis OS, termasuk versi kernel untuk Linux, pembaruan, dan perbaikan terbaru untuk Windows.Anda memiliki aplikasi internal yang perlu didukung, tetapi Anda juga harus rajin memahami siklus pembaruan aplikasi, ketergantungannya, dan titik temu antara aplikasi dan matriks dukungan OS.Jika lingkungan Anda homogen, bagus.Jika tidak, tim Anda perlu mengetahui perbedaan antara RHEL, turunan RHEL, dan SUSE.Jika Anda adalah Linux dan Windows, Anda juga perlu mengetahuinya.Anda juga perlu memahami perbedaan yang akan dihasilkan infrastruktur pada aplikasi dan kombinasi OS.AWS dan Azure menghadirkan perbedaan untuk ketersediaan tinggi yang berbeda dari GCP, on-premise, dan hypervisor lainnya.

5. Ubah kemampuan manajemen

Bayangkan Anda memiliki tim pengembangan untuk membuat solusi, dengan pengetahuan teknis dan bisnis bersama dengan pemahaman yang kuat tentang OS, Infrastruktur, dan Aplikasi.Tapi, menyatukan skrip hanyalah permulaan.Tim Anda juga membutuhkan kemampuan manajemen perubahan.Bagaimana tim Anda akan melacak perubahan kode dan versi, paket, dan lokasi paket?Bagaimana tim Anda akan mengelola rilis pembaruan dan perubahan?Tim Anda harus berpengalaman dalam repositori sumber, seperti git, alat manajemen proyek, seperti Jira, dan keahlian rilis kereta.Anda akan membutuhkan tim yang memahami cara memperbarui kode, mengirimkan tambalan dan perbaikan, sambil menghindari dampak yang tidak diinginkan.

6. Pengalaman analitik data dan pemecahan masalah

Saat Anda memasuki ruang penyampaian solusi HA Anda sendiri, tim Anda akan membutuhkan analitik dan pengalaman pemecahan masalah.Anda harus memiliki sumber daya yang memahami persimpangan kode aplikasi, pesan sistem, dan log kesalahan aplikasi serta file pelacakan.Saat terjadi kerusakan sistem, Anda harus menggali log lebih dalam untuk memecahkan masalah dan menemukan akar penyebabnya, menganalisis data untuk membuat rekomendasi, dan bersiap untuk meluncurkan perubahan (lihat # 5 di atas).Jangan lupa, tim Anda juga perlu mengetahui dan memahami apa yang dapat diberitahukan oleh data dari log dan file pelacakan ini kepada Anda tentang kesehatan lingkungan Anda meskipun tidak ada kesalahan, kegagalan, atau kerusakan sistem.

7. Koneksi (Dev, QA, Partners, Community)

Jujur saja, bisnis Anda bukan tentang memberikan ketersediaan tinggi, tetapi jika Anda memutuskan untuk terjun ke dunia HA open source, Anda akan membutuhkan lebih banyak bantuan daripada hanya kecemerlangan dalam tim Anda.Kunci untuk mendapatkan bantuan tambahan tersebut adalah memahami dari mana harus memulai dan kemudian membuat koneksi yang tepat dengan pengembang komunitas, orang-orang yang ahli dalam pengujian, HA dan mitra aplikasi, dan komunitas sumber terbuka.Forum terbuka sangat membantu, tetapi Anda harus memeriksa ulang apakah waktu respons sesuai dengan SLA dan SLO Anda.

Menggunakan solusi Open Source adalah pilihan yang dipilih banyak perusahaan untuk mengejar masalah biaya dan persepsi tentang fleksibilitas, biaya lebih rendah, dan risiko lebih sedikit.Namun, pembeli berhati-hatilah, mungkin ada biaya tersembunyi dalam bentuk keterampilan dan manajemen baru, dan risiko tersembunyi dalam hal program sumber terbuka yang Anda gunakan yang akan diperlukan untuk setiap solusi "roll your own HA".

– Cassius Rhue, VP, Pengalaman Pelanggan

Direproduksi dari SIOS

Pada tahun 2020, kami telah melihat lebih banyak perusahaan yang memigrasikan lebih banyak aplikasi penting, ERP, dan database mereka ke cloud. Namun, tidak semua migrasi ini mulus. Saya secara pribadi telah menyaksikan proyek migrasi cloud secara dramatis melambat dan bahkan berhenti karena kurangnya perencanaan untuk ketersediaan aplikasi, kompleksitas perkuatan 'DIY Ketersediaan Tinggi', kesalahpahaman terkait dengan apa yang diperlukan 'pengangkatan dan pergeseran' dan biaya tak terduga.

Ada sejumlah praktik terbaik, daftar periksa cloud, dan cara lain bagi organisasi untuk mempersiapkan cloud. Praktik terbaik berikut harus diperhitungkan dalam setiap strategi migrasi untuk pengelompokan ketersediaan tinggi bagi mereka yang telah mencapai jeda pada migrasi cloud tahun 2020 mereka, atau berencana untuk terus maju pada tahun 2021.

Praktik Terbaik Migrasi Cloud

Kumpulkan persyaratannya

Banyak organisasi yang pindah ke cloud berpikir bahwa cloud adalah arsitektur lokal yang dipindahkan ke cloud. Kesalahpahaman dalam migrasi cloud ini sering menyebabkan kemacetan dan penundaan saat jaringan, penyimpanan, kecepatan disk, dan ukuran sistem untuk lokal bertabrakan dengan realitas cloud. Transisi yang lebih mulus ke cloud dimulai dengan mengumpulkan persyaratan nyata untuk infrastruktur, tata kelola dan kepatuhan, keamanan, ukuran, serta kontrol dan sumber daya terkait.

Desain dan Dokumen

Dalam fase desain, arsitektur lingkungan lokal dipetakan ke lingkungan cloud yang telah dipilih untuk ketersediaan maksimum dan didokumentasikan secara menyeluruh. Dalam fase ini, saat arsitektur mulai terbentuk dan Anda mengidentifikasi strategi untuk IP, penyeimbang beban, IOPS, dan ketersediaan data. Tim perlu melihat bagaimana ketersediaan yang asli dari cloud perlu ditambah dengan aplikasi yang kuat dan solusi ketersediaan infrastruktur yang mampu mengotomatiskan kompleksitas cloud. Di SIOS, para ahli kami dalam pengelompokan dan ketersediaan AWS dan Azure bekerja dengan pelanggan untuk menukar NFS di lokasi dengan AWS EFS, Azure ANF, atau tingkat klaster NFS mandiri. Selain itu, bagian penting dari keberhasilan implementasi dalam fase ini adalah mendokumentasikan semuanya. Dokumentasi adalah elemen yang sering diabaikan, tetapi merupakan elemen penting dari keberhasilan migrasi.

Rencanakan untuk Ketersediaan Tinggi

Mencapai ketersediaan tinggi di cloud membutuhkan pemahaman tentang persyaratan, membuat desain, dan mendokumentasikan rencana yang menjabarkan strategi untuk mencapai persyaratan tersebut. Sebuah rencana dasar harus mencakup kepegawaian, pelatihan staf, penerapan pengujian sistem QA, langkah-langkah pra-produksi, penerapan, validasi pasca penerapan, dan iterasi yang sedang berlangsung. Hasil terbaik untuk migrasi cloud muncul dari proses yang direncanakan dan disengaja; bukan pendekatan ad hoc, pemecahan masalah.

Staf

Seberapa baik staf Anda dalam migrasi cloud? Meja bantuan tradisional, TI klien / server, atau tim TI mungkin tidak cukup untuk migrasi cloud. Jika tim Anda baru mengenal cloud, mungkin sudah waktunya untuk mempertimbangkan menambahkan lebih banyak sumber daya atau solusi berbasis layanan profesional. Bermigrasi ke cloud dapat melelahkan, membosankan, dan sulit tanpa wawasan, informasi, atau pelatihan yang tepat. Apakah staf Anda perlu memasukkan pelatihan yang terkait dengan lingkungan cloud? Dan saat Anda mencari pelatihan dan layanan profesional untuk membantu tim TI Anda, tanyakan kepada vendor Anda untuk pelatihan yang terkait dengan solusi ketersediaan. Banyak vendor memberikan pelatihan fleksibel untuk solusi HA dan pelatihan cloud dapat diperoleh dengan vendor cloud atau situs populer seperti Udemy.

Terapkan QA

Fase penerapan QA adalah fase di mana tim menjalankan rencana untuk menerapkan sistem aktual ke cloud. Tim penerapan yang berhasil memvalidasi rencana dan strategi mereka, memahami proses migrasi data, mengungkap ketergantungan yang hilang, dan mempersiapkan langkah selanjutnya dalam proses tersebut, terutama pengujian. Saat langkah ini dilewati atau dilewati, migrasi yang dulu menjanjikan sering kali terhenti atau gagal. Saat Anda mencapai fase penerapan sistem QA, tim Anda akan melakukan tugas berat pada migrasi awal dan konfigurasi aplikasi, database, dan data penting di cloud.

Uji Ketersediaan Tinggi Anda

Menguji di lingkungan QA Anda adalah langkah penting. Tes ini tidak membuang-buang waktu; mereka adalah penghemat waktu. Menerapkan lingkungan di cloud seringkali lebih mudah daripada menerapkan di lokasi. Lingkungan QA Anda dapat dibuat skrip dengan alat seperti Ansible, digunakan dengan cepat sebagai templat dari pasar cloud atau gambar kloning, atau diterapkan dan dibangun dari templat pembentukan awan. Setelah diterapkan, skenario bencana dapat diselesaikan dan dioptimalkan sebelum bencana, bukan di dalamnya. Skenario pengujian dapat dimanfaatkan untuk mengidentifikasi overprovisioning, under-provisioning, atau bottleneck dengan kecepatan jaringan atau disk. Skenario pengujian lengkap juga dapat digunakan sebagai bagian dari strategi orientasi untuk staf baru. Selain itu, pengujian juga harus dilakukan pada snapshot dan backup.

Terapkan Produksi

Saat fase pengujian selesai, dan tim Anda telah memvalidasi hasil pengujian, fase selanjutnya adalah beralih dari QA ke praproduksi, dan dari praproduksi ke go-live. Fase pengujian adalah fase terakhir dari pengangkatan berat yang melibatkan pengujian penerimaan pengguna akhir, pemotongan akhir dan pembaruan data produksi, dan kemudian pengguna.

Review, Revisi, dan Ulangi

Migrasi yang berhasil tidak berakhir setelah Anda mencapai fase go-live, tetapi berlanjut melalui fase siklus proses. Pada fase pasca go-live dari strategi migrasi cloud, tim Anda terus meninjau, merevisi, dan mengulangi langkah-langkah dari 'Kumpulkan' hingga 'Terapkan Produksi'. Faktanya, tim Anda harus mengulangi proses ini berulang kali, berdasarkan persyaratan khusus untuk rilis, pembaruan aplikasi, pembaruan keamanan, pemeliharaan sistem terkait, versi sistem operasi, perencanaan pemulihan bencana, serta persyaratan dari vendor ketersediaan tinggi Anda sendiri. praktek. Platform cloud selalu berkembang dan menambahkan fitur, fungsionalitas, dan pembaruan baru yang dapat meningkatkan solusi dan arsitektur HA Anda yang ada. Meninjau, merevisi, dan mengulangi proses akan menjadi langkah penting dalam orientasi yang sukses.

Pada tahun 2021, kita akan melihat lebih banyak perusahaan memigrasikan lebih banyak aplikasi, ERP, dan database yang sangat penting ke cloud. Faktor utama utama dalam kesuksesan mereka adalah memanfaatkan praktik terbaik migrasi cloud untuk menghindari penundaan dan kegagalan selama proses. Memahami persyaratan dan kebutuhan bisnis Anda, mendokumentasikan desain dan rencana, menerapkan dalam lingkungan QA dengan solusi pengelompokan yang dibuat khusus, dan menjalankan pengujian ekstensif sebelum go-live akan menjadi penting. Hubungi Teknologi SIOS untuk memahami bagaimana SIOS Protection Suite dapat disertakan dalam praktik terbaik migrasi cloud yang bijaksana.

-Cassius Rhue, VP, Pengalaman Pelanggan

Direproduksi dari SIOS

Bagaimana Cara Membangun Solusi Server yang Sangat Tersedia?

Komponen kunci untuk solusi ketersediaan tinggi adalah mencari tahu cara mengarahkan lalu lintas klien. Hampir setiap aplikasi berbasis pengguna perlu terhubung ke server. Mengarahkan lalu lintas klien akan memungkinkan pengguna untuk terhubung tanpa harus tahu di mana aplikasi atau database sebenarnya berada.

Sebagian besar solusi merekomendasikan pengalihan IP berbasis jaringan atau pengalihan DNS berbasis jaringan. Ini bekerja. Namun, solusi terbaik untuk server ketersediaan tinggi menurut pengalaman kami adalah penggunaan alamat IP virtual yang dapat dialihkan dari satu server ke server lainnya. Server mendengarkan sambungan dari alamat IP virtual, yang dihosting di satu server hari ini dan dialihkan ke server lain di hari lain.

Untuk melangkah lebih jauh, Anda dapat mengotomatiskan failover. Di sinilah sistem membuat keputusan dan mengganti aplikasi ketika ada kegagalan yang terdeteksi. Ingatlah bahwa langkah ini adalah kunci untuk membangun solusi yang sangat tersedia.

Manfaat Solusi Beli vs. Bangun dengan Ketersediaan Tinggi

Ini dapat diimplementasikan menggunakan skrip dan logika untuk memeriksa status proses dan alamat IP virtual dari satu server ke server lainnya. Namun salah satu tantangan yang kami hadapi dalam solusi beli vs bangun ketersediaan tinggi adalah berapa banyak waktu yang benar-benar harus kami habiskan untuk membangun. Ini termasuk waktu untuk pengkodean skrip, pengembangan API seperti API cloudwatch atau fungsi lambda. Jangan lupakan pengujian, dan pemeliharaan.

Ketika saya masih muda, saya sangat ingin menulis kode itu. Tetapi setelah bekerja untuk perusahaan besar yang masuk daftar Fortune 100, dan dimarahi oleh manajer tingkat tinggi, ketika salah satu skrip saya tidak berfungsi pada jam 3 pagi, saya merasa berbeda. Masalah ini diperburuk ketika saya menemukan masalah untuk kode yang saya tulis setahun yang lalu. Manajer saya menginginkan solusi yang sangat tersedia untuk bekerja 100%. Jika tidak berhasil, saatnya menelepon seseorang dan meneriaki mereka.

SIOS Mengotomatiskan Ketersediaan Tinggi

Bukankah lebih murah dalam jangka panjang untuk membeli solusi dan meluangkan sedikit waktu untuk menyesuaikannya agar sesuai dengan setelan kita? Di sinilah solusi SIOS ketersediaan tinggi (HA) masuk, apa pun aplikasi atau database-nya. SIOS memiliki kode untuk mengalihkan tumpukan proses dari satu server ke server lainnya. Ini memberi pengguna dan manajer ketenangan pikiran yang datang dari mengotomatiskan orkestrasi failover dan ketersediaan tinggi.

Ada dua hal yang saya suka dari payung SIOS HA yaitu. Satu, kode untuk IP virtual di mana alamat IP ditambahkan ke server dan aplikasi di-restart untuk mendengarkan koneksi. Yang kedua diaktifkan melalui penggunaan set API agnostik aplikasi yang disediakan SIOS. Ini memungkinkan siapa saja untuk melindungi aplikasi apa pun dengan menggunakan plugin. Hubungi SIOS hari ini untuk mempelajari lebih lanjut tentang solusi ketersediaan tinggi khusus untuk lingkungan Anda.

– Edmond Melkomian, PMP, MCSD, konsultan, SIOS technology, Inc.

Direproduksi dari SIOS

Tahapan IT Disaster Recovery Duka

Kesedihan atas pemulihan bencana dapat tiba-tiba muncul jika Anda belum menerapkan arsitektur ketersediaan perusahaan yang tepat. Temui teman kita Dave di bagian TI untuk memandu kita melalui 5 tahap kesedihan akibat bencana.

Tahap 1: Penolakan

Dave di IT: "O-oh.Peringatan apa itu?Itu hanya aplikasi kecil yang mogok, bukan?Bukan masalah besar.Aku akan menyelesaikan semuanya dalam waktu singkat. "

Di negeri ketersediaan perusahaan, tidak ada yang namanya crash aplikasi kecil atau bukan masalah besar.Perusahaan memiliki SLA dengan uang sungguhan di telepon.Realitas selektif Anda mungkin bukan perspektif yang sama dari pelanggan dan pemangku kepentingan Anda.

Tahap 2: Kemarahan

Dave dalam IT: “Apakah Anda bercanda.Dari semua… ..[censored]. kali, hari ini aplikasi tidak akan dimulai.Ughh.Aku benci ap[censored]lik[censored]asi …… ini.Tunggu, lansiran baru apa ini.Serius, sekarang, pusat data mati! "

Ini menjadi sangat, sangat cepat dalam kecepatan cepat, dan lingkungan taruhan tinggi. Ketika peringatan dan kegagalan yang tidak terkendali terjadi, masalah dapat meningkat dengan cepat bersamaan dengan tekanan, frustrasi, dan kemarahan.

Status 3: Perundingan

Dave di TI: “Hai Ard di Aplikasi, ini Dave di TI.Apakah kalian punya backup untuk lingkungan App1? . . .Ard apakah kamu yakin?Bisakah Anda memeriksa lagi?Saya tahu Anda sudah memeriksanya dua kali, tetapi bisakah Anda memeriksanya sekali lagi.Aku akan membeli minuman di Taco Tuesday! ”

Dave di TI: “Hai Donna DBA, ini Dave di TI. Art in Applications mengatakan Anda dapat membantu saya.Apakah Anda secara kebetulan mengatur replikasi database untuk database keuangan atau sistem manajemen inventaris? . . . Apakah kamu yakinUmh, apakah kamu ingat jika kita punya cara untuk pulih dari umh. . . pusat data crash? ”

Ketika putri saya mendapat masalah, tawar-menawar adalah yang pertama dia lakukan.Oke, kedua.Yang pertama adalah menghilang, tetapi Anda terlalu pintar untuk menjauh dari api.Namun, Dave di bidang TI bukanlah satu-satunya yang menyadari bahwa tawar-menawar dan mengemis adalah pengganti yang buruk untuk strategi yang terdefinisi dengan baik untuk ketersediaan tinggi dan pemulihan bencana.Lewati tawar-menawar dan memohon tentang bencana Anda karena "80% orang tidak peduli, dan 20% senang itu Anda (diparafrasekan dari Les Brown)."

Tahap 4: Kesedihan

Dave dalam IT: “Ini luar biasa.Server aplikasi macet, pusat data tidak aktif, dan cadangan, jika saya dapat menemukannya dan jika saya dapat memuatnya, akan memakan waktu berjam-jam untuk memulihkannya.Tidak mungkin saya keluar dari ini… di mana saya meletakkan resume yang diperbarui itu. ”

Tentu saja Anda memiliki cadangan, dan Anda telah memvalidasinya.Namun ada dampak RTO dan RPO jika kembali ke backup tersebut.Apakah Anda dapat menyerap kali ini?Itu tentu saja, setelah pusat data Anda pulih.

Langkah 5: Penerimaan

Dave di IT: "Sudah dua jam.Saya tidak pernah tahu kami memiliki banyak pemangku kepentingan Eksekutif sebelumnya.Tidak mungkin saya bisa merayakan ulang tahun ke-2 saya setelah ini.Saya rasa saya akan membersihkan kantor saya besok.Tidak mungkin aku berhasil melewati ini! "

Kegagalan terjadi.Pusat data turun.Aplikasi gagal.Tidak dapat disangkal kemungkinan kehilangan pusat data, server gagal, atau aplikasi crash.Jenis penerimaan ini normal, bagian dari peningkatan ketersediaan Anda.Menerima bahwa Anda mungkin kehilangan pekerjaan atau lebih buruk karena Anda gagal menerapkan strategi ketersediaan adalah sesuatu yang ingin dihindari oleh para ahli di SIOS Technology Corp.

Jangan seperti Dave dalam IT.Hindari tahapan kesedihan bencana, dan jam pemulihan bencana serta waktu henti dengan merancang dan mengimplementasikan arsitektur ketersediaan perusahaan yang mencakup hybrid, on-premise, atau cloud terbaik yang digabungkan dengan solusi terbaik untuk pemantauan, pemulihan, dan otomatisasi failover sistem .

– Cassius Rhue, VP Customer Experience

Direproduksi dari SIOS