SIOS APAC Portal

Januari 13, 2022	Mengapa Anda Membutuhkan Rencana Kontinuitas Bisnis Mengapa Anda Membutuhkan Rencana Kontinuitas Bisnis Facebook, Instagram, dan WhatsApp baru saja mengalami hari Senin yang sangat buruk Ini adalah akhir hari kerja di sini di pantai timur dan saya melihat bahwa Facebook masih tidak tersedia. Facebook mengakui masalah dalam dua Tweet berikut. Saya dapat menentukan waktu Facebook offline untuk saya. Saya mencoba untuk mengirim komentar pada sebuah posting dan komentar saya tidak memposting. Saya sedikit kesal, dan hampir mengira poster itu telah memblokir saya, atau menghapus komentar saya. Ini adalah pada 11:45 EDT. 5+ jam Facebook untuk saya masih down. Meskipun kami tidak mengetahui penyebab pasti dari waktu henti, dan apakah itu kesalahan pengguna, beberapa serangan jahat, atau hanya bencana kesalahan yang tidak terduga, kami dapat mempelajari beberapa hal tentang pemadaman ini pada saat ini. Waktu Henti Itu Mahal Meskipun kita mungkin tidak pernah tahu biaya pasti dari waktu henti yang dialami saat ini, ada beberapa biaya yang sudah dapat diukur. Hingga tulisan ini dibuat, saham Facebook turun 4,89% hari ini. Itu di atas September yang sudah brutal untuk Facebook dan saham teknologi lainnya. Koreksi mungkin tidak dapat dihindari, tetapi pemadaman hari ini tentu saja tidak membantu. Tapi berapa biaya sebenarnya bagi perusahaan? Dengan banyaknya merek yang memanfaatkan media sosial sebagai bagian penting dari jangkauan pemasaran mereka, bagaimana penghentian ini akan berdampak pada pengeluaran iklan di masa mendatang? Minimal saya mengantisipasi pengiklan untuk menyelidiki platform media sosial lain jika mereka belum melakukannya. Hanya waktu yang akan menjawab, tetapi bahkan sebelum pemadaman ini, kami telah melihat lebih banyak persaingan untuk pengeluaran pemasaran dari platform lain seperti tik tok . Rencanakan untuk Skenario Kasus Terburuk Hal-hal terjadi, kita tahu itu dan berencana untuk itu. Rencana Kontinuitas Bisnis (BCP) harus ditulis ke alamat setiap kemungkinan bencana. Sekali lagi, kami tidak tahu penyebab pasti dari bencana khusus ini, tetapi saya harus membayangkan bahwa RTO 5+ jam tidak ditulis ke BCP apa pun yang ada di rak di Facebook, Instagram, atau WhatsApp. Apa yang ada di BCP Anda? Pernahkah Anda membayangkan bencana yang mungkin terjadi? Sudahkah Anda mengukur dampak waktu henti dan menetapkan sasaran waktu pemulihan (RTO) dan sasaran titik pemulihan (RPO) yang memadai untuk setiap komponen bisnis Anda? Saya berani mengatakan bahwa tidak mungkin merencanakan setiap kemungkinan hal yang bisa salah. Namun, saya akan menyarankan semua orang untuk mengunjungi kembali BCP Anda secara teratur dan memperbaruinya untuk memasukkan bencana yang mungkin tidak ada di radar saat terakhir kali Anda meninjau BCP Anda. Apakah Anda memiliki pandemi global di BCP Anda? Jika tidak, Anda mungkin harus berebut untuk mengakomodasi tenaga kerja "bekerja dari rumah". Intinya, rencanakan yang terburuk dan berharap yang terbaik. Komunikasi Dalam Bencana Komunikasi saat terjadi bencana harus menjadi bab tersendiri di BCP Anda. Seorang karyawan Facebook mengatakan kepada Reuters bahwa semua alat internal mati. Tanggapan Facebook menjadi jauh lebih sulit karena karyawan kehilangan akses ke beberapa alat mereka sendiri selama penutupan, kata orang yang melacak masalah tersebut. Beberapa karyawan mengatakan mereka tidak diberitahu apa yang salah. https://www.reuters.com/technology/facebook-instagram-down-thousands-users-downdetectorcom-2021-10-04/ BCP yang benar-benar kuat harus mencakup beberapa sarana komunikasi mundur. Ini menjadi jauh lebih penting karena bisnis Anda tersebar di beberapa gedung, wilayah, atau negara. Pikirkan saja bagaimana tim Anda berkomunikasi hari ini. Telepon, teks, email, Slack mungkin menjadi empat teratas Anda. Tetapi bagaimana jika semuanya tidak tersedia, bagaimana Anda menjangkau tim Anda? Jika Anda tidak tahu, Anda mungkin ingin mulai menyelidiki opsi lain. Anda mungkin tidak memerlukan radio gelombang pendek dan sekawanan merpati pos, tetapi saya yakin ada lembaga pemerintah yang menyediakan keduanya untuk situasi "pecahan kaca dalam keadaan darurat". Ringkasan Anda memiliki tanggung jawab terhadap diri Anda sendiri, pelanggan Anda, dan investor Anda untuk memastikan bahwa Anda mengambil setiap tindakan pencegahan terkait ketersediaan bisnis Anda. Pastikan Anda menginvestasikan sumber daya yang memadai dalam membuat BCP Anda dan bahwa tim yang bertanggung jawab atas kelangsungan bisnis memiliki alat yang mereka butuhkan untuk memastikan mereka dapat melakukan bagian mereka dalam memenuhi RTO dan RPO yang ditentukan dalam BCP Anda. Direproduksi dengan izin dari Mengelompokkan mantan manusia
Januari 9, 2022	Memperbaiki Perjalanan Cloud Anda Memperbaiki Perjalanan Cloud Anda Dalam beberapa hal, peristiwa yang mengubah dunia pada tahun 2020 dan 2021 telah mengubah hampir semua hal yang kita ketahui, dan ketersediaan tinggi tidak terkecuali. Meskipun ada penutupan dan pembatasan, banyak tim TI menukar pusat data lokal untuk cloud.Banyak yang bertanya, 'Sekarang apa?' Berikut adalah lima hal yang harus dilakukan untuk memperbaiki perjalanan cloud Anda di tahun 2022. Menambahkan ketersediaan tinggi Dalam dorongan ke cloud, banyak pemimpin TI dan bisnis mendapati diri mereka bergegas untuk memindahkan layanan dan aplikasi dari pusat data yang mereka tutup karena COVID-19 ke cloud. Yang lain bergegas ke cloud, bukan karena penutupan pusat data, tetapi untuk menghadapi gelombang permintaan yang meledak. Bagi sebagian orang, perjalanan ke cloud begitu cepat sehingga HA tidak disertakan, dan sekarang mereka telah menemukan cara yang sulit bahwa aplikasi masih crash di cloud dan bahwa pemadaman tak terduga dan downtime yang tidak direncanakan masih menjadi musuh AWS, Azure dan GCP sebanyak mereka berada di pusat data mereka sebelumnya. Langkah pertama dalam memperbaiki perjalanan cloud Anda adalah menambahkan C . Ini akan berarti beberapa hal untuk perusahaan Anda: Merancang dan merancang arsitektur yang sangat tersedia dan berlebihan Memilih perangkat lunak dan layanan yang akan melindungi komponen dan aplikasi penting Mendefinisikan dan mendokumentasikan proses dan prosedur terkait, dan setidaknya tata kelola minimal Menyebarkan salinan produksi untuk jaminan kualitas, pengujian prosedural, dan pengujian kekacauan Perluas untuk ketersediaan yang lebih tinggi untuk pemulihan bencana Tentu saja, tidak semua orang pindah ke cloud tanpa mempertimbangkan beberapa bentuk HA. Beberapa tim TI memiliki pandangan ke depan untuk tidak meninggalkan HA di lokasi, tetapi karena terburu-buru ke cloud, semua server penting mereka dipindahkan ke Availability Zone cloud yang sama. Meskipun memiliki beberapa perlindungan HA lebih baik daripada kerentanan lengkap, jika Anda hanya menerapkan server dan aplikasi Anda dalam satu Availability Zone (AZ), sekaranglah saatnya untuk memperluas ke multi-AZ untuk node cluster siaga Anda, atau bahkan membangun pemulihan bencana dengan menyebarkan node ketiga di wilayah yang berbeda. SIOS' telah membantu lusinan pelanggan merencanakan arsitektur multi-AZ dan menambahkan solusi pemulihan bencana. Bangun tim Anda Dalam semalam beberapa perusahaan, dan tim TI mereka, beralih dari sepenuhnya di lokasi menjadi bergulat dengan Cloud Formation Templates, Panduan Memulai Cepat, peran IAM, penyeimbang beban internal, IP Overlay, dan menguraikan apa arti ukuran VM itu.Kini saatnya membangun tim untuk mendukung perjalanan ke cloud.Ini akan berarti beberapa hal: Menambah kapasitas.Kecuali Anda dapat melakukan lift dan shift penuh, Anda mungkin memiliki staf yang sama yang mengelola aplikasi cloud dan lokal.Solusi lawas dikenal temperamental dan membutuhkan banyak pekerjaan agar tetap stabil dan tersedia. Untuk menavigasi perjalanan cloud ke depan, Anda memerlukan kapasitas yang mampu menangani persyaratan ketersediaan, memahami arsitektur cloud, dan merencanakan kursus ke depan untuk kebutuhan perusahaan. Meningkatkan keterampilan dengan pelatihan.Berikan pelatihan kepada tim Anda untuk cloud.Untuk mengelola dan merencanakan kursus ke depan, cari cara untuk meningkatkan keunggulan TI dalam organisasi Anda dengan pelatihan tambahan tentang solusi cloud, arsitektur, praktik terbaik, dan pertukaran.Staf yang terlatih dengan percaya diri tidak hanya akan membayar dividen dalam peningkatan ketersediaan, tetapi mereka juga akan membayar dividen dengan menangani ketersediaan, pemeliharaan, dan pertumbuhan dengan cara yang ekonomis, terukur, dan logis.Terjemahan: mereka akan menghindari pemborosan uang saat mereka membangun sisa infrastruktur cloud Anda. Mengintegrasikan otomatisasi dan analitik Sebagai Wakil Presiden Pengalaman Pelanggan di SIOS Technology Corp. Saya telah bekerja dengan beberapa perusahaan yang pindah ke cloud pada tahun 2021 tanpa mengorbankan HA, DR, atau tim mereka.Jika Anda menganggap serius pencapaian jumlah sembilan sembilan waktu aktif yang diperlukan (99,99%) dan memiliki rencana bencana tidak dapat dinegosiasikan, maka inilah saatnya untuk menambahkan ketelitian analitik dan pemantauan tambahan. Pastikan bahwa solusi ketersediaan Anda memiliki otomatisasi dan orkestrasi aplikasi untuk pemulihan jika terjadi bencana atau waktu henti yang tidak direncanakan. Tambahkan analitik dan otomatisasi untuk memperkuat solusi Anda dan tingkatkan migrasi cloud Anda dari salah satu failover reaktif ke pemberitahuan proaktif dan mitigasi kegagalan sebelum terjadi.Bayangkan diberi tahu tentang aplikasi berperforma buruk, atau peningkatan latensi, kesalahan, atau perilaku non-responsif VM tepat waktu untuk menghindari waktu henti di waktu sibuk bisnis. Analytics juga penting karena dapat mengungkapkan sistem dan aplikasi yang mungkin lolos dari arsitektur ketersediaan asli Anda. Perbarui proses dan tata kelola Banyak hal yang kita anggap sebagai kegagalan berakar pada kegagalan proses. Pastikan bahwa proses organisasi Anda mutakhir, didokumentasikan dengan baik, dikomunikasikan dengan benar, dan dipatuhi. Proses ini harus berisi beberapa kunci minimum yang terkait dengan siapa, apa, kapan, di mana, dan bagaimana semuanya terkait dengan strategi bisnis, tujuan, dan kebutuhan organisasi yang berkaitan dengan pelanggan. Pastikan bahwa proses kepemilikan dan sign-off untuk lingkungan cloud baru Anda didokumentasikan dengan baik. Saya telah melihat secara langsung rasa frustrasi yang berasal dari peran dan tanggung jawab yang saling bertentangan, bentrok, atau tidak terselesaikan bagi pelanggan yang telah pindah dari tim perangkat keras yang memperoleh infrastruktur ke tim cloud. Menyelesaikan migrasi adalah satu set masalah, menggali bencana tanpa tata kelola yang jelas adalah masalah yang jauh lebih besar dan lebih mahal. Jika Anda telah membuat lompatan ke cloud, tetap di sana dan membuatnya bekerja untuk Anda adalah bagian selanjutnya dari perjalanan.Jika perjalanan cloud Anda tiba-tiba atau sulit, pertimbangkan lima poin ini untuk memperbaiki perjalanan cloud Anda dan ketahuilah bahwa Teknologi SIOS dapat membantu Anda meningkatkan tidak hanya ketersediaan tinggi di cloud, tetapi juga proses Anda untuk berjalan di cloud. Direproduksi dengan izin dari SIOS
Januari 6, 2022	Cara Memasang Kunci Lisensi Edisi Kluster DataKeeper SIOS Cara Memasang Kunci Lisensi Edisi Kluster DataKeeper SIOS Setelah Anda menginstal Perangkat lunak SIOS DataKeeper Cluster Edition dan telah mengaktifkan lisensi Anda, Anda perlu menginstal kunci lisensi Anda sebelum Anda dapat memulai. Video berdurasi 4 menit ini akan mengulas cara menginstal perangkat lunak SIOS DataKeeper Cluster Edition dan mendemonstrasikan cara mengaktifkan lisensi Anda untuk mulai melindungi aplikasi penting Anda. Saksikan sebagai perwakilan dukungan SIOS mendemonstrasikan masing-masing dari tiga prasyarat utama yang diperlukan untuk menginstal lisensi SIOS: memastikan Anda memiliki versi terbaru dan pembaruan perangkat lunak SIOS DataKeeper; gunakan manajer kunci lisensi sederhana kami untuk memvalidasi lisensi yang diaktifkan dari hak yang dibeli, unduh dan terapkan kunci lisensi dan mulai Perangkat lunak SIOS DataKeeper . Video ini juga berjalan melalui proses akses kami Portal Dokumentasi SIOS , di mana Anda dapat menemukan catatan rilis, panduan penginstalan, dokumentasi teknis, dan informasi yang merinci SIOS DataKeeper Cluster Edition serta berbagai topik tentang semua SIOS. Lihat kiat dan wawasan praktis tentang cara menyelesaikan langkah dengan cepat dan sederhana.Sekarang Anda dan mulai melindungi aplikasi penting Anda dengan perangkat lunak pengelompokan SIOS DataKeeper Direproduksi dari SIOS
Januari 1, 2022	Empat Strategi Penghindaran untuk Meningkatkan Ketahanan, Kinerja, dan Hasil Cluster Empat Strategi Penghindaran untuk Meningkatkan Ketahanan, Kinerja, dan Hasil Cluster Langkah Sederhana untuk Penerapan di Lingkungan Cluster Suite Perlindungan SIOS Menghindari sesuatu – kita semua pernah melakukannya.Api tua yang kita lihat di toko saat berjalan dengan pasangan kita, seorang penjual ketika kita tidak “siap untuk membeli”, dan bahkan seorang bos saat kita sedang “berlibur”.Ketika saya menjadi manajer tim pengembangan, saya melihat sekilas seorang reporter langsung menjelajah di sebuah toko ketika mereka seharusnya berada di luar kantor karena sakit.Mereka merunduk di antara rak pakaian dan bergegas menyusuri lorong berikutnya dan bergegas pergi.Kita semua pernah melakukannya sebelumnya, dan dalam beberapa kasus, untuk kesehatan mental, kesehatan fisik, atau alasan yang tetap pribadi dan pribadi, kita semua memerlukan beberapa tindakan penghindaran.Bahkan di HAJadi, bagaimana Anda menambahkan penghindaran ke lingkungan Ketersediaan Tinggi Anda, dan mengapa? Empat Alasan Untuk Menggunakan Strategi Penghindaran Dalam Ketersediaan Tinggi 1. Performa Lebih Baik (meminimalkan kelebihan server) Salah satu alasan untuk menggunakan strategi penghindaran di HA adalah untuk meningkatkan kinerja aplikasi dan server.Pertimbangkan kasus tiga server yang menjalankan beban kerja produksi, sebut saja Server Alpha, Server Beta, Server Gamma.Server Alpha dan Beta menjalankan aplikasi penting yang didukung oleh database, sementara Server Gamma menjalankan tugas laporan dan transformasi data.Jika terjadi kegagalan Server Alpha, kegagalan ke Server Beta biasanya akan terjadi.Namun, karena server Beta sudah menjalankan beban kerja yang besar, beban aplikasi tambahan yang dihasilkan dapat mengakibatkan kelebihan server yang tidak diinginkan dan kinerja yang buruk untuk kedua aplikasi.Jadi mungkin bijaksana untuk menerapkan strategi penghindaran untuk memastikan bahwa Server Gamma dipilih sebagai target failover. 2. Pengoptimalan Kinerja Perhatikan kembali skenario tiga server, Alpha, Beta, dan Gamma.Server Alpha dan Beta diskalakan untuk menangani beban kerja puncak, sedangkan Server Gamma adalah server dengan biaya yang dioptimalkan.Jika terjadi kegagalan Server Alpha dan Server Beta, kegagalan akan terjadi pada server yang dioptimalkan biaya, Gamma.Namun, server ini tidak diskalakan untuk menangani beban kerja puncak, atau beban kerja Server Alpha dan Server Beta secara bersamaan.Dalam hal ini, strategi penghindaran dapat digunakan untuk mengoptimalkan kinerja dengan secara otomatis memindahkan satu atau kedua beban kerja dari Server Gamma segera setelah host lain tersedia. 3. Optimasi Ketersediaan Tinggi HA Optimization adalah skenario lain untuk menerapkan strategi penghindaran. Seperti strategi pengoptimalan kinerja, pengoptimalan HA digunakan untuk memastikan bahwa lingkungan Anda dapat bertahan dari sebagian besar skenario kegagalan dan bahwa aplikasi Anda dioptimalkan untuk memberikan tingkat ketersediaan setinggi mungkin kapan saja.Optimalisasi HA penting untuk aplikasi seperti SAP dengan proses enqueue yang direplikasi.Di lingkungan SAP mana pun, Anda tidak ingin instans ASCS (ABAP SAP Central Service) dan ERS (enqueue replica services) berada di server yang sama untuk waktu yang lama karena risiko kehilangan kunci dan pekerjaan yang dibatalkan. Untuk mencegah hal ini terjadi, Anda dapat menggunakan strategi penghindaran yang menyebabkan instans ERS dan ASCS selalu berjalan pada node cluster yang berlawanan.Pertimbangkan kasus tiga server yang menjalankan beban kerja produksi, sebut saja Server Alpha, Beta, Gamma.Server Alpha menjalankan instance ASCS, sementara Server Beta menjalankan instance ERS.Server Gamma berfungsi sebagai node ketiga untuk failover Server Beta (ERS) dan Server Alpha (ASCS).Jika Beta mogok, Anda tidak ingin sumber daya ERS berjalan pada node yang sama dengan instans ASCS.Untuk memastikan operasi ini, Anda dapat menerapkan strategi penghindaran yang secara otomatis memeriksa terlebih dahulu dan memastikan kedua aplikasi berada di server terpisah, dan mempertahankan praktik terbaik SAP ASCS/ERS untuk penguncian failover. 4. Penghindaran DR Misalkan Anda memiliki dua pusat data: City Alpha dan City Beta yang berjarak sekitar 70 mil dengan sebagian besar klien Anda berlokasi di antara keduanya. Namun, karena perubahan terbaru dalam organisasi internal, merger/penutupan dan akuisisi, dan persyaratan tata kelola, tim TI Anda harus menambahkan pusat data ketiga yang terletak di City Gamma, yang berjarak sekitar 350 mil dari Alpha dan Beta.Sekarang sumber daya yang terutama dilindungi di Alpha dan Beta juga diperluas ke lokasi Gamma.Mengingat bahwa sebagian besar pengguna dan tim berada di dekat lokasi Alfa dan Beta dan bahkan pengguna paling ekstrem berada di kota-kota tetangga, tim Anda perlu menghindari failover ke lokasi Gamma. Seperti strategi lainnya, penghindaran DR berupaya mengoptimalkan kinerja, biaya data regional masuk/keluar, latensi, dan akses klien dengan menghindari node DR jika hanya satu node dalam kedua wilayah yang gagal.Ini juga akan memastikan bahwa meskipun kedua node gagal setelah waktu yang berbeda, failover selalu terjadi pada node lain di cluster atau pusat data sebelum pindah ke DR. Jadi, bagaimana Anda menerapkan strategi penghindaran?Banyak penyedia memiliki aturan afinitas yang dapat dikonfigurasi, sementara yang lain menggunakan kombinasi prioritas server atau langkah manual.Dalam kasus Suite Perlindungan SIOS untuk Linux, Anda dapat menggunakan sejumlah metode bawaan termasuk: 1. Prioritas sumber daya Jika terjadi kegagalan, sumber daya akan dialihkan ke server yang memiliki sisa prioritas terendah dan mengalir ke server tambahan mana pun (Alpha, Beta, dan Gamma).Server Alpha adalah server utama untuk Resource.HR, Server Beta adalah server utama untuk Resource.MFG, dan Server Gamma adalah server cadangan untuk semua sumber daya/server.Menggunakan prioritas sumber daya, Resource.HR akan memiliki prioritas satu (1) di Server Alpha dan prioritas dua (2) di Server Gamma.Sedangkan Resource.MFG dapat memiliki prioritas satu (1) pada Server Beta dan prioritas dua (2) pada Server Gamma.Jika pelanggan ingin mengoptimalkan penggunaan lingkungan, maka Resource.HR dapat memiliki prioritas tiga (3) pada Server Beta dan Resource.MFG dapat memiliki prioritas tiga (3) pada Server Alpha.Jika terjadi kegagalan Server Alpha, sumber daya Resource.HR akan gagal ke Server Gamma terlebih dahulu sebelum mencoba masuk dalam layanan (dipulihkan) di Server Alpha. Suite Perlindungan SIOS untuk Linux (UI dan CLI) memungkinkan pengguna untuk menentukan prioritas untuk setiap server dan kombinasi sumber daya. 2. Kebijakan atau aturan afinitas Aturan kebijakan juga dapat digunakan untuk mencegah pemulihan sumber daya terjadi pada server tertentu dan dengan demikian memungkinkan sumber daya untuk menghindari server tertentu yang mungkin menjalankan beban kerja yang lebih kritis atau intensif sumber daya.Kebijakan umum meliputi: Kebijakan batasan yang akan memblokir aplikasi dari server tertentu secara default. Kebijakan sumber daya yang akan memblokir aplikasi dari server yang tidak memiliki sumber daya yang memadai Kebijakan temporal yang menentukan periode waktu di mana sumber daya diizinkan atau tidak diizinkan dari suatu sistem Kebijakan kustom yang menentukan server pilihan atau kemungkinan kemampuan kepemilikan aplikasi dalam cluster. Perlindungan SIOS untuk Linux CLI memungkinkan pengguna untuk menentukan aturan kebijakan yang dapat menonaktifkan failover ke sumber daya tertentu untuk server tertentu, menyediakan kebijakan sementara yang menjaga kegagalan, menonaktifkan kegagalan jenis aplikasi tertentu, kebijakan kendala, dan kebijakan kustom. Sumber Daya Penghindaran Spesifik Cara paling terperinci untuk menetapkan strategi penghindaran sumber daya adalah dengan menerapkan skrip penghindaran spesifik dalam setiap hierarki.Metode ini akan memungkinkan pengguna untuk mengonfigurasi aplikasi tertentu, (misalnya app1 dan app2), untuk menghindari satu sama lain bila memungkinkan sambil mengizinkan aplikasi lain berjalan tanpa batasan.Dalam kasus tiga server kami, Alpha, Beta, dan Gamma, dan tiga sumber daya app1, app2, dan app3 metode ini akan memberikan fleksibilitas terbesar.Dalam contoh ini, app1 dan app2 akan berusaha menghindari kolokasi saat server gagal, tetapi app3 akan gagal ke node berikutnya yang tersedia berdasarkan prioritas tanpa batasan kolokasi. Untuk contoh tambahan strategi dan sumber daya penghindaran, pertimbangkan Suite Perlindungan SIOS untuk Linux dokumentasi .Jika pelanggan memiliki dua aplikasi, app1 dan app2, yang mereka perlukan untuk dijalankan pada node yang berbeda bila memungkinkan, pelanggan dapat membuat dua sumber daya node daun terminal penghindaran menggunakan sumber daya gen/aplikasi SIOS Protection Suite untuk Linux dan '/opt/LifeKeeper /lkadm/bin/avoid_restore' skrip. – Cassius Rhee, Wakil Presiden, Pengalaman Pelanggan Direproduksi dari SIOS
Desember 28, 2021	Pengelompokan Windows Pengelompokan Windows Pengelompokan Windows Cara Mencapai Ketersediaan Tinggi di Windows Untuk mengurangi waktu henti sistem dan memastikan ketersediaan tinggi untuk Windows, praktik terbaik TI menyarankan Anda mengelompokkan server (atau node) sehingga jika satu node gagal, satu atau lebih node lain secara otomatis mengambil alih pemrosesan. Ini juga disebut sebagai pengelompokan Windows. Perangkat lunak pengelompokan diperlukan yang memantau kesehatan node utama dan memulai tindakan pemulihan jika mendeteksi masalah. Pengelompokan HA juga memerlukan cara untuk memastikan bahwa, jika terjadi kegagalan, node sekunder mengakses versi data terbaru dalam penyimpanan.Dalam kebanyakan kasus, ini dicapai dengan menghubungkan semua node cluster ke penyimpanan bersama yang sama. Node cluster harus dipisahkan secara geografis untuk melindungi aplikasi dari bencana di seluruh situs dan regional. Di lingkungan Windows Server, Microsoft menyertakan Windows Server Failover Clustering (WSFC) di platform Windows Server. Apa itu Windows Server Failover Clustering? Dengan WSFC, setiap node aktif memiliki node siaga yang memiliki spesifikasi perangkat keras yang sama dan berbagi penyimpanan yang sama. Node ketiga sering dikonfigurasi sebagai server “saksi” yang tujuan utamanya adalah untuk memastikan bahwa node utama beroperasi dan, jika masalah terdeteksi, untuk memberi sinyal perlunya operasi failover ke node siaga. Selain memantau kesehatan cluster, node di WSFC juga bekerja sama untuk secara kolektif menyediakan:[1] Pengelolaan sumber daya – Node individu menyediakan sumber daya fisik seperti SAN dan antarmuka jaringan. Aplikasi yang dihosting terdaftar sebagai sumber daya cluster dan dapat mengonfigurasi dependensi startup dan kesehatan pada sumber daya lain. Koordinasi kegagalan – Setiap sumber daya di-host pada node utama dan dapat secara otomatis atau manual ditransfer ke satu atau lebih node sekunder. Node dan aplikasi yang dihosting diberi tahu saat terjadi failover sehingga dapat bereaksi dengan tepat. WSFC bekerja dengan Microsoft Always On Availability Groups dan Always On Failover Clustering untuk mengoordinasikan failover di lingkungan Microsoft SQL Server. Bagaimana SIOS DataKeeper Melengkapi WSFC WSFC memerlukan penyimpanan bersama untuk memastikan semua node cluster mengakses data terbaru jika terjadi failover. Seringkali, perusahaan menggunakan perangkat keras SAN yang mahal untuk memastikan redundansi data. SAN mewakili satu titik risiko kegagalan. Dan, jika Anda ingin menjalankan aplikasi di cloud dengan perlindungan pengelompokan Windows Server Failover yang sama, SAN tidak tersedia. Edisi Kluster Penjaga Data SIOS terintegrasi secara mulus dengan dan memperluas pengelompokan WSFC dan SQL Server Always On Failover dengan menghilangkan kebutuhan akan penyimpanan bersama. Ini menyediakan replikasi berbasis host yang dioptimalkan kinerja untuk menyinkronkan penyimpanan lokal di semua node cluster, menciptakan cluster tanpa SAN. Sementara WSFC mengelola cluster, SIOS DataKeeper melakukan replikasi penyimpanan sinkron atau asinkron yang memberikan node siaga akses langsung ke data terkini jika terjadi failover. SIOS DataKeeper tidak hanya menghilangkan biaya, kerumitan, dan risiko kegagalan satu titik dari SAN, tetapi juga memungkinkan Anda untuk menggunakan PCIe Flash dan SSD cepat terbaru di penyimpanan lokal Anda untuk kinerja dan perlindungan dalam satu biaya- solusi yang efisien. Dengan SIOS DataKeeper, Anda juga dapat menyeimbangkan bandwidth jaringan dan penggunaan CPU untuk setiap aplikasi. Jika replikasi cepat sangat penting, SIOS DataKeeper dapat mencapai pemanfaatan bandwidth lebih dari 90 persen untuk mempercepat sinkronisasi data. Jika meminimalkan dampak jaringan adalah prioritas utama Anda, SIOS DataKeeper menawarkan kompresi terintegrasi dan pembatasan bandwidth. Selain itu, fitur Snapshot Target SIOS DataKeeper memungkinkan Anda menjalankan laporan tepat waktu dari node sekunder untuk melepaskan beban kerja yang dapat memengaruhi kinerja pada node utama. Ini memungkinkan Anda membuat kueri dan menjalankan laporan lebih cepat dan membuat keputusan lebih cepat. Bekerja dengan WSFC, SIOS DataKeeper Cluster Edition melindungi lingkungan Windows yang penting bagi bisnis, termasuk Microsoft SQL Server, SAP, SharePoint, Lync, Dynamics, dan Hyper-V menggunakan perangkat keras standar industri pilihan Anda dan penyimpanan lokal yang terpasang di “shared-nothing ” atau konfigurasi tanpa SAN.[2] SIOS DataKeeper juga menyediakan ketersediaan tinggi dan perlindungan pemulihan bencana untuk aplikasi penting bisnis Anda di lingkungan cloud, seperti Amazon Web Services (AWS), Microsoft Azure, dan Google Cloud Services tanpa mengorbankan kinerja. Suite Perlindungan SIOS – Melindungi Lingkungan Windows Tanpa WSFC Suite Perlindungan SIOS untuk Windows mencakup DataKeeper, SIOS LifeKeeper, dan Kit Pemulihan aplikasi opsional untuk operasi aplikasi dan infrastruktur terkemuka. Ini adalah solusi pengelompokan terintegrasi yang menggabungkan ketersediaan tinggi pengelompokan failover, pemantauan aplikasi berkelanjutan, replikasi data, dan kebijakan pemulihan yang dapat dikonfigurasi untuk melindungi aplikasi dan data penting bisnis Anda dari waktu henti dan bencana. Metadata dan notifikasi terdistribusi Layanan WSFC dan metadata/status node dihosting di setiap node dalam cluster. Ketika perubahan terjadi pada setiap node, informasi yang diperbarui secara otomatis disebarkan ke semua node lainnya. SIOS Protection Suite tidak memerlukan WSFC karena SIOS memantau kesehatan lingkungan aplikasi, termasuk server, sistem operasi, dan database. Itu dapat menghentikan dan memulai ulang aplikasi baik secara lokal maupun di server cluster lain di situs yang sama atau di lokasi lain. Ketika masalah terdeteksi, SIOS Protection Suite secara otomatis melakukan tindakan pemulihan dan secara otomatis mengelola cascading dan failover yang diprioritaskan. Dengan SIOS Protection Suite, Anda dapat menggunakan klaster SAN atau SANless pilihan Anda menggunakan beragam perangkat penyimpanan, termasuk penyimpanan yang terpasang langsung, iSCSI, Fibre Channel, dan banyak lagi. Suite Perlindungan SIOS untuk Windows dapat memenuhi ketersediaan tinggi Anda dan pemulihan bencana kebutuhan dalam satu situs dan di beberapa situs. Solusi Pengelompokan Windows SIOS Populer Beberapa solusi pengelompokan Windows SIOS yang paling populer – untuk SQL Server, SAP, dan lingkungan berbasis cloud – dibahas lebih detail di bawah ini. Pengelompokan Windows untuk SQL Server, SAP, S/4HANA, dan Oracle SIOS memberikan perlindungan bersertifikasi SAP yang komprehensif untuk aplikasi dan data, termasuk ketersediaan tinggi, replikasi data, dan pemulihan bencana. Untuk melindungi SAP di lingkungan Windows, SIOS Protection Suite menyertakan SIOS LifeKeeper, yang memantau seluruh tumpukan aplikasi. SIOS melindungi Database Oracle Anda baik Anda menggunakannya dengan SAP atau menjalankan aplikasi Oracle mandiri – Anda cukup memilih Kit Pemulihan Aplikasi yang sesuai dengan konfigurasi Anda. Pengelompokan Windows di Cloud Baik Anda memerlukan SIOS DataKeeper untuk mengaktifkan Windows Server Failover Clustering di cloud atau SIOS Protection Suite untuk Windows untuk pemantauan aplikasi dan orkestrasi failover, serta replikasi data tingkat blok yang efisien, SIOS memberikan fleksibilitas konfigurasi yang lengkap. SIOS memungkinkan Anda membuat cluster dalam kombinasi infrastruktur fisik, virtual, cloud, atau hybrid cloud. Misalnya, bekerja dengan WSFC, SIOS DataKeeper dapat: Lindungi aplikasi bisnis lokal atau hibrid yang penting ke lingkungan Windows dengan ketersediaan tinggi di AWS, Azure, atau Google Cloud. Lindungi aplikasi cloud, seperti SQL Server dan SAP, dengan membuat kluster Windows di AWS, Azure, atau Google Cloud. Menyediakan perlindungan pemulihan bencana dan ketersediaan tinggi di seluruh situs, lokal, atau regional dengan gagal mengatasi instans aplikasi di seluruh zona atau wilayah ketersediaan cloud. SIOS DataKeeper Cluster Edition dapat memberikan perlindungan cluster ketersediaan tinggi di seluruh cloud Kesimpulan SIOS menyediakan penawaran yang mendukung berbagai aplikasi, sistem operasi, dan lingkungan infrastruktur, menyediakan solusi tunggal yang dapat menangani semua kebutuhan ketersediaan tinggi Anda. Berikut adalah beberapa contoh yang menunjukkan kekuatan SIOS. Stadion Perth di Australia Barat menerapkan SIOS DataKeeper dengan WSFC untuk menyediakan ketersediaan tinggi untuk mesin virtual Hyper-V mereka. Bayar ( paygoutilities.com ), yang berbasis di AS, menerapkan SIOS DataKeeper dengan WSFC untuk menyediakan ketersediaan tinggi untuk SQL Server di AWS. Toyo Gosei, yang berbasis di Jepang, mengimplementasikan SIOS DataKeeper dengan WSFC untuk menyediakan ketersediaan tinggi dan pemulihan bencana untuk aplikasi SAP mereka di Azure. Untuk informasi lebih lanjut tentang ketersediaan tinggi/solusi pemulihan bencana untuk mendukung lingkungan Windows Anda, klik di sini[TM(1] . Referensi https://www.techopedia.com/definition/24358/windows-clustering https://searchwindowsserver.techtarget.com/definition/Windows-Server-failover-clustering https://docs.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/windows-server-failover-clustering-wsfc-with-sql-server?view=sql-server-ver15[1] https://docs.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/windows-server-failover-clustering-wsfc-with-sql-server?view=sql-server-ver15[2] Arsitektur shared-nothing (SN) adalah arsitektur komputasi terdistribusi di mana setiap permintaan pembaruan dipenuhi oleh satu node (unit prosesor/memori/penyimpanan). https://en.wikipedia.org/wiki/Shared-nothing_architecture Direproduksi dari SIOS

Results 236-240 of 939
< Page 48 of 188 >

Bergabunglah dengan Milis Kami

First Name Last Name Email Address
Pencarian