SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • Produk
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • Berita dan acara
  • Cluster server penyederhanaan
  • Kisah sukses
  • Hubungi kami
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

Apakah Saya Bahkan Membutuhkan perangkat lunak dengan Ketersediaan Tinggi di Cloud?

Januari 23, 2021 by Jason Aw Leave a Comment

Apakah Saya Bahkan Membutuhkan perangkat lunak dengan Ketersediaan Tinggi di Cloud?

Apakah Saya Bahkan Membutuhkan perangkat lunak dengan Ketersediaan Tinggi di Cloud?

Izinkan saya untuk membangkitkan ingatan Anda. . .

Mungkin hari ini Anda tidak mengalami kegagalan dalam belasan bulan atau lebih dan tiba-tiba pembaruan slam dunk untuk lisensi perangkat lunak ketersediaan tinggi Anda berada di bawah garis merah pena CFO.Atau mungkin, sebagian karena penggunaan istilah yang berlebihan, pemasaran yang cerdik, atau definisi ulang ketersediaan tinggi CIO Anda, yang pernah menjadi penggemar paling siap pakai, mulai goyah pada nilainya.Atau mungkin, mungkin saja bukan CFO atau CIO, tetapi Anda yang memutuskan bahwa Anda mungkin memiliki cukup HA tanpa memerlukan perangkat lunak ketersediaan tinggi atau lebih tinggi dalam persamaan.

Sementara cloud publik sangat tangguh dan ketersediaan telah dipertimbangkan di banyak kesempatan, kebutuhan akan perangkat lunak ketersediaan tinggi yang stabil dan dapat dipelihara masih menjadi kenyataan saat ini.Pertimbangkan tahun 2020 misalnya, kemajuan dalam komputasi awan publik dan ketersediaan masih tidak dapat mencegah kesalahan umum seperti praktik buruk dan kode buruk yang menyebabkan aplikasi mogok, kegagalan pusat data yang tidak diungkapkan, gangguan konstruksi tanpa nama yang memengaruhi daya atau jaringan, kelebihan kapasitas pada VM , atau kegagalan sistem pendingin seperti yang disebutkan oleh satu artikel CRN.

Berikut tujuh alasan Anda masih membutuhkan perangkat lunak dengan ketersediaan lebih tinggi di Cloud:

1. Untuk meningkatkan kedalaman dan keluasan cakupan aplikasi untuk aplikasi perusahaan Anda yang paling penting

Tidak ada satu vendor Cloud yang akan memiliki semua alat, perangkat lunak, dan aplikasi yang Anda butuhkan untuk dimasukkan ke dalam infrastruktur cloud mereka dengan cara yang dapat digunakan oleh perusahaan Anda.Karena itu, Anda kemungkinan akan memigrasi beban kerja ke cloud ke dalam penawaran IaaS yang memerlukan seseorang atau sesuatu untuk melindungi beban kerja tersebut dan memastikan ketersediaannya sangat tinggi.

2. Untuk pemulihan aplikasi otomatis dan cerdas dari sistem, sumber daya, dan ketergantungannya.

Vendor cloud tahu tentang cloud. Vendor ketersediaan tinggi tahu tentang ketersediaan tinggi aplikasi. Jika, bukan jika, kegagalan terjadi di cloud, aplikasi Anda memerlukan pemulihan cerdas dari komponen yang gagal; sistem, sumber daya aplikasi, komponen infrastruktur dan ketergantungannya.Sebagai ahli dalam ketersediaan, vendor perangkat lunak Anda memiliki pengetahuan luas yang dimasukkan ke dalam perlindungan aplikasi. Dalam produk Suite Perlindungan SIOS untuk Linux, otomatisasi berbasis wizard menggunakan praktik terbaik industri, dan riwayat panjang keahlian aplikasi mendorong pemulihan otomatis aplikasi yang jelas dalam skenario kegagalan

3. Untuk replikasi data tingkat blok yang cerdas untuk aplikasi Anda, meningkatkan ketahanan Anda jika terjadi kepanikan sistem atau pemadaman pusat data

Cakupan aplikasi dan pemulihan yang cerdas dan seimbang dimungkinkan ketika data tersedia pada sistem siaga jika terjadi kegagalan.Ketika vendor HA Anda menyertakan replikasi data tingkat blok, Anda dapat memperluas ketahanan failover aplikasi Anda di luar satu pusat data atau wilayah menjadi beberapa pusat data dan wilayah.Replikasi data level blok juga merupakan cara yang efektif untuk menghindari nilai perangkat keras yang memengaruhi volume cloud di satu pusat data.Satu insiden cloud yang melibatkan daya pusat data dan kegagalan generator berikutnya mengakibatkan kerusakan perangkat keras dan kehilangan data untuk instans yang berjalan di pusat data tunggal.Cloud tidak berarti bahwa Anda benar-benar aman dari semua kegagalan, dan cadangan serta salinan replikasi data yang sangat tersedia adalah suatu keharusan.

4. Untuk mekanisme respons yang lebih cepat untuk deteksi dan penyelesaian masalah

Perangkat lunak HA Anda adalah garis pertahanan pertama untuk mengidentifikasi dan memulihkan kegagalan aplikasi.Dengan daemon pemantauan, kegagalan aplikasi dapat dengan cepat dideteksi dan diperbaiki oleh perangkat lunak sebelum pengguna terkena dampak kritis.Selain itu, perangkat lunak ketersediaan tinggi Anda seperti solusi SIOS Protection Suite untuk Linux menyertakan metode yang dapat dikonfigurasi untuk mengirim dan mengkomunikasikan peringatan ke administrator, konsol acara, atau dasbor yang memungkinkan Anda berkomunikasi secara instan dan efektif dengan tombol.

5. Untuk sumber data tambahan yang dapat ditambang dan diaudit untuk membantu memprediksi kesehatan dan stabilitas perusahaan Anda

Data adalah raja.Perangkat lunak ketersediaan tinggi Anda adalah sumber data dan informasi yang luar biasa tentang lingkungan Anda yang dapat ditambang dan diaudit.Saat solusi HA Anda merespons kegagalan aplikasi, masalah infrastruktur dan latensi, dan mendorong waktu aktif Anda melalui kegagalan sementara, log mereka menangkap informasi penting tentang kesehatan perusahaan Anda.Sebagai VP Pengalaman Pelanggan, tim Keberhasilan dan Dukungan Pelanggan kami dapat menggunakan log HA kami untuk memberikan pemeriksaan kesehatan kepada pelanggan, memberi tahu mereka tentang beberapa masalah aplikasi dan pengoptimalan yang mungkin terjadi karena data log yang diambil.

6. Untuk sudut pandang yang seimbang dan jujur, dan kebijaksanaan tambahan yang dibutuhkan untuk perusahaan Anda

Selain nilai dari perangkat lunak Ketersediaan Tinggi, ada alasan lain mengapa Anda masih membutuhkan perangkat lunak HA di cloud.Alasan tambahan tersebut adalah sudut pandang yang seimbang dan jujur serta kebijaksanaan tambahan dari tim pengembangan, layanan, dan pengalaman pelanggan vendor HA Anda.Perangkat lunak HA Anda didukung oleh tim ahli, insinyur ketersediaan berpengalaman, dan yang terpenting tim layanan dan dukungan dengan pengalaman praktik terbaik selama bertahun-tahun, pengetahuan khusus aplikasi, dan ide serta keterampilan yang diserbuki silang yang dapat sangat menguntungkan perusahaan Anda.

7. Untuk mengurangi waktu henti pemeliharaan terencana

Last but not least, perangkat lunak ketersediaan tinggi Anda membantu mengurangi atau mungkin menghilangkan waktu henti yang diperlukan untuk peningkatan, tambalan kecil, dan pemeliharaan preventif bergulir.Memanfaatkan kemampuan peralihan dan failover perangkat lunak HA Anda, server siaga Anda dapat secara aktif ditambal, diperbarui, dan diuji kemudian dipromosikan menjadi simpul ketersediaan aktif.Dengan demikian memastikan bahwa sistem penting Anda berjalan pada rilis terbaru sambil meminimalkan penalti peningkatan.

Ya, Cloud telah menambahkan peningkatan perangkat keras dan stabilitas platform untuk aplikasi, pengembang, dan pengguna perusahaan, tetapi jika Anda mulai berpikir bahwa Anda tidak membutuhkan ketersediaan tinggi, Anda sedang menuju ke gang gelap yang berakhir dengan keputusasaan akhir-akhir ini. malam pizza dingin menempatkan aplikasi kembali online, menjelaskan yang tidak bisa dijelaskan, dan merenungkan resume membersihkan.Jadi terima kasih telah membiarkan saya membangkitkan ingatan Anda. . .Anda dan perangkat lunak HA Anda saling membutuhkan, bahkan di Cloud.

– Cassius Rhue, Wakil Presiden, Pengalaman Pelanggan

Direproduksi dengan izin dari SIOS

 

Filed Under: Cluster server penyederhanaan

Haruskah Saya Tetap Menggunakan Zabbix Di AWS?

Januari 16, 2021 by Jason Aw Leave a Comment

Haruskah Saya Tetap Menggunakan Zabbix Di AWS

Haruskah Saya Tetap Menggunakan Zabbix Di AWS?

Pemantauan Amazon EC2

Zabbix memiliki pangsa pasar yang tinggi sebagai alat pemantauan OSS terintegrasi.Meskipun telah digunakan secara luas di lingkungan di lokasi, ada banyak contoh Zabbix yang digunakan di lingkungan AWS.Terlepas dari kenyataan bahwa AWS juga memiliki layanan pemantauan seperti Amazon CloudWatch, mengapa Anda harus menggunakan Zabbix?Bagian ini menjelaskan manfaat pemantauan instans EC2 dan instans lainnya, serta proses konfigurasi.

Mengapa menggunakan Zabbix daripada Amazon CloudWatch?

Di lingkungan AWS, semua infrastruktur dioperasikan oleh AWS, tetapi Anda harus bertanggung jawab atas pengoperasian instans Amazon EC2 itu sendiri dan aplikasi yang dibangun di Amazon EC2. Dengan kata lain, Anda harus memantau aplikasi untuk memastikan bahwa aplikasi tersebut beroperasi dengan benar, dan Anda harus mengambil tindakan saat terjadi masalah.Zabbix adalah kandidat yang baik untuk alat pemantauan semacam ini.

Zabbix memiliki keunggulan karena dapat memantau tidak hanya di tempat. Tetapi juga cloud dan lingkungan virtual secara terintegrasi.

Sedangkan Amazon CloudWatch standar terbatas untuk memantau sumber daya AWS (CPU, memori, dll.), Zabbix memungkinkan Anda untuk memantau bahkan status aplikasi Anda secara detail.

Berikut ini adalah daftar keunggulan lain dari Zabbix.

Pemantauan lingkungan terintegrasi dengan beberapa akun AWS

Amazon CloudWatch melakukan pemantauan per akun AWS.Zabbix dapat memantau lingkungan beberapa akun AWS, yang dapat memantau sistem bisnis yang terdiri dari beberapa akun.Itu juga dapat mendeteksi anomali tidak hanya dengan peringatan sederhana berdasarkan ambang batas, tetapi juga dengan beberapa ambang batas dan kondisi dalam kombinasi. 

Itu dapat dikonfigurasi dengan pemberitahuan rinci agar sesuai dengan kondisi operasi yang sebenarnya

Amazon CloudWatch dapat memberi tahu Anda dengan pesan jika terjadi anomali.Misalnya, jika sistem Anda sedang dalam pemeliharaan, Anda tidak perlu diberi tahu melalui pesan.Di sinilah Zabbix memungkinkan Anda untuk mengkonfigurasi kasus ini dengan cara yang memungkinkan Anda untuk menyembunyikan pesan yang tidak diinginkan.Dengan cara ini Anda dapat memastikan bahwa Anda hanya diberi tahu ketika ada sesuatu yang benar-benar salah yang perlu ditangani.

Tidak ada periode retensi untuk metrik (log pemantauan)

Dengan Amazon CloudWatch, metrik dapat disimpan hingga 15 bulan.Selain itu, Anda hanya dapat menyimpan metrik setiap jam selama 15 bulan, dan jika interval pemantauan disetel ke kurang dari 60 detik, Anda hanya dapat menyimpannya selama maksimal 3 jam.Zabbix memungkinkan penyimpanan metrik jangka panjang tanpa mengubah perincian informasi.

Cara memantau lingkungan AWS dengan Zabbix

Jika Anda ingin menggunakan Zabbix di AWS, Anda perlu membuat instans Amazon EC2 dan DB dan menginstal Zabbix di dalamnya.Setelah instalasi, proses konfigurasi Zabbix pada dasarnya sama dengan proses on-premise, hanya saja Anda perlu mengatur yang berikut ini

  1. Akun pengguna (selain pengguna Admin Zabbix, Anda perlu membuat pengguna untuk penggunaan produksi)
  2. Agen host Zabbix (menentukan dari mana data dikumpulkan)
  3. Item (mengatur data apa yang akan dikumpulkan)
  4. Pemicu (menentukan keadaan data yang tidak normal)
  5. Tindakan (mendefinisikan tindakan yang akan diambil ketika terjadi kesalahan)

Selain itu, Anda dapat mengonfigurasi pengaturan khusus AWS, seperti membuat pengguna di AWS IAM dengan izin yang diperlukan untuk Zabbix, yang akan memungkinkan Zabbix memantau aplikasi dan aspek lain dari lingkungan AWS Anda.

Gunakan alat yang tepat untuk kebutuhan pemantauan Anda

Tidak semua sistem perusahaan beroperasi secara terpisah, tetapi banyak sistem yang dihubungkan bersama untuk bertukar data dan memastikan konsistensi secara keseluruhan.Dalam lingkungan ini, Zabbix adalah alat yang hebat untuk memantau dan mendeteksi anomali di beberapa server dan sistem.Misalnya, jika aplikasi web berbasis DB memiliki anomali pada server aplikasi web, data dapat dinonaktifkan, misalnya.

Di sisi lain, Zabbix memiliki banyak opsi konfigurasi, jadi Anda harus memutuskan apa yang akan dipantau dan bagaimana, dan kondisi apa yang tidak normal.

Di sisi lain, Zabbix memiliki banyak pengaturan, jadi Anda harus mendesain operasi dengan tepat apa yang harus dipantau dan apa yang harus dilakukan, dan apa yang harus dilakukan. Tentu saja, untuk sistem kritis, desain seperti itu penting, namun, untuk sistem yang relatif sederhana, seperti "jika suatu proses berhenti, mulai ulang saja", tidak ada yang cocok untuk pemantauan Zabbix.SIOS AppKeeper adalah solusi yang baik untuk kasus seperti itu, karena ia memantau layanan (proses) dari aplikasi yang berjalan pada instans EC2, dan memulai ulang aplikasi jika mendeteksi masalah. Ini memungkinkan pemantauan dan pengoperasian yang sederhana.

Tentu saja, tidak “wajib” menggunakan Zabbix di setiap sistem.Dengan menggunakan alat yang tepat untuk setiap jenis pemantauan, Anda akan dapat mengoperasikan sistem Anda dengan lebih efisien.

Tambahkan SIOS AppKeeper ke operasi pemantauan dan pemulihan EC2 Anda.

Direproduksi dari SIOS

Filed Under: Cluster server penyederhanaan

Bagaimana Memilih Awan Saat Anda Membutuhkan Ketersediaan Tinggi

Januari 8, 2021 by Jason Aw Leave a Comment

Cara Memilih Cloud saat Anda membutuhkan Ketersediaan Tinggi

Bagaimana Memilih Awan Saat Anda Membutuhkan Ketersediaan Tinggi

Pahami pasar cloud

Sejumlah firma analis memperkirakan jumlah penerapan aplikasi, database, dan solusi yang terus meningkat di cloud. Menurut Gartner, perusahaan "beralih ke cloud dengan kecepatan yang men[1]ingkat". Faktanya, Gartner dan analis lainnya memperkirakan laju migrasi dan penerapan cloud akan terus meningkat, sebagian besar didorong oleh laju inovasi di cloud. Dalam artikel TechTarget oleh Kurt Marko, dari MarkoInsights, Marko mencatat bahwa laju inovasi yang "dilakukan di cloud kemungkinan tidak dapat direplikasi di tempat karena sifat cloud publik terkelola yang elastis, dapat diskalakan, dan sesuai permintaan. jasa."

Kami melihat semakin banyak perusahaan yang selama ini menggunakan cloud hanya untuk aplikasi DevOps dan database yang tidak penting untuk bisnis mereka, kini memindahkan aplikasi, ERP, dan database misi penting yang memerlukan perlindungan ketersediaan tinggi ke cloud.

Jika Anda sedang mempertimbangkan untuk pindah ke cloud – dan sepertinya memang demikian – ada beberapa kunci yang perlu dipahami saat Anda membutuhkan ketersediaan tinggi.

Biasakan diri Anda dengan opsi ketersediaan tinggi cloud

Untuk merencanakan solusi ketersediaan yang tepat untuk cloud atau penerapan cloud hybrid, pertimbangkan apa saja poin masalah terkait dengan ketersediaan (99,9% waktu aktif) dan ketersediaan tinggi (99,99% waktu aktif). Anda juga perlu memahami opsi yang tersedia untuk ketersediaan tinggi dengan memperhatikan rencana Anda untuk bermigrasi ke cloud. Analis dan pakar terkemuka menyarankan untuk mencari solusi yang tidak hanya akan mengurangi dan mengurangi rasa sakit saat memigrasi beban kerja Anda, tetapi juga akan memberikan pendekatan yang seimbang dan komprehensif untuk ketersediaan di seluruh masa pakai arsitektur cloud Anda. Perhatikan, sebaiknya pertimbangkan juga solusi yang dapat memberikan perlindungan dan ketersediaan tinggi untuk sebagian dari beban kerja Anda yang suatu hari dapat dikembalikan dari cloud ke lingkungan lokal Anda.

Berikut sepuluh hal yang perlu dipertimbangkan saat membandingkan opsi ketersediaan Anda di cloud:

1. Metode penerapan. Apakah mungkin untuk menerapkan solusi ketersediaan yang Anda pertimbangkan menggunakan gambar, CLI, UI, atau solusi berulang lainnya seperti template pembentukan awan atau skrip paket.

2. Persyaratan sistem.Terutama, pertimbangkan persyaratan sistem operasi (OS), disk, CPU, dan memori.

3. Lingkungan penerapan.Apakah opsi ketersediaan Anda hanya mendukung lokal, satu atau beberapa cloud publik, atau dapatkah mereka mendukung campuran, dan / atau penyebaran cloud hybrid. Apakah ada penawaran SaaS juga tersedia?

4. Luas dan kedalaman perlindungan aplikasi. “Breadth” artinya jenis aplikasi, database, front-end, jaringan, dan komponen infrastruktur apa yang dapat dilindungi?Apakah ada kerangka kerja yang fleksibel untuk menambahkan aplikasi dan varian baru? Arti “Kedalaman” – apakah solusinya sadar aplikasi – dan mampu mempertahankan praktik terbaik khusus aplikasi selama proses failover / failback aplikasi?

5. Persyaratan kinerja. Kami sering memikirkan RTO dan RPO, tetapi bagaimana dengan kinerja lain yang membutuhkan solusi Anda. Akankah solusi ketersediaan Anda menyebabkan masalah kinerja saat failover?

6. Persyaratan ketahanan.Seberapa besar cluster yang dapat didukung oleh solusi ketersediaan ?, Berapa banyak kesalahan dan kegagalan yang dapat dideteksi dan dipulihkan. Bagaimana replikasi akan ditangani sambil menjaga metadata tetap sinkron?

7. Dukungan dan pemeliharaan.Apakah vendor ketersediaan memiliki pengalaman dengan berbagai macam kebutuhan dan konfigurasi ketersediaan? Apakah mereka memiliki umur panjang, dan sistem pendukung yang dirancang untuk mengatasi masalah yang mungkin melampaui solusi mereka? Dapatkah mereka membantu Anda meminimalkan gangguan dan waktu henti yang direncanakan selama pengelolaan dan pemeliharaan sistem Anda (tambalan, peningkatan versi, dan pemeliharaan umum).

8. Total biaya kepemilikan.Ada seluruh industri dan layanan yang didedikasikan untuk membantu Anda menghitung total biaya kepemilikan, jadi kami tidak akan membahasnya di sini. Singkatnya, perhitungan Anda akan unik untuk organisasi, penyedia cloud, aplikasi, dan tim TI Anda. Anda harus mempertimbangkan apakah vendor solusi ketersediaan Anda dapat membantu Anda mengidentifikasi strategi untuk menghemat penggunaan, lisensi, dan biaya lainnya? Apakah solusi mengotomatiskan tugas manual, mengurangi waktu kerja TI?

9. Perizinan dan model harga.Bagaimana Anda menggunakan biaya perangkat lunak? Apakah ada biaya langganan, model langganan, penawaran bayar sesuai pemakaian, bawa lisensi Anda sendiri (BYOL), atau kombinasi opsi fleksibel. Bagaimana Anda akan mengaktifkan lisensi produk?Apakah ada server lisensi, layanan lisensi, atau kunci terenkripsi berdasarkan detail penerapan mesin virtual, seperti alamat, nama host, alamat MAC.

10. Dampaknya pada staf TI.Berapa banyak pelatihan dengan solusinya yang dibutuhkan? Berapa banyak intervensi manual yang akan dibutuhkan jika terjadi peristiwa kegagalan aplikasi atau bencana? Apakah ini memerlukan skrip khusus yang perlu dipertahankan? Siapa yang akan bertanggung jawab atas pemeliharaan berkelanjutan?

Pertimbangkan manfaat dan kompromi

Seperti setiap keputusan penting, Anda perlu memahami pengorbanan Anda dan memilih keseimbangan terbaik untuk memenuhi kebutuhan Anda. Misalnya, baru-baru ini saya meminta seorang teman untuk merekomendasikan sepatu jalan yang bagus. Saya membeli sepasang yang dia ocehkan – memperhatikan betapa ringannya mereka, seberapa kuat dan tahan lama kainnya, dan betapa gayanya mereka.Saya pergi untuk lari jarak jauh pertama saya di dalamnya, dan saya segera menyumbangkan sepasang sepatu “satu lari” pertama saya setelah itu. Ketika saya pergi ke 'Fleet Feet' untuk mendapatkan pendapat ahli, saya mendapatkan sepatu yang lebih berat, dengan kain yang lebih bernapas (juga kurang tahan lama), dan tingkat keburukan yang tak tertandingi. Saya melakukan tradeoff antara penampilan dan fungsi yang sesuai dengan kebutuhan dan anggaran saya.

Seperti sepatu lari, tidak ada solusi peluru perak yang sesuai untuk setiap perusahaan, setiap aplikasi, setiap database, dan setiap server dan arsitektur yang memungkinkan. Anda secara resmi bebas untuk berhenti mencarinya. Alih-alih, selesaikan aktivitas menimbang trade-off untuk menentukan apa yang tepat untuk kebutuhan perusahaan Anda. Pikirkan pengorbanan Anda. Misalnya, jika Anda yakin akan menjadi toko Microsoft sepenuhnya, pentingnya dukungan GCP dan AWS seharusnya sedikit lebih rendah dalam proses evaluasi Anda.

Pertimbangkan dinamika infrastruktur TI Anda

Pikirkan secara holistik tentang ketersediaan di seluruh infrastruktur TI Anda – baik di lokasi maupun di cloud. Alasan untuk melakukannya paling baik dijelaskan dengan analogi lain. Pada tahun 2018, saya menjadi koordinator untuk program penjangkauan memberi makan para tunawisma dan kelaparan di Columbia, Carolina Selatan. Kelompok kami bertemu sekali seminggu untuk menyajikan makanan dan pesan harapan kepada lebih dari 100 pria, wanita dan anak-anak. Saat kami mempertimbangkan untuk memperluas – menambahkan lebih banyak hari dalam seminggu, lebih banyak jam, atau layanan tambahan, kami harus memikirkan jauh di luar persyaratan penjadwalan sederhana. Mengetahui bahwa kami memberikan layanan penting kepada klien yang bergantung pada kami, kami harus mempertimbangkan semua faktor yang memengaruhi kemampuan kami untuk memberikan layanan tersebut secara konsisten untuk jangka panjang, seperti: biaya, usia anggota tim kami, kewajiban luar , metode alternatif untuk mencapai tujuan kami, faktor risiko, dan dinamika lain dalam organisasi induk kami.

Saat Anda memilih solusi, setelah Anda memahami pasar, membiasakan diri dengan opsi, dan menimbang kompromi, langkah terakhir adalah memperhitungkan berbagai dinamika lain di lingkungan Anda secara keseluruhan. Akankah solusi tersebut memenuhi kebutuhan bisnis Anda secara keseluruhan? Akankah data penting Anda dilindungi dari kehilangan? Akankah produktivitas pengguna akhir Anda dilindungi dari waktu henti? Pelatihan apa yang akan diperlukan untuk pindah ke cloud dan bagaimana hal itu akan memengaruhi kemampuan Anda untuk mengelola atau mempertahankan solusi yang Anda pilih? Peran TI apa yang akan ditambahkan, dihapus, atau diubah dalam perjalanan cloud Anda?Akankah tanggung jawab untuk ketersediaan aplikasi berpindah ke pemilik lini bisnis mana pun? Dan bagaimana perubahan dalam tanggung jawab, atau pembentukan tim akan meningkatkan atau menurunkan potensi kesuksesan Anda secara keseluruhan. Pertimbangkan apakah tim Anda perlu mengambil pendekatan langkah demi langkah, memigrasi beban kerja yang lebih kecil terlebih dahulu.

Sebagai Wakil Presiden Pengalaman Pelanggan, saya telah melihat berbagai macam perencanaan migrasi cloud – beberapa langsung yang lainnya sangat mengganggu. Dalam satu contoh, perpindahan pelanggan ke cloud sangat kontroversial karena manajemen melihatnya sebagai peluang untuk menghilangkan seluruh departemen TI. Saya tidak menyarankan Anda untuk bermain politik, tetapi Anda harus menyadari semua faktor yang berperan dalam proyek kompleks ini.

Bermigrasi ke cloud diharapkan dapat menghemat uang, waktu, dan sumber daya sambil meningkatkan ketersediaan dan ketahanan. Apa pun cloud yang Anda pilih, pastikan Anda mempertimbangkan tip berikut dan memilih solusi ketersediaan terkait yang memberi Anda fleksibilitas untuk memberikan perlindungan yang Anda butuhkan dalam konfigurasi yang Anda inginkan.

Pelajari lebih lanjut tentang opsi ketersediaan tinggi cloud dengan SIOS.

– Cassius Rhue, Wakil Presiden Pengalaman Pelanggan, SIOS

Direproduksi dengan izin dari SIOS

Filed Under: Cluster server penyederhanaan

Cara Mengkloning Ketersediaan Di Cloud Dengan Hasil Lebih Baik

Desember 30, 2020 by Jason Aw Leave a Comment

Cara Mengkloning Ketersediaan Di Cloud Dengan Hasil Lebih Baik

Cara Mengkloning Ketersediaan Di Cloud Dengan Hasil Lebih Baik

Tips dari film – Multiplisitas

Multiplicity adalah film komedi fiksi ilmiah Amerika tahun 1996 yang dibintangi Michael Keaton sebagai Doug Kinney, seorang pekerja konstruksi sibuk yang berjuang untuk menyediakan waktu bagi keluarganya dan pekerjaannya yang menuntut. Saat seorang ilmuwan menawarkan untuk mengkloningnya, Doug setuju untuk mempermudah pemenuhan jadwal dan komitmennya. Tapi kemudian salinan dirinya mulai membuat salinan dari dirinya sendiri. Pada saat salinan terakhir dibuat, intinya sudah jelas. Kloning mungkin tidak semudah yang diharapkan, atau setidaknya disertai dengan beberapa peringatan, tantangan, dan efek samping yang kuat. Episode orisinal Star Trek yang terkenal "Trouble with Tribbles" mengilustrasikan hal serupa.

Seperti kloning di layar besar (atau kecil), kloning di cloud adalah alat yang hebat, tetapi bukannya tanpa tantangan.

Tips tentang cara mendapatkan hasil yang lebih baik saat Anda mengkloning ketersediaan di cloud

1. Menggandakan sistem operasional

Ini terdengar jelas, tetapi saya telah melihat itu terjadi lebih dari sekali di lingkungan perusahaan yang nyata. Jika Anda mengkloning sistem non-fungsional Anda, klon tersebut akan sama-sama tidak berfungsi dan bermasalah saat Anda memulihkannya. Pastikan bahwa klon yang Anda buat berasal dari sistem operasional dan fungsional.

2. Sinkronkan data ke disk dan sinkronkan ulang saat pemulihan

Integritas sistem file sangat penting. Jika Anda tidak memastikan aplikasi dan / atau VM Anda dalam keadaan konsisten, sebagian besar vendor tidak akan menjamin gambar yang dibuat yang dihasilkan. Karena snapshot hanya menangkap data yang telah ditulis ke volume Anda pada saat perintah snapshot dikeluarkan, ini mungkin mengecualikan data apa pun yang telah di-cache oleh aplikasi atau sistem operasi apa pun. Memastikan data telah disinkronkan dengan benar ke sistem file merupakan langkah penting, dan sangat penting dalam lingkungan cluster.

Integritas sistem file juga penting untuk diingat saat Anda memulihkan dari gambar. Jika Anda menggunakan replikasi data dan Anda memulihkan gambar sebagai sumber atau target di cluster, pastikan kedua node sinkron adalah yang terpenting. Kegagalan untuk melakukannya dapat menyebabkan kesalahan sistem file pada failover atau peralihan, atau bahkan potensi kehilangan data. Klon ketersediaan di cloud untuk mendapatkan hasil yang Anda inginkan.

3. Hentikan instance Anda

Banyak lingkungan tidak mengharuskan Anda menghentikan instans untuk membuat gambar, dan beberapa, seperti AWS akan melakukan langkah mematikan node sebelum membuat salinan.Namun, banyak alat dan situs merekomendasikan untuk memastikan aplikasi dihentikan dan akses sistem file disinkronkan dengan benar untuk menghindari kerusakan, kehilangan integritas, atau membuat gambar yang mengalami masalah saat memulai, menghentikan, atau menjalankan aplikasi yang diinstal.

4. Beri label semua yang ada di cloud (node, disk, NIC, semuanya)

Saat membuat klon adalah operasi gratis, disk dan komponen yang dihasilkan biasanya tidak.AWS menyatakan, misalnya, Anda "dikenai biaya untuk snapshot hingga Anda membatalkan pendaftaran gambar dan menghapus snapshot." Ketika sesuatu tidak diberi label, mengetahui apa yang digunakan atau tidak digunakan dan mengapa hal itu dibuat bisa menjadi masalah. Itu juga menjadi sasaran ingatan sekilas atau konsentrasi anggota tim yang ada.Beri label semuanya.

5. Sering-seringlah memangkas klon dan snapshot (penghematan biaya dan penghematan sakit kepala)

Memangkas snapshot dan klon lama tidak hanya baik untuk penghematan biaya, tetapi juga baik untuk mengurangi sakit kepala.Snapshot yang lebih lama berisiko memunculkan kembali kerentanan yang telah diatasi atau diselesaikan di salinan yang lebih baru.Sebagai Wakil Presiden Pengalaman Pelanggan di SIOS Technology Corp., Saya melihat konsekuensinya secara langsung saat kami bekerja dengan pelanggan yang memulihkan dari snapshot. Mereka mengalami beberapa masalah saat memulai ulang aplikasi. Setelah pemecahan masalah, kami memutuskan bahwa klon menjalankan perangkat lunak keamanan versi lama. Kredensial dan metadata yang disimpan dalam profil pengguna tidak lagi disinkronkan dengan data aplikasi aktual yang disimpan di drive data yang dipasang secara eksternal.

6. Batasi atau batasi kloning kloning di cloud

Terakhir, tidak semua yang Anda lakukan di cloud perlu di-clone. Pertimbangkan untuk membatasi jenis beban kerja yang akan Anda klon dan batasi jumlah atau peran yang dapat membuat klon di lingkungan Anda.

Dalam film tersebut, ketika klon Doug memicu serangkaian duplikasi mereka sendiri, Doug (Michael Keaton) yang sudah kewalahan dipaksa untuk mengerahkan energi ekstra untuk mengelola banyak klonnya sambil mencoba menyembunyikan kekacauan yang ia buat dari istrinya. Mencapai ketersediaan klon di cloud dengan hasil yang lebih baik tidaklah sulit. Kloning dengan hati-hati untuk menghindari membuat lebih banyak pekerjaan dan menambah risiko dari alat yang seharusnya membuat pekerjaan Anda lebih mudah dan lingkungan Anda lebih aman.

– Cassius Rhue, Wakil Presiden, Pengalaman Pelanggan

Direproduksi dari SIOS

Filed Under: Cluster server penyederhanaan

Rilis Produk Baru: SIOS Protection Suite for Linux 9.5.1

Desember 26, 2020 by Jason Aw Leave a Comment

Rilis Produk Baru: SIOS Protection Suite for Linux 9.5.1

SIOS terus memperbarui produk kami untuk memenuhi kebutuhan pelanggan yang terus berkembang akan ketersediaan tinggi untuk aplikasi penting. Kami sangat senang mengumumkan ketersediaan umum SIOS Protection Suite untuk Linux versi 9.5.1!Fitur rilis ini menambahkan dukungan untuk lebih banyak jenis platform dan penyempurnaan pada fitur antarmuka baris perintah kami.

Rilis Produk Baru: SIOS Protection Suite for Linux 9.5.1

Pembaruan utama termasuk

      • Dukungan untuk sistem operasi dan platform berikut: VMware Vsphere 7, Red Hat Enterprise Linux (RHEL) 8.2, Oracle Linux 8.2, CentOS 8.2, SUSE Linux Enterprise (SLES) 12 SP5, RHEL 7.8, CentOS 7.8, Oracle Linux 7.8, SLES 15 SP2
      • CLI Auto Install dengan skrip pengaturan yang ditingkatkan – untuk implementasi yang lebih cepat dan mudah
      • Dukungan CLI yang diperluas untuk ARK dan Kloning – memungkinkan penerapan beberapa klaster yang sederhana dan konsisten

Direproduksi dengan izin dari SIOS

Filed Under: Cluster server penyederhanaan

  • 1
  • 2
  • 3
  • …
  • 41
  • Next Page »

Tulisan Terbaru

  • Apakah Saya Bahkan Membutuhkan perangkat lunak dengan Ketersediaan Tinggi di Cloud?
  • Haruskah Saya Tetap Menggunakan Zabbix Di AWS?
  • Bagaimana Memilih Awan Saat Anda Membutuhkan Ketersediaan Tinggi
  • Cara Mengkloning Ketersediaan Di Cloud Dengan Hasil Lebih Baik
  • Rilis Produk Baru: SIOS Protection Suite for Linux 9.5.1

Posting Terpopuler

Maximise replication performance for Linux Clustering with Fusion-io
Failover Clustering with VMware High Availability
create A 2-Node MySQL Cluster Without Shared Storage
create A 2-Node MySQL Cluster Without Shared Storage
SAP for High Availability Solutions For Linux
Bandwidth To Support Real-Time Replication
The Availability Equation – High Availability Solutions.jpg
Choosing Platforms To Replicate Data - Host-Based Or Storage-Based?
Guide To Connect To An iSCSI Target Using Open-iSCSI Initiator Software
Best Practices to Eliminate SPoF In Cluster Architecture
Step-By-Step How To Configure A Linux Failover Cluster In Microsoft Azure IaaS Without Shared Storage azure sanless
Take Action Before SQL Server 20082008 R2 Support Expires
How To Cluster MaxDB On Windows In The Cloud

Bergabunglah dengan Milis Kami

Copyright © 2021 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in