Saya terlibat dalam suatu diskusi menarik dengan sejumlah rekan kerja beberapa hari yang lalu. Ketika itu, saya diminta untuk memberikan saran seputar pendekatan teknis hingga high level design terkait rencana implementasi konsep active-active data center pada salah satu customer yang bergerak dibidang service provider. Dalam diskusi tersebut, setidaknya terdapat 3 data center yang akan saling terhubung dimana 2 data center diantaranya bertindak sebagai data center aktif dan selebihnya ditujukan sebagai shared recovery site atau DRC.
Setelah melihat sejumlah requirement bisnis yang ada, saya melihat jika pendekatan teknis melalui teknologi vSphere Metro Storage Cluster (vMSC) dinilai lebih tepat untuk memastikan tingkat ketersediaan diantara 2 data center aktif yang ada. Berhubung customer bersangkutan menggunakan juga menghadirkan layanan cloud (IaaS) berbasis vCloud Director kepada pengguna akhirnya, maka pertanyaan berikutnya adalah bagaimana memastikan ketersediaan terhadap layanan tersebut.
Khusus untuk implementasi stretched cluster seperti yang terjadi pada (Metro Storage Cluster) tentunya hal ini tidak akan menjadi kendala berarti (setidaknya dari sisi infrastruktur virtual dimana 2 data center aktif tersebut akan tergabung dalam satu logical data center didalam instance management vCenter Server yang sama). Selanjutnya vCenter Server dimasukkan sebagai salah satu resource (baca: Provider Virtual Data Center) yang dikelola dalam suatu vCloud Director Cell. Dalam kondisi demikian, perlindungan terhadap ketersediaan aplikasi atau workload yang berjalan diatas konfigurasi tersebut, selanjutnya dapat ditangani oleh fitur vSphere HA yang terintegrasi solusi virtualisasi server dari VMware (dalam hal ini VMware vSphere).
Diagram konfigurasi vMSC Uniform
(Image courtesy to VMware)
Namun, pertanyaan berikutnya yang juga muncul dalam diskusi tersebut adalah bagaimana pendekatan teknis yang dapat ditempuh untuk memastikan tingkat ketersediaan dapat tetap terjaga untuk kondisi dimana opsi active-active data center menjadi tidak tersedia (dikarenakan keterbatasan dari sisi limitasi infrastruktur yang tersedia). Artinya hanya terdapat 1 data center utama (aktif) dan 1 Recovery Site. Atau, user case lainnya misalnya ketika terdapat business requirement terkait penyediaan shared recovery site terhadap stretched data center (atau active-active data center) yang telah terbentuk sebelumnya.Dalam hal ini, yang menjadi fokus pembahasan terkait proteksi ketersediaan dimaksud adalah bagaimana memastikan workload yang berjalan atau dikelola oleh vCloud Director Cell dapat dipulihkan ketika kondisi bencana (misalnya) terjadi pada sisi data center utama.
Tantangan dalam menjaga Tingkat Ketersediaan vCloud Director
Perlu diketahui bahwa baik vCloud Director maupun vCenter Server sangat bergantung pada informasi Management Object Reference Identifiers (MoRef IDs) dalam menghubungkan atau mengkorelasikan objek diantara kedua platform tersebut. Setiap perubahan yang dilakukan tanpa perencanaan terhadap informasi identifier tersebut akan mengakibatkan objek tersebut tidak lagi dapat dikelola atau dikenali oleh vCloud Director. Tentunya penggunaan solusi management DRC seperti VMware Site Recovery Manager (SRM) akan mengakibatkan perubahan terhadap informasi MoRef ID pada tingkatan vCenter Server ketika objek tersebut (misalnya virtual machine) menjalani proses recovery menuju secondary data center. Hal ini tentunya menjadikan objek tersebut menjadi tidak lagi dikenali atau dikelola dari perspektif vCloud Director.
Setelah merujuk pada sejumlah artikel maupun white paper terkait dari VMware, saya berkesimpulan jika terhadap kondisi diatas proteksi melalui solusi manajemen DRC seperti VMware Site Recovery Manager (SRM) masih menjadi lebih opsi yang paling tepat untuk case seperti ini.
Sekalipun pada versi 6.5 terbaru yang telah hadir beberapa waktu yang lalu, SRM telah menghadirlam sejumlah improvement yang signifikan, namun use case seputar proteksi terhadap objek vCloud masih relatif terbatas. Hal ini memang telah tertuang dalam release notes dari VMware SRM 6.5. Secara garis besar, SRM hingga sejauh ini masih belum dapat digunakan untuk memproteksi objek (dalam hal ini virtual machine) yang berjalan diatas resource pool dari vCloud.
Namun demikian, modul SRM masih mendukung proteksi terhadap struktur management yang terdapat didalam vCloud Director. Hal ini menunjukkan bahwa modul SRM masih dapat diterapkan dengan pendekatan active/standby DR (dimana sisi recovery site ‘tidak digunakan’ pada kondisi normal).
Melalui dokumen white paper VMware vCloud Director Infrastructure Resiliency Case Study, VMware telah menjelaskan secara spesifik terkait pendekatan yang dimaksud. Dari sisi high level architecture, pendekatan teknis tersebut menghendaki adanya setidaknya 2 sistem vCenter Server pada sisi protected site atau data center utama dimana masing-masingnya dimaksudkan untuk tujuan berikut.
- 1 instance vCenter Server didedikasikan untuk mengelola workload seputar management modules (atau management cluster), serta
- 1 instance vCenter yang ditujukan untuk mengelola workload utama atau production dari vCloud
Modul SRM Server yang terinstall pada masing-masing site nantinya akan dipasangkan dengan vCenter Server yang mengelola management modules pada masing-masing site. SRM server tentunya akan berperan dalam mengorkestrasi mekanisme failover atau recovery antar site yang tidak hanya mencakup workload pada sisi production namun juga sebagian management modules yang terdapat didalam Management Cluster (termasuk vCloud Director Cell).
Diagram gambaran umum Management Cluster
(Image courtesy to VMware)
Pendekatan seperti ini juga tentunya memastikan setiap objek vCloud (seperti virtual machine) yang dikelola pada data center utama akan tetap ditangani oleh instance vCloud Director dan vCenter Server production yang sama ketika dipulihkan pada sisi recovery site. Hal ini sekaligus memastikan bahwa informasi MoRef ID dari objek vCloud tersebut akan tetap terjaga sehingga memastikannya dapat dikelola dengan baik oleh vCloud Director.