HA Solution: High Availability Cluster Multi-Processing (HACMP) a.k.a. Power HA

Halo semuanya,

Untuk postingan kali ini, saya ingin membahas mengenai sistem HA untuk level enterprise yang diluncurkan oleh sebuah perusahaan IT yang sudah sangat legendaris yaitu IBM yang bernama High Availability Cluster Multi Processing (HACMP). Supaya tidak terlalu panjang, berikut ini adalah pembahasannya.

Arsitektur Sistem HACMP

       System ini nampaknya lebih rumit ketimbang system lain yang ada dalam kajian ini. Namun, disamping itu system ini juga memiliki kelebihan, salah satunya adalah pengiriman paket heartbeat dapat dilakukan tidak hanya melalui satu atau dua private network, melainkan dapat juga dikirimkan melalui jaringan TCP/IP, jaringan point-to-point maupun shared disk. Berikut ini adalah beberapa pion penting yang ada dalam HACMP:

1.       Seperti tampak pada gambar, secara fisik HACMP cluster terbagi atas 4 komponen yaitu:

a.       Networks

HACMP dapat bekerja dengan berbagai macam jaringan yang berbasis TCP/IP (telah diuji dengan jaringan Ethernet, Token Ring, ATM dan jaringan lainnya). Seluruh node dalam cluster HACMP menggunakan network untuk:

·         Memungkinkan clients untuk mengakses seluruh node dalam cluster

·         Memungkinkan seluruh node dalam cluster untuk bertukar heartbeat message

·         Mengakses data

b.      Client

Client menjalankan aplikasi front end yang melakukan request kepada aplikasi server yang berjalan pada cluster node. Meskipun client termasuk dalam struktur HACMP, namun HACMP tidak membuat client menjadi Highly Available. Untuk mengetahui status dari cluster, client dapat menggunakan tool Clinfo.

c.       Nodes

·   Client node

Menjalankan front end application yang me-retrieve data dari server node. Client node dapat menjalankan HACMP software untuk melakukan memonitor keadaan dari seluruh node dan melakukan tindakan jika terjadi failure. Client node melakukan komunikasi dengan server nodes melalui Service IP Address. Client node dapat dibagi menjadi 2 kategori, yaitu naïve client dan intelligent client:

·         Naïve client melihat cluster sebagai satu entitas, jika sebuah server mengalami failure dan koneksi terputus, naïve client harus melakukan restart atau setidaknya melakukan reconnect ke server.

·         Intelligent client adalah cluster aware client. Saat terjadi failure, client ini melakukan reconnect ke server lain, dan mungkin melakukan masking failure untuk kenyaman user.

·   Server node

Adalah core dari HACMP system. Server nodes menjalankan service ataupun back end application yang mengakses data dari shared external disk. Dalam server nodes berjalan HACMP daemon.

d.      Shared disk

Menyimpan mission-critical data, umumnya mirrored atau menggunakan RAID untuk data redundancy dan terhubung ke beberapa server node. Shared disk juga dapat digunakan untuk mentransmisikan heartbeat dari satu node ke node lain.

2.       Yang dilakukan oleh HACMP pada saat terjadi failure (misalkan pada salah satu node):

a.       HACMP mendeteksi adanya failure pada salah satu node dengan hilangnya heartbeat (jika terjadi shutdown atau network failure) atau pesan error pada heartbeat (jika failure pada application, internal disk atau failure lainnya yang membuat node masih dapat mengirimkan heartbeat)

b.      Node lain (yang telah dikonfigurasi) melakukan takeover seluruh task/job dan resource (shared disk, client, dll) yang dimiliki oleh failure node sementara node lain tersebut menjalankan task/job dan resourcenya sendiri.

c.       Jika node yang melakukan takeover mengalami kelebihan load, maka HACMP akan melakukan load balancing.

d.      Business continue.

3.       Poin-poin penting untuk sistem HACMP:

a.       Menggunakan konsep Shared Availability

b.      Node bertugas untuk menyimpan dan menjalankan aplikasi server

c.       Shared disk menyimpan mission critical data

d.      Dapat menggunakan berbagai macam jaringan berbasis TCP/IP

e.      Cluster dapat terdiri dari 1 standalone System P Server hingga 32 System P server dengan sistem operasi AIX

4.       Kelebihan dan kekurangan

a.       Kelebihan

·   Very high degree availability

·   Increased scalability

·   Dapat berfungsi sebagai load balancer

·   Tidak bergantung pada 1 network untuk mentransmisikan heartbeat

·   Antara satu node dengan node lain tidak harus identik untuk dapat melakukan takeover

·   Tidak menggunakan teknik virtualization sehingga aplikasi yang berada di dalam setiap node dapat berjalan lebih ringan ketimbang dengan virtualization

b.      Kekurangan

·   Hanya bekerja pada platform System P dan i series dengan sistem operasi AIX

·   Kompleksitas yang lebih tinggi sehingga membutuhkan skill khusus untuk melakukan implementasi dan administrasi

Sistem HA ini sangat cocok untuk diterapkan untuk level Enterprise yang menginginkan HA dengan SLA yang lebih tinggi.

Isi dari postingan ini saya kutip dari dokumentasi “High Availability Cluster Multi-Processing for AIX, Concepts and facilities guide” oleh IBM. Saya rasa cukup sekian postingan kali ini, jika anda memiliki pertanyaan, saran, atau kritik, silahkan sampaikan melalui komentar atau email: adie_ndonk@yahoo.co.id. 

 

Thanks & Regards,

Adhie Indi Arysanto.

HA Solution: Microsoft Cluster Server (MSCS)

Halo semuanya,

Pada kesempatan kali ini, saya akan membahas tentang solusi HA/DR yang diluncurkan oleh produsen software yang tidak asing bagi kita yaitu Microsoft Cluster Server (MSCS).

HA system yang satu ini agak berbeda dengan HA system yang lain, karena menggunakan konsep failover availability, namun kedua server dapat bersifat aktif dan dapat berfungsi sebagai load balancer. Setiap server (dalam MSCS disebut dengan Node) tidak harus identik, dan dapat berbeda baik dalam hal processing speed, physical memory, bahkan hard drive configuration. Sayangnya, HA system ini tidak dapat dikonfigurasi untuk Disaster Recovery plan. Hal ini dapat disebabkan oleh adanya Shared Storage yang hanya dapat menggunakan SCSI Shared-Storage Bus.

Dalam system MSCS, setiap cluster terdiri dari:

1.       Node (server)

Dapat berjumlah 1 (Virtual Only Solution/no failover) atau maksimal 2 buah komputer server yang saling terhubung melalui private network. Dalam masing-masing node terdapat group dan resources:

·         Group (virtual server)

Dalam MSCS, client tidak perlu tahu di node mana proses yang mereka berikan dieksekusi. Client akan mengenali group sebagai virtual server dimana aplikasi mereka berjalan.

·         Resource

Sebuah resource adalah aplikasi atau tool lainnya yang terinstall dalam sebuah node. Di dalam masing-masing group terdapat satu atau lebih resource. sebuah resource hanya dapat ditempatkan di satu host dalam satu waktu, namun dapat dilakukan konfigurasi untuk failover.

2.       Shared disk/storage

Dalam masing-masing node terdapat satu atau lebih shared storage yang digunakan untuk menyimpan mission critical data. Saat ini, MSCS hanya mendukung SCSI Shared Storage Bus.

3.       Private network

Adalah jaringan TCP/IP yang digunakan oleh masing-masing node untuk berkomunikasi, baik dalam mentransmisikan heartbeat maupun melakukan sinkronisasi antar node. Microsoft sangat menyarankan penggunaan lebih dari satu private network untuk mengurangi adanya single point of failure dalam cluster.

4.       Public network

Adalah jaringan TCP/IP yang menghubungkan antara client dengan masing-masing cluster server.

 

Beberapa model cluster yang dapat digunakan dalam merencanakan implementasi MSCS:

A.      High Availability with static load balancing

Pada model ini, masing-masing node terpasang group yang saling berbeda satu sama lain. Pada gambar terlihat node 1 terdapat “FilePrint group1” dan pada node 2 terdapat “FilePrint group2”. Untuk mengantisipasi failover, maka pada node 1 disediakan tempat dan dilakukan konfigurasi untuk melakukan takeover saat node 2 mengalami failure ataupun kelebihan load. Hal yang serupa juga terdapat pada node 2.

Dalam mengimplementasikan model  ini, perlu diperhitungkan antara beban yang akan dialami masing-masing node dengan sumber daya yang dimiliki oleh masing-masing node, agar seluruh group dapat berjalan dengan baik saat melakukan takeover (seluruh group akan berjalan dalam satu node).

B.       “Hot Spare” Solution With Maximum Availability

Model ini serupa dengan konsep yang dimiliki oleh Neverfail, hanya saja berbeda pada sistem virtualisasi dan adanya shared storage sehingga tidak dapat digunakan untuk Disaster Recovery Plan.

C.      Partial MSCS Solution

Hampir sama dengan model sebelumnya (Hot Spare), hanya saja tidak semua group yang ada dalam node diberikan alokasi untuk failover pada node lainnya.

D.      Virtual Server Only Solution (no Failover)

Dalam model ini, failover tidak dimungkinkan. Sehingga MSCS hanya berfungsi untuk melakukan restart aplikasi (setelah recovery dilakukan).

E.       Hybrid Solution

Model ini adalah gabungan dari 2 model sebelumnya yaitu High Availability with Static Load Balancing dan Partial MSCS Solution.

Secara keseluruhan, MSCS memiliki beberapa kelebihan dan kekurangan antara lain:

A.      Kelebihan:

·         Dapat diimplementasikan dalam berbagai macam model sesuai dengan kebutuhan

·         Pada beberapa model dapat berfungsi sebagai load balancer

·         Kedua node tidak harus identik, sehingga dapat menghemat investasi

·         Kedua node dapat bersifat aktif

B.      Kekurangan:

·         Hanya didukung oleh sistem operasi Windows NT Server, Enterprise Edition

·         Harus menggunakan Shared Storage dengan interface SCSI Shared-Storage Bus

·         Tidak dapat digunakan dalam DR plan

Screenshot MSCS Cluster Administrator:

Untuk anda yang memiliki datacenter dengan homogeneus platform (Ms Windows) mungkin solusi ini dapat dijadikan pertimbangan karena fleksibilitas dalam menentukan model cluster yang ingin diimplementasikan.

Isi dari postingan ini saya kutip dari dokumentasi MSCS yang disediakan oleh Microsoft. Saya rasa cukup sekian postingan kali ini, jika anda memiliki pertanyaan, saran, atau kritik, silahkan sampaikan melalui komentar atau email: adie_ndonk@yahoo.co.id. 

 

Thanks & Regards,

Adhie Indi Arysanto.

Database HA Solution: xkoto GRIDSCALE

Halo semuanya, pada posting kali ini saya akan membahas mengenai salah satu solusi HA untuk service database yang cukup terkenal yaitu xkoto GRIDSCALE. Dan berikut ini adalah arsitekturnya.

Arsitektur xkoto GRIDSCALE 

Adalah sebuah teknologi HA yang menggunakan teknik Database Virtualization untuk menjamin Continuous Availability pada service database. Berikut ini adalah poin-poin penting yang ada pada GRIDSCALE:

1.       Dikhususkan menangani database

2.       Berada terpisah dengan server database

3.       Menggunakan konsep multiple copy

4.       Server-server yang ditangani oleh GRIDSCALE dapat heterogenus baik dalam segi Operating System maupun Database Server (misalkan: server 1 menggunakan DB2 dalam Linux, server 2 menggunakan Oracle dalam HP UX dan server 3 menggunakan SQL Server dalam environment Windows)

5.       Juga berfungsi sebagai load balancer

6.       Performa database akan berbanding lurus dengan jumlah database server yang digunakan, terutama untuk database read-intensive application

7.       Seluruh database server yang ditangani oleh GRIDSCALE adalah aktif

8.       Database server yang ditangani GRIDSCALE dapat dipisahkan secara geografis untuk scenario DR

9.       Server GRIDSCALE dapat berjumlah 2 buah (active-passive) untuk lebih menjamin HA

10.   Dari sisi client, server GRIDSCALE tampak sebagai satu buah server yang melayani seluruh aplikasi

11.   Aplikasi tidak perlu tahu berapa banyak server yang digunakan, melainkan hanya perlu mengakses server GRIDSCALE untuk mendapatkan seluruh data. Sehingga tidak akan ada perubahan dari sisi user application

Cara kerja xkoto GRIDSCALE:

1.       Dari sisi client, GRIDSCALE tampak seperti sebuah database server

2.       Saat terdapat aplikasi yang melakukan Read/SELECT, GRIDSCALE akan memilih (dengan algoritma tertentu) database server mana yang dapat menyajikan data up-to-date dengan waktu tercepat

3.       Saat terdapat aplikasi yang melakukan Write (INSERT, UPDATE, DELETE atau DDL), GRIDSCALE akan melakukan replicate statement tersebut untuk kemudian diberikan kepada seluruh server yang ditangani oleh GRIDSCALE. Untuk kejadian seperti ini, GRIDSCALE dapat dikonfigurasi untuk bekerja synchronous maupun asynchronous:

a.       Synchronous

GRIDSCALE akan menunggu untuk seluruh server memberikan respon bahwa statement telah selesai dieksekusi lalu memberikan respon kepada application. Jika terdapat server yang gagal melakukan eksekusi, GRIDSCALE akan melakukan Rollback untuk server lain yang berhasil melakukan eksekusi dan memberikan respon gagal kepada application

b.      Asynchronous

GRIDSCALE tidak menunggu seluruh server memberikan respon berhasil untuk memberikan respon berhasil kepada application melainkan hanya perlu menunggu server yang paling awal memberikan respon sukses. Hal ini dilakukan untuk memberikan waktu eksekusi yang lebih singkat dalam mengeksekusi

Mungkin anda akan merasa penasaran mengenai bagaimana interface GRIDSCALE pada saat anda ingin melakukan administrasi dari sistem. Untuk itu, berikut ini adalah beberapa screenshot dari GRIDSCALE Management Console:

Dashboard

Cluster Administration

 Cukup menarik bukan?. Karena console tersebut berbasis web, anda tidak perlu melakukan installasi pada komputer client dimana anda akan melakukan administrasi untuk sistem tersebut.

Isi dari postingan ini saya kutip dari artikel “TECHNICAL WHITEPAPER GRIDSCALE® DATABASE VIRTUALIZATION SOFTWARE” yang disediakan oleh xkoto. Saya rasa cukup sekian postingan kali ini, jika anda memiliki pertanyaan, saran, atau kritik, silahkan sampaikan melalui komentar atau email: adie_ndonk@yahoo.co.id.  

 

Thanks & Regards,

Adhie Indi Arysanto.

Konsep Sistem High Availability dan Disaster Recovery

Halo semuanya, sesuai janji saya pada posting sebelumnya, kali ini saya akan membahas mengenai konsep yang dapat diaplikasikan untuk mengimplementasikan sistem yang Highly Available pada datacenter anda.

Sebelum membahas tentang teknologi yang berhubungan dengan HA, ada baiknya untuk mengenal sekilas mengenai konsep yang diterapkan untuk implementasi HA. Dari segi tipe, HA terbagi atas 2 tipe yaitu Continuous Availability dan Failover Availability:

1.       Continuous Availability

Dalam Continuous availability, service (sebagai contoh database engine) dituntut untuk tetap available tanpa adanya downtime yang dapat dirasakan oleh user. Terdapat 3 design standar yang dapat digunakan untuk mengimplemetasikan Continuous availability, yaitu Programatic, Shared dan Multiple Copy:

a.       Programmatic

Pada intinya, konsep ini mengandalkan pemrograman dari sisi user application (bukan dari sisi server) dengan cara mengakses ke dua atau lebih server yang tidak saling berhubungan. Keuntungan dari system ini adalah mendapatkan maximum flexibility dimana saat terjadi failure pada satu server tidak akan mempengaruhi kinerja dari user application.

Kelebihan:

·         Maximum flexibility

Kekurangan:

·         Waktu dan biaya pembuatan aplikasi yang sangat tinggi

·         Kurangnya dukungan dari aplikasi yang ada dipasaran

·         Kompleksitas yang sangat tinggi

b.      Shared Availability

Design konsep ini adalah dengan penggunaan redundant systems yang berbagi critical redources. Dengan konsep ini, selain untuk High Availibility, system juga berfungsi sebagai load balancer.

Kelebihan:

·         Very high degree of availability

·         Increased Scalability

·         Tidak perlu mengubah aplikasi

Kekurangan:

·         Biaya yang sangat tinggi

·         Diperlukan hardware khusus

·         Diperlukan skill khusus untuk mengimplementasikan

c.       Multiple Copy

Konsep ini menggunakan beberapa copy dari data yang diinginkan untuk highly available pada beberapa server yang saling berhubungan. Dengan konsep ini, selain untuk High Availibility, server-server juga berfungsi sebagai load balancer. Marathon everRun adalah satu contoh software pendukung dalam implementasi konsep ini.

Kelebihan:

·         Very high degree of availability

·         Tidak perlu adanya perubahan pada sisi user application

·         Moderate cost increase

·         Mudah dalam implementasi dan administrasi

Kekurangan:

·         Diperlukan software pendukung

·         Additional hardware administration

 

2.       Failover Availability

Berbeda dengan Continuous Availability, Failover Availability membutuhkan waktu (walaupun sedikit) saat terjadi failure. Dalam konsep ini digunakan 2 buah server (primary dan secondary) dengan data (yang diinginkan untuk highly available) identik pada masing-masing server.

Pada saat system dengan konsep ini berjalan normal, hanya primary server yang bertugas untuk melayani seluruh user. Sedangkan pada saat primary server mengalami failure dan secondary server mendeteksi hal tersebut, maka secondary server menggantikan fungsi dari primary server. Dalam Failover Availability, terdapat 2 tipe yaitu synchronous dan asynchronous:

a.       Synchronous

Dengan tipe ini, masing-masing server (primary dan secondary) saling melakukan sinkronisasi data, sehingga keseragaman data pada masing-masing server tersebut lebih terjamin.

Kelebihan:

·         Keseragaman data pada kedua server lebih terjamin, sehingga pada saat terjadi failure, keselamatan data akan lebih terjamin

Kekurangan:

·         Karena kedua server saling melakukan sinkronisasi, maka network traffic akan lebih tinggi jika dibandingkan dengan tipe Asynchronous

b.      Asynchronous

Dengan tipe ini, sinkronisasi dilakukan dengan cara mengirim perubahan data pada server yang sedang aktif kepada server yang sedang pasif. Sehingga hanya satu server yang melakukan sinkronisasi dan pada akhirnya network traffic akan lebih terminimalisir. Contoh software pendukung yang menggunakan tipe ini adalah neverfail.

Kelebihan:

·         Network traffic lebih terminimalisir

Kekurangan:

·         Keseragaman data kurang terjamin

 

Wow..panjang juga yah... Sebagai informasi, posting ini sebagian besar saya kutip dari IBM Developer Works melalui artikelnya yang berjudul “Implementing high availability with DB2 9.5”. Melalui posting ini, saya harap anda dapat mengetahui konsep mana yang cocok untuk diimplementasikan untuk datacenter anda. Pada Posting selanjutnya, saya akan membahas tentang berbagai macam solusi yang dapat dipertimbangkan untuk diterapkan pada datacenter anda. Sampai bertemu pada posting saya yang selanjutnya.

Pengenalan High Availability dan Disaster Recovery

Saat saya membuka arsip-arsip kajian yang telah saya buat sejak awal saya bekerja, saya menemukan sebuah kajian yang cukup menarik yaitu mengenai system High Availability dan Disaster Recovery untuk datacenter mulai dari SMB (Small Medium Business), hingga Enterprise.

Sebelum memulainya, mungkin masih ada yang belum mengetahui apa itu High Availability (HA) dan Disaster Recovery (DR). Setiap user sudah pasti menginginkan bahwa server yang mereka akses selalu dalam keadaan Available agar dapat mereka manfaatkan untuk memenuhi kebutuhan mereka misalkan untuk mengolah data transaksi pada sebuah Bank. Dapat dibayangkan apabila sebuah Bank yang telah memiliki ratusan cabang yang tersebar di seluruh Nusantara dan memiliki ribuan jaringan ATM tiba-tiba tidak Available (Down). Tentunya seluruh nasabah pada Bank itu akan kehilangan kepercayaan yang mengakibatkan bencana berdampak menyeluruh pada Bank tersebut.

Oleh karena itu, diciptakanlah sebuah sistem High Availability untuk menjamin agar sebuah layanan data dapat selalu Available untuk dapat menjamin Business Continuity pada perusahaan tersebut. Berbagai macam konsep digunakan oleh masing-masing vendor yang menyediakan sistem HA, mulai dari Sistem Otomasi, hingga menggunakan beberapa physical server yang bekerja bersamaan dalam melayani data ataupun mengeksekusi aplikasi server side untuk menjamin availability dari service tersebut.

Selain itu, kita juga sering mendengar adanya berbagai macam bencana alam seperti gempa bumi, tsunami, banjir dll, ataupun bencana lainnya seperti terganggunya pasokan listrik dan BBM untuk daerah tertentu dimana sebuah datacenter berada. Tentunya berbagai hal tersebut dapat mengancam ketersediaan (Availability) dari satu atau lebih layanan data yang disediakan dalam datacenter tersebut. Oleh karena itu, banyak perusahaan yang membangun Disaster Recovery Center (DRC) yang terletak berjauhan dari pusat datacenter, misalkan antar kota, pulau hingga antar benua.

Masing-masing teknologi HA dan DR tentunya memiliki kelebihan dan kekurangan baik dalam segi Availability, kompleksitas dan platform yang dapat digunakan. Hal ini tentunya perlu disesuaikan dengan kebutuhan masing-masing perusahaan baik dalam segi platform, cost/budget maupun Service Level (SLA) yang diinginkan.

Pada posting berikutnya, saya akan membahas mengenai beberapa konsep yang dapat digunakan untuk menyediakan sistem yang Highly Available yang dapat dijadikan acuan saat ingin mengimplementasikan sistem HA ataupun DR pada datacenter yang anda miliki. Sampai bertemu pada posting selanjutnya.

Thanks & Regards,

Adhie Indi Arysanto

Hello... (Readme)

Hi semuanya,

Saya Adhie Indi Arysanto, seorang biasa yang ingin berbagi pengetahuan dalam dunia IT yang saya tekuni. Melalui Blog ini, saya ingin berbagi ilmu dan belajar segala sesuatu khususnya yang ada dalam dunia IT. Untuk itu, saya mengharapkan segala macam kritik dan saran dari anda para pengunjung.

Semoga Blog ini bermanfaat bagi semuanya.

Thanks & Regards,

Adhie Indi Arysanto