SIOS SANless clusters

Juni 27, 2022	Opsi Baru untuk Cluster Ketersediaan Tinggi, SIOS Memperkuat Dukungannya untuk Disk Bersama Microsoft Azure Opsi Baru untuk Cluster Ketersediaan Tinggi, SIOS Memperkuat Dukungannya untuk Disk Bersama Microsoft Azure Microsoft memperkenalkan Disk Bersama Azure pada Q1 tahun 2022. Disk Bersama memungkinkan Anda untuk melampirkan disk yang dikelola ke lebih dari satu host. Secara efektif ini berarti bahwa Azure sekarang memiliki penyimpanan SAN yang setara, memungkinkan Sangat Tersedia cluster untuk menggunakan disk bersama di cloud! Keuntungan utama menggunakan Azure Shared Disk dengan hierarki klaster SIOS Lifekeeper adalah Anda tidak lagi diharuskan memiliki kuorum penyimpanan atau simpul saksi. Dengan cara ini Anda dapat menghindari apa yang disebut otak terbelah – yang terjadi ketika komunikasi antar node terputus dan beberapa node berpotensi mengubah data secara bersamaan. Lebih sedikit node berarti lebih sedikit biaya dan kompleksitas. Kit Pemulihan LifeKeeper SCSI-3 Persistent Reservations (SCSI3) SIOS telah memperkenalkan Kit Pemulihan Aplikasi (ARK) untuk produk LifeKeeper untuk Linux kami. Ini disebut Kit Pemulihan LifeKeeper SCSI-3 Persistent Reservations (SCSI3). Ini memungkinkan Azure Shared Disks untuk digunakan bersama dengan reservasi SCSI-3. ARK menjamin bahwa disk bersama hanya dapat ditulis dari node yang saat ini menyimpan reservasi SCSI-3 pada disk tersebut. Saat menginstal SIOS Lifekeeper, penginstal akan mendeteksi bahwa itu berjalan di Microsoft Azure EC2. Ini akan secara otomatis menginstal Kit Pemulihan LifeKeeper SCSI-3 Persistent Reservations (SCSI3) untuk mengaktifkan dukungan untuk Azure Shared Disk. Pembuatan sumber daya dalam Lifekeeper sangat mudah dan sederhana (Gambar 1). Azure Shared Disk hanya ditambahkan ke Lifekeeper sebagai sumber daya jenis sistem file setelah dipasang secara lokal. Lifekeeper akan memberinya ID (Gambar 2) dan mengelola penguncian SCSI-3 secara otomatis. Gambar 1. Membuat Instans SAP (sapinst) di LifeKeeper Gambar 2: Dibuat Diperluas ke kedua node. Reservasi SCSI-3 menjamin bahwa Azure Shared Disk hanya dapat ditulis pada node yang menyimpan reservasi (Gambar 3). Dalam skenario di mana node cluster kehilangan komunikasi satu sama lain, server siaga akan online, menyebabkan potensi situasi otak terbelah. Namun, karena reservasi SCSI-3, hanya satu node yang dapat mengakses disk pada satu waktu. Ini sebenarnya mencegah skenario otak terbelah yang sebenarnya. Hanya satu sistem yang akan menahan reservasi. Ini akan menjadi node aktif baru (dalam hal ini yang lain akan reboot) atau tetap menjadi node aktif. Node yang tidak memegang reservasi Azure Shared Disk hanya akan berakhir dengan sumber daya dalam status "Siaga". Hanya karena mereka tidak dapat memperoleh reservasi. Gambar 3 – Keluaran dari log Lifekeeper saat mencoba memasang disk yang sudah dicadangkan. Tautan ke definisi Microsoft tentang Azure Shared Disks https://docs.microsoft.com/en-us/azure/virtual-machines/disks-shared Apa yang Dapat Anda Harapkan Saat ini, SIOS mendukung Locally-redundant Storage (LRS).Kami bekerja sama dengan Microsoft untuk menguji dan mendukung Zone-Redundant Storage (ZRS). Idealnya kami ingin tahu kapan ada kegagalan ZRS sehingga kami dapat mengalihkan hierarki sumber daya ke node paling lokal ke penyimpanan aktif. SIOS mengharapkan dukungan Azure Shared Disk akan tiba di rilis Lifekeeper 9.6.2 untuk Linux berikutnya. Direproduksi dengan izin dari SIOS
Juni 23, 2022	Apa itu "Otak Terbelah" dan Bagaimana Menghindarinya Apa itu "Otak Terbelah" dan Bagaimana Menghindarinya Seperti yang telah kita bahas, dalam Ketersediaan Tinggi lingkungan cluster ada satu node aktif dan satu atau lebih node siaga yang akan mengambil alih layanan ketika node aktif gagal atau berhenti merespons. Ini terdengar seperti asumsi yang masuk akal sampai lapisan jaringan antara node dipertimbangkan. Bagaimana jika jalur jaringan antara node turun? Tidak ada node yang sekarang dapat berkomunikasi dengan yang lain dan dalam situasi ini server siaga dapat mempromosikan dirinya sendiri untuk menjadi server aktif atas dasar bahwa ia percaya bahwa node aktif telah gagal. Hal ini menyebabkan kedua node menjadi 'aktif' karena masing-masing akan melihat yang lain mati. Akibatnya, integritas dan konsistensi data terganggu karena data pada kedua node akan berubah. Ini disebut sebagai "Otak Terbelah" . Untuk menghindari skenario otak terbelah, simpul Kuorum (juga disebut sebagai 'Saksi') harus dipasang di dalam cluster. Menambahkan node kuorum (ke sebuah cluster yang terdiri dari jumlah node yang genap) menciptakan jumlah node yang ganjil (3, 5, 7, dll.), dengan voting node untuk memutuskan mana yang harus bertindak sebagai node aktif dalam cluster. Pada contoh di bawah, rak server yang berisi Node B telah hilang LAN konektivitas. Dalam skenario ini, melalui penambahan node ke-3 ke lingkungan cluster, sistem masih dapat menentukan node mana yang harus menjadi node aktif. Fungsi kuorum/Saksi disertakan dalam SIOS Suite Perlindungan. Saat instalasi, Kuorum / Saksi dipilih di semua node (tidak hanya node kuorum) dan jalur komunikasi ditentukan antara semua node (termasuk node kuorum). Node kuorum tidak menghosting layanan aktif apa pun. Satu-satunya perannya adalah untuk berpartisipasi dalam komunikasi node untuk menentukan mana yang aktif dan untuk memberikan 'tie-break voting' jika terjadi gangguan komunikasi. SIOS juga mendukung Pagar dan Penyimpanan IO sebagai perangkat kuorum, dan dalam konfigurasi ini node kuorum tambahan tidak diperlukan. Direproduksi dengan izin dari SIOS
Juni 19, 2022	Bagaimana Replikasi Data antar Node Bekerja? Bagaimana Replikasi Data antar Node Bekerja? Dalam skenario pusat data tradisional, data biasanya disimpan di jaringan area penyimpanan ( SAN ). Lingkungan cloud biasanya tidak mendukung penyimpanan bersama. SIOS DataKeeper menyajikan penyimpanan 'bersama' menggunakan teknologi replikasi untuk membuat salinan data yang sedang aktif. Ini menciptakan perangkat NetRAID yang berfungsi sebagai perangkat RAID1 (data dicerminkan di seluruh perangkat). Perubahan data direplikasi dari Mirror Source (perangkat disk pada node aktif – Node A pada diagram di bawah) ke Mirror Target (perangkat disk pada node standby – Node B pada diagram di bawah). Untuk menjamin konsistensi data di kedua perangkat, hanya node aktif yang memiliki akses tulis ke perangkat yang direplikasi (/titik pemasangan datakeeper dalam contoh di bawah). Akses ke perangkat yang direplikasi (titik pemasangan /datakeeper) tidak diperbolehkan saat itu adalah Target Cermin (yaitu, pada node siaga). Direproduksi dengan izin dari SIOS
Juni 15, 2022	Bagaimana Klien Terhubung ke Node Aktif Bagaimana Klien Terhubung ke Node Aktif Seperti yang dibahas sebelumnya, sekali Cluster Ketersediaan Tinggi telah dikonfigurasi, dua atau lebih node berjalan secara bersamaan dan pengguna terhubung ke simpul "aktif" . Ketika masalah terjadi pada node aktif, kondisi "failover" terjadi dan node "standby" menjadi node "aktif" baru. Ketika terjadi failover harus ada mekanisme yang memungkinkan klien untuk mendeteksi kondisi failover dan menyambung kembali, atau transfer mulus sesi klien aktif pengguna ke node aktif. Alamat IP Virtual Biasanya alamat IP "virtual" dibuat ketika sebuah cluster dikonfigurasi dan klien berkomunikasi dengan simpul aktif menggunakan alamat IP virtual. Ketika terjadi failover, alamat IP virtual dipindahkan ke node aktif baru dan klien menyambung kembali ke alamat IP virtual yang sama. Sebagai contoh, mari kita asumsikan bahwa ada dua node, A dan B, dengan alamat IP 10.20.1.10 dan 10.20.2.10 . Dalam contoh ini, kami akan mendefinisikan alamat IP virtual 10.20.0.10 yang harus dianggap ditetapkan ke node aktif saat ini. Ini mirip dengan menetapkan alamat IP kedua ke satu kartu antarmuka jaringan pada satu node. Jika perintah ip a dimasukkan pada node aktif, kedua alamat IP akan muncul (seperti pada baris 10 dan 12 dalam contoh Linux ini): Itu ARP Protokol Ketika klien mencoba untuk menemukan server menggunakan alamat IP, klien biasanya menggunakan: ARP (Protokol Resolusi Alamat) untuk menemukan MAC (Kontrol Akses Media) alamat mesin target. Setelah klien menyiarkan pesan untuk menemukan alamat IP target, node aktif menjawab dengan MAC alamat dan klien menyelesaikan permintaan dan menghubungkannya. ARP Alternatif untuk Lingkungan Cloud Di lingkungan cloud, bagaimanapun, tidak mungkin untuk mengidentifikasi node aktif menggunakan ARP karena banyak lapisan diabstraksikan dalam lingkungan virtual. Metode alternatif berdasarkan infrastruktur jaringan yang digunakan di lingkungan cloud tertentu mungkin diperlukan. Biasanya ada beberapa pilihan, dan pilihan harus dibuat dari daftar berikut. AWS Skenario Tabel Rute AWS Skenario IP Elastis AWS Skenario Route53 Skenario Penyeimbang Beban Internal Azure Skenario Penyeimbang Beban Internal Google Cloud Direproduksi dengan izin dari SIOS
Juni 11, 2022	Platform Cloud Publik dan Perbedaan Struktur Jaringannya Platform Cloud Publik dan Perbedaan Struktur Jaringannya Ada beberapa platform cloud publik termasuk Layanan Web Amazon ( AWS ), Microsoft Azure dan Google Cloud. Meskipun ada banyak kesamaan dalam infrastruktur mereka, ada beberapa perbedaan. Dalam banyak kasus VPC (Virtual Private Cloud) atau a VNET (Jaringan Virtual) yang terikat pada suatu wilayah dibuat. Satu atau lebih VPC s dapat didefinisikan untuk sekelompok aplikasi logis. Dengan demikian, sistem yang berbeda dibagi menjadi jaringan terpisah yang tidak terhubung kecuali berbeda VPC s secara khusus terhubung. Di bawah VPC banyak subnet yang berbeda dapat didefinisikan. Berdasarkan tujuannya, beberapa subnet dikonfigurasi sebagai subnet "publik" yang dapat diakses ke internet dan beberapa subnet dikonfigurasi sebagai subnet "pribadi" yang tidak dapat diakses ke internet. Beberapa penyedia cloud (seperti Azure dan Google Cloud) mengizinkan subnet untuk ditentukan di seluruh Availability Zone (pusat data yang berbeda), sementara beberapa (seperti AWS ) tidak mengizinkan subnet ditentukan di seluruh Availability Zone. Dalam kasus terakhir, subnet perlu ditentukan untuk setiap Availability Zone. Dalam panduan ini, kami akan menggunakan Availability Zone yang berbeda untuk setiap node. Setelah fungsi dasar dari SIOS produk dipahami, mungkin tepat untuk mengeksplorasi skenario yang berbeda (mirip dengan yang digunakan di infrastruktur jaringan Anda sendiri) yang melibatkan distribusi beban kerja di berbagai subnet, memodifikasi rentang IP untuk subnet ini, mengubah cara jaringan terhubung ke internet, dll. Direproduksi dengan izin dari SIOS