Friday, April 10, 2015

Implementasi SPF, DKIM, DMARC dan Reverse DNS Sebagai Standard Protection dan Meningkatkan Email Integrity

Ketika kita membangun sebuah email server sering kita lupa bahwa ada konfigurasi tambahan yang harus kita lakukan. Konfigurasi ini termasuk kategori penting loh sebab ini terkait integritas email system yang telah kita bangun, pertanyaannya itu seberapa penting sih? 

Banyak Email System saat ini terutama seperti Gmail, Yahoo, AOL, sampe Email System Perbankan (Bank-Bank) biasanya sangat memperhatikan paramater-parameter seperti SPF, DKIM, DMARC, dan Resolve DNS yang digunakan oleh si pengirim email. Kenapa sih kok ribet amat yah? Itu karna mereka mengeluarkan banyak tenaga untuk bertarung melawan spam dan email spoofing. Inilah kenapa sebabnya biasanya paket email yang tidak terdapat SPF, DKIM, DMARC bahkan yang Resolve DNS nya kurang baik konfigurasinya sering dianggap spam dan lebih parahnya lagi bahkan di DROP oleh email system penerima.

By the way untuk tulisan ini best practicenya menggunakan platform zimbra. Namun, kudu diinget meskipun saya sebelumnya pernah berguru sama salah satu jagoan email server dgn platform zimbra di Indonesia, bukan berarti bahwa standard yang saya tulis ini hanya untuk platform zimbra saja, namun sebenernya juga untuk semua platform. Artinya ketika selesai mendeploy sebuah email system jangan cuma intinya bisa kirim dan terima email saja, sebaiknya jangan lupa juga tambahkan konfigurasi lainnya untuk meningkatkan proteksi dan juga email integrity, antara lain yaitu sebagai berikut ini :
  • Sender Policy Framework (SPF).
  • Domain Keys Identified Mail (DKIM).
  • Domain-Based Message Authentication, Reporting & Conformance (DMARC).
  • Reverse DNS.

Berikut beberapa penjelasan singkat termasuk best practice untuk membangun standard proteksi dan memperbaiki reputasi serta email integrity di email system yang kita bangun. Nah best practicenya baru mengacu pada platform zimbra nih hehe...

Sender Policy Framework (SPF)
Sender policy framework adalah sebuah email validation system yang sebenernya di desain untuk mencegah spoofing. Cara kerja SPF cukup sederhana yaitu SPF akan melakukan verifikasi Source IP dari email yang dikirim lalu mencocokannya dengan DNS TXT record menggunakan SPF content.
Dibawah ini kira-kira merupakan flow gimana kira-kira SPF bekerja.


Penjelasan :
Nah kalo dari flow diatas terlihat bahwa email system yang menerima email akan mengecek Sender-ID Framework dari tiap-tiap email yang mereka terima dengan cara menanyakan SPF record si pengirim email ke DNS.  Nah hasilnya hanya ada dua yaitu Pass atau Fail, apabila pass maka email biasanya akan di redirect ke folder inbox penerima dan apabila fail maka email akan diredirect ke folder Junk/Quarantine bahkan yang lebih parahnya lagi bisa saja di drop.
Sebenernya ada juga status selain Pass dan Fail yaitu neutral. Kalo statusnya neutral ada beberapa kemungkinan bisa saja masih menunggu propagasi DNS atau memang sudah di konfigurasi namun namun memang si admin menginginkan implementasi SPF tanpa policy.
Apa dampaknya kalo kita enggak buat SPF di email system kita? Biasanya kalo si penerima memang agak strict ya email kita di anggap spam bahkan bisa aja di drop karna dianggap tidak trusted.

Konfigurasi SPF?
Setelah saya ceritain dulu konsep SPF biar paham jadi gak cuma bisa konfig doang hehe, maka selanjutnya kita masuk ke proses konfigurasi SPF. Konfigurasinya standardnya sih sebenernya mudah kok, mungkin untuk beberapa kasus yang custom baru sedikit lebih rumit cuma saya coba share yang standard yah..

Format
"v=spf1 a mx include:servermta.domain.com ~all"

Contoh
"v=spf1 a mx include:mail.example.com ~all"

Kalo agan pake WHM contohnya seperti dibawah ini.


Notes :
  • Saya merahin karna pake domain orang, yang saya merahin seharusnya adalah nama domain agan. Nah yang saya kasih tanda panah isi dengan server mta yang sudah di isi dengan A Record di DNS agan.
  • Sebagai catatan tambahan aja kalo masih gak ngerti ~all, -all, ?all, +all bisa liat tabel dibawah ini.

Nah kalo sudah selesai agan tinggal nunggu propagasi DNS paling lama 1-2 hari. 

Pengecekan SPF
Kalo propagasi DNS sudah selesai agan bisa test SPF internet seperti mxtoolbox.com disini. Setelah itu cari box yang SPF lalu masukan domain agan. Kalo sudah selesai seharusnya hasil testing akan seperti dibawah ini.

Dan apabila agan coba ngirim email ke google dan show original code maka SPF akan terlihat pass.




Domain Keys Identified Mail (DKIM)
Domain keys adalah salah satu metode security pada email untuk mengasosiasikan domain name dengan email yang dikirim. Dengan adanya DKIM maka ini memungkinkan adanya proses signature pada masing-masing email yang dikirim oleh si pengirim dengan metode enkripsi asymetric dengan saling berbagi informasi mengenai public keys dan private keys yang digunakan.

Coba agan perhatikan gambar dibawah ini :

Penjelasan :
Nah dari gambar diatas terlihat bahwa MTA si pengirim mempublish public keys di DNS public lalu ketika proses pengiriman email terjadi, maka si penerima akan menggunakan public keys yang ada di DNS untuk mencocokan apakah match atau tidak, apabila match maka akan tertera bahwa email yang dikirim signed-by domain si pengirim.

Konfigurasi DKIM?
Konfigurasi DKIM lebih sedikit rumit daripada SPF namun enggak susah kok. Langkah-langkahnya itu adalah sebagai berikut ini, saya contohkan generate dengan zimbra yah.
  • Masuk ke server lalu masuk lagi ke user zimbra setelah itu cek dengan command ini "/opt/zimbra/libexec/zmdkimkeyutil -q -d contoh.com"
  • Kalau belum ada saatnya buat dengan format seperti dibawah ini :
    /opt/zimbra/libexec/zmdkimkeyutil -a -d example.com -s namadkim
  • Setelah selesai di generate maka akan muncul public key yang bisa di publish di DNS, agan bisa copas public key tersebut lalu buat lagi TXT record di DNS agan. Sebagai contoh hasil generate public key seperti dibawah ini :

    "v=DKIM1; k=rsa; "  "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2c4zVBYQtUsoeEGiqYKEZ7JLU3cbuQCOYvr+IDQJPOQjVlsSTapsu+4yUZ6OJ41RmzYQooneL+We1MMYDmGMAQmHNQAAfhoudLN/+aSC7ggo+rTAd4ipwMujgySB8SsKzKBeAFLth/WteAOrVMIfMrmNgKj0pLUfQp1sVpa1WGQIDAQAB"

    Hapus tanda-tanda petik diatas lalu coba copas ke website tools checker dkim di disini.
    Kalo hasilnya sudah seperti pada screenshot dibawah ini maka berarti DKIM untuk domain agan sudah berjalan.

  • Setelah selesai di cek copas key record yang sudah valid tsb ke WHM atau manajemen tools yang agan gunakan, buat TXT record yah. Sebagai contoh seperti dibawah ini :

Pengecekan DKIM
Untuk mengecek DKIM agan sudah berjalan atau belum agan bisa cek di link yang sama di dkimcore disini. Lalu masukan nama dkim yang agan generete tadi lalu domain seperti dikotak merah ini.


Kalo hasilnya sudah valid seperti gambar dibawah berarti DKIM anda sudah terecord di DNS.



Tinggal lanjutkan coba kirim email dari email agan ke google lalu cek parameter ini dan show original code, apabila sudah sesuai seperti dibawah ini harusnya DKIM sudah berjalan.

Show Original Code

Show Arrow Details


Keliatan kalo di original code bahwa dkim agan statusnya PASS dan di arrow details bisa dilihat signed-by nah yg garis merah seharusnya nama domain agan.
Kalo seperti ini lebih reliable dan trusted kan? hehe


Domain-Based Message Authentication, Reporting & Conformance (DMARC)
Selanjutnya kita membahas DMARC, sebenernya cara kerjanya hampir sama seperti dengan SPF namun metodenya dan fungsinya sedikit berbeda. Meskipun begitu nampaknya saat ini DMARC merupakan salah satu komponen penting juga yang kudu dikonfigurasi pada email system kita yang sudah established untuk meningkatkan email integrity.
DMARC sendiri adalah sebuah spesifikasi teknis yang dibuat oleh sekelompok organisasi yang ingin membantu mengurangi potensi penyalahgunaan email dengan metode email authentication protocol. Coba perhatikan cara kerjanya pada gambar dibawah ini.


Penjelasan :
DMARC melakukan standarisasi dengan mendeteksi bagaimana penerima email menjalankan autentikasi menggunakan mekanisme well-known SPF & DKIM yang telah ada di record DNS. Hal ini biasanya akan berdampak pada user experience pengirim email tersebut karna email yg dikirim akan menerima "Consistent Authentication Results" dari setiap penerima email mereka yg juga menjalankan mekanisme DMARC, yang jelas dengan menggunakan mekanisme ini komunikasi email yang terjadi antara pengirim dan penerima akan menjadi lebih reliable.

Konfigurasi DMARC?
Untuk melakukan konfigurasi DMARC sebaiknya lakukan dulu konfigurasi SPF dan DKIM di email system agan. Setelah itu agan bisa generate record untuk DMARC disini.

Nah coba isi parameter seperti contoh dibawah ini, lalu kalo sudah selesai tekan tombol "Get DMARC Record". Nama domain example.com ganti dengan nama domain masing-masing yah.


Dari policy diatas itu saya tentukan apabila status email paket fail maka akan di redirect ke quaratine. Sebenernya agan bisa juga pilih policy yang reject kalo mau lebih strict sih, cuma kekurangannya kita jadi gak bisa analisa aja itu email spam ato bukan karna langsung di drop emailnya. #CMIIW

Setelah dapet DMARC Record seperti gambar dibawah ini agan bisa masukan record yang ada di kotak merah dari gambar dibawah ini ke DNS agan, seperti biasa buat TXT record.


Copas record yang sudah di generate dari link diatas yg ada di kotak merah tsb lalu buat TXT Record di WHM ato cPanel ato DNS managemen agan lah pokoke seperti contoh gambar dibawah ini.


Kalo sudah selesai ketik OK/Apply Modification.

Pengecekan DMARC
Kamu bisa cek dari mxtoolbox.com disini lalu cari kotak box DMARC dan masukan domain agan, atau bisa juga di dmarcian.com disini dengan cara yang sama tinggal masukan domain agan. Sebagai contoh saya masukan domain google.com di mxtoolbox kalo domain agan yang dimasukan hasilnya sudah sesuai sama seperti gambar dibawah ini maka seharusnya mekanisme DMARC sudah berjalan di email system agan.


Agan bisa cek juga dengan kirim email ke gmail misalnya lalu di "Show Original Code" cari parameter DMARC, apabila sudah PASS seperti gambar dibawah ini artinya sudah berjalan nih mekanisme DMARC di email system agan.



Reverse & Resolve DNS
Sepertinya banyak engineer dan sysadmin yang kurang aware juga untuk hal yang satu ini, di beberapa email system yang sudah strict banged ada loh biasanya yang mereject pengirim email yang tidak memiliki Reverse DNS yang konsisten.
Gambaran proses untuk Resolve DNS bisa dilihat dari gambar dibawah ini.


Setelah liat gambar diatas harusnya dapet yah gambarannya? Kalo Resolution DNS itu menentukan IP Address yang diasosiasikan ke domain name, sedangkan kalo Reverse DNS itu sebaliknya Domain yang diasosiasikan ke IP Address.

Konfigurasi Reverse DNS?
Cara satu-satunya itu cuma bisa minta tolong ISP di tempat dimana agan berlangganan. Bilang aja ke mereka kalo kita punya IP Public pengen bikin PTR Record yang dipointing ke domain A dengan IP Public yang digunakan B, sesimple itu kok hehe.
Setelah itu jangan lupa edit SMTP Helo agan, kalo di zimbra bisa menggunakan command dibawah ini.

Perhatikan bahwa mail.example.com ganti dengan nama mx record yg digunakan di DNS agan yah.

Version 8.0.X
zmlocalconfig -e postfix_smtpd_banner="mail.example.com"
zmcontrol restart

Version 8.5 keatas
zmprov ms  `zmhostname` zimbraMtaSmtpdBanner mail.example.com
zmcontrol restart

Pengecekan Reverse DNS
Caranya gampang gan, tinggal pake mxtoolbox.com aja menggunakan link disini. Lalu agan tinggal masukan IP Address yang agan gunakan sebagai mail server agan yg juga digunakan sebagai MX Record. Kalo sudah sesuai artinya sudah tidak ada issue lagi dan dengan cara ini pastinya email integrity dari email system kita akan naik di pihak penerima email.


Done! 
Lumayan panjang yah? Namanya juga catetan pribadi, semoga bermanfaat terutama buat diri saya pribadi hehehe.....

Thursday, April 9, 2015

Implementasi High Availability VMware vSphere

Sekalian bikin catetan pribadi, saya sekalian mau coba share gimana cara implementasi High Availability di vSphere. VMware vSphere yg saya gunakan kebeneran masih versi 5.5 karna masih males upgrade di kosan ke 6.0 haha.

Karna niatnya catetan pribadi saya cuma mau bahas cara konfignya aja yang simpel sebenernya, jadi kalo mau tau konsep HA bisa baca tulisan saya sebelumnya disini.
Selain itu HA itu banyak sekali model implementasinya terutama admission control yang digunakan harus disesuaikan dengan kebutuhan agan.

OK langsung aja topologi yang saya gunakan kira2 seperti dibawah ini.


Keterangan 
Dalam environment diatas terdapat dua VM yang ada di host 192.168.99.10 dan VM tersebut menggunakan NFS Storage.

Kalo agan masih bingung gimana cara bikin NFS Storagenya bisa baca disini.
Nah syarat simpel untuk implementasi ini itu intinya ialah :
  • Host udah dimanage dengan vCenter
  • Virtual Machine ada di dalam shared storage
  • Usahakan bikin vmkernel port untuk vMotion link.

Nah, kalo environment sudah ready seperti diatas agan bisa langsung akses vCenter server melalui web agan. Kalo pada case diatas saya akses melalui https://192.168.99.11:9443

Langkah Pertama, Buat Cluster
Kalo sudah dibuka, kamu bisa pilih tab vCenter > Host and Clusters, akan muncul gambar seperti dibawah ini. Digambar tersebut sudah dibuat datacenter virtual bernama Latihan


Nah klik kanan di tab Latihan lalu pilih New Clusters


Akan muncul gambar seperti dibawah ini, agan kasih nama cluster agan lalu centang turn on HA.
Agan bisa ikuti seperti pada gambar dibawah ini.


Nah sepengetahuan saya itu kalo dari konfigurasi diatas, apabila agan pilih "Percentage of cluster resources reserved as failover spare capacity" itu berarti di dalam cluster akan direserved resources untuk Memory 25% dan CPU 25% untuk process failover.
(Untuk admission control yg lainnya mungkin akan saya tulis lain kali kalo ada waktunya hehe)..

Tekan OK apabila sudah selesai, cluster dengan nama Testing HA telah berhasil dibuat seperti gambar dibawah ini.



Langkah Kedua, Masukan Host Ke Dalam Cluster

Nah di lab ini ada dua host yaitu vSphere1(192.168.99.9) dan vSphere2(192.168.99.10) masukan kedua host tersebut kedalam cluster dengan hanya mendrag lalu drop.

Drag n drop host 192.168.99.10 kedalam cluster.



Drag n drop host 192.168.99.9 kedalam cluster.


Tunggu proses sampai selesai..

Langkah Ketiga, Testing Apakah HA Berjalan?

Untuk melakukan testing relatif cukup mudah, agan bisa tinggal melakukan ping saja ke masing2 VM dalam kasus diatas VM menggunakan IP 192.168.99.101 dan 192.168.99.102.

Namun sebelumnya cek dulu beberapa hal dibawah ini :
  • Host mana yang menjadi master? Agan bisa cek dengan klik host lalu summary, dalam LAB  kita ini kebeneran yang menjadi master adalah host 192.168.99.10

  • Lalu cek dimana masing2 VM berjalan, nah bisa cek vm1-1 dan vm2-1 berjalan di host mana? Dalam lab ini kedua VM berjalan di atas host 192.168.99.10.


Nah karna kita sudah tahu bahwa kedua VM berjalan diatas host 192.168.99.10 dan host itupun berjalan sebagai master saatnya kita test. Agan bisa shutdown host tersebut dari vCenter agan sambil ping ke masing2 Virtual Machine yaitu vm1-1(192.168.99.101) dan vm2-1 (192.168.99.102).


Sekarang agan coba Shutdown host 192.168.99.10, ikuti langkah seperti dibawah ini.



Pada tab reason ketik saja testing HA lalu klik OK.

Nah sekarang Host 192.168.99.10 sudah mati, kalo diliat dari vCenter server juga akan terlihat seperti dibawah ini.


Nah kalo coba di ping kedua Virtual Machine responsenya adalah destination unreachable yang menandakan tidak ada respon dari si vm tsb, tunggu sampai sekitar 1-3 menit sampe kedua VM tsb UP kembali.


Tunggu sampai UP lagi seperti gambar dibawah ini.



Nah kalo sudah up agan bisa cek ke vCenter agan siapa sekarang yang menjadi master host? Seharusnya adalah host master saat ini adalah 192.168.99.9, lalu coba cek masing2 Virtual Machine seharusnya kedua vm tersebut saat ini akan berada di host 192.168.99.9 seperti gambar dibawah ini.



Nah gimana mudah kan? Selamat mencoba yah semoga berguna catetan saya ini buat agan hehe..

Friday, April 3, 2015

High Availability Cluster CentOS Menggunakan Heartbeat

Pada lab kali ini saya mau share sedikit implementasi sederhana cluster menggunakan heartbeat di CentOS, percobaan ini dilakukan untuk melakukan cluster pada service httpd.
Topologi yang akan kita gunakan adalah seperti dibawah ini :


Kalo masih bingung, Virtual IP Address adalah IP yang dibentuk oleh heartbeat. Heartbeat sendiri adalah program yang menjalankan special script yang biasanya mengirim signal ke node lain untuk saling mengkontrol dan berkomunikasi satu dengan yang lainnya. 

Metode yang digunakan adalah Active-Standby/Master-Slave, apabila ada satu node master mati maka heartbeat bertugas untuk memberi tahu node yang standby/slave untuk segera mencover si node master tsb. Langsung aja yah dibawah ini konfigurasinya :

Notes :
- Di lab ini konfigurasi IPTABLES dan Selinux dalam keadaan disabled.

Konfigurasi

Pastikan hostname di masing2 node sudah benar.
[root@web1 ~]# uname -n
web1

[root@web2 ~]# uname -n
web2

Tambahkan konfigurasi di /etc/hosts di masing2 node.
[root@web1 ~]# vi /etc/hosts
#tambahkan ini 
192.168.99.91 web1
192.168.99.92 web2

[root@web2 ~]# vi /etc/hosts
#tambahkan ini 
192.168.99.91 web1
192.168.99.92 web2

Install package di masing2 node adalah sebagai berikut ini.
[root@web1 ~]# rpm -Uvh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
[root@web1 ~]# yum --enablerepo=epel install heartbeat; yum install httpd -y

[root@web2 ~]# rpm -Uvh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
[root@web2 ~]# yum --enablerepo=epel install heartbeat; yum install httpd -y

Matikan service httpd ketika boot dengan command chkconfig httpd off, hal ini karna httpd akan dinyalakan oleh heartbeat ketika booting.

[root@web1 ~]# chkconfig httpd off

[root@web2 ~]# chkconfig httpd off

Heartbeat yang terinstall di web server saya adalah versi heartbeat-3.0.4, setelah heartbeat di install maka pindahkan tiga file (ha.cf, authkeys, haresources) ini ke /etc/ha.d/.

[root@web1 ~]# cp /usr/share/doc/heartbeat-3.0.4/authkeys /etc/ha.d/; cp /usr/share/doc/heartbeat-3.0.4/ha.cf /etc/ha.d/; cp /usr/share/doc/heartbeat-3.0.4/haresources /etc/ha.d/

[root@web2 ~]# cp /usr/share/doc/heartbeat-3.0.4/authkeys /etc/ha.d/; cp /usr/share/doc/heartbeat-3.0.4/ha.cf /etc/ha.d/; cp /usr/share/doc/heartbeat-3.0.4/haresources /etc/ha.d/

Sekarang mulai konfigurasi heartbeat, dimulai dengan konfigurasi di authkeys.
[root@web1 ~]# vi /etc/ha.d/authkeys
#tambahin konfig ini
auth 2
2 sha1 test-ha

Jangan lupa, ganti permission file ini agar hanya root saja yang bisa ganti2 konfig di file ini
[root@web1 ~]# chmod 600 /etc/ha.d/authkeys

Lalu lanjut konfigurasi di di ha.cf yang merupakan part terpenting, edit file ha.cf sbb.
[root@web1 ~]# vi /etc/ha.d/ha.cf
##tambahin konfig ini
logfile /var/log/ha-log ##(buat logging file)
logfacility local0 ##(severity log)
keepalive 2 ##(keepalive parameter 2s)
deadtime 30 ##(deadtime timer 30s)
initdead 120 ##(initdead timer 120s)
bcast eth0 ##(broadcast interface yg digunakan)
udpport 694 ##(port yang digunakan 694 udp)
auto_failback on ##(auto failback)
node web1 ##(node 1 yaitu web1)
node web2 ##(node 2 yaitu web2)

Terakhir adalah haresources file, kita isi sbg informasi master node dan virtual ip address yg digunakan.
[root@web1 ~]# vi /etc/ha.d/haresources
##tambahin konfig ini
web1 192.168.99.93 httpd

Biar cepet, copy ketiga file atau semua file yang ada di /etc/ha.d di web1 ke web2.
[root@web1 ~]# scp -r /etc/ha.d/ root@web2:/etc/


Setelah itu, konfigurasi file httpd.conf dengan mengubah parameter dibawah ini.
[root@web1 ~]# vi /etc/httpd/conf/httpd.conf
##standarnya adalah 'Listen 80', ubah parameter listen menjadi seperti dibawah ini##
Listen 192.168.99.93:80

Biar cepet juga, copy file httpd.conf di web1 ke web2.
[root@web1 ~]# scp /etc/httpd/conf/httpd.conf root@web2:/etc/httpd/conf/

Buat index file di masing2 node, biar keliatan bedanya saya bedain isinya di masing2 index.html.
[root@web1 ~]# echo "konten di web1" > /var/www/html/index.html

[root@web2 ~]# echo "konten di web2" > /var/www/html/index.html


Sekarang start heartbeat kamu, inget start hearbeatnya aja gak usah start httpdnya. Nanti yang bertugas jalanin httpdnya adalah aplikasi heartbeatnya.

[root@web1 ~]# /etc/init.d/heartbeat start
Starting High-Availability services: INFO:  Running OK
CRITICAL: Resource 192.168.99.91 is active, and should not be!
CRITICAL: Non-idle resources can affect data integrity!
info: If you don't know what this means, then get help!
info: Read the docs and/or source to /usr/share/heartbeat/ResourceManager for more details.
CRITICAL: Resource 192.168.99.91 is active, and should not be!
CRITICAL: Non-idle resources can affect data integrity!
info: If you don't know what this means, then get help!
info: Read the docs and/or the source to /usr/share/heartbeat/ResourceManager for more details.
CRITICAL: Non-idle resources will affect resource takeback!
CRITICAL: Non-idle resources may affect data integrity!
Done.

[root@web2 ~]# /etc/init.d/heartbeat start
Starting High-Availability services: INFO:  Running OK
CRITICAL: Resource 192.168.99.92 is active, and should not be!
CRITICAL: Non-idle resources can affect data integrity!
info: If you don't know what this means, then get help!
info: Read the docs and/or source to /usr/share/heartbeat/ResourceManager for more details.
CRITICAL: Resource 192.168.99.92 is active, and should not be!
CRITICAL: Non-idle resources can affect data integrity!
info: If you don't know what this means, then get help!
info: Read the docs and/or the source to /usr/share/heartbeat/ResourceManager for more details.
CRITICAL: Non-idle resources will affect resource takeback!
CRITICAL: Non-idle resources may affect data integrity!
Done.

Testing Apakah Cluster Heartbeat Sudah Berjalan? 

Coba akses Virtual IP Address http://192.168.99.93 dari browser agan.
Output seharusnya adalah "konten di web1"



Sekarang untuk ngetes apakah cluster berjalan dengan baik coba matikan service heartbeat di web1 atau kalo mau ekstrem coba reboot/shutdown web1 lalu akses lagi  http://192.168.99.93
Output seharusnya adalah "konten di web2"


Done!
Semoga bermanfaat.

Wednesday, April 1, 2015

Cloning Virtual Machine di VMware vSphere Melalui vSphere Client (Tanpa vCenter)

Cloning adalah proses mengcopy virtual machine yang sudah ada menjadi virtual machine yang baru dengan state dan konfigurasi yang sama. Karna virtual machine sebenarnya merupakan sebuah file maka sebagai administrator kita dapat dengan mudah mencopy virtual machine untuk kebutuhan tertentu, yang perlu kamu ingat bahwa proses cloning bisa dilakukan dengan 2 cara yaitu :

  • Cloning dari vSphere-Client.
  • Cloning dari vCenter Server apabila host sudah di manage dengan vCenter.

Nah di lab kali ini saya bakal coba demonstrasiin gimana caranya cloning virtual machine dari vSphere client, di lab ini virtual machine yang akan di clone adalah vm1 menjadi vm2.
Posisi awal sebelum vm1 di clone adalah seperti dibawah ini, vm1 akan kita coba cloning menjadi vm2..

  • Langkah pertama, remote host dengan vsphere client lalu ke tab configuration - storage.

  • Klik kanan di datastore lalu browse datastore.

  • Akan muncul tampilan seperti dibawah ini, lalu klik tab create new folder.
  • Buat folder baru dengan nama vm2.

  • Buka folder vm1, cari file dengan format .vmx dan .vmdk.

  • Klik kanan lalu copy kedua file tersebut.

  • Masuk ke folder vm2 lalu paste .vmx dan .vmdk


  • Setelah proses paste selesai di folder vm2, selanjutnya klik kanan di file vm1.vmx lalu pilih add to inventory.

  • Agan bisa isi form selanjutnya yaitu untuk nama vm hasil cloning, mau di taro di resource pool mana setelah selesai klik finish seperti gambar dibawah ini.

        Agan bisa isi nama vm name sesuai dengan nama vm yang agan mau.



        Agan pilih resource pool yang agan inginkan, pilih host sesuai yang kita mau.



        Apabila agan sudah selesai klik finish untuk complete.

Nah kalo sudah di add ke inventory seharusnya akan ada vm baru di inventory vsphere agan.



Dari gambar diatas kelihatan ada vm baru yaitu vm2 sebagai hasil cloning dari vm1.

Semoga bermanfaat yah.. :)