Cara Memberikan Ketersediaan Tinggi untuk SQL Server di Lingkungan Linux

Jika organisasi Anda menjalankan Microsoft SQL Server yang penting bagi bisnis di Linux, tim TI Anda pasti tahu betapa sulitnya mempertahankan ketersediaan, kinerja, dan keamanan yang tinggi. Yang paling sulit adalah cara memastikan ketersediaan tinggi dengan replikasi yang kuat dan failover otomatis. Menggunakan perangkat lunak sumber terbuka dan solusi klaster HA SANless yang mudah dikonfigurasi dapat menawarkan pendekatan pemeliharaan yang lebih sederhana tanpa mengorbankan keselamatan dan kinerja yang dibutuhkan organisasi Anda.

Opsi Ketersediaan Tinggi Terbatas untuk Linux

Sebagian besar distribusi Linux memberi departemen TI dua pilihan lebih rendah untuk ketersediaan tinggi: membayar lebih untuk SQL Server Enterprise Edition untuk mengimplementasikan Always On Availability Groups, atau berjuang untuk membuat konfigurasi Linux HA sendiri yang rumit berfungsi dengan baik — sesuatu yang bisa sangat luar biasa sulit dilakukan.

Masalah dengan menggunakan Edisi Perusahaan adalah bahwa hal itu merusak strategi penghematan biaya untuk menggunakan sistem operasi sumber terbuka pada perangkat keras komoditas. Untuk sejumlah aplikasi SQL Server kecil yang terbatas, mungkin saja ada alasan untuk membenarkan biaya tambahan. Tapi itu terlalu mahal untuk banyak aplikasi database dan tidak akan melakukan apa pun untuk menyediakan HA tujuan umum untuk Linux.

Menyediakan HA di semua aplikasi yang berjalan di lingkungan Linux dimungkinkan menggunakan perangkat lunak sumber terbuka, seperti Pacemaker dan Corosync, atau Ekstensi Ketersediaan Tinggi SUSE Linux Enterprise. Tetapi membuat tumpukan perangkat lunak lengkap berfungsi seperti yang diinginkan memerlukan pembuatan (dan pengujian) skrip khusus untuk setiap aplikasi, dan skrip ini sering kali perlu diuji ulang dan diperbarui bahkan setelah perubahan kecil dilakukan pada perangkat lunak atau perangkat keras yang digunakan. Kemampuan terkait ketersediaan yang tidak didukung di SQL Server Standard Edition dan Linux dapat membuat upaya ini lebih menantang.

Menemukan Solusi Ketersediaan Tinggi Alternatif untuk SQL Server di Linux

Untuk membuat HA hemat biaya dan mudah diterapkan, Anda mungkin ingin mempertimbangkan dua pendekatan tujuan umum yang berbeda.

Salah satunya adalah menggunakan sistem berbasis penyimpanan yang melindungi data dengan mereplikasinya dalam jaringan area penyimpanan (SAN) yang redundan dan tangguh. Pendekatan ini agnostik sehubungan dengan sistem operasi host, tetapi memerlukan bahwa seluruh infrastruktur SAN diperoleh dari satu vendor dan bergantung pada ketentuan failover terpisah untuk memberikan ketersediaan tinggi.

Pendekatan lainnya adalah berbasis host dan melibatkan pembuatan kluster SANless agnostik penyimpanan di seluruh instance server Linux. Sebagai hamparan HA, cluster ini mampu beroperasi di LAN dan WAN di cloud pribadi, publik, dan hybrid. Hamparan tersebut juga bersifat aplikasi-agnostik, memungkinkan organisasi memiliki solusi HA universal tunggal di semua aplikasi. Meskipun pendekatan ini menghabiskan sumber daya host, ini relatif murah dan mudah diskalakan di lingkungan Linux.

Sebagian besar opsi cluster HA SANless menyediakan kombinasi replikasi data level blok waktu nyata, pemantauan aplikasi berkelanjutan, dan kebijakan pemulihan failover / failback yang dapat dikonfigurasi untuk melindungi semua aplikasi bisnis penting, termasuk yang menggunakan Mesin Virtual Cluster Always On Failover yang tersedia dalam Edisi Standar dari SQL Server.

SIOS Technology Corp. menawarkan solusi cluster HA SANless yang lebih kuat untuk Linux dengan kemampuan canggih yang dirancang untuk membebaskan TI dari kerumitan dan tantangan sehari-hari dalam mendukung dan mengoptimalkan infrastruktur komputasi. Solusi SIOS Protection Suite dengan LifeKeeper menyediakan:

• Pemantauan berkelanjutan dari seluruh tumpukan aplikasi Linux
• Perlindungan Sadar Aplikasi Lengkap dengan kit pemulihan aplikasinya (ARK) untuk pemulihan yang cepat dan aman atau kegagalan aplikasi dan database yang kompleks
• Penyiapan yang digerakkan oleh wizard untuk pengelompokan Linux
• Fleksibilitas konfigurasi, seperti menggunakan cluster penyimpanan bersama tradisional atau perangkat lunak untuk menyinkronkan penyimpanan lokal dalam konfigurasi cluster tanpa SAN

Misalnya, cluster SANless dapat menangani dua kegagalan bersamaan. Operasi dasarnya sama di LAN dan WAN, serta di cloud pribadi, publik, dan hybrid.

Dalam server cluster dua-node tipikal # 1 pada awalnya adalah yang utama yang mereplikasi data ke server #. Ini mengalami masalah, secara otomatis memicu failover ke server # 2, yang sekarang menjadi yang utama.

Dalam situasi ini, departemen TI kemungkinan akan mulai mendiagnosis dan memperbaiki masalah apa pun yang menyebabkan server # 1 gagal. Setelah diperbaiki, ini bisa mengambil alih sebagai server utama atau # 2 dapat melanjutkan dalam kapasitas mereplikasi data ke server # 1.

Dengan sebagian besar konfigurasi pengelompokan tanpa HA SAN, pengalihan terjadi secara otomatis, dan pengalihan serta pengalihan dapat dikontrol oleh konsol berbasis browser.

Untuk informasi lebih lanjut tentang solusi SIOS LifeKeeper dan Protection Suite, kunjungi SIOS SAN dan SANless High Availability Clusters untuk Cluster Server Environments.

Direproduksi dengan izin dari SIOS

Hilangkan * waktu henti server web Apache dengan SIOS AppKeeper Monitoring

Saat ini, server web Apache adalah server web paling populer di Internet.  Perusahaan menerapkan aplikasi misi penting yang menghadap pelanggan yang dibangun di atas Apache menggunakan platform cloud seperti Amazon AWS, Microsoft Azure, dan Google Cloud Platform.  Jadi, Anda dapat bertaruh bahwa mereka menginvestasikan banyak waktu dan uang untuk memantau aplikasi tersebut dan mencoba mengurangi waktu henti. Tetapi bagaimana jika kami memberi tahu Anda bahwa kami dapat menghilangkan kebutuhan akan intervensi manual melalui pemantauan otomatis dan memulai ulang aplikasi ketika server web Apache Anda mati?

Sebelum kita membahas bagaimana kita dapat melakukannya, mari kita mundur sejenak dan melihat pilihan yang dimiliki perusahaan dalam hal memantau dan mengelola server web Apache mereka dan aplikasi penting tersebut.

Cara memantau dan melindungi server web Apache Anda dari waktu henti yang tidak perlu

Siapa pun yang menerapkan aplikasi menggunakan server web Apache sedang mempertimbangkan untuk memantau kesehatan server web mereka sendiri atau mengalihkan tugas itu ke pihak ketiga.

Dalam hal memantau aplikasi cloud yang berjalan di Amazon Web Services, pilihan yang populer adalah menggunakan Amazon CloudWatch.  Beberapa perusahaan bahkan memperluas fungsionalitas CloudWatch dengan membuat beberapa tingkat otomatisasi dengan mengembangkan skrip atau dengan menggunakan AWS Lambda.  Tetapi mengonfigurasi Amazon CloudWatch dengan benar dengan metrik khusus dan menyiapkan AWS Lambda memerlukan sejumlah keahlian teknis yang mungkin melampaui banyak perusahaan.  Dan kemudian ada biaya dan upaya yang diperlukan untuk mempertahankan skrip apa pun saat aplikasi berkembang.

Pilihan lainnya adalah berinvestasi dalam solusi Application Performance Monitoring ("APM") yang komprehensif dari vendor seperti New Relics, Dynatrace, DataDog, atau LogicMonitor. Ini bisa sangat sesuai jika Anda ingin memantau lebih dari sekadar lingkungan AWS Anda. Solusi APM sangat dapat dikonfigurasi dan akan memberi Anda banyak data dalam hal informasi tentang apa yang terjadi.

Tapi apakah Anda sudah mengurangi waktu henti Anda? Mungkin tidak.  Apa yang telah Anda lakukan diinvestasikan dalam sistem yang akan segera memberi tahu Anda jika dan ketika server web Apache Anda mati, dan akan membebani Anda dengan data (atau "peringatan badai") saat Anda mencoba menjalankan kembali semuanya.

Beberapa perusahaan telah memutuskan untuk mengalihkan tanggung jawab untuk memantau dan mengelola aplikasi mereka ke pihak ketiga yang tepercaya (seringkali "penyedia layanan terkelola" atau MSP). Sebagai imbalan atas biaya bulanan dasar, MSP memantau aplikasi dan menawarkan serangkaian layanan inti, sering kali terikat oleh Perjanjian Tingkat Layanan. Saat peringatan diterima, mereka menyelidiki. Dalam beberapa kasus, penyelidikan ini dapat memerlukan eskalasi (mahal). Jika dan ketika aplikasi mati, MSP kemudian akan mengambil kendali dan memulai ulang layanan atau mem-boot ulang instans di mana mereka bisa.  Tetapi tindakan perbaikan ini seringkali menjadi biaya tambahan.

Pasti ada cara yang lebih baik.

Bagaimana pemantauan otomatis dan restart dengan SIOS AppKeeper menghilangkan waktu henti Apache Webserver

Berdasarkan pengalaman pelanggan kami, rata-rata perusahaan dengan hanya tiga instans EC2 mengalami waktu henti setidaknya sebulan sekali.  “Situsnya sedang down! Menjatuhkan semuanya. Cari tahu apa yang perlu dilakukan! ” Yang perlu Anda lakukan adalah mengurangi kebutuhan akan latihan kebakaran yang tidak perlu ini.

SIOS AppKeeper adalah layanan SaaS yang mudah dipasang dan dikonfigurasi serta memantau layanan dan aplikasi apa pun yang berjalan di Amazon EC2, seperti layanan httpd Apache Anda.  Saat anomali terdeteksi, AppKeeper otomatis memulai ulang layanan, dan jika tidak berhasil, seluruh instance akan di-boot ulang. Tidak perlu lagi membaca log untuk menunjukkan alasan kegagalan, atau eskalasi ke pengembang untuk memulai ulang layanan Anda. Atau biaya outsourcing yang mahal.  AppKeeper menyediakan fungsionalitas "set-it-and-forget-it" sehingga Anda dapat menghilangkan waktu henti.

Saat ini ratusan perusahaan mengandalkan AppKeeper untuk menjaga lingkungan cloud mereka tetap berjalan. Kami mengundang Anda untuk melihat video di bawah ini untuk mendemonstrasikan bagaimana AppKeeper melindungi server web Apache.  Dan jika Anda menyukai apa yang Anda lihat, jangan ragu untuk mendaftar uji coba gratis AppKeeper selama 14 hari.

* Berdasarkan data pelanggan, AppKeeper mengatasi 85% kegagalan layanan aplikasi. Jadi hampir sembilan dari sepuluh AppKeeper mengirimkan email yang memberi tahu pelanggan bahwa waktu henti terdeteksi dan layanan dimulai ulang atau instans di-boot ulang secara otomatis.  Bukankah itu lebih baik daripada panik dan menggali file log sebelum memulai ulang semuanya secara manual?

Lihat posting terkait: Mengapa AWS EC2 Application Monitoring Begitu Sulit?

Tip untuk Memulihkan Suite Perlindungan SIOS untuk Spesifikasi Konfigurasi Linux

Kerja bagus "Rekan Kerja Acak"! Dan dengan pekerjaan bagus, yang saya maksud bukan pekerjaan bagus.  Dan yang dimaksud dengan "Rekan Kerja Acak" yang saya maksud adalah pria yang mencentang kotak yang tidak boleh dicentang, atau tidak mencentang kotak yang harus dicentang, pria atau wanita yang melewatkan pesan dan peringatan, dan tindakan pengamanan "Harap konfirmasi" dan baru saja merusak konfigurasi SIOS Protection Suite untuk Linux Anda.

Kita semua pernah ke sana.  Itu adalah sebuah kecelakaan.  Bagaimanapun itu terjadi, itu terjadi.  Tiba-tiba Anda berebut untuk mencari tahu apa yang harus dilakukan untuk memulihkan konfigurasi, data, dan "apa pun" sebelum bos mengetahuinya.

Sebagai VP Customer Experience di SIOS Technology Corp. tim kami secara aktif bekerja dengan mitra dan pelanggan untuk merancang dan mengimplementasikan ketersediaan perusahaan untuk melindungi sistem mereka dari waktu henti.  Kecelakaan terjadi, dan pengalaman pelanggan baru-baru ini mengingatkan saya bahwa meskipun dengan beberapa pemeriksaan dan peringatan kami, bahkan produk SIOS Protection Suite untuk Linux tidak kebal terhadap perubahan konfigurasi yang tidak disengaja, tetapi ada tip sederhana untuk pemulihan yang lebih cepat dari "Random Coworker's Kesalahan yang tidak disengaja.

Bagaimana Memulihkan Suite Perlindungan SIOS untuk Linux Setelah Perubahan Konfigurasi yang Tidak Disengaja 

Asli dari SIOS Protection Suite for Linux (SPS-L) adalah alat yang disebut lkbackup, terletak di bawah / opt / LifeKeeper / bin / lkbackup.  Alat, seperti namanya, membuat cadangan detail konfigurasi SPS-L.  Catatan: Alat ini tidak mencadangkan semua data aplikasi, tetapi alat ini membuat cadangan semua data untuk konfigurasi SPS-L seperti: definisi sumber daya, merdu yang dikonfigurasi dalam file / etc / default / LifeKeeper, generik yang dibuat pelanggan skrip aplikasi, tanda yang terkait dengan status cluster, jalur komunikasi / definisi cluster, dan banyak lagi.

[root@baymax ~ ] # / opt / LifeKeeper / bin / lkbackup -c -f /root/mylkbackup-5.15.2020-v9.4.1 –cluster –ssh

Contoh: lkbackup create syntax

Ini membuat file cadangan bernama mylkbackup-5.15.2020-v9.4.1 di bawah folder / root.  The –cluster memberitahu lkbackup untuk membuat file yang sama pada setiap node cluster.  –Ssh menggunakan protokol ssh untuk terhubung ke setiap node cluster.  Detail lkbackup tambahan ada di sini:

Tim Layanan Pengalaman Pelanggan kami merekomendasikan untuk membuat cadangan sebelum membuat perubahan konfigurasi SPS-L, seperti peningkatan, penghapusan atau penambahan sumber daya, atau perubahan konfigurasi.

Jadi, saat Anda perlu memulihkan konfigurasi SPS-L, perubahannya semudah menjalankan lkbackup lagi.

[root@baymax ~ ] # / opt / LifeKeeper / bin / lkbackup -x -f /root/mylkbackup-5.15.2020-v9.4.1 –cluster –ssh

Contoh: sintaks pemulihan lkbackup

Fitur Autobackup Secara Otomatis Mengambil File lkbackup 

Tetapi, apa yang Anda lakukan jika Anda lupa menjalankan lkbackup untuk membuat file ini sebelum "Random Coworker" Anda melakukan kesalahan dalam beberapa jam pengaturan dan konfigurasi SPS-L? Apa yang Anda lakukan jika "Guy" atau "Gal" yang menyiapkan SPS-L sedang berlibur, cuti hamil atau melahirkan? Bagaimana jika Anda adalah "Rekan Kerja Acak" dan Steve dari Tim Basis sedang menuju ke lorong untuk melihat bagaimana keadaannya? Untuk sebagian besar penginstalan, SIOS mengaktifkan fitur cadangan otomatis selama penginstalan.  Fitur autobackup ini akan secara otomatis mengambil file lkbackup untuk Anda pada pukul 3 pagi waktu setempat, di bawah /opt/LifeKeeper/config/auto-backup.#.tgz

[root@baymax ~]# ls -ltr /opt/LifeKeeper/config/auto-backup.*

• -rw-r – r–. 1 root root 31312 6 Mei 03:00 /opt/LifeKeeper/config/auto-backup.3.tgz
• -rw-r – r–. 1 root root 31310 7 Mei 03:00 /opt/LifeKeeper/config/auto-backup.4.tgz
  -rw-r – r–. 1 root root 31284 8 Mei 03:00 /opt/LifeKeeper/config/auto-backup.5.tgz
  -rw-r – r–. 1 root root 31290 9 Mei 03:00 /opt/LifeKeeper/config/auto-backup.6.tgz
  -rw-r – r–. 1 root root 31291 10 Mei 03:00 /opt/LifeKeeper/config/auto-backup.7.tgz
  -rw-r – r–. 1 root root 31295 11 Mei 03:00 /opt/LifeKeeper/config/auto-backup.8.tgz
  -rw-r – r–. 1 root root 31280 12 Mei 03:00 /opt/LifeKeeper/config/auto-backup.9.tgz
  -rw-r – r–. 1 root root 31333 13 Mei 03:00 /opt/LifeKeeper/config/auto-backup.0.tgz
  -rw-r – r–. 1 root root 31325 14 Mei 03:00 /opt/LifeKeeper/config/auto-backup.1.tgz
  -rw-r – r–. 1 root root 31359 15 Mei 03:00 /opt/LifeKeeper/config/auto-backup.2.tgz

Contoh. Keluaran dari daftar config / auto-backup

Jika sistem Anda telah diinstal dan dikonfigurasi dengan benar, pencadangan otomatis telah berjalan setiap malam, siap untuk melindungi Anda saat "Rekan Kerja Acak" Anda menyerang. Temukan SPS-L auto-backup. # .Tgz sebelum kesalahan, dan menggunakan alat lkbackup SPS-L, ambil dan pulihkan SIOS Protection Suite untuk Konfigurasi Linux ke keadaan yang dikonfigurasi sebelumnya.

[root@baymax ~ ] # lkstop; / opt / LifeKeeper / bin / lkbackup -c -f /opt/LifeKeeper/config/auto-backup.0.tgz

Contoh: lkbackup restore syntax untuk auto-backup

Ulangi ini di node lain di cluster sesuai kebutuhan.

Catatan.  Jika sistem Anda tampaknya tidak dikonfigurasi untuk menghasilkan file cadangan otomatis dan melindungi Anda dari "Rekan Kerja Acak" Anda sendiri, SIOS menawarkan layanan penginstalan dan konfigurasi, dan pemeriksaan kesehatan konfigurasi yang dilakukan oleh Insinyur Layanan Profesional SIOS.

– Cassius Rhue, VP, Pengalaman Pelanggan

Langkah-demi-Langkah: Cara mengonfigurasi klaster failover SANless MySQL Linux di Amazon EC2

Dalam panduan langkah demi langkah ini, saya akan memandu Anda melalui semua langkah yang diperlukan untuk mengonfigurasi klaster MySQL 2-node yang sangat tersedia (plus server saksi) di Amazon Elastic Compute Cloud (Amazon EC2). Panduan ini mencakup tangkapan layar, perintah shell, dan cuplikan kode yang sesuai. Saya berasumsi bahwa Anda agak akrab dengan Amazon EC2 dan sudah memiliki akun. Jika tidak, Anda dapat mendaftar hari ini. Saya juga akan berasumsi bahwa Anda memiliki pemahaman dasar tentang administrasi sistem Linux dan konsep pengelompokan failover seperti IP Virtual, dll.

Pengelompokan failover telah ada selama bertahun-tahun. Dalam konfigurasi umum, dua atau lebih node dikonfigurasikan dengan penyimpanan bersama untuk memastikan bahwa jika terjadi failover pada node utama, node sekunder atau target akan mengakses data paling terbaru. Menggunakan penyimpanan bersama tidak hanya memungkinkan tujuan titik pemulihan mendekati nol, ini juga merupakan persyaratan wajib untuk sebagian besar perangkat lunak pengelompokan. Namun, penyimpanan bersama menghadirkan beberapa tantangan. Pertama, ini adalah satu titik risiko kegagalan. Jika penyimpanan bersama – biasanya SAN – gagal, semua node di cluster gagal. Kedua, SAN bisa mahal dan rumit untuk dibeli, disiapkan, dan dikelola. Ketiga, penyimpanan bersama di cloud publik, termasuk Amazon EC2 tidak mungkin, atau tidak praktis bagi perusahaan yang ingin mempertahankan ketersediaan tinggi (waktu aktif 99,99%), waktu pemulihan dan tujuan titik pemulihan mendekati nol, dan perlindungan pemulihan bencana.

Berikut ini menunjukkan betapa mudahnya membuat cluster SANless di cloud untuk menghilangkan tantangan ini sambil memenuhi HA / DR SLA yang ketat. Langkah-langkah di bawah ini menggunakan database MySQL dengan Amazon EC2, tetapi langkah yang sama dapat disesuaikan untuk membuat klaster 2-node di AWS untuk melindungi SQL, SAP, Oracle, atau aplikasi lainnya.

CATATAN: Tampilan fitur, layar, dan tombol Anda mungkin sedikit berbeda dari screenshot yang disajikan di bawah ini

1. Buat Virtual Private Cloud (VPC)
2. Buat Gateway Internet
3. Buat Subnet (Zona Ketersediaan)
4. Konfigurasi Tabel Rute
5. Konfigurasikan Grup Keamanan
6. Luncurkan Instance
7. Buat IP Elastis
8. Buat Entri Rute untuk IP Virtual
9. Nonaktifkan Pemeriksaan Sumber / Tujuan untuk ENI
10. Dapatkan ID Kunci Akses dan Kunci Akses Rahasia
11. Konfigurasi OS Linux
12. Instal Alat API EC2
13. Instal dan Konfigurasi MySQL
14. Instal dan Konfigurasi Cluster
15. Konektivitas Cluster Uji

Gambaran

Artikel ini akan menjelaskan cara membuat cluster dalam satu wilayah Amazon EC2. Node cluster (node1, node2 dan server saksi) akan berada di Availability Zone yang berbeda untuk ketersediaan maksimum. Ini juga berarti bahwa node akan berada di subnet yang berbeda.

Alamat IP berikut akan digunakan:

• node1: 10.0.0.4
• node2: 10.0.1.4
• saksi: 10.0.2.4
• virtual / "mengambang" IP: 10.1.0.10

Langkah 1: Buat Virtual Private Cloud (VPC)

Pertama, buat Virtual Private Cloud (alias VPC). VPC adalah jaringan terisolasi dalam cloud Amazon yang didedikasikan untuk Anda. Anda memiliki kendali penuh atas hal-hal seperti blok dan subnet alamat IP, tabel rute, grup keamanan (mis. Firewall), dan banyak lagi. Anda akan meluncurkan mesin virtual (VM) Azure Iaas Anda ke Jaringan Virtual Anda.

Dari dasbor AWS utama, pilih "VPC"

Di bawah "VPC Anda", pastikan Anda telah memilih region yang tepat di kanan atas layar. Dalam panduan ini wilayah "AS Barat (Oregon)" akan digunakan, karena merupakan wilayah yang memiliki 3 Availability Zone. Untuk informasi lebih lanjut tentang Region dan Availability Zone, klik di sini.

Beri nama VPC, dan tentukan blok IP yang ingin Anda gunakan. 10.0.0.0/16 akan digunakan dalam panduan ini:

Anda sekarang akan melihat VPC yang baru dibuat di layar "VPC Anda":

Langkah 2: Buat Gateway Internet

Selanjutnya, buat Gateway Internet. Ini diperlukan jika Anda ingin Instance (VM) Anda dapat berkomunikasi dengan internet.

Di menu sebelah kiri, pilih Gateway Internet dan klik tombol Buat Gateway Internet. Beri nama, dan buat:

Selanjutnya, pasang gateway internet ke VPC Anda:

Pilih VPC Anda, dan klik Lampirkan:

 

Langkah 3: Buat Subnet (Zona Ketersediaan)

Selanjutnya, buat 3 subnet. Setiap subnet akan berada di Availability Zone itu sendiri. 3 Mesin Virtual (VM: node1, node2, saksi) akan diluncurkan ke subnet terpisah (dan oleh karena itu, Availability Zone) sehingga kegagalan Availability Zone tidak akan menghilangkan beberapa node cluster.

Wilayah AS Barat (Oregon), alias us-west-2, memiliki 3 zona ketersediaan (us-west-2a, us-west-2b, us-west-2c). Buat 3 subnet, satu di masing-masing dari 3 zona ketersediaan.

Di bawah Dasbor VPC, buka Subnet, lalu Buat Subnet:

Beri nama subnet pertama ("Subnet1)", pilih zona ketersediaan us-west-2a, dan tentukan blok jaringan (10.0.0.0/24):

Ulangi untuk membuat zona ketersediaan subnet kedua us-west-2b:

Ulangi untuk membuat subnet ketiga di zona ketersediaan us-west-2c:

Setelah selesai, verifikasi bahwa 3 subnet telah dibuat, masing-masing dengan blok CIDR yang berbeda, dan di Availability Zone yang terpisah, seperti yang terlihat di bawah ini:

Langkah 4: Konfigurasikan Tabel Rute

Perbarui tabel rute VPC sehingga lalu lintas ke dunia luar dikirim ke Gerbang Internet yang dibuat pada langkah sebelumnya. Dari Dasbor VPC, pilih Tabel Rute. Buka tab Rute, dan secara default hanya akan ada satu rute yang mengizinkan lalu lintas hanya dalam VPC.

Klik Edit:

Tambahkan rute lain:

Tujuan dari rute baru ini adalah "0.0.0.0/0" (internet) dan untuk Target, pilih Gateway Internet Anda. Kemudian klik Simpan:

Selanjutnya, kaitkan 3 subnet dengan Tabel Rute. Klik tab "Asosiasi Subnet", dan Edit:

Centang kotak di samping 3 subnet, dan Simpan:

Verifikasi bahwa 3 subnet terkait dengan tabel rute utama:

Nanti, kami akan kembali dan memperbarui Tabel Rute sekali lagi, menentukan rute yang akan memungkinkan lalu lintas untuk berkomunikasi dengan IP Virtual cluster, tetapi ini perlu dilakukan SETELAH Linux Instances (VM) telah dibuat.

Langkah 5: Konfigurasikan Grup Keamanan

Edit Grup Keamanan (firewall virtual) untuk mengizinkan lalu lintas SSH dan VNC yang masuk. Keduanya nantinya akan digunakan untuk mengkonfigurasi instance linux serta instalasi / konfigurasi software cluster.

Di menu sebelah kiri, pilih "Grup Keamanan" lalu klik tab "Aturan Masuk". Klik Edit:

Tambahkan aturan untuk SSH (port 22) dan VNC. VNC umumnya menggunakan port di 5900, tergantung pada cara Anda mengkonfigurasinya, jadi untuk keperluan panduan ini, kami akan membuka kisaran port 5900-5910. Konfigurasi yang sesuai berdasarkan penyiapan VNC Anda:

Langkah 6: Luncurkan Instans

Kami akan menyediakan 3 Mesin Virtual (Mesin Virtual) dalam panduan ini. Dua VM pertama (disebut "node1" dan "node2") akan berfungsi sebagai node cluster dengan kemampuan untuk menghadirkan database MySQL dan resource terkaitnya secara online. VM ke-3 akan bertindak sebagai server saksi cluster untuk perlindungan tambahan terhadap otak yang terbelah.

Untuk memastikan ketersediaan maksimum, ketiga VM akan di-deploy ke Availability Zone yang berbeda dalam satu region. Ini berarti setiap instance akan berada di subnet yang berbeda.

Buka dasbor AWS utama, dan pilih EC2:

 

Buat "node1"

Buat instance pertama Anda ("node1"). Klik Luncurkan Instance:

Pilih distribusi linux Anda. Perangkat lunak cluster yang digunakan nanti mendukung RHEL, SLES, CentOS, dan Oracle Linux. Dalam panduan ini kita akan menggunakan RHEL 7.X:

Ukuran instans Anda sesuai. Untuk tujuan panduan ini dan untuk meminimalkan biaya, ukuran t2.micro digunakan karena memenuhi syarat tingkat gratis. Lihat di sini untuk informasi lebih lanjut tentang ukuran dan harga instans.

Selanjutnya, konfigurasikan detail instance. PENTING: pastikan untuk meluncurkan instance pertama (VM) ini ke dalam "Subnet1", dan tentukan alamat IP yang valid untuk subnet (10.0.0.0/24) – di bawah 10.0.0.4 dipilih karena ini adalah IP gratis pertama di subnet.
CATATAN: .1 / .2 / .3 di subnet mana pun di AWS sudah dipesan dan tidak dapat digunakan.

Selanjutnya, tambahkan disk ekstra ke node cluster (ini akan dilakukan pada "node1" dan "node2"). Disk ini akan menyimpan database MySQL kami dan nantinya akan direplikasi antar node.

CATATAN: Anda TIDAK perlu menambahkan disk ekstra ke node "saksi". Hanya "node1" dan "node2". Tambahkan Volume Baru, dan masukkan ukuran yang diinginkan:

Tentukan Tag untuk instance, Node1:

Kaitkan instance dengan grup keamanan yang ada, sehingga aturan firewall yang dibuat sebelumnya akan aktif:

Klik Luncurkan:

PENTING: Jika ini adalah contoh pertama di lingkungan AWS Anda, Anda harus membuat pasangan kunci baru. File kunci pribadi perlu disimpan di lokasi yang aman karena akan diperlukan saat Anda melakukan SSH ke dalam instance linux.

Buat "node2"

Ulangi langkah-langkah di atas untuk membuat instance linux kedua Anda (node2). Konfigurasikan persis seperti Node1. Namun, pastikan Anda menerapkannya ke "Subnet2" (zona ketersediaan us-west-2b). Rentang IP untuk Subnet2 adalah 10.0.1.0/24, jadi IP 10.0.1.4 digunakan di sini:

Pastikan untuk menambahkan disk ke-2 ke Node2 juga. Ini harus berukuran persis sama dengan disk yang Anda tambahkan ke Node1:

Berikan tag pada contoh kedua…. “Node2”:

Buat "saksi"

Ulangi langkah-langkah di atas untuk membuat instance linux ketiga Anda (saksi). Konfigurasikan persis seperti Node1 & Node2, KECUALI Anda TIDAK perlu menambahkan disk ke-2, karena instance ini hanya akan bertindak sebagai saksi cluster, dan tidak akan membuat MySQL online.

Pastikan Anda menerapkannya ke "Subnet3" (zona ketersediaan us-west-2c). Rentang IP untuk Subnet2 adalah 10.0.2.0/24, jadi IP 10.0.2.4 digunakan di sini:

CATATAN: konfigurasi disk default baik-baik saja untuk node saksi. Disk ke-2 TIDAK diperlukan:

Tandai node saksi:

Mungkin perlu sedikit waktu untuk menyediakan 3 instans Anda. Setelah selesai, Anda akan melihat kemudian terdaftar sebagai berjalan di konsol EC2 Anda:

Langkah 7: Buat IP Elastis

Selanjutnya, buat Elastic IP, yang merupakan alamat IP publik yang akan digunakan untuk terhubung ke instans Anda dari dunia luar. Pilih Elastic IPs di menu sebelah kiri, lalu klik “Allocate New Address”:

 

Pilih Elastic IP yang baru dibuat, klik kanan, dan pilih "Associate Address":

Kaitkan IP Elastis ini dengan Node1:

Ulangi ini untuk dua contoh lainnya jika Anda ingin mereka memiliki akses internet atau dapat menggunakan SSH / VNC secara langsung.