Pindahkan SQL Server 2008 Dan 2008 R2 Clusters Ke Azure Untuk Dukungan Diperpanjang

Pindahkan SQL Server 2008 Dan 2008 R2 Clusters Ke Azure Untuk Dukungan Diperpanjang

Awal tahun ini Microsoft mengumumkan perpanjangan dukungan jika Anda memindahkan SQL Server 2008 dan 2008 R2 Cluster ke Azure. Untuk semua detailnya, periksa https://www.microsoft.com/en-us/sql-server/sql-server-2008. Jika Anda memilih untuk tidak pindah, dukungan diperpanjang Anda berakhir pada 9 Juli 2019. Jika Anda masih menjalankan SQL Server 2008 R2, mungkin karena Anda tidak pernah memutakhirkan aplikasi Anda. Oleh karena itu versi SQL yang lebih baru tidak didukung. Atau mungkin, Anda memutuskan untuk tidak memperbaiki apa yang tidak rusak. Terlepas dari alasan ini, Anda baru saja membeli sendiri tiga tahun dukungan jika Anda bermigrasi ke Azure. Sekarang migrasi beban kerja ke Azure adalah prosedur yang didokumentasikan dengan cukup baik, menggunakan Pemulihan Situs Azure. Proses itu harus cukup mulus bagi Anda untuk contoh SQL Server yang berdiri sendiri. Tetapi bagaimana dengan contoh-contoh SQL Server yang berkerumun itu? Anda tentu tidak ingin kehilangan ketersediaan saat Anda pindah ke Azure. Bagian dari keindahan Azure adalah bahwa mereka memiliki infrastruktur yang hanya bisa Anda impikan. Namun, adalah kewajiban bagi pengguna untuk mengonfigurasi aplikasi mereka untuk memanfaatkan infrastruktur sepenuhnya untuk memastikan bahwa penyebaran Anda sangat tersedia. Dengan SQL Server 2008 dan 2008 R2, ketersediaan tinggi umumnya berarti SQL Server Failover Clustering pada Windows Server 2008 R2 atau Windows Server 2012 R2. Jika Anda baru mengenal Azure, Anda akan segera menemukan bahwa tidak ada opsi asli yang mendukung penyimpanan bersama. Sebaliknya, Anda perlu melihat solusi cluster SANLess seperti SIOS DataKeeper. Daftar Microsoft SIOS DataKeeper sebagai solusi HA untuk SQL Server Failover Clustering dalam dokumentasi mereka.

Mulai

Mari kita mulai bergerak SQL Server 2008 Dan 2008 R2 Cluster Untuk Azure Untuk Dukungan Diperpanjang. Berikut adalah langkah-langkah tingkat tinggi yang perlu Anda ambil.

• Ganti Sumber Daya Disk Fisik dalam Anda ada di premis SQL Server cluster dengan Sumber Daya Volume DataKeeper. Lakukan hal yang sama untuk sumber daya MSDTC jika Anda menggunakan MSDTC.
• Keluarkan Disk Witness Anda dan gantikan dengan File Share Witness.
• Gunakan Azure Site Recovery untuk mereplikasi node cluster Anda menjadi Azure, memastikan setiap node yang direplikasi berada di Domain Kesalahan yang berbeda atau di Zona Ketersediaan yang berbeda di Azure
• Pulihkan node node Anda yang mereplikasi di Azure
• Ganti File Share Witness dengan File Share yang dihosting di Azure
• Konfigurasikan Penyeimbang Beban Internal di Azure untuk pengalihan klien. Ini termasuk menjalankan skrip Powershell pada node lokal untuk memperbarui sumber daya IP Cluster SQL untuk mendengarkan probe ILB
• Dengan asumsi alamat IP dan subnet dari contoh SQL Server cluster berubah sebagai bagian dari migrasi ini, Anda juga perlu melakukan beberapa pembersihan alamat IP klaster dan endpoint pekerjaan DataKeeper untuk mencerminkan alamat IP baru

Saya tahu saya meninggalkan banyak detail. Tetapi jika Anda mendapati diri Anda harus melakukan pengangkatan dan pengalihan SQL Server ke Azure, atau cloud apa pun, saya akan senang menghubungi Anda untuk menjawab pertanyaan apa pun yang mungkin Anda miliki. Perlu diingat, langkah yang sama berlaku untuk versi SQL apa pun yang Anda rencanakan untuk dimigrasikan ke Azure. Jika Anda perlu memindahkan SQL Server 2008 dan 2008 R2 Cluster ke Azure, hubungi kami. Direproduksi dengan izin dari Clusteringformeremortals.com

Pemulihan Situs Azure untuk Pemulihan Bencana

Cara Memicu Peringatan Email Dari Monitor Kinerja Windows

$ counter = $ Args [0]
$ dtandtime = $ Args [1]
$ ctr_value = $ Args [2]
$ threshold = $ Args [3]
$ value = $ Args [4]
$ FileName = "$ env: ComputerName"
$ EmailFrom = "sios@medfordband.com"
$ EmailTo = "dave@medfordband.com"
$ Subject = "Pemberitahuan Dari $ FileName"
$ Body = "Data dan Time of Alert: $ dtandtime`nPerfmon Counter: $ ctr_value`nThreshold Value: $ threshold` nNilai sekarang: $ value "
$ SMTPServer = "smtp.gmail.com"
$ SMTPClient = New-Object Net.Mail.SmtpClient ($ SmtpServer, 587)
$ SMTPClient.EnableSsl = $ true
$ SMTPClient.Credentials = New-Object System.Net.NetworkCredential ("sios@medfordband.com", "ChangeMe123");
$ SMTPClient.Send ($ EmailFrom, $ EmailTo, $ Subject, $ Body)

schtasks / create / tn Alerts / sc onstart / tr "logman mulai Alerts" / sistem ru

Apakah Anda menikmati membaca Cara Memicu Peringatan Email Dari Monitor Kinerja Windows? Klik di sini untuk mengetahui lebih lanjut. Direproduksi dengan izin dari Clusteringformeremortals.com

Cara Memicu Peringatan Email Dari Peristiwa Windows Menggunakan Windows Server 2016

Step-By-Step: Cara Memicu Peringatan Email Dari Peristiwa Windows Yang Termasuk Perincian Peristiwa Menggunakan Windows Server 2016

pengantar

Memicu Peringatan Email Dari Peristiwa Windows Menggunakan Windows Server 2016 hanya memerlukan beberapa langkah. Tentukan tindakan yang akan terjadi ketika Tugas dipicu. Karena Microsoft telah memutuskan untuk menghapus opsi "Kirim e-mail", satu-satunya pilihan yang kita miliki adalah Memulai Program. Dalam kasus kami, program itu akan menjadi skrip Powershell untuk mengumpulkan informasi Log Peristiwa dan menguraikannya. Dengan cara ini, kami dapat mengirim email yang menyertakan rincian Log Event penting. Pekerjaan ini diverifikasi pada Windows Server 2016. Tapi saya menduga itu harus bekerja pada Windows Server 2012 R2 dan Windows Server 2019 juga. Jika Anda membuatnya bekerja pada platform lain, silakan komentar dan beri tahu kami jika Anda harus mengubah apa pun.

Langkah 1- Tulis Skrip Powershell

Hal pertama yang harus dilakukan adalah menulis skrip Powershell yang ketika dijalankan dapat mengirim email. Saat meneliti ini, saya menemukan banyak cara untuk menyelesaikan tugas ini, jadi apa yang akan saya tunjukkan kepada Anda hanyalah satu cara, tetapi jangan ragu untuk bereksperimen dan menggunakan yang tepat untuk lingkungan Anda. Di lab saya, saya tidak menjalankan server SMTP saya sendiri, jadi saya harus menulis skrip yang dapat memanfaatkan akun Gmail saya. Anda akan melihat dalam skrip Powershell saya bahwa kata sandi ke akun email yang diautentikasi ke server SMTP dalam teks biasa. Jika Anda khawatir seseorang mungkin memiliki akses ke skrip Anda dan menemukan kata sandi Anda, lakukan enkripsi kredensial Anda. Gmail membutuhkan dan koneksi SSL. Kata sandi Anda harus aman pada kabel, sama seperti klien email lainnya. Saya memiliki contoh skrip Powershell. Ketika digunakan bersama dengan Penjadwal Tugas, itu akan mengirim peringatan email secara otomatis ketika Peristiwa tertentu login di Windows Event Log. Di lingkungan saya, saya menyimpan skrip ini ke C: Alerts DataKeeper.ps1

$ EventId = 16,20,23,150,219,220

$ A = Get-WinEvent -MaxEvents 1 -FilterHashTable @ {Logname = "System"; ID = $ EventId}
$ Pesan = $ A.Message
$ EventID = $ A.Id
$ MachineName = $ A.MachineName
$ Source = $ A.ProviderName


$ EmailFrom = "sios@medfordband.com"
$ EmailTo = "sios@medfordband.com"
$ Subject = "Pemberitahuan Dari $ MachineName"
$ Body = "EventID: $ EventID`nSource: $ Source`nMachineName: $ MachineName` nMessage: $ Pesan "
$ SMTPServer = "smtp.gmail.com"
$ SMTPClient = New-Object Net.Mail.SmtpClient ($ SmtpServer, 587)
$ SMTPClient.EnableSsl = $ true
$ SMTPClient.Credentials = New-Object System.Net.NetworkCredential
("sios@medfordband.com", "mySMTPP @ 55w0rd");
$ SMTPClient.Send ($ EmailFrom, $ EmailTo, $ Subject, $ Body)

Contoh email yang dihasilkan dari skrip Powershell seperti ini. Anda mungkin memperhatikan bahwa skrip Powershell ini menggunakan cmdlet Get-WinEvent untuk mengambil entri Entri Peristiwa terbaru berdasarkan LogName, Sumber, dan eventID yang ditentukan. Ini kemudian mem-parsing acara dan menetapkan variabel EventID, Sumber, MesinName dan Pesan yang akan digunakan untuk menulis email. Anda akan melihat bahwa LogName, Sumber, dan eventID yang ditentukan sama dengan yang akan Anda tentukan ketika Anda mengatur Tugas Terjadwal di Langkah 2.

Langkah 2 – Mengatur Tugas Terjadwal

Di Penjadwal Tugas Buat Tugas seperti yang ditampilkan di cuplikan layar berikut.

1. Buat Tugas Pastikan tugas diatur ke Jalankan apakah pengguna sudah masuk atau tidak.
2.  Pada tab Pemicu pilih Baru untuk membuat Trigger yang akan memulai tugas "Pada Acara". Dalam contoh saya, saya akan membuat suatu peristiwa yang memicu setiap saat DataKeeper (extmirr) mencatat peristiwa penting ke log Sistem. Buat acara khusus dan Filter Acara Baru seperti yang ditunjukkan di bawah ini … Untuk pemicu saya, saya memicu pada SIOS DataKeeper yang biasa dipantau (ExtMirr) EventID 16, 20, 23.150.219.220. Anda perlu mengatur acara Anda untuk memicu pada Peristiwa spesifik yang ingin Anda pantau. Anda dapat menempatkan beberapa Pemicu di Tugas yang sama jika Anda ingin diberi tahu tentang acara yang berasal dari log atau sumber yang berbeda.
   

   

    

3. Setelah Pemicu Peristiwa dikonfigurasi, Anda harus mengonfigurasi Tindakan yang terjadi saat acara dijalankan. Dalam kasus kami, kami akan menjalankan skrip Powershell yang kami buat pada Langkah 1.
4. Parameter Kondisi default harus memadai.
5. Dan akhirnya, pada tab Pengaturan, pastikan Anda mengizinkan tugas dijalankan sesuai permintaan dan untuk "Memasuki instance baru" jika tugas sudah berjalan.
   

   

Langkah 3 (Jika Diperlukan) – Perbaiki Microsoft Windows DistributedCOM ID Peristiwa: 10016 Kesalahan

Secara teori, jika Anda melakukan semuanya dengan benar, Anda harus dapat Memicu Pemberitahuan Email Dari Peristiwa Windows Menggunakan Windows Server 2016. Namun, saya mengalami masalah izin aneh di salah satu server saya. Inilah perbaikan saya untuk masalah saya. Semoga itu akan membantu Anda juga. Dalam kasus saya ketika saya secara manual memicu acara, atau jika saya menjalankan skrip Powershell secara langsung, semuanya bekerja seperti yang diharapkan dan saya akan menerima email. Namun, jika salah satu EventID yang dipantau masuk ke log peristiwa itu tidak akan menghasilkan email yang dikirim. Satu-satunya petunjuk yang saya miliki adalah ID Peristiwa: 10016. Itu login di log peristiwa Sistem saya setiap kali saya mengharapkan Pemicu Tugas untuk mendeteksi peristiwa yang tercatat.

Nama Log: Sistem
Sumber: Microsoft-Windows-DistributedCOM
Tanggal: 10/27/2018 5:59:47 PM
ID Peristiwa: 10016
Kategori Tugas: Tidak ada
Tingkat: Kesalahan
Kata Kunci: Klasik
Pengguna: DATAKEEPER  dave
Komputer: sql1.datakeeper.local
Deskripsi:
Pengaturan izin khusus aplikasi tidak memberikan izin Aktivasi Lokal 
untuk aplikasi COM Server dengan CLSID 
{D63B10C5-BB46-4990-A94F-E40B9D520160}
dan APPID 
{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
kepada pengguna DATAKEEPER  dave SID (S-1-5-21-25339xxxxx-208xxx580-6xxx06984-500) 
dari alamat LocalHost 
(Menggunakan LRPC) yang berjalan dalam kontainer aplikasi Tidak tersedia SID (Tidak Tersedia). 
Izin keamanan ini dapat dimodifikasi menggunakan alat administratif Komponen Layanan.

Banyak hasil pencarian Google untuk kesalahan itu menunjukkan bahwa kesalahan itu jinak. Ini termasuk instruksi tentang cara menekan kesalahan daripada memperbaikinya. Namun, saya cukup yakin kesalahan ini adalah penyebab kegagalan saya saat ini. Jika saya tidak memperbaikinya, akan sulit untuk Memicu Peringatan Email Dari Peristiwa Windows Menggunakan Windows Server 2016. Setelah banyak pencarian, saya menemukan diskusi newsgroup ini.  Tanggapan dari Marc Whittlesey mengarahkan saya ke arah yang benar. Ini yang dia tulis …

Saya bisa mengikuti Langkah 1-15 cukup banyak kata demi kata. Namun, ketika saya sampai ke Langkah 16, saya benar-benar tidak tahu persis apa yang dia ingin saya lakukan. Awalnya saya memberikan akun pengguna DATAKEEPER dave Kontrol Penuh ke RuntimeBroker, tetapi itu tidak memperbaiki banyak hal. Akhirnya saya hanya memilih "Use Default" pada ketiga perizinan dan yang memperbaiki masalah. Saya tidak yakin bagaimana atau mengapa ini terjadi. Saya pikir saya lebih baik menulis semuanya kalau-kalau itu terjadi lagi karena butuh beberapa saat untuk mengetahuinya.

Langkah 4 – Mengotomasi Penempatan

Jika Anda perlu mengaktifkan peringatan yang sama pada beberapa sistem, ekspor Tugas Anda ke file XML dan Impor pada sistem Anda yang lain. Atau bahkan lebih baik lagi. Otomatiskan Impor sebagai bagian dari proses pembuatan Anda melalui skrip Powershell setelah membuat file XML Anda tersedia di berbagi file seperti yang ditunjukkan pada contoh berikut.

PS C: > Daftar-ScheduledTask -Xml (dapatkan-konten 
'\ myfileshare  tasks  DataKeeperAlerts.xml' | out-string) 
-TaskName "DataKeeperAlerts" - Pengguna datakeeper  dave 
-Password MyDomainP @ 55W0rd –Force

Memicu Peringatan Email Dari Peristiwa Windows Menggunakan Windows Server 2016

Dalam posting saya berikutnya, saya akan menunjukkan kepada Anda bagaimana untuk diberitahu ketika Layanan tertentu mulai atau berhenti. Tentu saja Anda bisa memantau EventID 7036 dari Service Control Monitor. Tapi itu akan memberi tahu Anda kapan pun layanan dimulai atau berhenti. Kami perlu menggali lebih dalam untuk memastikan kami mendapatkan pemberitahuan hanya ketika layanan yang kami pedulikan mulai atau berhenti. Jika Anda tertarik dengan artikel kami seperti Trigger Email Alerts Dari Peristiwa Windows Menggunakan Windows Server 2016, klik di sini. Direproduksi dari Clusteringformeremortals.com

Azure Outage Post Mortem Bagian 3

Penutup The Azure Outage Post-Mortem Bagian 3

Posting blog saya sebelumnya, Azure Outage Post-Mortem – Bagian 1 dan Azure Outage Post-Mortem Bagian 2, membuat beberapa asumsi berdasarkan informasi terbatas yang berasal dari posting blog dan twitter. Saya baru saja menghadiri sesi di Ignite yang memberikan sedikit lebih banyak kejelasan tentang apa yang sebenarnya terjadi. Suatu saat besok Anda harus dapat melihat sesi untuk diri sendiri. BRK3075 – Mempersiapkan yang tak terduga: Anatomi pemadaman Azure Analisis Root Cause resmi akan segera diterbitkan. Sementara itu, berikut beberapa informasi yang dikumpulkan dari sesi.

Penyebab

Dari kematian pos pemadaman biru, pemadaman itu TIDAK disebabkan oleh sambaran petir seperti yang dilaporkan sebelumnya. Sebaliknya, karena sifat dari badai, ada badai listrik melorot dan membengkak. Akibatnya, tanaman chiller terkunci di pusat ^data pertama. Selama pemadaman pertama ini, mereka dapat memulihkan chiller dengan cepat tanpa dampak yang nyata. Tak lama kemudian, ada pemadaman kedua di pusat data kedua yang tidak pulih dengan benar. Itu memulai serangkaian peristiwa yang tidak menguntungkan.

2 Habis

Selama pemadaman ini, Microsoft menyatakan bahwa “Insinyur tidak melakukan triase peringatan dengan benar – pemulihan pabrik chiller tidak diprioritaskan”. Ada banyak peringatan yang dipicu saat ini. Sayangnya chiller sedang offline tidak menerima prioritas yang seharusnya. RCA tentang mengapa itu terjadi masih diselidiki. Microsoft menyatakan bahwa tentu saja sistem chiller redundan sudah tersedia. Namun, sistem pendingin tidak diatur ke failover otomatis. Baru-baru ini dipasang peralatan baru belum sepenuhnya diuji. Jadi itu diatur ke mode manual sampai pengujian telah selesai. Setelah 45 menit, pendinginan ambien gagal, shutdown perangkat keras, penangan udara mati karena mereka mengira ada kebakaran. Staf telah dievakuasi karena alarm kebakaran palsu. Selama ini suhu di pusat data semakin meningkat. Beberapa perangkat keras tidak dimatikan dengan benar, menyebabkan kerusakan pada beberapa penyimpanan dan jaringan. Setelah secara manual mengatur ulang chiller dan membuka penangan udara, suhu mulai kembali normal. Butuh sekitar 3 jam dan 29 menit sebelum mereka memiliki gambaran lengkap tentang status datacenter. Masalah terbesar adalah kerusakan pada penyimpanan. Perhatian utama Microsoft adalah perlindungan data. Microsoft akan bekerja untuk memulihkan data untuk memastikan tidak ada kehilangan data. Ini tentu memakan waktu, yang memperpanjang panjang keseluruhan pemadaman. Kabar baiknya adalah tidak ada data pelanggan yang hilang. Kabar buruknya adalah sepertinya butuh 24-48 jam agar semuanya kembali normal. Ini berdasarkan apa yang saya baca di Twitter dari pelanggan yang mengeluh tentang pemadaman berkepanjangan.

Asumsi

Semua orang berharap pemadaman ini akan berdampak pada pelanggan yang dihosting di Wilayah Tengah Selatan. Tapi apa yang mereka tidak harapkan adalah pemadaman itu akan berdampak di luar wilayah itu. Dalam sesi tersebut, Microsoft membahas beberapa jangkauan pemadaman yang diperpanjang.

Azure Service Manager (ASM)

Ini mengontrol sumber daya “Klasik” Azure, AKA, sumber daya pra-ARM. Siapa pun yang mengandalkan ASM bisa terkena dampak. Tidak jelas bagi saya mengapa ini terjadi. Tampaknya Wilayah Tengah Selatan memiliki beberapa komponen penting dari layanan tersebut yang menjadi tidak tersedia.

Visual Studio Team Service (VSTS)

Sekali lagi, tampaknya banyak sumber daya yang mendukung layanan ini di-host di Wilayah Tengah Selatan. Pemutusan ini dijelaskan dengan sangat terperinci oleh Buck Hodges (@tfsbuck), Direktur Teknik, Azure DevOps pos blog ini.

POSTMORTEM: VSTS 4 SEPTEMBER 2018

Azure Active Directory (AAD)

Ketika kawasan Tengah Selatan gagal, AAD melakukan apa yang dirancang untuk jatuh tempo dan mulai mengarahkan permintaan otentikasi ke wilayah lain. Ketika Pantai Timur mulai bangun dan online, lalu lintas otentikasi mulai meningkat. Sekarang biasanya AAD akan menangani peningkatan lalu lintas ini melalui penskalaan otomatis. Tapi autoscaling memiliki ketergantungan pada ASM, yang tentu saja offline. Tanpa kemampuan autoscale, AAD tidak dapat menangani peningkatan permintaan otentikasi. Situasi yang menjengkelkan adalah bug di klien Office yang membuat mereka memiliki logika mencoba-coba yang sangat agresif, dan tidak ada logika backoff. Lalu lintas autentikasi tambahan ini akhirnya membawa AAD ke lututnya. Mereka kehabisan waktu untuk membahas ini lebih lanjut selama sesi Ignite. Satu fitur yang akan mereka perkenalkan akan memberi pengguna kemampuan untuk failover Storage Accounts secara manual di masa depan. Jadi dalam kasus di mana waktu pemulihan obyektif (RTO) lebih penting daripada (RPO), pengguna akan memiliki kemampuan untuk memulihkan penyimpanan geo-redundansi asynchronous direplikasi mereka di pusat data alternatif jika Microsoft mengalami pemadaman panjang lagi di masa depan.

Apa yang Dapat Anda Lakukan Sekarang

Sampai saat itu, Anda harus bergantung pada solusi replikasi lain seperti SIOS DataKeeper Azure Site Recovery. Atau solusi replikasi khusus aplikasi yang memiliki kemampuan untuk mereplikasi data di seluruh wilayah dan menempatkan kemampuan untuk memberlakukan rencana pemulihan bencana Anda dalam kendali Anda. Baca lebih lanjut tentang post mortal emisi azure kami Direproduksi dengan izin dari Clusteringformeremortals.com