Bagikan melalui

Ketersediaan Tinggi dan Pemulihan Bencana

  • Artikel

Penting

Versi Operations Manager ini telah mencapai akhir dukungan. Kami menyarankan Anda untuk meningkatkan ke Operations Manager 2022.

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 dan gudang data Operations Manager, 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 saat membuka konsol, Anda mereferensikan nama virtual yang terdaftar di DNS, dari server manajemen yang seimbang.

Catatan

Load Balancer Jaringan tidak didukung untuk server konsol web Operations Manager.

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 memberikan redundansi melalui failover gateway agen, server gateway dapat dikonfigurasi untuk melakukan failover antar server manajemen dalam grup manajemen jika beberapa server manajemen tersedia.

Meskipun SQL Server Reporting Services mendukung model penyebaran peluasan skala yang memungkinkan Anda menjalankan beberapa instans server laporan yang berbagi database server laporan tunggal, model tersebut tidak didukung dengan Operations Manager. Pelaporan Manajer Operasi menginstal ekstensi keamanan kustom sebagai bagian dari 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 proaktif dan pelaporan 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 dicadangkan atau tertinggal 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 melebihi nilai data. Dalam kasus di mana nilai data jangka dekat 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 untuk waktu henti akan membantu mendorong keputusan yang perlu dipahami untuk merancang arsitektur manajer operasi dengan benar dan tingkat kompleksitas dan biaya yang diperlukan 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 Operasional dan Gudang 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 memotong, tidak ada perbedaan dalam apa yang dipantau, diberi tahu atau dilaporkan, disajikan, dan akhirnya ditingkatkan. Integrasi dengan platform pemantauan lain atau platform ITSM seperti System Center - Service Manager, Remedy, atau ServiceNow juga harus ada, dan mungkin dikonfigurasi dalam keadaan aktif/pasif untuk menghindari duplikasi insiden, item konfigurasi, dan sebagainya. Agen akan di-multihomed antara kedua grup manajemen, sehingga akan ada duplikasi data.

Diagram berikut adalah contoh skenario desain ini.

Diagram MG Duplikat.

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. Minimal, pertimbangkan untuk menerapkan Grup Ketersediaan AlwaysOn SQL Server 2014 atau 2016 untuk menyediakan pemulihan database Operasional dan Gudang Data antara dua pusat data atau lebih, di mana instans kluster failover dua node (FCI) disebarkan di pusat data utama, dan SQL Server mandiri di pusat data sekunder sebagai bagian dari satu Kluster Failover Server Windows (WSFC). Replika sekunder untuk Grup Ketersediaan AlwaysOn akan berada pada instans mandiri non-FCI seperti yang ditunjukkan dalam diagram berikut.

Diagram Konfigurasi DR Sederhana.

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 sampel: 


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 prompt perintah.

Selama waktu ini, agen akan mengantre data yang dikumpulkan (pemberitahuan, peristiwa, performa, dan sebagainya) hingga mereka dapat melanjutkan komunikasi dengan server manajemen dalam 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 operasi 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 sebagai anggota dari tiga kumpulan sumber daya utama - Semua Kumpulan Sumber Daya Server Manajemen, Pemberitahuan, dan Penetapan 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, Orchestrator, atau Manajer Layanan), ini perlu direncanakan dengan langkah-langkah pemulihan manual atau otomatis tergantung pada konfigurasi integrasi dan urutan langkah-langkah pemulihan. Ini memastikan dependensi lain pada server manajemen ditangkap dan direncanakan ketika rencana pemulihan bencana perlu diterapkan.

Ilustrasi Konfigurasi DR Kompleks.

Jika satu situs offline, agen akan gagal ke server manajemen di situs lain, dengan asumsi bahwa konfigurasi failover agen memungkinkan ini. Konfigurasi ulang agen Windows untuk menyimpan hanya server manajemen di pusat data utama Anda yang harus mengelolanya untuk mencegah mereka mencoba failover ke server manajemen di pusat data sekunder, yang hanya akan menunda 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. Anda juga perlu menyebarkan SQL Server pada komputer virtual di Azure dan bukan dalam konfigurasi hibrid, karena latensi antara server manajemen dan SQL Server menghosting database Operations Manager 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, undang-undang atau kebijakan yang relevan atau peraturan, dan sebagainya untuk merancang skenario ini dengan benar dalam Azure IaaS atau penyedia cloud publik lainnya.