Implementasi Replikasi secara Realtime


Dalam pengimplementasian sistem replikasi ini, terdapat beberapa langkah yang dilakukan. Adapaun secara garis besar langkah-langkah tersebut adalah :
1. Instalasi Sistem Operesi Ubuntu Server 8.04 LTS (Hardy Heron)
2. Instalasi Paket Web Server (Instalasi Apache, MySQL Server dan Paket SNMP)
3. Konfigurasi Server Replikasi
4. Mengatur Akun Replikasi di Masing-masing Server
5. Konfigurasi Replikasi Master – Slave
6. Mengaktifkan Slave
7. Instalasi Paket Heartbeat
8. Konfigurasi Replikasi Master – Master dengan Mode Aktif – Pasif

1. Installasi Ubuntu Server
Proses instalasi sistem operasi dilakukan melalui CD-Drive dengan CD Ubuntu Server 8.04 LTS (Hardy Heron). Setelah proses instalasi selesai, maka penulis melakukan perintah update pada sistem, yang berfungsi untuk melakukan pembaharuan terhadap data repository :

# apt-get install update

2. Installasi Web Server
Apache merupakan server web yang dapat dijalankan di banyak sistem operasi (Unix, BSD, Linux, Microsoft Windows dan Novell Netware serta platform lainnya) yang berguna untuk melayani dan memfungsikan situs web.

Karena paket apache sudah tersedia pada repository Ubuntu. Maka untuk instalasi apache cukup menggunakan perintah:

# apt-get install apache2

Maka apache sudah berhasil terpasang di server secara otomatis beserta dependency nya. Selain itu, untuk mendukung web yang dinamis, maka perlu di pasang pula paket php :

# apt-get install php5

Berikut adalah paket-paket perangkat lunak yang juga di tambahkan penulis untuk mendukung paket-paket utama.

# apt-get install php5-mysql php5-mcrypt libapache2-mod-php5 libapache2-mod-auth-mysql php5-cli

3. Installasi MySQL Server
Karena percangan sistem digunakan untuk aplikasi Web, maka basis data yang paling cocok adalah MySQL, karena MySQL berkembang dari solusi yang dipakai oleh pembuatnya, TcX AB, dalam memproses data untuk aplikasi web. Fokusnya adalah pada kecepatan. Adapun cara instalasinya :

# apt-get install mysql-server

4. Installasi Paket SNMP
Paket SNMP digunakan sebagai protokol untuk memantau aktivitas server. Paket di instal pada semua server yang di gunakan dalam pengimplementasian sistem replikasi ini :

# apt-get install snmp snmpd

Adapun paket monitoring utama yang berupa paket tar ball di install pada server virtual beserta paket pendukung nya :

# apt-get install rrdtool snmp snmpd php5-snmp libphp-adodb dbconfig-common

# tar -xzvf cacti-0.8.7b.tar.gz

Kemudian melakukan penyesuaian konfigurasi dengan file config.php dan global.php yang ada di /var/www/cacti/include :

# nano /var/www/cacti/include/config.php
$database_type = “mysql”;
$database_default = “cacti”;
$database_hostname = “localhost”;
$database_username = “root”;
$database_password = “dan”;
$database_port = “3306″;

Lalu membuat basis data di MySQL dengan nama “cacti”. Dan terkahir mengimpor basis data yang sudah ada di folder /var/www/cacti dengan nama cacti.sql.

Penulis juga membuat sebuah penjadwalan dengan jeda selama lima menit sekali untuk menjalankan file poller.php.

# nano /etc/crontab
*/5 * * * * dhanu php /var/www/cacti/poller.php > /dev/null 2>&1

Kemudian mengisi konfigurasi di /etc/snmp/snmpd.conf yang ada pada ke tiga server yang akan di uji seperti di bawah ini, tujuannya agar Cacti bisa mengenali device yang akan di monitoring :

syslocation serverdanu
syscontact “Adminstrator <ridhanu@umm.ac.id>”
rocommunity public 127.0.0.1
rocommunity public 172.16.32.0/24
disk /

5. Konfigurasi Server Replikasi
Menyiapkan replikasi merupakan proses yang cukup sederhana di MySQL, tapi ada banyak variasi di langkah dasar, tergantung pada skenario. Skenario penulis adalah replikasi dengan sebuah master dan sebuah slave yang baru diinstal, dan harus memiliki data yang sama. Kemudian asumsi server yaitu :

webserver : alamat IP 172.16.32.31 (Web Server)
master : alamat IP 172.16.32.32 (Primary Database Server)
slave : alamat IP 172.16.32.33 (Secondary Database Server)

6. Mengatur Akun Replikasi di Masing-masing Server
MySQL memiliki beberapa hak khusus yang memungkinkan proses replikasi dapat berjalan. Slave I/O thread yang berjalan pada slave, membuat koneksi TCP/IP ke master. Kondisi seperti ini mengharuskan dibuatnya sebuah akun pengguna pada master dengan memberikan hak istimewa sesuai dengan kebutuhan replikasi. Sehingga Thread I/O di slave terhubung dengan user/pengguna dan membaca file binary log di master. Berikut adalah cara yang penulis lakukan untuk menciptakan akun pengguna :

mysql> CREATE USER ‘pmbrepl’@’172.16.32.%’ IDENTIFIED BY ‘pmb123’;
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘pmbrepl’@’172.16.32.%’;

Di sini penulis membuat akun pengguna yang sama pada kedua server basis data baik di master ataupun slave. Penulis juga membatasi hak istimewa pengguna hanya ke jaringan lokal, karena akun replikasi tidak aman. Replikasi sebenarnya hanya membutuhkan hak istimewa REPLICATION SLAVE pada slave untuk dapat menjalankan replikasi itu sendiri. Tanpa akun ini slave tidak dapat memperbaharui data yang sudah di update di master. Tapi di sini penulis juga menambahkan akun REPLICATION CLIENT untuk dapat memonitor status replikasi di kedua server. Lebih mudah untuk menggunakan akun yang sama seperti ini untuk beberapa tujuan nantinnya seperti promosi sebuah slave yang akan di jadikan sebuah master basis data (daripada membuat akun pengguna yang berbeda untuk tujuan seperti ini jika nantinya slave dan master akan beralih peran).

7. Konfigurasi Replikasi Master – Slave
Sebelum melakukan konfigurasi replikasi pada server basis data, penulis melakuan konfigurasi pada file /etc/mysql/my.cnf. Kemudian memberi tanda pagar “#” di depan baris bind address, agar MySQL bisa di akses dari jaringan lain. Karena pada pengaturan default nya MySQL tidak mengijinkan koneksi selain jaringan lokal.

Langkah selanjutnya adalah mengaktifkan beberapa pengaturan di primary database server, yang penulis asumsikan sebagai master. Yang harus di aktifkan adalah log_bin dan menentukan ID server. Untuk mengaktifkan replikasi di master penulis menambahkan baris berikut ke dalam file my.cnf :

log_bin = /var/log/mysql/pmb-bin
server_id = 32
binlog_do_db = replika

ID server harus unik. Penulis memilih untuk menggunakan 32 bukan 1, karena 1 adalah nilai default server yang biasanya akan dipilih ketika nilai tidak ditentukan. Jika menggunakan 1, dapat dengan mudah menyebabkan kebingungan dan konflik dengan server yang tidak memiliki ID server yang eksplisit. Di sini penulis menggunakan komposisi terakhir dari alamat IP server, yang mengasumsikan bahwa itu unik dan tidak berubah. Log_bin di sini berfungsi untuk menetukan lokasi dan penamaan binary log sendiri.

Setelah konfigurasi di master selesai, maka MySQL harus di restart. Untuk memverifikasi bahwa file binary log berhasil dibuat pada master, penulis menjalankan perintah SHOW MASTER STATUS, keluaran yang di dapatkan adalah seperti berikut :

mysql> SHOW MASTER STATUS;
+————–+——–+————+—————-+
|File |Position|Binlog_Do_DB|Binlog_Ignore_DB|
+————–+——–+————+—————-+
|pmb-bin.000002|106 | replika | |
+————–+——–+————+—————-+
1 row in set (0.00 sec)

Pada slave juga penulis mengkonfigurasi aturan yang mirip dengan master di file my.cnf nya, dan juga merestart MySQL setelah semua konfigurasi berhasil ditambahkan :

log_bin = /var/log/mysql/pmb-bin
server_id = 33
relay_log = pmb-relay-bin
log_slave_updates = 1

Beberapa opsi pada konfigurasi MySQL di slave secara teknis tidak diperlukan. Sebenarnya, hanya parameter server_id yang diperlukan pada slave, tapi pada konfigurasi MySQL di slave penulis mengaktifkan log_bin juga, dan memberikan log_bin nama yang eksplisit. Karena secara default dinamai setelah nama host server, tetapi yang dapat menyebabkan masalah jika hostname berubah. Selain itu, jika ingin mengaktifkan promosi dari slave ke master maka setiap log server harus diberi nama yang sama untuk kemudahannya.

Dengan demikian, sama seperti saat menciptakan akun pengguna replikasi yang sama pada kedua server, penulis juga menggunakan pengaturan yang sama untuk master dan slave terhadap binary log ini, memberikan nama dan lokasi binary log yang identik.
Di sini penulis tambahkan dua parameter konfigurasi lainnya yaitu relay_log (untuk menentukan lokasi dan nama log relay) dan log_slave_updates (untuk membuat event di log slave direplikasi untuk binary log sendiri). Opsi ini memang menyebabkan slave untuk bekerja ekstra, tetapi akan mudahnya nantinya untuk mempromosikan slave manjadi master.

8. Mengaktifkan Slave
Langkah berikutnya adalah untuk memberitahu slave cara untuk terhubung ke master dan mulai mengambil data binary log. Penulis tidak menggunakan file my.cnf untuk konfigurasi ini, sebagai gantinya penulis menggunakan CHANGE MASTER TO. Pernyataan ini menggantikan pengaturan my.cnf secara keseluruhan. Hal ini juga memungkinkan penulis mengarahkan slave pada master yang berbeda, tanpa menghentikan server. Berikut perintah untuk menjalankan slave untuk memulai replikasi :

mysql> CHANGE MASTER TO MASTER_HOST=’172.16.32.32′,
-> MASTER_USER=’pmbrepl’,
-> MASTER_PASSWORD=’pmb123′,
-> MASTER_LOG_FILE=’pmb-bin.000002′,
-> MASTER_LOG_POS=0;

MASTER_LOG_FILE merupakan posisi terakhir dari binary log yang dapat di lihat pada status master. Parameter MASTER_LOG_POS diatur ke 0 karena ini adalah awal dari log.

9. Instalasi Paket Heartbeat
Heartbeat merupakan proyek Linux-HA yang paling banyak di gunakan untuk sistem operasi Linux. Tujuan dari instalasi ini adalah untuk meningkatkan High-availability Cluster Server atau bisa juga di sebut Failover Cluster. Adapun cara instalasinya adalah sebagai berikut (Instalasi paket dilakukan pada kedua server basis data) :

root@master:/# apt-get install heartbeat-2

Heartbeat mempunyai tiga file konfigurasi utama yaitu authkeys, ha.cf, dan cib.xml. Untuk file authkeys dan ha.cf memang secara otomatis tidak tercipta ketika isntalasi paket Heartbeatnya. Karena itu perlu dibuatkan terlebih dahulu.

root@master:/# nano /etc/ha.d/authkeys

Kemudian mengisi file tersebut dengan konfigurasi sebagai berikut :

auth 1
1 md5 ridhanu

File ini menyimpan informasi untuk autentikasi Heartbeat yang akan di gunakan oleh node cluster. File yang berisi metode tanda tangan digital ini mempunyai tiga metode unuk autentikasinya yaitu crc, sha1, dan md5. Hanya crc yang tidak membutuhkan sebuah password untuk autentikasinya dan metode ini juga yang merupakan metode tercepat dari metode lainnya, hanya saja kelemahannya adalah kurang amannya proses komunikasi nantinya. Oleh karena itu penulis menggunakan metode md5.

Kemudian mengatur hak akses file ini menjadi hak akses 600 karena file authkeys harus menjadi milik root.

root@master:/# chmod 600 /etc/ha.d/authkeys

Kemudian penulis juga membuat file ha.cf yang merupakan file konfigurasi utama dari Heartbeat.

root@master:/# nano /etc/ha.d/ha.cf

Adapaun isi file tersebut adalah sebagi berikut:

use_logd on
udpport 694
keepalive 1
warntime 15
deadtime 30
initdead 30
bcast eth0
node master
node slave
auto_failback off
ping 172.16.32.1
crm yes

Karena pada file ha.cf penulis mengaktifkan use_logd on, maka otomatis penulis juga harus menciptakan file ha_logd.cf untuk menyimpan informasi tentang apa saja yang terjadi pada Heartbeat.

root@master:/# nano /etc/ha_logd.cf

Kemudian mengisi file ini dengan :

logfacility daemon

logfacility merupakan fasilitas syslog sebagai logging daemon yang di gunakan untuk menyimpan informasi log Heartbeat. Adapun tempat penyimpanannya berada pada /var/log/message.

Setelah selesai mengkonfigurasi file, penulis melakukan penyalinan file dari server master ke server slave, adapun file yang di salin adalah sebagai berikut:

root@master:/# scp /etc/ha.d/authkeys root@slave: /etc/ha.d/
root@master:/# scp /etc/ha.d/ha.cf root@slave: /etc/ha.d/
root@master:/# scp /etc/ha_logd.cf root@slave: /etc/

Menjalankan Heartbeat :

root@master:/# /etc/init.d/heartbeat start

Setelah konfigurasi sistem cluster selesai dibuat, maka penulis menentukan beberapa opsi global untuk pengatur resource cluster.

root@master:/# crm_attribute –attr-name symmetric-cluster –attr-value true
root@master:/# crm_attribute –attr-name default-resource-stickiness –attr-value INFINITY

Kemudian, membuat file berikut /tmp/resources.xml, sebagai parameter konfigurasi untuk resource:

root@master:/# nano /tmp/resources.xml

        <group id=”group_1″>

         <primitive id=”VIP_eth0″ provider=”heartbeat” type=”IPaddr2″>

           <operations>

             <op id=”VIP_eth0_mon” interval=”5s” name=”monitor” timeout=”5s”/>

           </operations>

           <instance_attributes id=”VIP_eth2_inst_attr”>

             <attributes>

               <nvpair id=”VIP_eth0_attr_0″ name=”ip” value=”172.16.32.5″/>

               <nvpair id=”VIP_eth0_attr_1″ name=”netmask” value=”24″/>

               <nvpair id=”VIP_eth0_attr_2″ name=”nic” value=”eth0″/>

             </attributes>

           </instance_attributes>

         </primitive>

        </group>

Setelah membuat file resources.xml, kemudian memberitahukan kepada Heartbeat untuk menambahkannya ke konfigurasi cluster.

root@master:/# cibadmin -o resources -C -x /tmp/resources.xml

Terakhir, penulis membuat file berikut, /tmp/constraints.xml, yang akan memberitahu Cluster Resource Manager bagaimana seharusnya layanan failover di jalankan. Adapun isi file ini adalah :

        <constraints>

         <rsc_location id=”rsc_location_group_1″ rsc=”group_1″>

          <rule id=”prefered_location_group_1″ score=”100″>

           <expression attribute=”#uname” id=”prefered_location_group_1_expr” operation=”eq” value=”ha01″/>

          </rule>

         </rsc_location>

        </constraints>

Setelah membuat file constraints.xml, kemudian juga memberitahukan Heartbeat untuk menambahkannya ke konfigurasi cluster.

root@master:/# cibadmin -o constraints-C -x /tmp/constraints.xml

10. Konfigurasi Replikasi Master – Master dengan Mode Aktif – Pasif
Cara yang sangat ampuh untuk merancang sistem fault-tolerant dan High availability adalah dengan menggunakan metode replikasi master-master dengan salah satu server pasif. Konfigurasi ini memungkinkan menukar peran server aktif dan pasif secara bolak-balik dengan sangat mudah, karena konfigurasi server yang simetris. Hal ini membuat failover dan failback menjadi mudah.

Adapaun langkah-langkah konfigurasi pada kedua server sehingga nanti akan terkonfigurasi secara simetris adalah sebagai berikut :

1. Mengaktifkan log_bin dan memilih ID server yang unik, serta menambahkan akun replikasi.
2. Mengaktifkan log_slave_update. Hal ini sangat penting untuk failover dan failback, karena perintah ini berfungsi untuk melakukan replikasi ke binary log server sendiri..
3. Server harus memiliki data yang sama persis.
4. Mengkonfigurasi setiap server sebagai slave dari yang lain, dimulai dengan binary log yang baru dibuat. Sehingga proses pergantian peran akan berlangsung secara otomatis.

Dengan sistem seperti ini, jika terjadi perubahan pada server aktif, perubahan ini akan langsung ditulis ke binary log dan mengalir melalui replikasi untuk log relay ke server pasif. Server pasif mengeksekusi query dan menulis event untuk binary log sendiri, karena pada konfigurasi di atas telah mengaktifkan log_slave_updates. Server aktif kemudian mengambil perubahan yang sama melalui replikasi ke log relay nya sendiri, sehingga bisa di pastikan data dari kedua server akan sama identik.

11. Instalasi Paket Heartbeat
Heartbeat merupakan proyek Linux-HA yang paling banyak di gunakan untuk sistem operasi Linux. Tujuan dari instalasi ini adalah untuk meningkatkan High-availability Cluster Server atau bisa juga di sebut Failover Cluster. Adapun cara instalasinya adalah sebagai berikut (Instalasi paket dilakukan pada kedua server basis data) :

root@master:/# apt-get install heartbeat-2

Heartbeat mempunyai tiga file konfigurasi utama yaitu authkeys, ha.cf, dan cib.xml. Untuk file authkeys dan ha.cf memang secara otomatis tidak tercipta ketika isntalasi paket Heartbeatnya. Karena itu perlu dibuatkan terlebih dahulu.

root@master:/# nano /etc/ha.d/authkeys

Kemudian mengisi file tersebut dengan konfigurasi sebagai berikut :

auth 1
1 md5 ridhanu

File ini menyimpan informasi untuk autentikasi Heartbeat yang akan di gunakan oleh node cluster. File yang berisi metode tanda tangan digital ini mempunyai tiga metode unuk autentikasinya yaitu crc, sha1, dan md5. Hanya crc yang tidak membutuhkan sebuah password untuk autentikasinya dan metode ini juga yang merupakan metode tercepat dari metode lainnya, hanya saja kelemahannya adalah kurang amannya proses komunikasi nantinya. Oleh karena itu penulis menggunakan metode md5.

Kemudian mengatur hak akses file ini menjadi hak akses 600 karena file authkeys harus menjadi milik root.

root@master:/# chmod 600 /etc/ha.d/authkeys

Kemudian penulis juga membuat file ha.cf yang merupakan file konfigurasi utama dari Heartbeat.

root@master:/# nano /etc/ha.d/ha.cf

Adapaun isi file tersebut adalah sebagi berikut:

use_logd on
udpport 694
keepalive 1
warntime 15
deadtime 30
initdead 30
bcast eth0
node master
node slave
auto_failback off
ping 172.16.32.1
crm yes

Karena pada file ha.cf penulis mengaktifkan use_logd on, maka otomatis penulis juga harus menciptakan file ha_logd.cf untuk menyimpan informasi tentang apa saja yang terjadi pada Heartbeat.

root@master:/# nano /etc/ha_logd.cf

Kemudian mengisi file ini dengan :

logfacility daemon

logfacility merupakan fasilitas syslog sebagai logging daemon yang di gunakan untuk menyimpan informasi log Heartbeat. Adapun tempat penyimpanannya berada pada /var/log/message.

Setelah selesai mengkonfigurasi file, penulis melakukan penyalinan file dari server master ke server slave, adapun file yang di salin adalah sebagai berikut:

root@master:/# scp /etc/ha.d/authkeys root@slave: /etc/ha.d/
root@master:/# scp /etc/ha.d/ha.cf root@slave: /etc/ha.d/
root@master:/# scp /etc/ha_logd.cf root@slave: /etc/

Menjalankan Heartbeat :

root@master:/# /etc/init.d/heartbeat start

Setelah konfigurasi sistem cluster selesai dibuat, maka penulis menentukan beberapa opsi global untuk pengatur resource cluster.

root@master:/# crm_attribute –attr-name symmetric-cluster –attr-value true
root@master:/# crm_attribute –attr-name default-resource-stickiness –attr-value INFINITY

Kemudian, membuat file berikut /tmp/resources.xml, sebagai parameter konfigurasi untuk resource:

root@master:/# nano /tmp/resources.xml

        <group id=”group_1″>

         <primitive id=”VIP_eth0″ provider=”heartbeat” type=”IPaddr2″>

           <operations>

             <op id=”VIP_eth0_mon” interval=”5s” name=”monitor” timeout=”5s”/>

           </operations>

           <instance_attributes id=”VIP_eth2_inst_attr”>

             <attributes>

               <nvpair id=”VIP_eth0_attr_0″ name=”ip” value=”172.16.32.5″/>

               <nvpair id=”VIP_eth0_attr_1″ name=”netmask” value=”24″/>

               <nvpair id=”VIP_eth0_attr_2″ name=”nic” value=”eth0″/>

             </attributes>

           </instance_attributes>

         </primitive>

        </group>

Setelah membuat file resources.xml, kemudian memberitahukan kepada Heartbeat untuk menambahkannya ke konfigurasi cluster.

root@master:/# cibadmin -o resources -C -x /tmp/resources.xml

Terakhir, penulis membuat file berikut, /tmp/constraints.xml, yang akan memberitahu Cluster Resource Manager bagaimana seharusnya layanan failover di jalankan. Adapun isi file ini adalah :

        <constraints>

         <rsc_location id=”rsc_location_group_1″ rsc=”group_1″>

          <rule id=”prefered_location_group_1″ score=”100″>

           <expression attribute=”#uname” id=”prefered_location_group_1_expr” operation=”eq” value=”ha01″/>

          </rule>

         </rsc_location>

        </constraints>

Setelah membuat file constraints.xml, kemudian juga memberitahukan Heartbeat untuk menambahkannya ke konfigurasi cluster.

root@master:/# cibadmin -o constraints-C -x /tmp/constraints.xml

12. Konfigurasi Replikasi Master – Master dengan Mode Aktif – Pasif
Cara yang sangat ampuh untuk merancang sistem fault-tolerant dan High availability adalah dengan menggunakan metode replikasi master-master dengan salah satu server pasif. Konfigurasi ini memungkinkan menukar peran server aktif dan pasif secara bolak-balik dengan sangat mudah, karena konfigurasi server yang simetris. Hal ini membuat failover dan failback menjadi mudah.

Adapaun langkah-langkah konfigurasi pada kedua server sehingga nanti akan terkonfigurasi secara simetris adalah sebagai berikut :
1. Mengaktifkan log_bin dan memilih ID server yang unik, serta menambahkan akun replikasi.
2. Mengaktifkan log_slave_update. Hal ini sangat penting untuk failover dan failback, karena perintah ini berfungsi untuk melakukan replikasi ke binary log server sendiri..
3. Server harus memiliki data yang sama persis.
4. Mengkonfigurasi setiap server sebagai slave dari yang lain, dimulai dengan binary log yang baru dibuat. Sehingga proses pergantian peran akan berlangsung secara otomatis.

Dengan sistem seperti ini, jika terjadi perubahan pada server aktif, perubahan ini akan langsung ditulis ke binary log dan mengalir melalui replikasi untuk log relay ke server pasif. Server pasif mengeksekusi query dan menulis event untuk binary log sendiri, karena pada konfigurasi di atas telah mengaktifkan log_slave_updates. Server aktif kemudian mengambil perubahan yang sama melalui replikasi ke log relay nya sendiri, sehingga bisa di pastikan data dari kedua server akan sama identik.

Analisa dan Perancangan Sistem Replikasi secara Realtime

Perihal ridhanu
I'm Network Engineer, Bankir, Born May 12, 1988 on Barabai. My twitter: @ridhanu, facebook: ridhanu@yahoo.co.id, mobile phone: 0852 4936 4064, email: ridhanu@gmail.com

One Response to Implementasi Replikasi secara Realtime

  1. Ping-balik: Analisa dan Perancangan Sistem Replikasi secara Realtime | Ridhanu's Weblog

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: