Dampak pandemi COVID-19, banyak UKM/UKM beralih ke platform online. Kelas tatap muka atau fisik juga terpengaruh oleh pandemi ini dan banyak sekolah dan universitas juga beralih ke online dan mencari alat yang tersedia untuk digunakan agar dapat terus melayani siswa atau siswa, seperti yang telah dilakukan oleh pendidikan. agar tidak terhambat. Salah satu platform terkenal yang tersedia untuk tujuan pendidikan online atau pembelajaran online adalah Moodle.
Apa itu Moodle?
Moodle adalah perangkat lunak sumber terbuka untuk sistem manajemen pembelajaran online, atau LMS (juga dikenal sebagai Lingkungan Pembelajaran Virtual atau VLE) di bawah lisensi GPL. Ini memungkinkan pendidik untuk membuat situs web pribadi mereka sendiri yang diisi dengan kursus dinamis yang memperluas pembelajaran, kapan saja, di mana saja. Moodle memiliki semua dukungan dengan akses dan fitur yang mudah untuk guru, siswa, atau administrator.
Karena ini adalah open source dan platform perangkat lunak gratis, Anda dapat menggunakan perangkat lunak ini secara gratis dan tanpa biaya royalti seperti perangkat lunak sumber terbuka lainnya. Biaya hanya dikenakan jika perangkat lunak ini dihosting di platform hosting berbayar, atau jika Anda menghostingnya dengan Moodle Cloud mereka. Moodle juga tersedia untuk perangkat genggam seperti ponsel atau tablet.
Mengapa Anda Membutuhkan Basis Data yang Sangat Tersedia?
Pada tahun 1990-an, solusi yang sangat sederhana untuk High Availability (HA) ditemukan, yaitu Detak Jantung. Sebuah cluster Heartbeat pada dasarnya dapat melakukan dua hal:memonitor dua node (dan tidak lebih dari dua), dan dikonfigurasi untuk memulai satu atau lebih layanan pada dua node tersebut. Jika node yang saat ini menghosting sumber daya turun, itu memulai ulang sumber daya cluster di node yang tersisa. Meskipun rilis awal Heartbeat tidak memiliki pemantauan sumber daya itu sendiri, perubahan ini sampai rilis Heartbeat 2.0 pada awal 2000-an di mana ia memungkinkan untuk mengelola lebih dari dua node ke cluster. Pada dasarnya, ini terdiri dari keadaan pengelompokan HA Linux yang sebagian besar didasarkan pada Heartbeat 2.0. Sejak saat itu, banyak solusi HA yang terpengaruh dan telah dikembangkan dan dibuat untuk meminimalkan waktu henti terutama untuk sumber daya penting.
Menjadi sangat tersedia tidak hanya berarti meminimalkan waktu henti. Ini juga mencakup tingkat tanggung jawab untuk dapat terus mengoperasikan dan memelihara layanan yang Anda tawarkan dan janjikan kepada pelanggan Anda. Menjadi tersedia untuk pelanggan tidak berarti Anda juga mampu menanggapi mereka jika mereka membutuhkan bantuan. Itu harus membuat aplikasi dan sistem bisnis Anda berfungsi penuh seolah-olah selalu dalam keadaan operasi normal bahkan jika bencana yang belum pernah terjadi sebelumnya telah terjadi.
Anda tidak dapat mengoperasikan aplikasi VLE Anda menggunakan Moodle saat database Anda sedang dalam pemeliharaan. Jika Anda hanya memiliki satu server database, yang sangat umum untuk pengaturan aplikasi yang sederhana dan ringan, setelah server mati maka aplikasi Anda akan berhenti. Jika Anda memiliki cluster database menggunakan replikasi master-slave kemudian menemukan insiden yang belum pernah terjadi sebelumnya yang pada gilirannya aplikasi Anda menulis pada dua master setelah insiden tersebut, maka itu bisa menjadi kekacauan besar yang pada gilirannya menyebabkan korupsi data ke seluruh aplikasi bisnis Anda dan lapisan data. Jika ada pembayaran berkelanjutan yang terjadi saat itu, itu bisa menjadi bencana besar dan melibatkan banyak pekerjaan saat melakukan pemulihan data.
Jadi, mengapa database Anda harus sangat tersedia? Karena memang harus begitu,
- Mampu melakukan pemeliharaan atau pemadaman terencana dengan layak dan pada periode pemeliharaan yang diizinkan
- Uptime sangat penting dan harus menghindari downtime bila perlu
- SLA penting untuk tingkat derajat yang lebih tinggi untuk mencapai layanan pelanggan berkualitas tinggi
- Berikan layanan dan kegunaan yang berkelanjutan
- Tidak ada satu pun titik kegagalan
- Dapat melakukan failover saat master rusak atau mogok
- Hindari skenario split-brain di mana beberapa master bertindak sebagai penulis aktif secara bersamaan
Membangun Cluster Basis Data
Sekarang kami telah menekankan pentingnya memiliki HA sebagai rencana dan sebagai solusi untuk cluster database Anda, terutama untuk PostgreSQL, mari fokus membangun cluster dari atas ke bawah untuk mencapai penyiapan yang tersedia siap untuk penyiapan aplikasi Moodle.
Menginstal PostgreSQL
Pertama-tama, mengapa PostgreSQL? PostgreSQL memiliki keunggulan besar jika dibandingkan dengan database lain yang didukung oleh Moodle. Ini masalah preferensi jika saya harus meringkas karena semua database yang didukung oleh Moodle semuanya mampu menangani data dan juga tunduk pada pengoptimalan. Itu tergantung pada seberapa terampil dan berpengalaman Anda menggunakan database. Meskipun untuk meringkas mengapa menggunakan PostgreSQL, ini adalah database yang andal dan perangkat lunak open source yang canggih terutama dalam database yang dapat dibandingkan dengan vendor lain yang berpemilik, seperti Oracle dan MS SQL. Itu mendukung paralelisme kueri, mampu mengelola database besar atau besar, memiliki dukungan luas untuk JSON, dan banyak lagi. Anda dapat memeriksanya di sini untuk alasan mengapa memilih PostgreSQL. Sekarang mari kita lanjutkan menginstal PostgreSQL
Untuk blog ini, kita akan menggunakan PostgreSQL 12 menggunakan Ubuntu 18.04 (Bionic Beaver). Kemudian, untuk penyiapan Ketersediaan Tinggi, Anda harus memiliki node utama dan setidaknya node siaga (replika) yang akan diambil alih setelah master dimatikan.
- Setup repositori dan kunci penandatanganan
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/postgresql.list' wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - - Instal server PG 12
# Update the package lists: sudo apt-get update # Install server and client apt install postgresql-12 postgresql-client-12
Lakukan ini pada replika target juga, tetapi Anda perlu mengonfigurasinya sebagai standby atau replika. Atau, saya sarankan Anda menggunakan ClusterControl dan mengunduhnya karena gratis. Akan lebih cepat dan lebih cepat untuk menginstal dan menyiapkan penyiapan utama/siaga. Untuk pengaturan saya menggunakan ClusterControl dan menggunakan tab tampilan Topologi, saya mendapatkan topologi berikut:
Memiliki pengaturan master/slave atau primer/siaga, tidak berarti Anda sepenuhnya tercakup untuk cluster database yang tersedia tinggi. Ini belum sangat tersedia. Setelah utama atau master turun, tidak ada failover yang pasti akan terjadi. Hal lain adalah, tidak ada keseimbangan koneksi dari klien yang menuju master melawan budak. Meskipun penyeimbangan beban antara master/slave tidak berarti bahwa itu harus disetel atau harus diterapkan untuk memenuhi penyetelan yang sangat tersedia. Memiliki penyeimbangan beban antara master/primer dan slave/standby membantu node master Anda agar tidak membebani kinerja beban tinggi terutama pada jam lalu lintas yang sangat tinggi.
Menyiapkan Penyeimbangan Beban
Seperti yang disebutkan sebelumnya, penyeimbangan beban antara master dan slave membantu master Anda memilih beban. Ini tidak ideal jika Anda membiarkan standby Anda hanya digunakan untuk replikasi atau akan mengambil alih jika master turun. Meskipun itu bisa berhasil, bagaimanapun, itu memerlukan waktu henti dan pekerjaan manual jika master turun, karena Anda perlu mengalihkan peran node siaga Anda ke master. Itu juga bagus tetapi sekali lagi, memiliki penyeimbang beban dapat membantu mengarahkan penulisan ke master, lalu mengarahkan pembacaan antara master dan slave. Ini pada dasarnya memberi Anda pemisahan baca/tulis. Untuk melakukan ini, ada banyak opsi yang dapat Anda pilih dengan PostgreSQL. Pada dasarnya, setup yang paling umum namun sederhana dan ringan adalah menggunakan HAProxy.
Meskipun ada pilihan seperti menggunakan PgBouncer atau pgpool-II. Untuk mempermudah blog ini, mari kita gunakan HAProxy. Untuk menginstal HAProxy, cukup mudah jika Anda menggunakan ClusterControl. Mari kita lakukan itu melalui ClusterControl. Untuk melakukan itu, Anda bisa pergi ke tab Manage, pilih Load Balancer seperti gambar di bawah ini,
Karena kita perlu memiliki pengaturan yang sangat tersedia untuk cluster database PostgreSQL Anda, kita harus memiliki setidaknya dua node. Jadi jika node HAProxy utama Anda down, maka HAProxy pasif atau standby dapat mengambil alih. Mari kita lihat bagaimana tampilannya di sisi saya,
Meskipun itu terlihat bagus. Pengaturan ini masih belum cukup. Jika menurut Anda kami baik untuk pengaturan yang sangat tersedia dengan topologi itu, tidak ada failover jika HAProxy turun pada node 192.168.30.222 di port 9600 atau jika 192.168.30.223:9600 turun dan jika aplikasi Anda disetel untuk itu host, masih ada waktu henti jika tidak ada penyiapan proaktif yang dilakukan. Artinya, Anda memiliki waktu henti jika harus disetel secara manual. Dalam hal ini, kami akan menggunakan dan menyiapkan Keepalive agar instance HAProxy dipantau secara ketat untuk kesehatan dan failovernya jika node lain mengalami masalah.
Menjaga agar Load Balancer Tetap Tersedia
Sekarang kami memiliki penyeimbang beban di atas basis data kami, namun kami membutuhkan HAProxy kami untuk selalu hidup jika simpul utama untuk titik akhir aplikasi turun. Pada dasarnya, apa yang dapat dilakukan HAProxy dengan pengaturan yang kita miliki pada bagian sebelumnya, aplikasi dapat menggunakan 192.168.30.223 atau 192.168.30.222 dengan masing-masing port 5433 (port baca-tulis) dan 5434 (port hanya-baca). Sekarang ada kerumitan jika Anda perlu beralih jika node lain mati, ditambah hal buruknya adalah Anda merugikan bisnis karena mencakup waktu henti jika tidak ada failover otomatis untuk mengatasinya. Menghindari waktu henti adalah rute terbaik di sini kecuali Anda memiliki SLA yang sangat rendah serta RTO dan RPO yang tinggi.
Untuk mengurangi bencana atau downtime tersebut, kami menyarankan untuk mengatur Keepalive di atas HAProxy. Pada dasarnya, HAProxy akan memuat keseimbangan antara membaca dan menulis asalkan Anda melakukan pemisahan baca-tulis dan Keepalive hanya memantau kesehatan node HAProxy dan akan mengatur untuk mengambil node yang paling sehat sesuai dengan konfigurasi yang diinginkan. Keepalive adalah alat yang dapat Anda gunakan untuk membuat node HAProxy dipantau, meskipun tidak serumit untuk mengelola database. Keepalived menggunakan VIP (Virtual IP) yang menetapkan ke node HAProxy primer default dan kemudian menetapkan kembali VIP tersebut jika node HAProxy utama gagal dan mengarahkannya ke node HAProxy berikutnya atau standby.
Sekarang mari kita atur ini menggunakan ClusterControl karena lebih cepat dan lebih mudah untuk dikelola dengan ClusterControl. Untuk melakukan ini, pada dasarnya pendekatan yang sama seperti cara kita menyiapkan HAProxy tetapi sebagai gantinya pilih Keepalive seperti yang ditunjukkan di bawah ini,
Pada dasarnya, jika Anda menginstal Keepalive secara manual, kami memilih yang utama dibandingkan sekunder jika HAProxy primer gagal. Mari kita lihat bagaimana tampilan Topologi kita,
Ini mungkin terlihat sangat menjanjikan. Pada dasarnya, klien aplikasi Moodle akan terhubung ke VIP yaitu 192.168.30.201 di bawah port 5433 (port baca-tulis) dan 5434 (port hanya-baca). Misalnya, memverifikasinya di host eksternal yang saya miliki,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5433
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)yang mengungkapkan bahwa hanya simpul penulis yang saya miliki yang menunjuk ke simpul master saya, yaitu 192.168.30.22. Kemudian, port read-only saya harus menuju node master dan slave seperti yang ditunjukkan di bawah ini,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)
postgres=# \q
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.222
(1 row)Ini menunjukkan bahwa node utama dan node siaga saya diidentifikasi sebagai node "baca database".
Sekarang ini terlihat sangat menjanjikan seperti yang saya katakan sebelumnya. Namun, ada satu bagian yang kurang di sini yang sebenarnya sangat penting. Tidak ada mekanisme failover database yang siap untuk jenis pengaturan ini. Namun, kami memiliki Keepalive yang memonitor HAProxy dan kemudian melakukan failover dengan mengganti VIP jika HAProxy utama gagal atau mati. Namun, Keepalive tidak diatur untuk menangani pengaturan kompleks yang dimiliki PostgreSQL. Ada yang sangat layak yang tersedia dan gratis untuk mengatur ini. Anda dapat menggunakan Slony-I, sistem replikasi pihak ketiga.
Memiliki Mekanisme Failover Untuk Cluster PostgreSQL Anda
Ada beberapa cara untuk menyediakan mekanisme failover untuk PostgreSQL Anda. Slony-I atau biasa disebut hanya Slony adalah salah satu alat yang umum digunakan. Meskipun Slony mengharuskan penyiapan Anda harus berupa replikasi logis karena memerlukan penyiapan penerbit/pelanggan, Slony mungkin tidak ideal untuk penyiapan lain yang menggunakan replikasi streaming standar. Kelemahan dengan menggunakan Slony adalah tidak menyediakan deteksi otomatis untuk sistem yang gagal atau tidak ada dukungan pagar simpul. Oleh karena itu, yang biasa disebut STONITH (tembak node lain di kepala atau tembak node yang gagal di kepala) yang pada dasarnya melumpuhkan yang gagal untuk menghindari skenario split-brain di mana beberapa node master (node penulis aktif) menerima penulisan di waktu yang sama. Meskipun ini dapat diatur dengan tepat tetapi tetap saja dapat memakan waktu dan rumit jika dibuat dengan lebih sedikit pengalaman dan wawasan tentang skenario apa yang akan terjadi untuk PostgreSQL ketika bencana terjadi. Bagi Slony, mengabaikan transaksi yang dilakukan adalah keputusan bisnis yang tidak dapat dibuat oleh sistem database. Jika seseorang ingin memasukkan perintah di bawah ke dalam skrip yang dijalankan secara otomatis dari sistem pemantauan jaringan, maka Anda akan membiarkannya sendiri bahwa itu adalah data Anda, dan itu adalah kebijakan failover Anda.
Atau, jika Anda mencari opsi perusahaan namun dapat mengambil uang Anda dengan biaya yang wajar, maka ClusterControl memiliki pemulihan otomatis untuk cluster PostgreSQL. Pada dasarnya, pemulihan otomatis menjawab masalah yang disebutkan di atas dengan Slony. Meskipun pemulihan otomatis kami paling baik diuji dengan replikasi streaming dan hanya didukung untuk jenis replikasi streaming dari pengaturan PostgreSQL. Jadi bagaimana cara kerjanya? Pada dasarnya Anda hanya perlu mengaktifkan tombol pemulihan otomatis seperti di bawah ini,
Ini mendukung pagar simpul yang berarti akan mematikan simpul yang gagal jika terjadi node kembali hidup untuk beberapa alasan yang tidak diantisipasi. Selain itu, pemulihan otomatis oleh ClusterControl mendukung pemulihan node dan cluster yang jika master atau node slave secara tidak sengaja dimatikan atau dibunuh, ClusterControl akan mencoba untuk menghidupkannya kembali terutama jika itu terjadi di luar pemadaman yang direncanakan atau jendela pemeliharaan. Fitur ini hanya melindungi Anda dari ketakutan akan basis data dan pada saat yang sama juga memberi Anda pemantauan proaktif yang akan memberi tahu Anda tentang beberapa kemungkinan bencana yang terjadi sebelum terlambat untuk pulih.
Kesimpulan
Pengaturan yang sangat tersedia untuk cluster database Anda, terutama untuk Moodle, dapat bervariasi tergantung pada jenis pengaturan dan persyaratan yang Anda butuhkan. Apakah itu murni bergantung pada teknologi sumber terbuka dan gratis atau ada opsi lain yang bernilai uang untuk diinvestasikan untuk aplikasi perusahaan Anda selama anggaran dapat mengakomodasi karena dapat memberi Anda situasi win-win terutama jika Anda ingin lebih fokus saja di sisi bisnis daripada berfokus pada alat lain seperti administrasi dan jenis pekerjaan devops.
