Ketersediaan Tinggi dan Pemulihan Bencana

Pusat Sistem – Server dan fitur Manajer Operasi berpotensi gagal, memengaruhi fungsionalitas Manajer Operasi. Jumlah data dan fungsionalitas yang hilang selama kegagalan berbeda dalam setiap skenario kegagalan. Ini tergantung pada peran fitur yang gagal dan lamanya waktu yang diperlukan untuk memulihkan fitur yang gagal.

Ketersediaan tinggi

Kebutuhan ketersediaan tinggi ditangani dengan membangun redundansi ke dalam grup manajemen untuk database operasional Manajer Operasi dan gudang data, gateway dan server manajemen, dan beban kerja tertentu. Beban kerja ini termasuk pemantauan perangkat jaringan, pemantauan lintas platform, dan beban kerja khusus grup manajemen yang sebelumnya dikelola oleh Server Manajemen Akar.

Beberapa server, konfigurasi grup manajemen tunggal dapat menggunakan SQL Server Always On untuk menyediakan ketersediaan tinggi dan kelangsungan layanan database Operations Manager. Toleransi kesalahan server manajemen disediakan dengan memiliki setidaknya dua server manajemen dan dengan menggunakan kumpulan sumber daya untuk memantau server UNIX, server Linux, dan perangkat jaringan. Server Windows berbasis agen dapat dikonfigurasi dengan server manajemen primer dan sekunder untuk mengalihkan komunikasi agen jika server manajemen gagal.

Emulator RMS juga dapat dipindahkan ke server manajemen lain jika server manajemen yang menghosting Emulator RMS menjadi tidak tersedia.

Koneksi konsol operasi dapat dibuat sangat tersedia dengan mengonfigurasi ketersediaan tinggi untuk Layanan Akses Data. Ini dapat dilakukan dengan menginstal Microsoft Network Load Balancing (NLB) atau menggunakan load balancer berbasis perangkat keras atau alias DNS. Satu atau beberapa server manajemen ditambahkan sebagai anggota kumpulan NLB dan ketika membuka konsol, Anda merujuk pada nama virtual yang terdaftar di DNS dari server manajemen penyeimbang beban.

Beberapa server gateway dapat disebarkan di seluruh batas kepercayaan untuk menyediakan jalur redundan untuk agen yang terletak di seluruh batas kepercayaan tersebut. Sama seperti agen dapat melakukan failover antara server manajemen utama dan satu atau beberapa server manajemen sekunder, mereka juga dapat melakukan failover di antara server gateway. Selain itu, beberapa server gateway dapat digunakan untuk mendistribusikan beban kerja pengelolaan komputer yang dikelola tanpa agen dan perangkat jaringan terkelola.

Selain menyediakan redundansi melalui failover gateway agen, server gateway dapat dikonfigurasi untuk melakukan failover di antara server manajemen dalam suatu kelompok manajemen apabila tersedia beberapa server manajemen.

Meskipun SQL Server Reporting Services mendukung model penerapan skala keluar yang memungkinkan Anda menjalankan beberapa instans server laporan yang berbagi satu database server laporan, penerapan ini tidak didukung oleh Operations Manager. Operations Manager Reporting menginstal ekstensi keamanan kustom dalam penyiapan komponen front-end, yang tidak dapat direplikasi di seluruh farm web.

Pemulihan bencana

Pemulihan bencana berkaitan dengan langkah-langkah yang diambil untuk memastikan bahwa operasi dapat dilanjutkan jika kegagalan bencana (misalnya, hilangnya seluruh pusat data yang menghosting infrastruktur utama). Ini adalah elemen penting yang harus dipertimbangkan dalam penyebaran apa pun dan keputusan yang dibuat dalam perencanaan pemulihan bencana memengaruhi bagaimana Operations Manager akan dapat terus mendukung pemantauan dan pelaporan proaktif tentang performa dan ketersediaan layanan IT penting Anda. Bagian ini akan berfokus pada strategi pemulihan dan ketahanan bencana yang direkomendasikan dan langkah-langkah apa yang harus diambil untuk memastikan pemulihan yang lancar.

Meskipun solusi HA dan DR akan memberikan perlindungan dari kegagalan sistem atau kehilangan sistem, solusi tersebut tidak boleh diandalkan untuk perlindungan dari kehilangan atau kerusakan data yang tidak disengaja, tidak diinginkan, atau berbahaya. Dalam kasus ini, salinan replikasi yang di-backup atau tertunda mungkin harus digunakan untuk operasi pemulihan. Dalam banyak kasus, operasi pemulihan adalah bentuk DR yang paling tepat. Salah satu contohnya bisa menjadi database pelaporan berprioritas rendah atau data analisis. Dalam banyak kasus, biaya untuk mengaktifkan DR multisitus di tingkat sistem atau aplikasi jauh lebih besar daripada nilai data. Dalam kasus di mana nilai jangka pendek data rendah dan kebutuhan untuk mengakses data dapat tertunda tanpa dampak bisnis yang parah jika kegagalan atau situs DR berlebihan, pertimbangkan untuk menggunakan proses pencadangan dan pemulihan sederhana untuk DR jika penghematan biaya menjaminnya.

Memahami dampak dan toleransi terhadap waktu henti akan memicu keputusan yang perlu dipahami agar dapat merancang arsitektur Pengelola Operasi dengan tepat, serta menentukan tingkat kompleksitas dan biaya yang dibutuhkan untuk mendukung pemulihan bencana. Selain itu, pertimbangkan sejauh mana pemantauan kehilangan data yang dapat ditoleransi organisasi TI tanpa menyebabkan konsekuensi bisnis. Ini paling baik dijelaskan dalam dua istilah: tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO).

Dua konfigurasi desain pemulihan bencana yang paling umum untuk Operations Manager adalah:

• Membuat grup manajemen duplikat yang disebarkan ke pusat data sekunder Anda yang menduplikasi dalam skala dan konfigurasi grup manajemen utama.
• Menyebarkan server tambahan di pusat data sekunder untuk mendukung database Gudang Operasional dan Data, dengan server manajemen yang disebarkan dalam konfigurasi siaga dingin, tidak berpartisipasi dalam grup manajemen sampai tindakan pemulihan perlu dilakukan.

Menyebarkan grup manajemen duplikat adalah opsi ketika tidak ada toleransi untuk waktu henti; namun, ini adalah opsi yang paling kompleks. Konfigurasi antara keduanya harus konsisten sehingga ketika Anda melakukan transisi, tidak ada perbedaan dalam apa yang dipantau, diberi peringatan atau dilaporkan, disajikan, dan akhirnya meningkatkan tingkat urgensinya. Integrasi dengan platform pemantauan lain atau platform ITSM seperti System Center - Service Manager, Remedy, atau ServiceNow juga harus ada, dan mungkin dikonfigurasi dalam status aktif/pasif untuk menghindari duplikasi insiden, item konfigurasi, dan sebagainya. Agen akan memiliki koneksi ganda di antara kedua grup manajemen, sehingga akan ada duplikasi data.

Diagram berikut adalah contoh skenario desain ini.

Diagram

Jika pemulihan segera tidak diperlukan untuk penyebaran Manajer Operasi dan Anda ingin menghindari kompleksitas grup manajemen duplikat, Anda dapat menyebarkan komponen grup manajemen tambahan di pusat data sekunder Anda untuk mempertahankan fungsionalitas grup manajemen Anda. Sebagai langkah minimum, pertimbangkan untuk menerapkan Grup Ketersediaan Always On SQL Server 2014 atau 2016 untuk menyediakan pemulihan database Operasional dan Gudang Data antara dua atau lebih pusat data, dengan sebuah instans kluster failover dua node (FCI) ditempatkan di pusat data utama, dan SQL Server mandiri di pusat data sekunder sebagai bagian dari satu Kluster Failover Windows Server (WSFC). Replika sekunder untuk Grup Ketersediaan AlwaysOn akan berada di instans mandiri non-FCI seperti yang ditunjukkan pada diagram berikut.

Diagram

Dalam contoh ini, Anda akan diminta untuk menyebarkan satu atau beberapa Windows Server dengan konfigurasi perangkat keras dan nama komputer yang sama, dan menginstal ulang peran server manajemen menggunakan parameter /Recover. Berikut adalah sampelnya:

Setup.exe /silent /AcceptEndUserLicenseAgreement:1 /recover /InstallPath:<Install Directory> /ManagementGroupName:MGNAME /SqlServerInstance:SQLServerName.domain.com /DatabaseName:OperationsManager /DWSqlServerInstance:SQLServerName.domain.com /DWDatabaseName:OperationsManagerDW /ActionAccountUser:DOMAIN\omaa /ActionAccountPassword:password /DASAccountUser:DOMAIN\omdas /DASAccountPassword:password /DatareaderUser:DOMAIN\omdr /DatareaderPassword:password /DataWriterUser:DOMAIN\omdw /DataWriterPassword:password /EnableErrorReporting:Always /SendCEIPReports:1 /UseMicrosoftUpdate:0

Untuk informasi selengkapnya, lihat menginstal Operations Manager dari command prompt.

Selama waktu ini, agen akan mengantre data yang dikumpulkan (pemberitahuan, peristiwa, performa, dan sebagainya) hingga mereka dapat melanjutkan komunikasi dengan server manajemen di grup manajemen. Pendekatan ini menghindari penginstalan instans baru SQL Server dan memulihkan database dari cadangan baik terakhir yang diketahui. Namun, dalam skenario pemulihan ini kemungkinan akan ada penundaan yang lebih lama dalam kembali ke status yang dapat dioperasikan mengingat Anda harus menyebarkan peran lain yang diperlukan untuk melanjutkan fungsionalitas pemantauan minimum. Jika pendekatan ini tidak dapat diterima, Anda dapat menyebarkan server manajemen di pusat data sekunder Anda untuk pemulihan siaga. Hapus mereka sebagai anggota dari tiga kumpulan sumber daya utama - Kumpulan Sumber Daya Semua Server Manajemen, Pemberitahuan, dan Penugasan AD. Ini juga termasuk kumpulan sumber daya kustom apa pun, yang mungkin mencakup server manajemen yang dihosting di pusat data utama dan perlu terus berfungsi sebagai bagian dari rencana pemulihan. Layanan Akses Data Pusat Sistem, Manajemen Konfigurasi Pusat Sistem, dan Agen Pemantauan Microsoft harus dihentikan dan diatur ke manual atau nonaktifkan dan hanya dimulai dalam skenario pemulihan bencana.

Jika server manajemen mendukung integrasi (melalui konektor yang dihosting langsung di server manajemen atau dari produk Pusat Sistem lain seperti VMM, Orkestrator, atau Manajer Layanan), ini perlu direncanakan dengan langkah-langkah pemulihan manual atau otomatis tergantung pada konfigurasi integrasi dan urutan langkah pemulihan. Ini memastikan bahwa dependensi lain pada server manajemen diidentifikasi dan direncanakan ketika rencana penanggulangan bencana perlu diterapkan.

Jika satu situs offline, agen akan beralih ke server manajemen di situs lain, dengan anggapan bahwa konfigurasi failover agen memungkinkan ini. Konfigurasi ulang agen Windows untuk menyimpan cache hanya pada server manajemen di pusat data utama Anda yang bertanggung jawab mengelola mereka. Hal ini untuk mencegah mereka mencoba failover ke server manajemen di pusat data sekunder, yang hanya akan menyebabkan penundaan dalam pemulihan dan pelaporan. Ini dapat dicapai jika Anda menyebarkan agen secara manual secara otomatis dengan skrip (misalnya, VBScript, atau lebih baik lagi, PowerShell) untuk pra-konfigurasi selama penginstalan, atau pasca penyebaran jika Anda mendorong agen dari konsol, sekali lagi menggunakan metode skrip yang dikelola dengan solusi manajemen konfigurasi perusahaan Anda.

Manajer Operasi dapat disebarkan pada komputer virtual Azure sebagai opsi pemulihan bencana alternatif untuk menjaga kelangsungan grup manajemen. Perlu juga untuk menyebarkan SQL Server pada komputer virtual di Azure dan bukan dalam konfigurasi hibrid, karena latensi antara server manajemen dan SQL Server yang menghosting database Manajer Operasi akan berdampak negatif pada performa grup manajemen.

Pertimbangkan cakupan pemantauan, topologi jaringan, dan konektivitas jaringan ke Microsoft Azure (yaitu, VPN situs-ke-situs atau ExpressRoute), titik integrasi (yaitu, solusi ITSM, produk Pusat Sistem lainnya, add-on bagian ketiga, dan sebagainya), akses konsol, peraturan atau hukum atau kebijakan yang relevan, dan sebagainya untuk merancang skenario ini dengan benar dalam Azure IaaS atau penyedia cloud publik lainnya.