replikasi | SIOS SANless clusters

Cara Menggabungkan Pencadangan, Replikasi, dan Clustering Ketersediaan Tinggi

Juli 22, 2020 by Jason Aw Leave a Comment

Cara Menggabungkan Pencadangan, Replikasi, dan Clustering Ketersediaan Tinggi

Pencadangan, replikasi, dan ketersediaan tinggi (HA) adalah bagian mendasar dari manajemen risiko TI, dan mereka sangat diperlukan seperti roda pada mobil. Replikasi juga penting untuk perlindungan data TI.

Lingkungan Cadangan dan HA Cluster Tidak Saling Eksklusif

Sementara cadangan, replikasi, dan failover semuanya penting, ada perbedaan utama di antara mereka yang perlu dipahami untuk memastikan mereka diterapkan dengan benar.

Misalnya, saat Anda dapat menggunakan replikasi untuk mempertahankan salinan data yang terus-menerus diperbarui, tanpa mempertimbangkannya di lingkungan perlindungan data yang lebih besar, Anda juga akan menyalin data masalah (seperti data yang terinfeksi virus).

Dalam kasus seperti itu, cadangan sangat penting untuk mengembalikan data ke poin baik terakhir yang diketahui. Dengan melakukan replikasi, Anda dapat mengakses gambar yang direplikasi segera sebelum kegagalan sistem (= RTO / RTO lebih unggul) dengan cara yang hanya menyimpan data berdasarkan generasi dan mendukungnya dalam model tipe eDiscovery tidak bisa.

Oleh karena itu, SIOS Protection Suite mencakup perangkat lunak pengelompokan SIOS LifeKeeper dan perangkat lunak replikasi DataKeeper. SIOS LifeKeeper adalah produk cluster failover HA yang memantau kesehatan aplikasi dan mengatur failover aplikasi dan DataKeeper adalah perangkat lunak replikasi penyimpanan berbasis blok. Namun, hanya karena itu adalah cluster HA tidak berarti cadangan tidak diperlukan. Pertimbangkan tindakan pencegahan dan poin yang perlu diperhatikan saat mencadangkan di lingkungan HA cluster menggunakan SIOS Protection Suite.

Lima Poin Cadangan di Lingkungan Clustering Ketersediaan Tinggi

Pertimbangkan lima poin berikut sebagai target perolehan cadangan:

Sistem Operasi (OS)
SIOS Protection Suite – Program Clustering Software LifeKeeper / DataKeeper
SIOS Protection Suite – informasi konfigurasi LifeKeeper / DataKeeper
Program aplikasi (mis., SQL Server, SAP S / 4 HANA, Oracle, PostgreSQL, dll.)
Data aplikasi

Cadangkan OS

Untuk mencadangkan OS, biasanya digunakan utilitas OS standar atau perangkat lunak cadangan pihak ketiga. Namun, karena tidak ada pertimbangan khusus untuk lingkungan ketersediaan tinggi, kami tidak akan membahasnya di sini.

Cadangkan Perangkat Lunak Clustering SIOS Protection Suite

SIOS Protection Suite termasuk program SIOS LifeKeeper / DataKeeper juga dapat diperoleh dengan utilitas standar OS atau perangkat lunak cadangan pihak ketiga, tetapi jika program menghilang karena kegagalan disk, dll. tanpa sengaja mencadangkannya, Anda perlu menginstalnya kembali. Mungkin akan ada beberapa orang yang berpikir tentang dikotomi melakukannya.

Cadangkan Informasi Konfigurasi SIOS Protection Suite

SIOS LifeKeeper hadir dengan perintah sederhana bernama lkbackup yang memungkinkan Anda membuat cadangan informasi konfigurasi. lkbackup dapat dijalankan pada SIOS LifeKeeper dan sumber daya terkait dan tidak akan memengaruhi layanan yang berjalan.

Perintah ini dapat dieksekusi dalam tiga kasus utama berikut.

Segera setelah menginstal sumber daya SIOS LifeKeeper yang baru dibuat
Sebelum dan sesudah mengubah konfigurasi SIOS LifeKeeper (menambah / mengubah dependensi, menambah / menghapus sumber daya)
Sebelum dan sesudah pemutakhiran versi SIOS LifeKeeper

Jika Anda mencadangkan informasi konfigurasi dengan lkbackup, bahkan jika informasi konfigurasi hilang karena kegagalan disk atau jika informasi konfigurasi rusak karena kesalahan operasi, dll.) Anda dapat dengan cepat kembali ke keadaan operasional semula.

Program Operasional Cadangan

Meskipun mencadangkan program operasi mengacu pada mencadangkan aplikasi bisnis yang dilindungi di HA cluster Anda, dimungkinkan untuk membuat dan memulihkan gambar cadangan menggunakan utilitas standar OS atau perangkat lunak cadangan pihak ketiga seperti pada 1. dan 2 di atas.

Cadangkan Data Aplikasi Bisnis

Di lingkungan HA cluster, penyimpanan bersama yang dapat diakses oleh server aktif dan siaga disediakan. Selama operasi normal, penyimpanan bersama digunakan oleh node cluster aktif. Data aplikasi (misalnya, data basis data) biasanya penyimpanan dalam penyimpanan bersama ini, tetapi poin-poin berikut harus diingat ketika membuat cadangan penyimpanan ini.

Untuk konfigurasi penyimpanan bersama

Saat memperoleh cadangan data yang terletak di konfigurasi kluster SANless dengan penyimpanan yang dibagikan oleh node kluster aktif dan sistem siaga, data hanya dapat diakses dari sistem aktif (sistem siaga tidak dapat mengakses data). Akibatnya, cadangannya juga aktif. Dalam hal ini, pastikan bahwa ada kekuatan pemrosesan yang cukup untuk menangani skenario failover dan cadangan pemulihan.

Untuk konfigurasi penyimpanan bersama

Untuk konfigurasi replikasi data

Dalam hal konfigurasi replikasi data, cadangan dari sistem operasi adalah dasar, tetapi dengan menghentikan sementara mirroring dan melepaskan kunci, cadangan juga dapat dieksekusi di sisi sistem siaga. Namun, dalam hal ini, data sementara tidak sinkron.

Untuk konfigurasi replikasi data

Mencadangkan simpul cluster dari server cadangan eksternal

Untuk melakukan cadangan node cluster dari server backup eksternal, gunakan alamat IP virtual atau nyata dari node cluster. Poin yang perlu diperhatikan dalam setiap kasus adalah sebagai berikut.

Mencadangkan menggunakan alamat IP virtual node cluster

Dari perspektif server cadangan, cadangan dieksekusi ke node yang ditunjukkan oleh alamat IP virtual LifeKeeper. Dalam hal ini, server cadangan tidak perlu mengetahui simpul mana yang merupakan simpul aktif.

Mencadangkan menggunakan alamat IP virtual node cluster

Mencadangkan menggunakan alamat IP asli dari node cluster

Dari perspektif server cadangan, cadangan dilakukan ke alamat IP asli tanpa menggunakan alamat IP virtual LifeKeeper. Karena penyimpanan bersama tidak dapat diakses dari node cluster siaga, server cadangan dan klien harus memeriksa node mana yang merupakan node aktif.

Menggabungkan cadangan, replikasi, dan failover clustering dalam cadangan konfigurasi yang teruji dan diverifikasi sangat diperlukan. Menggunakan melakukan verifikasi operasi yang memadai terlebih dahulu di sisi pengguna.

Direproduksi dengan izin dari SIOS

Maksimalkan kinerja replikasi untuk Linux Clustering dengan Fusion-io

November 27, 2018 by Jason Aw Leave a Comment

Tips Untuk Memaksimalkan Kinerja Replikasi Untuk Linux Clustering Dengan Fusion-io

Ketika kebanyakan orang berpikir tentang menyiapkan klaster, biasanya melibatkan dua atau lebih server, dan SAN – atau beberapa jenis penyimpanan bersama lainnya. SAN biasanya sangat mahal dan rumit untuk disiapkan dan dikelola. Juga, mereka secara teknis mewakili Potensi Titik Gagal (SPOF) potensial dalam arsitektur cluster Anda. Saat ini, semakin banyak orang yang beralih ke perusahaan seperti Fusion-io, dengan ioDrives yang cepat, untuk mempercepat aplikasi penting. Perangkat penyimpanan ini ada di dalam server (yaitu "disk yang dibagikan"). Oleh karena itu tidak dapat digunakan sebagai disk klaster dengan banyak solusi pengelompokan tradisional. Untungnya, ada cara untuk Memaksimalkan kinerja replikasi untuk Linux Clustering dengan Fusion-io. Solusi yang memungkinkan Anda untuk membentuk kluster failover ketika tidak ada penyimpanan bersama yang terlibat – yaitu klaster "berbagi apa-apa".


Cluster Tradisional	Cluster "Dibagikan Tidak Ada"

Ketika memanfaatkan replikasi data sebagai bagian dari konfigurasi kluster, penting bahwa Anda memiliki cukup bandwidth sehingga data dapat direplikasi di seluruh jaringan secepat yang ditulis ke disk. Berikut ini adalah kiat penyetelan yang memungkinkan Anda untuk memanfaatkan konfigurasi klaster "bersama apa-apa", ketika penyimpanan berkecepatan tinggi dilibatkan:

Jaringan

Gunakan NIC 10Gbps: Perangkat penyimpanan berbasis flash dari Fusion-io (atau produk serupa lainnya dari OCZ, LSI, dll.) Mampu menulis data dengan kecepatan di HUNDREDS (750) MB / detik atau lebih. NIC 1Gbps hanya dapat mendorong maksimum teoritis ~ 125 MB / detik, sehingga siapa pun yang memanfaatkan potensi ioDrive dapat dengan mudah menulis data lebih cepat daripada yang dapat didorong melalui koneksi jaringan 1 Gbps. Untuk memastikan bahwa Anda memiliki bandwidth yang cukup antara server untuk memfasilitasi replikasi data real-time, NIC 10 Gbps harus selalu digunakan untuk membawa lalu lintas replikasi
Aktifkan Bingkai Jumbo: Dengan asumsi bahwa Kartu Jaringan dan Switch Anda mendukungnya, memungkinkan bingkai jumbo dapat meningkatkan throughput jaringan Anda sekaligus mengurangi siklus CPU. Untuk mengaktifkan frame jumbo, lakukan konfigurasi berikut (contoh dari server linux RedHat / CentOS / OEL)
- ifconfig <interface_name> mtu 9000
- Edit / etc / sysconfig / network-scripts / ifcfg- <interface_name> file dan tambahkan "MTU = 9000" sehingga perubahan tetap ada di reboot
- Untuk memverifikasi operasi bingkai jumbo ujung-ke-ujung, jalankan perintah ini: ping -s 8900 -M lakukan <IP-dari-server lain>
Ubah panjang antrian transmisi NIC:
- / sbin / ifconfig <interface_name> txqueuelen 10000
- Tambahkan ini ke /etc/rc.local untuk mempertahankan pengaturan di reboot

TCP / IP Tuning

Ubah netdev_max_backlog NIC:
- Set "net.core.netdev_max_backlog = 100000" di /etc/sysctl.conf
Penyetelan TCP / IP lainnya yang telah terbukti meningkatkan kinerja replikasi:
- Catatan: ini adalah nilai contoh dan beberapa mungkin perlu disesuaikan berdasarkan konfigurasi perangkat keras Anda
- Edit /etc/sysctl.conf dan tambahkan parameter berikut:
  - net.core.rmem_default = 16777216
  - net.core.wmem_default = 16777216
  - net.core.rmem_max = 16777216
  - net.core.wmem_max = 16777216
  - net.ipv4.tcp_rmem = 4096 87380 16777216
  - net.ipv4.tcp_wmem = 4096 65536 16777216
  - net.ipv4.tcp_timestamps = 0
  - net.ipv4.tcp_sack = 0
  - net.core.optmem_max = 16777216
  - net.ipv4.tcp_congestion_control = htcp

Penyesuaian

Biasanya Anda juga perlu melakukan penyesuaian pada konfigurasi kluster Anda, yang akan bervariasi berdasarkan teknologi pengelompokan dan replikasi yang Anda putuskan untuk diterapkan. Dalam contoh ini, saya menggunakan SteelEye Protection Suite untuk Linux (alias SPS, alias LifeKeeper), dari SIOS Technologies. Ini memungkinkan pengguna untuk membentuk cluster failover memanfaatkan hampir semua jenis penyimpanan back-end: Fibre Channel SAN, iSCSI, NAS, atau, yang paling relevan dengan artikel ini, disk lokal yang perlu disinkronkan / direplikasi secara real time antara node cluster. SPS untuk Linux termasuk terintegrasi, fungsi replikasi data tingkat blok yang membuatnya sangat mudah untuk men-setup cluster ketika tidak ada penyimpanan bersama yang terlibat.

Rekomendasi

Untuk Memaksimalkan kinerja replikasi untuk Linux Clustering dengan Fusion-io, mari coba ini. SteelEye Protection Suite (SPS) untuk rekomendasi konfigurasi Linux:

Alokasikan partisi disk kecil (~ 100 MB), yang terletak di drive Fusion-io untuk menempatkan file bitmap. Buat filesystem di partisi ini dan pasang, misalnya, di / bitmap:
- # mount | grep / bitmap
- / dev / fioa1 pada / bitmap type ext3 (rw)
Sebelum membuat mirror Anda, sesuaikan parameter berikut di / etc / default / LifeKeeper
- Sisipkan: LKDR_CHUNK_SIZE = 4096
  - Nilai default adalah 64
- Edit: LKDR_SPEED_LIMIT = 1500000
  - (Nilai default adalah 50000)
  - LKDR_SPEED_LIMIT menentukan bandwidth maksimum yang akan dilakukan ulang oleh resync – ini harus diatur cukup tinggi untuk memungkinkan resyncs berjalan pada kecepatan maksimum yang mungkin
- Edit: LKDR_SPEED_LIMIT_MIN = 200000
  - (Nilai default adalah 20000)
  - LKDR_SPEED_LIMIT_MIN menentukan seberapa cepat resync harus dibiarkan pergi ketika ada I / O lain terjadi pada saat yang sama – sebagai aturan praktis, ini harus diset ke setengah atau kurang dari throughput tulis maksimum drive untuk menghindari kelaparan keluar aktivitas I / O normal ketika resync terjadi

Dari sini, lanjutkan dan buat mirror Anda dan konfigurasikan kluster seperti biasa. Tertarik untuk Memaksimalkan Kinerja Replikasi Untuk Linux Clustering Dengan Fusion-io, lihat apa lagi yang dapat ditawarkan SIOS. Direproduksi dengan izin dari LinuxClustering

Cloud Witness Untuk Membangun Multi-Instance SQL Server Failover Cluster Di Azure

September 10, 2018 by Jason Aw Leave a Comment

Fitur Azure ILB Baru Memungkinkan Anda Untuk Membangun Multi-Instance SQL Server Failover Cluster Di Azure

Fitur baru, Cloud Witness adalah favorit saya saat ini. Sebelum kami melihat fitur kuorum baru di Windows Server 2016, saya pikir penting untuk mengetahui dari mana kami berasal. Dalam posting saya sebelumnya Memahami Kuorum Kluster Failover Windows Server di Windows Server 2012 R2 Saya membahas beberapa detail besar mengenai sejarah dan evolusi kuorum klaster. Saya sarankan Anda meninjau posting itu untuk memahami bagaimana kuorum bekerja di Windows Server 2012 R2. Juga, bagaimana fitur-fitur baru dari Windows Server 2016 akan membuat penyebaran klaster Anda bahkan lebih tangguh.

Cloud Witness

Cloud Witness memungkinkan Anda memanfaatkan Penyimpanan Azure Blob untuk bertindak sebagai saksi bagi kluster Anda. Saksi ini akan menjadi saksi Disk Witness atau File Share Witness. Konfigurasi Cloud Witness sangat mudah. Dari pengalaman saya biaya hampir tidak ada untuk menjadi tuan rumah di Azure. Satu-satunya downside adalah bahwa node cluster perlu dapat berkomunikasi melalui internet dengan Storage Azure Blob Anda. Sangat sering node klaster dilarang untuk berkomunikasi ke internet publik. Jadi Anda perlu berkoordinasi dengan tim keamanan Anda jika Anda ingin mengaktifkan Cloud Witness. Ada banyak alasan kuat untuk menggunakan Cloud Witness untuk membangun Multi-Instance SQL Server Failover Cluster In Azure. Tapi bagi saya itu sangat masuk akal dalam tiga lingkungan yang sangat spesifik: Failover Cluster di Azure, Cabang Kantor Cluster, dan Cluster Multisite.

Pada Pandangan Lebih Dekat

Mari kita lihat masing-masing skenario ini untuk melihat bagaimana seorang Cloud Witness dapat membantu. Gambar 1 – Ketika Anda mencoba untuk membangun Multi-Instance SQL Server Failover Cluster Di Azure, akun penyimpanan saksi cloud harus selalu dikonfigurasi Lokal Redundant Storage (LRS) [/ caption]

Penyebaran yang Sangat Tersedia

Jika Anda pindah ke Azure (atau benar-benar penyedia cloud apa pun), Anda akan ingin memastikan penyebaran Anda sangat tersedia. Jika Anda mengambil tentang SQL Server, File Server, SAP atau beban kerja lainnya yang secara tradisional bergerombol dengan Windows Server Failover Clustering, Anda harus menggunakan File Share Witness atau Cloud Witness, karena Disk Witness tidak mungkin di Azure. Dengan Windows Server 2012 R2 atau Windows Server 2008 R2, Anda harus menggunakan File Share Witness. Windows Server 2016 memungkinkan untuk menggunakan Cloud Witness. Keuntungan dari Cloud Witness adalah Anda tidak perlu mempertahankan instance Windows lainnya di Azure untuk menghosting File Share. Sebaliknya, Microsoft memungkinkan Anda untuk memanfaatkan Blob Storage. Ini memberi Anda solusi yang lebih murah, yang jauh lebih mudah dikelola, dan lebih tangguh.

Lokasi

Ketika melihat penyebaran cluster di kantor cabang, biaya dan pemeliharaan selalu menjadi pertimbangan. Untuk jaringan ritel dengan ratusan atau ribuan lokasi, memiliki SAN di setiap lokasi dapat menjadi penghalang biaya. Setiap lokasi mungkin untuk menjalankan dua node Hyper-V cluster pada konfigurasi S2-Hyper-converged at^au solusi replikasi pihak ke-3 untuk meng-host sejumlah mesin virtual. Sekarang yang dilakukan Cloud Witness adalah membantu bisnis menghindari biaya penambahan server fisik tambahan di setiap lokasi untuk bertindak sebagai File Share Witness atau biaya penambahan SAN ke setiap lokasi.

Menghilangkan Kebutuhan Akan P^usat Data Ketiga

Dan akhirnya, ketika menggelar cluster multisite, Cloud Witness menghilangkan kebutuhan untuk pusat dat^ake-3 untuk menjadi tuan rumah File Share Witness. Sebelum pengenalan Cloud Witness, praktik terbaik akan menentukan bahwa Saksi Berbagi Berkas berada di lo^kasi ketiga. Akses ke pusa^tdata ke-3 hanya untuk menghosting saksi berbagi file tidak selalu layak dan tentu saja memperkenalkan lapisan kompleksitas lain. Dengan menggunakan Cloud Witness Anda menghilangkan kebutuhan untu^kmempertahankan lokasi ketiga dan akses ke saksi dilakukan melalui internet publik, meminimalkan persyaratan jaringan juga.

Kesadaran Situs

Ketika membangun klaster multisite, selalu ada masalah umum lainnya. Mengontrol failover untuk selalu memilih situs lokal tidak mungkin dilakukan. Meskipun Anda dapat menentukan Pemilik Pilihan, pengaturan Pemilik Pilihan umumnya salah dimengerti. Administrator mungkin tidak menyadari hal ini. Tetapi tahukah Anda bahwa meskipun mereka tidak mencantumkan server sebagai Pemilik Pilihan, server secara otomatis ditambahkan ke bagian akhir daftar Pemilik Pilihan yang dikelola oleh kluster. Hasil dari kesalahpahaman ini adalah bahwa meskipun Anda mungkin hanya mendaftarkan server lokal sebagai Pemilik Pilihan, Anda berpotensi memiliki failover sumber gugus ke situs DR. Dan ini bahkan ketika ada node yang sangat baik yang tersedia di situs lokal. Tentunya ini bukan apa yang Anda harapkan dan gunakan Kesadaran Situs akan menghilangkan masalah ini bergerak maju. Kesadaran Situs memperbaiki masalah ini dengan selalu lebih memilih situs lokal ketika memutuskan node mana yang akan online. Jadi dalam keadaan normal beban kerja yang berkelompok akan selalu failover ke simpul lokal kecuali Anda memiliki situs lengkap pemadaman. Dalam hal mana salah satu DR node akan datang online. Hal yang sama berlaku saat Anda menjalankan di situs DR. Cluster akan memulihkan beban kerja pada server di situs DR jika sebelumnya berjalan pada node di situs DR. Kesadaran Situs akan selalu lebih memilih simpul lokal.

Domain Kesalahan

Membangun berdasarkan kesadaran situs adalah Domain Kesalahan. Fault Domains melangkah lebih jauh dan memungkinkan Anda menentukan lokasi Node, Chasse, dan Rack selain Situs. Domain Fault memiliki tiga manfaat: Penyimpanan Affinity dalam Cluster Stretch, meningkatkan ketahanan Storage Spaces. Ini meningkatkan peringatan Layanan Kesehatan dengan memasukkan data meta tentang lokasi sumber daya terkait yang meningkatkan alarm. Penyimpanan Afinitas akan membantu memastikan bahwa beban kerja dan penyimpanan gugus Anda berjalan di lokasi yang sama. Anda tentu tidak ingin membaca dan menulis data VM Anda yang ada di CSV di kota yang berbeda. Namun, saya pikir pemenang terbesar di sini adalah skenario Storage Spaces Direct (S2D). SD2 akan memanfaatkan informasi yang Anda berikan tentang lokasi node klaster Anda (Situs, Rak, Chassis) untuk memastikan bahwa beberapa salinan data yang ditulis untuk redundansi semua tinggal di Domain Kesalahan yang berbeda. Ini membantu memastikan bahwa penempatan data dioptimalkan sehingga kegagalan Node, Chassis, Rak, atau Situs tunggal tidak menurunkan seluruh penempatan S2D Anda. Cosmos Darwin memiliki video yang luar biasa di Saluran 9 yang menjelaskan konsep ini dengan sangat terperinci.

Ringkasan

Windows Server 2016 menambahkan beberapa perangkat tambahan baru ke kuorum klaster yang akan memberikan beberapa manfaat langsung ke penyebaran klaster Anda. Selain itu, periksa beberapa peningkatan klaster baru lainnya seperti peningkatan sistem rolling, Ketahanan Virtual Machine, Workgroup dan Multi-Domain Cluster dan lain-lain. Untuk membaca tentang tips lain seperti membangun Multi-Instance SQL Server Failover Cluster Di Azure dengan Cloud Witness, baca di posting kami. Direproduksi dengan izin dari Clusteringformeremortals.com

SIOS Replikasi Data Dan Solusi Pemulihan Bencana Untuk Perlindungan Data

Mei 27, 2018 by Jason Aw Leave a Comment

Perusahaan Perangkat Lunak yang Melayani Lembaga Pendidikan Menggunakan Replikasi Data Biaya-Efektif SIOS Dan Solusi Pemulihan Bencana Untuk Perlindungan Data Berkelanjutan

Windows Server 2008 R2 yang banyak diantisipasi menjadi tersedia pada akhir Oktober. VISUCATE menjadi salah satu dari banyak usaha kecil untuk menyebarkan Microsoft Hyper-V dan menikmati fitur barunya seperti migrasi langsung. Perusahaan membutuhkan replikasi data dan solusi pemulihan bencana. Salah satu yang cukup murah dan memberikan perlindungan kelas satu.

Dalam upaya untuk menyelesaikan pengaturannya, VISUCATE menginginkan platform kesinambungan bisnis yang memenuhi harapan bisnisnya yang kecil. Mereka memanfaatkan fitur ketersediaan tinggi dari Windows Server Failover Clustering. Namun, 5fhbvd VISUCATE membutuhkan jaminan tambahan bahwa hilangnya data penting atau downtime tidak akan mengganggu penjualan perangkat lunaknya. Untuk mengatasi hambatan replikasi data spesifik ini, VISUCATE beralih ke SIOS DataKeeper Cluster Edition.

Tantangan

Mereka membutuhkan solusi replikasi data dan pemulihan bencana yang terjangkau, tidak rumit dan kuat untuk melindungi seting Hyper-V yang baru. Untuk mencegah downtime, perusahaan membutuhkan servernya untuk mereplikasi dan mempertahankan kemampuan operasional mereka. Jika satu server gagal, server lain dikonfigurasi untuk mengambil alih untuk mempertahankan operasi, memaksimalkan waktu kerja dan menjamin produktivitas pengguna. Solusi bersama dari Microsoft Hyper-V dengan Windows Server Failover Clustering dan SIOS DataKeeper Cluster Edition memenuhi persyaratan bisnis penting untuk VISUCATE serta setiap organisasi yang berniat untuk mengatasi tantangan ini.

VISUCATE Mempertahankan Ketersediaan Hyper-V, Keberlangsungan Bisnis dengan SIOS DataKeeper®

VISUCATE menggunakan Windows Server 2008 R2 pada dua server fisik dengan peran Hyper-V diaktifkan. Perusahaan menggunakan Windows Server Failover Clustering dan SIOS DataKeeper Cluster Edition untuk menyediakan replikasi dan failover dari mesin virtual. Dengan penyebaran Hyper-V, lima mesin virtual VISUCATE dipasang di kedua server. Tiga dalam satu server dan dua di server lain.

Dengan menjaga mesin virtual Windows Server 2008 Hyper-V yang tersinkronisasi antara dua server fisik, SIOS DataKeeper memungkinkan pemulihan bencana tanpa pemulihan dan downtime yang biasanya terkait dengan teknologi back-up dan pemulihan tradisional. Replikasi terus-menerus secara terus-menerus dari mesin virtual Windows Server 2008 Hyper-V yang aktif memastikan bahwa dalam hal terjadi downtime yang berdampak pada VISUCATE set-up, mesin virtual yang direplikasi dapat secara otomatis dibawa ke layanan dengan kehilangan data minimal atau tidak ada sama sekali. VISUCATE mempertimbangkan beberapa opsi untuk solusi failover cluster. Perusahaan menolak opsi untuk membuat kluster dengan server lowcost SAN atau NAS / file. Jika SAN dalam konfigurasi itu gagal, seluruh pengaturan akan gagal.

SIOS DataKeeper Cluster Edition mengurangi biaya penggelaran kluster dengan menghilangkan kebutuhan akan SAN. Ini juga meningkatkan ketersediaan mesin virtual dan aplikasi dengan menghilangkan titik tunggal kegagalan yang mewakili SAN dalam kelompok penyimpanan bersama tradisional.

Manfaat

SIOS DataKeeper Cluster Edition memungkinkan perusahaan seperti VISUCATE untuk membangun "shared-nothing" dan secara geografis menyebarkan Windows Server 2008 Hyper-V cluster. Dengan menghilangkan persyaratan penyimpanan bersama, perusahaan dapat melindungi baik downtime terencana maupun tidak terencana untuk server dan penyimpanan. Juga, penggunaan SIOS DataKeeper dengan mesin virtual Windows Server 2008 Hyper-V memungkinkan untuk pengujian pemulihan bencana yang tidak mengganggu. Dengan hanya mengakses mesin virtual yang direplikasi di situs pemulihan bencana, VISUCATE dan perusahaan lain dapat menyegmentasikan jaringan virtual yang terpisah dari jaringan produksi. Juga, itu akan dapat memulai mesin virtual yang direplikasi untuk pengujian pemulihan bencana. Administrator dapat melakukan replikasi data yang lengkap dan pengujian solusi pemulihan bencana tanpa mempengaruhi situs produksi.

Selain dukungan untuk gugus Hyper-V, SIOS DataKeeper Cluster Edition memungkinkan kluster multi-situs untuk semua jenis sumber daya klaster Microsoft lainnya. Ini termasuk SQL Server, Exchange, File / Print dan DHCP.

Untuk mengetahui lebih lanjut tentang produk SIOS, buka di sini
Untuk membaca tentang bagaimana SIOS membantu VISUCATE mencapai replikasi data dan solusi pemulihan bencana, buka di sini