Studi Kasus: Solusi Pemantauan AWS EC2 membebaskan perusahaan manufaktur global dari tekanan saat berpindah ke cloud.

Pabrikan Tokyo Diamond Tools Melindungi Aplikasi Penting dengan SIOS AppKeeper

Didirikan pada tahun 1932, Tokyo Diamond Tools Mfg. Co, Ltd memproduksi alat berlian untuk memotong, memotong, memoles, dan proses pengeboran di berbagai bidang seperti elektronik rumah, semikonduktor, perangkat elektronik, kesehatan dan teknik sipil. Meskipun merupakan perusahaan yang telah lama berdiri dengan lebih dari 80 tahun sejarah, Tokyo Diamond selalu secara agresif memperkenalkan alat-alat TI baru.  Perusahaan memutuskan untuk pindah ke Amazon AWS dan virtualisasi untuk kecepatan dan efisiensi peningkatan bisnis. SIOS AppKeeper memainkan peran penting dalam memberikan perlindungan ketersediaan aplikasi yang mereka butuhkan. Salah satu alasan perpindahan Tokyo Diamond Tools ke cloud dan AWS adalah Gempa Bumi Besar Jepang Timur tahun 2011.  Meskipun tidak ada kerusakan langsung ke server di kantor pusat, peralatan di pabrik Sendai di Prefektur Miyagi keluar dari rak, menyebabkan kerusakan serius.  Tokyo Diamond melihat perlunya rencana kesinambungan bisnis yang lebih baik.  Ini adalah pendorong utama untuk beralih ke virtualisasi sistem inti mereka dan menggunakan lingkungan cloud.

Pada awalnya, perusahaan mulai memigrasi aplikasi yang relatif kecil ke cloud.  “Kami mulai bergerak sekitar November 2011.  Pada saat itu, kami tidak punya pilihan selain AWS, ”kata Mr Takuji Kokubo, kepala Sistem TI di Tokyo Diamond.  Mereka mengelola operasi sendiri menggunakan portal cloud "Managed Cloud with AWS" Sony Network Communications.  Mr. Kokubo, adalah "operasi IT One Man" yang menggambarkan dirinya sendiri, sehingga efisiensi dan otomasi penting untuk memungkinkan kelancaran operasi sistem TI perusahaan, di lokasi di Jepang serta di Singapura dan Thailand.

Pindah ke cloud dan mengidentifikasi kebutuhan untuk solusi pemulihan 

Diamond Tools mengimplementasikan Amazon EC2 dan Amazon S3, layanan penyimpanan cloud. Mereka memindahkan groupware, dukungan penjualan, dan sistem konferensi video mereka ke AWS.  Sistem konferensi video Diamond Tools sangat penting untuk operasi sehari-hari mereka.  “Ini adalah alat yang sangat sering digunakan dalam berbagai konferensi dan pertemuan dengan lokasi di luar negeri.  Ini digunakan sekitar 100 kali sebulan, dan dengan transisi dari sistem SaaS pay-as-you-go konvensional ke AWS, kami dapat mengurangi biaya sebanyak dua juta yen setahun, ”kata Kokubo.  Sebelumnya, kualitas suara sering turun ketika terlalu banyak pengguna termasuk perusahaan lain yang terhubung ke sistem secara bersamaan.  Kemudian Pak Kokubo akan menerima keluhan dari pengguna tetapi masalahnya tidak dapat diselesaikan dengan mudah.  Membangun sistem konferensi video khusus perusahaan di AWS telah menstabilkan kualitas video dan audio dan mengurangi keluhan.

Mr. Kokubo segera mengalami masalah dengan lingkungan EC2 mereka. “EC2 stabil sebagai infrastruktur; namun, terkadang layanan di dalamnya gagal. Saya selalu khawatir, dan suatu hari, selama perjalanan bisnis ke luar negeri, saya mendapat telepon yang mengatakan bahwa pengguna tidak dapat mengakses sistem.  Saya harus membuka laptop saya, yang saya bawa sepanjang waktu, untuk terhubung ke AWS melalui VPN dan memulihkan layanan yang gagal, ”kata Mr. Kokubo.  Jelas proses ini tidak dapat diskalakan.

Kegagalan layanan sering terjadi pada contoh di mana aplikasi groupware berjalan.  Sebagian besar karyawan perusahaan menggunakan aplikasi groupware setiap pagi untuk memeriksa kalender atau memesan ruang pertemuan. "Banyak orang akan memanggil saya untuk bertanya apa yang terjadi jika mereka mengalami masalah," kata Tuan Kokubo. Dia belajar risiko mengurus sistem sendiri melalui pengalaman ini.

“Sepuluh tahun yang lalu, sistem akan berhenti ketika ada kegagalan, dan pengguna terbiasa dengan itu. Namun, hari ini, saya mendapat keluhan begitu sesuatu berhenti. Sekarang, sistem diharapkan dapat beroperasi setiap saat, seperti air yang keluar dari keran kapan saja.  Sistem downtime menjadi semakin tidak dapat diterima, ”kata Mr. Kokubo.

Mr. Kokubo selalu merasa bahwa dia harus mengurus masalah apa pun ketika salah satu layanan yang berjalan di EC2 gagal.  Menjadi satu-satunya orang yang mampu menangani masalah apa pun terus menjadi beban baginya.  Pak Kokubo berkata, “Menjadi seorang pria yang berbelanja di IT, saya cenderung menganggap bahwa nilai saya terletak pada hanya menyediakan fungsi help desk.  Tapi itu tidak baik – saya perlu mempertimbangkan bagaimana saya dapat membuat sistem Tokyo Diamond bekerja tanpa dukungan saya. "

Karena dia adalah satu-satunya profesional TI di perusahaan yang lebih mengandalkan layanan cloud, dia tahu dia butuh bantuan. “Ketika Sony Network Communications memberi tahu saya bahwa SIOS AppKeeper menyediakan operasi otomatis dan manajemen instance EC2, saya memutuskan untuk menggunakannya bahkan sebelum melihat detailnya. Jika kami dapat memiliki solusi yang memulihkan layanan EC2 secara otomatis, maka saya tidak perlu memecahkan masalah setiap masalah dengan menghubungkan ke VPN saat bepergian, "tambah Mr. Kokubo.

SIOS AppKeeper adalah layanan cloud yang memantau instance EC2 dan memulai kembali layanan secara otomatis ketika mendeteksi gangguan sistem.  Ketika layanan yang dipantau gagal, SIOS AppKeeper memulihkan layanan secara otomatis tanpa harus memiliki staf yang campur tangan secara manual.

Lebih dari 10 Aplikasi Berjalan pada AWS

Tokyo Diamond terus memigrasi aplikasi lain ke AWS, dan pada Juni 2018 ada lebih dari 10 aplikasi yang berjalan di AWS. “Saya merasa bahwa AWS berguna: sistem operasi dimulai dalam 10 menit dan sumber daya dapat ditingkatkan / turun secara fleksibel tergantung pada bisnis. Kami bahkan dapat menghapus sumber daya meskipun tidak berfungsi.  Namun, sistem inti yang memproses sejumlah besar data dipindahkan ke lingkungan virtual menggunakan pusat data, bukan AWS.  Kami menggunakan AWS dan pusat data virtual untuk membangun sistem tergantung pada penggunaan dan kebutuhan, ”kata Mr. Kokubo.

Tokyo Diamond saat ini memantau tiga aplikasi penting yang diandalkan karyawan dengan AppKeeper, termasuk aplikasi groupware, otomasi tenaga penjualan, dan sistem konferensi video mereka.  Pak Kokubo berkata, “Pertama, kami mengklasifikasikan aplikasi kami dan memutuskan untuk memulai dengan tiga aplikasi. Adalah layak untuk membayar biaya jika saya dapat dibebaskan dari beban mental sehari-hari dan mendapatkan ketenangan pikiran selama perjalanan bisnis. ”

SIOS AppKeeper Memungkinkan Personil TI untuk Fokus pada Tugas Lainnya

Menurut Tuan Kokubo, ia tidak perlu lagi memikirkan operasi dan manajemen instance yang dipantau oleh AppKeeper.  AppKeeper bekerja dengan sempurna.  Ini telah meluangkan waktunya untuk fokus pada mesin virtual dan aplikasi AWS lainnya.  Mr. Kokubo merasa bahwa AppKeeper memberinya rasa aman tentang aplikasi inti ini.

Namun, ia memang memiliki permintaan untuk tim pengembangan SIOS Technology tentang AppKeeper.  “Jika tidak ada acara, saya khawatir tentang apakah itu berfungsi dengan baik, atau saya mungkin lupa cara login. Akan lebih baik jika sering memberi tahu saya bahwa itu berfungsi, ”kata Kokubo.  Operasi dan manajemen otomatis adalah kekuatan SIOS AppKeeper; Namun, hal itu bisa tidak terlihat ketika tidak ada yang terjadi.

Karena itu, Tuan Kokubo setuju bahwa sangat menguntungkan bahwa ia dibebaskan dari keharusan memecahkan masalah aplikasi ini.  Sekarang dia dapat menghabiskan lebih banyak waktu untuk manajemen, termasuk mengembangkan strategi dan perencanaan TI Diamond Tool, keamanan, dan inisiatif BCP.

Meskipun hari ini Diamond Tool menggunakan SIOS AppKeeper untuk operasi dan manajemen tiga aplikasi, ia berencana untuk memperluas cakupan AppKeeper ke aplikasi lain segera.  Ini akan memungkinkan Pak Kokubo menghabiskan banyak waktu untuk kegiatan-kegiatan bernilai tambah itu.  "Bahkan jika kita mencoba untuk merekrut personel sistem, itu sulit karena tenaga kerja Jepang menyusut.  Di masa depan, saya berharap alat sistem untuk menggantikan orang yang menggunakan AI (Kecerdasan Buatan), dan saya berharap SIOS AppKeeper juga mengembangkan fungsi seperti AI untuk secara otomatis mengatasi kegagalan berdampak tinggi, ”kata Kokubo, berharap untuk hari ketika otomatisasi lebih lanjut manajemen operasi akan direalisasikan.

Pelajari lebih lanjut tentang SIOS AppKeeper

Mendaftar untuk Uji Coba Gratis SIOS AppKeeper

 

 

Ketersediaan Perusahaan: Pelajaran dari Pengadilan

Ketersediaan Perusahaan: Pelajaran dari Pengadilan

Saya suka bermain basket. Saya suka memainkannya, menontonnya, dan memikirkan aspek otak dari permainan; pemikiran dan motivasi, strategi dan taktik. Saya suka mencari hal-hal kecil yang berfungsi atau gagal, layar diatur terlalu cepat atau gulungan yang terjadi terlambat. Saya suka pertahanan dan rotasi. Saya suka mengetahui strategi pelatih untuk latihan, penelusuran, perjalanan, dan sebagainya.  Jadi wajar saja beberapa bulan yang lalu, ketika saya mendapat hari libur dari dunia ketersediaan 24/7, bayangkan itu, saya mengambil cuti untuk menonton bola basket, dan lebih khusus lagi berlatih basket sekolah menengah putri saya.

Sekitar sepertiga dari cara menonton, saya tidak bisa menahan diri. Saya bersiul dan “mendorong” gadis muda itu dengan tertawa terbahak-bahak dan berlari ke pengadilan dan berteriak, “Lari! Keramaian!" Dan dia melakukannya, seperti yang dilakukan rekan satu tim dalam jarak dekat.  Beberapa menit berikutnya, permainan, dan latihan diisi dengan energi, potongan yang tajam, gerakan halus, dan dorongan.  Tapi, itu tidak bertahan lama.  Sebaliknya, ada lebih banyak peluit yang dibutuhkan, lebih banyak dorongan untuk bergerak dan berlari, untuk bermain keras, membuat luka tajam, menyelam, memperhatikan, fokus, belajar, dan memperbaiki. Ketika 2 jam hampir berakhir, saya mengambil momen terakhir perhatian saya untuk bernubuat, "Cara Anda berlatih akan menjadi cara Anda bermain!"

Saya hampir bisa merasakan Anda menyalurkan semangat AI, bukan Artificial Intelligence (AI), Allen Iverson (AI).  “Apakah kita sedang berbicara, berlatih.  Praktek!" Saya pikir ini tentang ketersediaan.  Yah, kecintaan saya pada bola basket bertemu dengan hasrat saya akan ketersediaan ketika saya mempertimbangkan putri saya dan rekan satu timnya. Bagaimana?

Strategi Basket Tiga Cara Seperti Strategi Ketersediaan:

• Dalam bola basket, setiap tim membutuhkan rencana, juga untuk ketersediaan perusahaan.
• Dalam bola basket, setiap tim perlu berlatih rencana itu, juga ketersediaan, pemulihan bencana, dan pemeliharaan terencana.
• Dalam bola basket, rencana ketika diuji di bawah api akan bertahan hanya sebaik rencana itu dipraktikkan
  

Ketersediaan Perusahaan Membutuhkan Rencana 

Ketersediaan Anda, khususnya bencana, pemeliharaan yang direncanakan, dan strategi pemulihan pemadaman, hanya sebaik yang Anda buat. Sederhananya, apa rencana Anda untuk pemadaman (awan catatan gagal, server crash, jaringan menjadi jenuh, dan kesalahan manusia – cukup kata).  Apakah Anda memiliki rencana yang terdokumentasi? Apakah Anda telah mengidentifikasi pemilik dan pemilik cadangan? Apakah Anda tahu arsitektur dan topologi Anda (server apa yang melakukan apa, di mana lokasinya, tim apa yang dimilikinya, fungsi apa yang dilayaninya, prioritas bisnis apa yang terkait dengannya, dan SLO / SLA apa yang diperlukan)? Siapa vendor utama Anda, dan apa daftar panggilan turun mereka? Apa pos pemeriksaan Anda, rencana perlindungan data, dan strategi cadangan? Dan apa rencana pengujian dan rencana validasi Anda untuk verifikasi rencana ini?

Praktek Ketersedian Kebutuhan Perusahaan 

Rencana yang bagus, periksa. Sekarang bagaimana dengan latihan.  Menerapkan langkah-langkah pemulihan bencana dan strategi pemadaman yang tidak direncanakan adalah komponen yang diperlukan dari setiap, setiap konfigurasi perusahaan. Tapi, strategi yang tidak dilatih sebenarnya bukan strategi. Dalam hal ini, ini hanyalah pendekatan yang mungkin dan diusulkan.  Ini lebih seperti sebuah saran, bukan rencana rekaman aktual. Langkah kedua adalah latihan. Berjalan melalui strategi rencana Anda. Latih waktu perawatan. Kembalikan cadangan dan data. Validasi asumsi dan mode kegagalan.

Ketersediaan Perusahaan Membutuhkan Pengujian 

Rencana dan panduan, periksa. Sekarang setelah Anda memiliki dua dari tiga, izinkan saya kembali ke tim putri saya.  Kata-kata perpisahan saya, sebagai "pelatih tidak resmi" adalah sebagai berikut: "Cara Anda berlatih akan menjadi cara Anda bermain!" Maju cepat tiga hari. Permainan turun ke menit-menit akhir. Tim yang mereka mainkan tidak cocok secara atletis, dan kalah besar seperti tahun lalu ketika pertandingan tahun itu berakhir pada babak pertama.  Namun tahun ini, tim yang tidak memiliki pasukan asing dan berukuran kurang jelas datang dengan lebih siap. Apa yang seharusnya menjadi kemenangan mudah sekarang memasuki menit akhir yang hampir terikat. Tim tuan rumah, lawan, memulai pers — sesuatu yang telah disiapkan oleh tim putri saya, meskipun secara sembarangan dan lesu, selama latihan yang menentukan itu.  Apa yang terjadi tidak cantik. Empat turnover tanpa paksaan, dua pelanggaran kritis selama upaya tiga-pointer, empat untuk tidak berlari, dan sekumpulan frustrasi memuncak dalam kehilangan satu poin yang menghancurkan seiring waktu berakhir.

Poin terakhir saya, seberapa baik Anda berlatih untuk pemadaman nyata Anda, bencana, atau pemeliharaan yang direncanakan? Apakah Anda berlatih dengan data nyata, klien nyata, dan dengan rasa urgensi yang nyata? Seberapa sering manajemen puncak Anda melakukan check-in? Percayalah, kehadiran bos di saat-saat penuh tekanan membuat orang melakukan hal-hal aneh dan tidak bijaksana! Apakah kotak pasir dan sistem pengujian Anda terlihat seperti produksi? Di masa lalu, saya pernah bekerja dengan pelanggan yang memiliki versi perangkat keras, penyimpanan, dan Linux OS yang berbeda antara prod dan QA. Ketika mereka masuk ke prod dengan pembaruan aplikasi, bencana melanda.  Apakah Anda memiliki pengguna dan data, dan pekerjaan yang berjalan selama pengujian Anda? Bagaimana dengan simulasi bencana yang sebenarnya? Ini adalah pil yang sulit untuk ditelan, menguji tabrakan keras dengan konsekuensi yang berpotensi merusak, pemulihan dari luar kantor, dan bahkan lebih sulit untuk mensimulasikan kegagalan sistem berganda multi-titik secara simultan, tetapi yang tidak dipraktikkan sering kali merupakan titik lemah yang mengubah pemeliharaan terencana selama 2 jam menjadi bencana perusahaan multi-tim selama delapan jam.  Yang kurang dipraktikkan atau kurang dipraktikkan adalah perbedaan antara kemenangan yang menakjubkan untuk strategi dan tim Anda, atau kekalahan telak dan kegagalan yang mahal untuk tim, vendor, perusahaan, dan pelanggan.

Dalam bola basket, rencana di bawah api akan bertahan hanya sebaik rencana itu dipraktikkan.  Ketika menerapkan rencana pemulihan dan bencana, rencana dan validasi yang baik adalah kuncinya, tetapi praktik yang hebat adalah raja.

Hubungi perwakilan di SIOS untuk mempelajari bagaimana para ahli dan produk kami yang ada dapat membantu Anda dengan rencana, prosedur, dan latihan.

Kunjungi kembali untuk posting pada tes Anda tidak boleh menghindari simulasi.

– Cassius Rhue, VP, Pengalaman Pelanggan

Artikel direproduksi dari SIOS

Langkah-demi-Langkah: ISCSI Target Server Cluster In Azure

Langkah-demi-Langkah: ISCSI Target Server Cluster In Azure

Saya baru-baru ini membantu seseorang membangun cluster server target iSCSI di Azure dan menyadari bahwa saya tidak pernah menulis panduan langkah demi langkah untuk konfigurasi tertentu. Jadi untuk memperbaikinya, berikut adalah petunjuk langkah demi langkah jika Anda perlu melakukannya sendiri.

Prasyarat

Saya akan menganggap Anda cukup terbiasa dengan Azure dan Windows Server, jadi saya akan memberi Anda beberapa detail. Mari kita asumsikan Anda setidaknya telah melakukan yang berikut sebagai prasyarat

• Menyediakan dua server (SQL1, SQL2) masing-masing dalam Zona Ketersediaan yang berbeda (Ketersediaan Set juga dimungkinkan, tetapi Zona Ketersediaan memiliki SLA yang lebih baik)
• Tetapkan alamat IP statis untuk mereka melalui portal Azure
• Bergabung dengan server ke domain yang ada
• Mengaktifkan fitur Clustering Failover dan fitur Server Target iSCSI di kedua node
• Tambahkan tiga Azure Premium Disk ke setiap node.
  CATATAN: ini opsional, satu disk adalah persyaratan minimum. Untuk peningkatan IOPS kita akan mengupas tiga Premium Azure Disk bersama-sama di kolam penyimpanan dan membuat disk virtual (RAID 0) sederhana
• SIOS DataKeeper akan digunakan untuk menyediakan penyimpanan yang direplikasi yang digunakan dalam cluster. Jika Anda membutuhkan DataKeeper, Anda dapat meminta uji coba di sini.

Buat Kolam Penyimpanan Lokal

Sekali lagi, langkah ini sepenuhnya opsional, tetapi untuk peningkatan IOPS kita akan mengupas tiga Cakram Azure Premium menjadi satu Kelompok Penyimpanan. Anda mungkin tergoda untuk menggunakan Disk Dinamis dan volume yang terbentang, tetapi jangan lakukan itu! Jika Anda menggunakan disk dinamis, Anda akan menemukan bahwa ada beberapa ketidakcocokan umum yang akan mencegah Anda membuat target iSCSI nanti.

Jangan khawatir, membuat Pool Storage lokal cukup mudah jika Anda mengetahui jebakan yang mungkin Anda temui seperti yang dijelaskan di bawah ini. Dokumentasi resmi dapat ditemukan di sini.

Pitfall # 1 – meskipun dokumentasi mengatakan ukuran minimum untuk volume yang akan digunakan dalam penyimpanan adalah 4 GB, saya menemukan bahwa P1 Premium Disk (4GB) TIDAK dikenali. Jadi di lab saya saya menggunakan Disk Premium P3 16GB.

Pitfall # 2 – Anda HARUS memiliki setidaknya tiga disk untuk membuat Pool Penyimpanan.

Pitfall # 3 – buat Storage Pool Anda sebelum Anda membuat cluster Anda. Jika Anda mencoba untuk melakukannya setelah Anda membuat cluster Anda, Anda akan berakhir dengan kekacauan besar ketika Microsoft mencoba untuk membuat kumpulan penyimpanan berkerumun untuk Anda. Kami TIDAK akan membuat kumpulan penyimpanan berkerumun, jadi hindari kekacauan itu dengan membuat Storage Pool Anda sebelum Anda membuat cluster. Jika Anda harus menambahkan Pool Penyimpanan setelah cluster dibuat, Anda harus terlebih dahulu mengusir node dari cluster, kemudian buat Pool Penyimpanan.

Berdasarkan dokumentasi yang ditemukan di sini, di bawah ini adalah tangkapan layar yang mewakili apa yang harus Anda lihat ketika Anda membangun Pool Penyimpanan lokal Anda di masing-masing dari dua node cluster. Selesaikan langkah-langkah ini di kedua server SEBELUM Anda membangun cluster.

Anda harus melihat kumpulan Primordial di kedua server.

Klik kanan dan pilih Pool Penyimpanan Baru …

Pilih Buat disk virtual saat wisaya ini ditutup

Perhatikan di sini Anda dapat membuat tingkatan penyimpanan jika Anda memutuskan untuk menggunakan kombinasi dari SSD Standar, Premium dan Ultra

Untuk kinerja terbaik gunakan tata letak penyimpanan sederhana (RAID 0). Jangan khawatir tentang keandalan karena Azure Managed Disk memiliki tiga redundansi di backend. Sederhana diperlukan untuk kinerja yang optimal.

Untuk tujuan kinerja gunakan Penyisihan tetap. Anda sudah membayar disk Premium lengkap, jadi tidak perlu tidak menggunakan semuanya.

Buat Cluster Anda

Sekarang setiap server masing-masing memiliki drive 45 GB X sendiri, kita akan membuat cluster dasar. Membuat cluster di Azure paling baik dilakukan melalui Powershell sehingga kita bisa menentukan alamat IP statis. Jika Anda melakukannya melalui GUI, Anda akan segera menyadari bahwa Azure memberikan alamat IP duplikat IP cluster yang harus Anda bersihkan, jadi jangan lakukan itu!

Berikut ini adalah contoh kode Powershell untuk membuat cluster baru.

 New-Cluster -Name mycluster -NoStorage -StaticAddress 10.0.0.100 -Node sql1, sql2

Outputnya akan terlihat seperti ini.

PS C:  Users  dave.DATAKEEPER> New-Cluster -Name mycluster -NoStorage 
-StaticAddress 10.0.0.100 -Node sql1, sql2
PERINGATAN: Ada masalah saat membuat peran berkerumun itu 
dapat mencegahnya dimulai. 
Untuk informasi lebih lanjut, lihat file laporan di bawah ini.
PERINGATAN: Laporkan lokasi file: C:  windows  cluster  Laporan  Buat Cluster 
Wisaya mycluster pada 2020.05.20 
Di 16.54.45.htm

Nama     
----     
mycluster

Peringatan dalam laporan akan memberi tahu Anda bahwa tidak ada saksi. Karena tidak ada penyimpanan bersama di cluster ini Anda harus membuat Cloud Witness atau File Share Witness. Saya tidak akan memandu Anda melalui proses itu karena cukup baik didokumentasikan di tautan tersebut.

Jangan menunda ini, silakan dan buat saksi sekarang sebelum Anda pindah ke langkah berikutnya!

Anda sekarang harus memiliki kluster 2-simpul dasar yang terlihat seperti ini.

Mengkonfigurasi Penyeimbang Muatan Untuk Alamat IP Core Cluster

Cluster di Azure unik karena jaringan virtual Azure tidak mendukung ARP serampangan. Jangan khawatir jika Anda tidak tahu artinya, yang harus Anda ketahui adalah bahwa alamat IP cluster tidak dapat dihubungi secara langsung. Sebagai gantinya, Anda harus menggunakan Azure Load Balancer, yang mengarahkan ulang koneksi klien ke node cluster aktif.

Ada dua langkah untuk mendapatkan penyeimbang beban yang dikonfigurasi untuk sebuah cluster di Azure. Langkah pertama adalah membuat penyeimbang beban. Langkah kedua adalah memperbarui alamat IP cluster sehingga mendengarkan penyelidikan kesehatan load balancer dan menggunakan subnet mask 255.255.255.255 yang memungkinkan Anda untuk menghindari konflik alamat IP dengan ILB.

Kami pertama-tama akan membuat penyeimbang beban untuk alamat IP inti klaster. Nanti kita akan mengedit load balancer untuk juga membahas alamat IP sumber daya cluster iSCSI yang akan kita buat di akhir dokumen ini.

Perhatikan bahwa alamat IP statis yang kami gunakan adalah alamat yang sama yang kami gunakan untuk membuat sumber daya IP cluster inti.

Setelah load balancer dibuat, Anda akan mengedit load balancer seperti yang ditunjukkan di bawah ini

Tambahkan dua node cluster ke kolam backend

Tambahkan dua node cluster ke kolam backend

Tambahkan pemeriksaan kesehatan. Dalam contoh ini kita menggunakan 59999 sebagai port. Ingat port itu, kita akan membutuhkannya di langkah berikutnya.

Buat jalan baru untuk mengarahkan ulang semua port HA, Pastikan Floating IP diaktifkan.

LANGKAH 2 – EDIT KE CLUSTER CORE ALAMAT IP UNTUK BEKERJA DENGAN LOAD BALANCER

Seperti yang saya sebutkan sebelumnya, ada dua langkah untuk mengatur penyeimbang beban agar berfungsi dengan benar. Sekarang kita memiliki load balancer, kita harus menjalankan skrip Powershell di salah satu node cluster. Berikut ini adalah contoh skrip yang perlu dijalankan pada salah satu node cluster.

$ ClusterNetworkName = “Cluster Network 1” 
$ IPResourceName = “Alamat IP Cluster” 
$ ILBIP = “10.0.0.100” 
Impor-Modul FailoverClusters
Dapatkan-ClusterResource $ IPResourceName | Set-ClusterParameter 
-Multiple @ {Address = $ ILBIP; ProbePort = 59998; SubnetMask = "255.255.255.255"
; Jaringan = $ ClusterNetworkName; EnableDhcp = 0} 

Hal penting tentang skrip di atas, selain memastikan semua variabel benar untuk lingkungan Anda, adalah memastikan ProbePort diatur ke port yang sama dengan yang Anda tetapkan dalam pengaturan penyeimbang beban untuk alamat IP khusus ini. Anda akan melihat nanti bahwa kami akan membuat pemeriksaan kesehatan kedua untuk sumber daya IP cluster iSCSI yang akan menggunakan port lain. Hal penting lainnya adalah memastikan Anda meninggalkan set subnet di 255.255.255.255. Ini mungkin terlihat salah, tapi itulah yang perlu diatur.

Setelah Anda menjalankannya, hasilnya akan terlihat seperti ini.

 PS C:  Users  dave.DATAKEEPER> $ ClusterNetworkName = "Cluster Network 1" 
$ IPResourceName = “Alamat IP Cluster” 
$ ILBIP = “10.0.0.100” 
Impor-Modul FailoverClusters
Dapatkan-ClusterResource $ IPResourceName | Set-ClusterParameter 
-Multiple @ {Alamat = $ ILBIP; ProbePort = 59999; SubnetMask = "255.255.255.255"
; Jaringan = $ ClusterNetworkName; EnableDhcp = 0}
PERINGATAN: Properti disimpan, tetapi tidak semua perubahan akan berlaku 
sampai alamat IP Cluster diambil offline dan kemudian online lagi.

Anda akan perlu untuk mengambil sumber daya IP cluster inti offline dan membawanya kembali online sebelum akan berfungsi dengan baik dengan load balancer.

Dengan asumsi Anda melakukan segalanya dengan benar dalam menciptakan penyeimbang beban Anda, Server Manager Anda di kedua server harus mendaftar cluster Anda sebagai Online seperti yang ditunjukkan di bawah ini.

Periksa Server Manager di kedua node cluster. Cluster Anda harus ditampilkan sebagai "Online" di bawah Pengaturan.

Instal DataKeeper

Saya tidak akan melalui semua langkah di sini, tetapi pada dasarnya pada saat ini Anda siap untuk menginstal SIOS DataKeeper di kedua node cluster. Ini pengaturan yang cukup sederhana, jalankan saja pengaturan dan pilih semua default. Jika Anda mengalami masalah dengan DataKeeper, biasanya itu adalah satu dari dua hal. Masalah pertama adalah akun layanan. Anda perlu memastikan bahwa akun yang Anda gunakan untuk menjalankan layanan DataKeeper ada di Grup Administrator Lokal pada setiap node.

Masalah kedua berkaitan dengan firewall. Meskipun penginstalan DataKeeper akan memperbarui Windows Firewall lokal secara otomatis, jika jaringan Anda terkunci, Anda perlu memastikan bahwa node cluster dapat berkomunikasi satu sama lain di seluruh port DataKeeper yang diperlukan. Selain itu, Anda perlu memastikan probe kesehatan ILB dapat menjangkau server Anda.

Setelah DataKeeper diinstal, Anda siap untuk membuat pekerjaan DataKeeper pertama Anda. Selesaikan langkah-langkah berikut untuk setiap volume yang ingin Anda tiru menggunakan antarmuka DataKeeper.

Gunakan antarmuka DataKeeper untuk terhubung ke kedua server

Klik buat pekerjaan baru dan beri nama

Klik Ya untuk mendaftarkan volume DataKeeper di kluster

Setelah volume terdaftar itu akan muncul di Penyimpanan Tersedia di Failover Cluster Manager

Buat Cluster Server Target ISCSI

Pada langkah selanjutnya ini kita akan membuat peran server target iSCSI di cluster kami. Di dunia yang ideal saya akan memiliki skrip Powershell yang melakukan semua ini untuk Anda, tetapi demi waktu untuk saat ini saya hanya akan menunjukkan kepada Anda bagaimana melakukannya melalui GUI. Jika Anda menulis kode Powershell, silakan berbagi dengan kami semua!

Ada satu masalah dengan metode GUI. Anda akan berakhir dengan alamat IP duplikat ketika Sumber Daya IP dibuat, yang akan menyebabkan sumber daya gugusan Anda gagal sampai kami memperbaikinya. Saya akan menjalani proses itu juga.

Buka Properti sumber IP Address yang gagal dan pilih IP Statis dan pilih alamat IP yang tidak digunakan di jaringan Anda. Ingat alamat ini, kami akan menggunakannya pada langkah kami berikutnya ketika kami memperbarui penyeimbang beban.

Anda sekarang harus dapat membawa sumber daya gugus iSCSI online.

Perbarui Load Balancer Untuk Resource ISCSI Target Server Cluster

Seperti yang saya sebutkan sebelumnya, klien tidak dapat terhubung langsung ke alamat IP cluster (10.0.0.110) yang baru saja kami buat untuk cluster server target iSCSI. Kami harus memperbarui penyeimbang beban yang kami buat sebelumnya seperti yang ditunjukkan di bawah ini.

Mulailah dengan menambahkan alamat IP frontend baru yang menggunakan alamat IP yang sama dengan yang digunakan sumber daya IP cluster iSCSI.

Tambahkan pemeriksaan kesehatan kedua pada port yang berbeda. Ingat nomor port ini, kita akan menggunakannya lagi dalam skrip powershell yang kita jalankan selanjutnya

Kami menambahkan satu lagi aturan keseimbangan beban. Pastikan untuk mengubah alamat IP Frontend dan pemeriksaan Health untuk menggunakan yang baru saja kita buat. Pastikan juga pengembalian langsung server diaktifkan.

Langkah terakhir untuk memungkinkan penyeimbang beban berfungsi adalah menjalankan skrip Powershell berikut di salah satu node cluster. Pastikan Anda menggunakan port Healthprobe, alamat IP, dan nama Sumber Daya IP yang baru.

 $ ClusterNetworkName = “Cluster Network 1” 
$ IPResourceName = “Alamat IP 10.0.0.0” 
$ ILBIP = “10.0.0.110” 
Impor-Modul FailoverClusters
Dapatkan-ClusterResource $ IPResourceName | Set-ClusterParameter 
-Multiple @ {Address = $ ILBIP; ProbePort = 59998; SubnetMask = "255.255.255.255"
; Jaringan = $ ClusterNetworkName; EnableDhcp = 0} 

Output Anda akan terlihat seperti ini.

 PS C:  Users  dave.DATAKEEPER> $ ClusterNetworkName = "Cluster Network 1" 
$ IPResourceName = “Alamat IP 10.0.0.0” 
$ ILBIP = “10.0.0.110” 
Impor-Modul FailoverClusters
Dapatkan-ClusterResource $ IPResourceName | Set-ClusterParameter 
-Multiple @ {Address = $ ILBIP; ProbePort = 59998; SubnetMask = "255.255.255.255"
; Jaringan = $ ClusterNetworkName; EnableDhcp = 0}
PERINGATAN: Properti disimpan, tetapi tidak semua perubahan akan berlaku 
sampai Alamat IP 10.0.0.0 diambil offline dan kemudian online lagi.

Pastikan untuk mengambil sumber daya offline dan online agar pengaturan berlaku.

Buat Target ISCSI Clustered Anda

Sebelum Anda mulai, yang terbaik adalah memeriksa untuk memastikan Server Manager dari KEDUA server dapat melihat dua node cluster, ditambah dua sumber daya nama cluster, dan keduanya muncul "Online" di bawah pengelolaan seperti yang ditunjukkan di bawah ini.

Jika salah satu server memiliki masalah meminta salah satu dari nama-nama cluster maka langkah selanjutnya akan gagal. Jika ada masalah, saya akan memeriksa ulang semua langkah yang Anda ambil untuk membuat penyeimbang beban dan skrip Powershell yang Anda jalankan.

Kami sekarang siap untuk membuat target iSCSI cluster pertama kami. Dari salah satu node cluster, ikuti langkah-langkah yang diilustrasikan di bawah ini sebagai contoh tentang cara membuat target iSCSI.

Tentu saja berikan ini ke server atau server mana saja yang akan terhubung ke target iSSI ini.

Dan begitulah, sekarang Anda memiliki server target iSCSI yang berfungsi di Azure.

Jika Anda membuat ini, tinggalkan komentar dan saya tahu bagaimana Anda berencana untuk menggunakannya!

Artikel direproduksi dengan izin dari Clusteringwithmeremortals

Solusi Singkat: SANless Clusters untuk Lingkungan Cloud Hybrid

Solusi Singkat: SANless Clusters untuk Lingkungan Cloud Hybrid

Cluster SIOS SANless adalah cara mudah dan hemat biaya untuk menambahkan perlindungan bencana ke lingkungan cluster berbasis server fisik Anda tanpa biaya dan kompleksitas pusat data tambahan atau situs pemulihan bencana. Tambahkan SIOS SANless cluster node di cloud ke lingkungan cluster berbasis server fisik Anda untuk replikasi tingkat blok dan perlindungan bencana yang efisien, real-time dan untuk aplikasi bisnis penting Anda. Perangkat lunak SIOS memungkinkan kegagalan instance aplikasi di seluruh lokasi geografis dan zona atau wilayah ketersediaan cloud untuk memberikan perlindungan bencana di seluruh lokasi, lokal, dan regional. Perangkat lunak SIOS SANless memungkinkan Anda membangun kluster menggunakan penyimpanan lokal yang tersedia untuk sistem fisik, virtual, atau cloud Anda. Perangkat lunak SIOS membuat penyimpanan lokal disinkronkan untuk perlindungan ketersediaan tinggi tanpa perlu penyimpanan bersama.

Fleksibilitas konfigurasi

Apakah Anda ingin melindungi aplikasi di server fisik, cloud pribadi di dalam organisasi Anda, di cloud publik atau cloud hybrid, perangkat lunak SIOS SANless memberi Anda fleksibilitas untuk membangun sebuah cluster yang sepenuhnya otomatis, aplikasi-sentris dan solusi replikasi dengan pilihan Anda. perangkat keras standar industri, skema replikasi, dan penyebaran (aktif / aktif, aktif / pasif).

Perangkat lunak SIOS memungkinkan Anda mereplikasi antara konfigurasi pilihan Anda – antara SAN dan lingkungan SANless dan kombinasi konfigurasi fisik, virtual, dan cloud. Tidak ada vendor yang terkunci. Tidak perlu untuk perangkat keras yang identik di sumber dan tujuan.

Mudah digunakan. Mudah untuk dimiliki

Anda dapat membangun SIOS SANless cluster dan mengkonfigurasinya dalam beberapa menit menggunakan antarmuka intuitif kami. SIOS juga memudahkan pemantauan dan pengelolaan cluster Anda. Konsol manajemen yang mudah digunakan memungkinkan Anda memantau status server yang dilindungi, jalur komunikasi, sumber daya dan aplikasi sekilas.

Kunci Keuntungan

Perlindungan Bencana

• Mudah, hemat biaya, ketersediaan tinggi dan perlindungan bencana untuk aplikasi bisnis yang penting

Fleksibilitas

• Campurkan lingkungan fisik server dan cloud untuk efisiensi maksimum.

Kemudahan penggunaan

• Konsol intuitif untuk pemantauan dan manajemen yang mudah dan berkelanjutan.

Unduh Solusi Singkat tentang SANless Clusters untuk Lingkungan Cloud Hybrid

Solusi Singkat: Solusi SANless Cluster untuk Lingkungan Server Virtual

Solusi Singkat: Solusi SANless Cluster untuk Lingkungan Server Virtual

Perangkat lunak SIOS SANless memungkinkan Anda membangun cluster di lingkungan tervirtualisasi tanpa perlu penyimpanan bersama. Anda dapat menggunakan jenis penyimpanan lokal yang tersedia dan disediakan oleh hypervisor. Perangkat lunak SIOS menggunakan replikasi tingkat blok yang efisien untuk menjaga sinkronisasi penyimpanan lokal, memungkinkan server siaga di kluster Anda untuk terus beroperasi setelah kegagalan dengan akses ke data terbaru.

Mesin virtual cluster

Perangkat lunak SIOS SANless memungkinkan Anda membuat cluster menggunakan mesin virtual yang berada di atas hypervisor apa pun (VMware, Xen, Microsoft Hyper-V, dan lainnya). Ini menggunakan replikasi real-time untuk menyinkronkan penyimpanan pada VM primer dengan penyimpanan pada VM siaga yang terletak di pusat data yang sama, di situs pemulihan bencana Anda, atau keduanya. Dalam hal terjadi bencana, VM siaga dapat segera dibawa ke layanan, menghilangkan jam yang dibutuhkan untuk pemulihan dari media cadangan. Anda cukup mengakses VM yang direplikasi di situs DR secara langsung.

Pengelompokan host Hyper-V yang mendukung Migrasi Langsung

Dalam lingkungan Microsoft Hyper-V, perangkat lunak SIOS SANless memungkinkan Anda untuk mengelompokkan seluruh mesin host Hyper-V pada tingkat hypervisor untuk portabilitas VM lengkap dan perlindungan terhadap kegagalan. Dengan menyimpan salinan real-time dari VM yang berjalan yang disinkronkan pada host Hyper-V alternatif, perangkat lunak SIOS memungkinkan Anda dengan mudah failover atau Live Migrasikan VM dari satu host Hyper-V ke yang lain. Anda mendapatkan portabilitas lengkap untuk memindahkan masing-masing VM atau semua VM di host ke host Hyper-V lain di cluster.

Membangun cluster SIOS SANless menggunakan server virtual (A). Dalam lingkungan Microsoft Hyper-V (B), cluster SIOS SANless dapat digunakan pada tingkat mesin virtual untuk Migrasi Langsung yang mudah dan portabilitas server yang lengkap.

Pengujian pemulihan bencana mudah

Perangkat lunak SIOS juga memungkinkan Anda mengembalikan VM yang direplikasi untuk melakukan pengujian pemulihan bencana tanpa gangguan ke lokasi produksi. Ketika pengujian selesai, perangkat lunak SIOS menghilangkan perubahan yang dibuat pada server target selama pengujian dan melanjutkan replikasi dari tempat berhenti.

Unduh Solusi Singkat tentang Solusi SANless Cluster untuk Lingkungan Server Virtual