GDPS – Konfigurasi Sistem Komputer Antar Kota Antar Propinsi

20 Dec 2010 GDPS – Konfigurasi Sistem Komputer Antar Kota Antar Propinsi

Barangkali kita sudah tidak asing lagi dengan mesin dan onderdil komputer. Bila komputer kita buka cashing-nya, kita bisa melihat yang mana disk atau harddisk, mana CPU atau processor, mana memory dll. Kita juga tahu kabel mana yang digunakan sebagai jalur lalulintas data antara disk dan memory. Semua berdekatan kan? Jarak disk dan memory paling hanya beberapa cm. Panjang kabel data juga tidak sampai 100 cm.

Ternyata ada sebuah komputer yang disk-nya berjarak 100 km dari memory. Antara disk dan memory berada di kota yang berbeda. Bahkan beda propinsi. Tentu tidak dalam satu cashing. Lah wong antar kota antar propinsi (AKAP)… ya mana mungkin ada tong yang cukup untuk mewadahinya.

AKAP ternyata bukan untuk bus saja. Di dunia IT juga ada AKAP, sebuah konfigurasi sistem komputer yang membentang antar kota bahkan antar propinsi. Ini bukan network lho! Kalo network ya pasti luas, bahkan antar negara maupun benua. Yang ini adalah konfigurasi sistem host, yaitu antara CPU/memory dan I/O devies. Konfigurasi sistem semacam ini populer disebut GDPS atau Geographically Dispersed Parallel Sysplex. Silakan simak gambar berikut ini,

Bagi yang tidak kenal mainframe (MF), mungkin tidak kenal GDPS. Karena sampai dengan hari ini, GDPS hanya dimiliki oleh teknologi MF. GDPS adalah salah satu sarana untuk mendukung aplikasi komputasi mission-critical atau business-critical, yaitu komputasi yang bersifat sangat sensitif, tidak boleh salah dan harus tepat waktu. Kesalahan atau keterlambatan sedikit saja akan berpengaruh langsung pada bisnis atau misi perusahaan. Contohnya di bank. Setiap digit data bank adalah uang nasabah dan itu merupakan materi utama bisnis perbankan. Keterlambatan proses sangat tidak dilolerir karena setiap proses harus segera disusul proses berikutnya dan tidak boleh menunggu. Jadwalnya ketat dan proses hari itu harus selesai hari itu, karena hari berikutnya proses tersebut harus diulang lagi untuk tanggal yang berbeda.

Transaksi online-nya pun tidak boleh leled. Keleledan akan membosankan nasabah dan bank tersebut akan ditinggalkan oleh nasabah. Terlebih jika ada kesalahan yang merugikan nasabah, tentu akan sangat mempengaruhi bisnis bank tersebut.

Contoh lain mission-critical adalah sistem informasi pemerintahan. Tapi ini hanya berlaku untuk pemerintahan yang “sungguhan”. Artinya pemerintahan yang benar-benar melayani rakyat dan mengelola negara dengan cermat dan maksimal untuk meraih kemajuan dan kemakmuran seluruh rakyatnya. Dalam melayani rakyat tidak ada istilah “tar-sok” apa lagi mempersulit. Tidak ada aturan yang kontradiksi satu sama lain. Tidak membiarkan apalagi mengandalkan preman untuk mengelola sarana umum maupun sumberdaya alam. Dan… tidak ada budaya “clamitan”, mau ngurusin rakyat hanya kalo dikasih uang, baik yang terus terang meminta maupun pura-pura bikin birojasa dan memprioritaskan atau bahkan hanya memberi layanan kepada birojasa tersebut. Pemerintah semacam itu adalah pemerintah “bohongan”.

Disana seseorang tidak mungkin membuka rekening bank dengan KTP palsu seperti penipu-penipu yang marak di sekitar kita dengan modus transfer bank. Bank secara online akan mengkroscek KTP calon nasabah dengan database penduduk (milik pemerintah). Bank juga tahu sseorang nasabah atau calon nasabah mengemplang pajak atau sedang terlibat perkara. Karena database penduduk ada link online dengan database pajak dan database perkara /kriminalitas. Dengan demikian tidak mungkin pengemplang pajak atau kriminal lain bisa mendapatkan pinjaman bank.

Polisi juga sangat sulit bermain “bisnis” dengan perkara. Database perkara juga terpusat seperti kependudukan dan perpajakan. Jika ada seseorang terlibat perkara, polisi harus mencatat semua hasil sidikan ke database tersebut. Hal ini dikuatkan dengan perundangan dimana seseorang baru dinyatakan berperkara manakala sudah mendapatkan nomor registrasi perkara, yang sebenarnya adalah “key” database perkara. Selama belum ada key, dia masih termasuk orang bersih dan polisi tidak berhak menginterogasi. Dengan demikian, mau nggak mau polisi harus signup untuk mendapatkan key bagi orang tersebut. Setelah dapat key, berarti record sudah dipantau dari segala penjuru oleh seluruh lembaga yang berkepentingan. Nah.. pak polisi sudah tidak bisa main-main lagi.

Dari beberapa contoh sederhana di atas saja sudah kelihatan bahwa database penduduk, perpajakan dan perkara maupun kriminalitas memiliki urgensi yang mirip dengan perbankan, yaitu terpusat dan mission-critical. . Bagi yang seneng mengamati pemerintahan negara lain atau pernah ikutan proyek-proyek IT di pemerintah negara lain mungkin tahu. Sebenarnya wakil rakyat kita juga sering “study banding” ke negara-negara lain. Namun mereka sibuk ngurus belanjaan dan oleh-oleh sehingga tidak memiliki banyak waktu untuk melihat hal-hal seperti ini. Bahkan bisa jadi tak kepikiran sama sekali ada ginian 🙂

Manfaat GDPS untuk Komputasi Mission-Critical

Kembali ke GDPS… dan kaitannya dengam komputasi mission-critical. Mari kita simak lagi contoh GDPS pada gambar di atas. Disana ada 2 CPU MF, satu di Jakarta dan satu di Purwakarta, dan 2 disk array, satu di Bogor dan satu di Cirebon. Digambarkan sistem tersebut memuat 2 aplikasi, A dan B. Aplikasi A jalan di CPU Jakarta dan datanya di disk Bogor dan di-mirror ke disk Cirebon. Sedangkan aplikasi B jalan di CPU Purwakarta dan datanya di disk Cirebon dan di-mirror ke disk Bogor. Selain untuk aplikasi A, CPU Jakarta juga untuk mem-backup aplikasi B dari CPU Purwakarta. Demikian pula CPU Purwakarta, selain untuk aplikasi B, juga dipersiapkan untuk mem-backup aplikasi A dari CPU Jakarta.

Jangan dibayangkan seperti ada 2 sistem, Jakarta dan Purwakarta. Konfigurasi ini secara logik tampil sebagai sistem tunggal. Jika ini bank, nasabah tidak tahu di balik teller, ATM, web maupun ponsel yang mereka hadapi ternyata sebuah sistem AKAP seperti ini. Jangankan nasabah, para teller dan orang IT yang kerja disana selain kelompok support juga tidak tahu dia sedang login di sistem yang mana.

Namun sistem ini adalah sistem produksi. CPU Jakarta maupun Purwakarta adalah bagian produksi. Semua bekerja serius setiap hari, saling berbagi beban dan saling backup. Inilah yang dinamakan live backup. Tidak lagi ada backup site yang tidur nyeyak sepanjang tahun dan hanya bekerja manakala sistem produksi kena musibah. Jadi bisnis tidak dirugikan. Namun perlu dicatat, karena ini sistem produksi, maka development system tidak ikut nimbrung disini. Development system sebaiknya dipisahkan karena baik sekuritas maupun kontens nya sangat berbeda dengan sistem produksi.

Lantas apa kaitan dan manfaatnya dengan komputasi mission-critical? Nah… untuk melihat manfaatnya bagi komputasi mission-critical, mari kita simak contoh kasus pada gambar berikut ini.

Dalam contoh kasus ini, di Jakarta terjadi musibah (disaster) yang menimpa CPU disana, berhenti total. Tentu aplikasi A juga berhenti total. Namun dengan dukungan teknologi Parallel Sysplex yang dikelola oleh sistem operasi z/OS melalui komponen WLM, maka aplikasi A otomatis nyambung jalan di CPU yang di Purwakarta dengan data tetap di disk Bogor dan di-mirror ke disk Cirebon. Dengan demikian bisnis tetap jalan seperti tidak terjadi apa-apa.

Musibah bisa saja terjadi di Cirebon.   Kali ini bukan CPU yang kena, melainkan disk.  Walaupun disk biasanya banyak, anggap saja musibah ini besar sehingga seluruh data di Cirebon hancur tak bisa diakses lagi.   Sehingga aplikasi B yang jalan di CPU Purwakarta kehilangan aksesnya ke data B di Cirebon.  Namun GDPS secara otomatis membelokkannya ke duplikat data B yang di Bogor.  Sehingga aplikasi B yang di CPU Purwakarta tetap jalan lancar.   Dengan demikian bisnis tetap jalan lancar seperti tidak pernah terjadi apa-apa.

Apa yang terjadi jika sekaligus terjadi 2 musibah, di Jakarta dan Cirebon.   Suasananya seperti pada gambar ini.   Memang kejadian semacam ini sangat kecil peluangnya. Dalam perhitungan teknis, jika reliability setiap komponen 95%, maka peluang failure sekaligus 2 komponen oleh penyebab yang berbeda atau terpisah adalah (1-95%)**2 = 2.5%. Tapi tak apalah… sekedar untuk contoh pembahasan.

Dalam musaibah ini, CPU Jakarta berhenti total dan data di Cirebon juga hangus total. Otomatis sistem akan melanjutkan aplikasi A di CPU Purwakarta ngumpul bersama aplikasi B. Sedangkan data B di Bogor otomatis menjadi data primer untuk aplikasi B. Sehingga aplikasi A maupun B tetap jalan normal dan semua mengakses disk yang di Bpgpr. Dengan demikian bisnis tetap jalan lancar seperti tidak pernah terjadi apa-apa.

Nah… apa pula yng terjadi bilamana CPU Jakarta dan Purwakarta serempak terkena musibah? Atau disk di Bogor dan Cirebon serempak terkena musibah? Tentu jawabannya tamatlah riwayat konfigurasi AKAP tersebut.

Meskipun peluangnya kecil sekali, tetapi bukan mustahil GDPS kecele. Oleh karena itu kita harus pandai menyusun bentangan seaman mungkin. Beberapa parameter yang harus dicermati antara lain:

1. Bentangan yang paling optimum adalah melintasi wilayah-wilayah yang heterogen. Artinya, jangan sampai hadir satu bencana, beberapa wilayah terimbas. Misalnya, bila ada gempa di Bogor, selalu Jakarta ikut bergoyang dombret, atau sebaliknya. Maka salah satu harus dicoret, karena hanya buang biaya kurang manfaat.
2. Batasan teknologi juga harus diperhatikan. Jangan sampai sudah capek-capek bikin rancangan ternyata nggak bisa dilaksanakan. Jarak terjauh sambungan Ficon tanpa RPQ dan penguat untuk produk Ficon IBM saat ini adalah 100 km. Antara CPU dan disk primer tidak boleh ada penguat, berarti 100 km. Antara disk primer dan sekunder (mirror) tergantung teknologi mirroring yang kita pilih. Kalo kita pilih PPRC (sinkron lewat CPU) berarti terbatas 100 km. Kalo langsung disk-to-disk dengan XRC (asinkron) tak terbatas, bisa Jakarta-Ambon, karena boleh menggunakan penguat dan RPQ. Tetapi pada saat mirror-nya dijadikan primer (karena ada musibah), aplikasinya tidak bisa jalan di Jakarta, harus di Ambon. Semua itu harus dirancang dengan cermat. Biasanya ada produk OEM yang melebihi kemampuan produk orisinilnya.

–

Kapan Bank Kita Menggelar GDPS?

Sungguh pertanyaan yang sulit dijawab. Karena mereka harus boyong ke MF dulu. Sebagian mungkin masih dipimpin bos yang dulu yang alergi mahalnya MF. Sebagian lagi mungkin sama sekali tidak tahu MF. Lagi pula, boyongan antar platform biayanya tak terukur dan resikonya tinggi. Bos-bos lama (andaikan masih berkuasa) mungkin masih trauma bagaimana hamburadulnya ketika mereka boyong ke distributed system sehingga baru 2 tahun terpaksa harus kembali ke centralized system.

Boyong dari non-MF ke MF untuk komputasi mission-criitical adalah “jalan yang benar”. Tetapi bukan berarti bebas investasi dan resiko. Hari ini memang MF jauh lebih murah dibanding MF pra 2000. Terlebih dibanding MF pra 90an. Tetapi investasinya kan tidak hanya MF saja yang harus dihitung. SDM juga merupakan parameter yang sangat serius. Oleh karena itu sejak tahun 2003 mulai banyak universitas di beberapa negara yang berafiliasi dengan IBM Academic Initiative untuk mengajarkan keterampilan MF pada mahasiswa jurusan IT.

Cerita ini akan berbeda lagi jika situasinya seperti Malaysia dan negara-negara yang benar-benar menerapkan UU perlindungan konsumen. Disana ada aturan pemerintah (melalui bank sentralnya) yang mengharuskan setiap bank untuk memiliki live backup site yang secara geografis terpisah jauh dan siap diujicoba disaster 2 kali setahun. Kalo sudah begini, mau tak mau hanya MF pilihannya.

Topik-topik terkait

• Komputer Mainframe
• OS Mainframe
• Mengoptimasi z/OS
• Downsize – Manfaat apa Mudharat? 
• Mainframe z/Enterprise, Cara Jitu Beternak Server
• Capacity Planning untukVirtualisasi
• Mainframe Solusi Paling Jitu untuk e-Gov
• Web Server Sederhana Berbahanbaku Rexx untuk z/OS
• Virtualisasi dengan z/VM makin Heboh

1. Awan Cumulonimbus Hadir di Jagat IT