Dalam dunia jaringan komputer, setiap komputer yang terhubung dalam sebuah jaringan memiliki sebuah identitas yang unik berupa IP address atau berupa hostname. IP address adalah serangkaian segment angka desimal (atau heksadesimal pada IPv6) yang menunjukkan jaringan mana sebuah komputer terhubung. Contoh dari IP address misalnya 192.168.0.1 di mana 192.168.0 menunjukkan jaringan, dan 1 menunjukkan identitas komputer yang dimaksud. Sedangkan hostname atau machine name merupakan alias dari sebuah mesin komputer. [1]
Fully Qualified Domain Name (FQDN) adalah domain name yang lengkap untuk mereferensi sebuah komputer yang berada di Internet [2]. FQDN membutuhkan naming service seperti DNS untuk me-resolve hostname mapping ke IP address. Contoh dari FQDN misalnya dev.nostratech.com di mana dev merupakan machine name dan nostratech.com merupakan domain name tempat mesin dev tersebut terhubung. [2]
Ketika tahap development, umumnya kita hanya diberikan informasi IP address karena infrastruktur DNS belum/tidak ada pada development environment. Sehingga kita menggunakan IP address tersebut sebagai penanda identitas server address pada konfigurasi aplikasi. Ketika deployment ke production, barulah konfigurasi IP address tersebut diganti menjadi IP address production atau hostname yang sudah ditetapkan.
Pada dasarnya
alur kerja seperti ini tidak akan bermasalah, namun terkadang saya
menemui aplikasi seperti Oracle Enterprise Manager 12c yang tidak mau
di-install jika menggunakan IP address. Aplikasi tersebut mengharapkan
FQDN sebagai server address yang ter-register. Masalah lain juga pernah saya temui ketika perlu membuat development environment yang merupakan clone dari production environment, di mana salah satu SOA composite deployment me-refer ke IP address dari production environment sedangkan development environment berada di beda jaringan dengan production. Bagaimana cara mengatasinya dengan kondisi yang terbatas seperti itu?
Satu hal yang mulai saya biasakan ketika membuat development environment adalah dengan membuat entry hostname di file /etc/hosts server. Jika memang DNS service belum tersedia di environment, saya gunakan hostname untuk server address pada konfigurasi aplikasi dan meng-update file /etc/hosts dengan IP address yang sesuai. Keuntungan dari metode ini adalah jika suatu ketika dari tim jaringan ada perubahan topologi atau mapping IP address, tidak ada perubahan yang harus dilakukan di sisi aplikasi. Satu-satunya perubahan yang perlu dilakukan adalah mapping hostname-IP address pada file /etc/hosts di masing-masing server.
Hostname sendiri bisa dibagi menjadi 2 tipe hostname, yaitu physical hostname dan virtual hostname. Physical hostname adalah hostname yang merupakan mapping dari physical IP address (koneksi kabel fisik) sebuah server, sedangkan virtual hostname adalah hostname yang merupakan mapping dari virtual IP address (software-based IP address) sebuah server. Saya mulai mengetahui adanya kedua tipe ini ketika saya mulai mempelajari dokumentasi Oracle. Pada dokumentasi tersebut nampak ada 4 physical hosts, yaitu SOAHOST1, SOAHOST2, BAMHOST1, dan BAMHOST2. Physical IP address pada dokumentasi adalah IP1, IP2, dan IP3; sementara VIP1, VIP2, VIP3, VIP4, dan VIP5 adalah virtual IP address-nya. Berikut adalah diagram yang saya capture pada dokumentasi Oracle tersebut: [3]
IP dan Virtual IP assignment pada dokumentasi Oracle |
Setelah memperhatikan dan mulai mengikuti network plan dari Oracle, saya mulai membiasakan untuk melakukan strategi hostname berikutnya yaitu dengan menggunakan virtual hostname untuk server address yang dipanggil dalam operasi yang sifatnya internal atau transparan dari sisi pengguna. Misalnya, ketika ingin mengacu ke database server address yang memiliki physical hostname db1-dev.nostratech.com, maka gunakan virtual hostname appdb. Keuntungan dari strategi ini adalah konfigurasi yang sama dapat digunakan di environment yang berbeda tanpa harus mengubah hostname pada konfigurasi. Namun ada pengecualian seperti pada kasus Oracle Database RAC di mana harus menggunakan DNS service untuk me-register ke-3 FQDN milik RAC.
Ketika membuat disaster recovery site atau kloning dari production environment, dokumentasi Oracle menyarankan untuk menggunakan alias hostname pada mesin target. Misalnya, di production environment server address untuk database server adalah proddb1.nostratech.com, maka entry /etc/hosts yang diperlukan di production site dan disaster recovery site adalah sebagai berikut: [4]
# Production Site
192.168.1.100 proddb1.nostratech.com proddb1 dbnode1.nostratech.com dbnode1
# Disaster Recovery Site
192.168.100.100 proddb1.nostratech.com proddb1 stbydbnode1.nostratech.com stbydbnode1
# Development Site
192.168.99.100 proddb1.nostratech.com proddb1 devdbnode1.nostratech.com devdbnode1
# Site X Format
# IP_ADDRESS ALIAS_WITH_DOMAIN ALIAS HOSTNAME_WITH_DOMAIN HOSTNAME
Jadi, kesimpulan dari strategi hostname yang bisa saya usulkan adalah:
- Jangan pernah menggunakan IP address dalam melakukan konfigurasi server address, kecuali jika memang aplikasi tersebut hanya dapat menggunakan IP address.
- Bedakan antara physical hostname dengan virtual hostname yang akan digunakan oleh aplikasi untuk lebih mendukung portabilitas konfigurasi.
- Manfaatkan file /etc/hosts di masing-masing server untuk server address yang sifatnya internal operation yang tidak perlu di-ekspose ke pengguna aplikasi, misalnya database server address, WebLogic virtual hostname, dan server address lainnya yang tidak perlu di-entry di DNS service.
- Gunakan DNS service hanya pada server address yang sifatnya harus diakses langsung dari client. Jika DNS service belum tersedia, manfaatkan kembali file /etc/hosts pada client dan server.
- Pastikan eksternal server address yang akan menjadi address yang diakses oleh client dalam bentuk FQDN.
- Gunakan alias hostname ketika ingin membuat disaster recovery site untuk meminimalkan konfigurasi yang perlu dilakukan pada kedua site (production dan disaster recovery site).
Daftar Pustaka:
[1] Massachusetts Institute of Technology Knowledge Base
[2] Indiana University Knowledge Base
[3] Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite
[4] Oracle Fusion Middleware Disaster Recovery Guide
No comments:
Post a Comment