Failover Clustering Dengan VMware Ketersediaan Tinggi Sebuah Pertandingan Sempurna?

Failover Clustering Dengan VMware High Availability: Overkill Atau Pertandingan Sempurna?

Menerapkan ketersediaan tinggi (HA) di lapisan VMware adalah solusi yang bermanfaat. Ini membantu melindungi terhadap beberapa jenis kegagalan. Namun, VMware HA sendiri tidak mencakup semua basis. Mari kita telusuri kemungkinan Failover Clustering dengan VMware High Availability.

Menurut Gartner Research, pemadaman yang tidak direncanakan sebagian besar disebabkan oleh kegagalan aplikasi (40 persen pemadaman) atau kesalahan admin (40 persen). Masalah perangkat keras, jaringan, listrik, atau lingkungan menyebabkan sisanya (total 20 persen). VMware HA berfokus pada perlindungan terhadap kegagalan perangkat keras, tetapi solusi aplikasi-pengelompokan yang baik akan mengisi kekosongan di area lain.

Memiliki Strategi Yang Baik Sangat Penting Untuk Failover Clustering dengan Ketersediaan Tinggi VMware

Berikut adalah beberapa hal yang perlu dipertimbangkan ketika merancang strategi HA yang tepat untuk lingkungan VMware Anda.

Mempersingkat Pemadaman Dengan Monitoring dan Clustering Tingkat Aplikasi

Bagaimana dengan kecepatan pemulihan? Di dunia yang sempurna, tidak akan ada kegagalan, pemadaman atau downtime. Tetapi jika pemadaman yang tidak direncanakan terjadi, hal terbaik berikutnya adalah bangkit dan berlari lagi dengan cepat. Persamaan ini mewakili total ketersediaan lingkungan Anda: Seperti yang Anda lihat, waktu deteksi adalah bagian penting dari persamaan. Inilah tempat lain di mana VMware HA saja tidak cukup memotongnya. VMware HA memperlakukan setiap mesin virtual (VM) sebagai "kotak hitam" dan tidak memiliki visibilitas nyata ke dalam kesehatan atau status aplikasi yang sedang berjalan di dalamnya. VM dan OS yang berjalan di dalamnya mungkin baik-baik saja, tetapi aplikasinya bisa dihentikan, digantung, atau salah konfigurasi, mengakibatkan pemadaman untuk pengguna. Bahkan ketika kegagalan server host adalah masalah, Anda harus menunggu VMware HA untuk me-restart VM yang terkena pada host lain di kelompok VMware. Itu berarti aplikasi yang berjalan pada VM tersebut turun sampai 1) pemadaman terdeteksi, 2) OS melakukan boot sepenuhnya pada sistem host baru, 3) aplikasi restart, dan 4) pengguna terhubung kembali ke aplikasi. Dengan mengelompokkan pada lapisan aplikasi antara beberapa VM, Anda tidak hanya terlindungi terhadap pemadaman tingkat aplikasi, Anda juga mempersingkat waktu pemadaman-pemadaman Anda. Aplikasi ini hanya dapat di-restart pada VM siaga, yang sudah di-boot dan menunggu untuk mengambil alih. Untuk memaksimalkan ketersediaan, VM yang terlibat harus tinggal di server fisik yang berbeda. Atau lebih baik lagi, pisahkan VMware HA cluster atau bahkan pusat data terpisah!

Hilangkan Penyimpanan Sebagai Potensi Titik Kegagalan Tunggal (SPOF)

Solusi pengelompokan tradisional, termasuk VMware HA, memerlukan penyimpanan bersama dan biasanya melindungi aplikasi atau layanan hanya dalam satu pusat data. Secara teknis, perangkat penyimpanan bersama mewakili SPOF dalam arsitektur Anda. Jika Anda kehilangan akses ke penyimpanan back-end, klaster dan aplikasi Anda turun untuk menghitung. Tujuan dari setiap solusi HA adalah untuk meningkatkan ketersediaan secara keseluruhan dengan menghilangkan sebanyak mungkin SPOF potensial. Jadi bagaimana Anda dapat menambah cluster VMware HA asli untuk menyediakan tingkat ketersediaan yang lebih besar? Untuk melindungi seluruh tumpukan Anda, dari perangkat keras hingga aplikasi, mulailah dengan VMware HA. Selanjutnya, Anda perlu cara untuk memantau dan melindungi aplikasi. Pengelompokan pada tingkat aplikasi (yaitu, dalam VM) adalah pilihan alami. Pastikan untuk memilih solusi pengelompokan yang mendukung replikasi data berbasis host (yaitu konfigurasi bersama-tidak ada) sehingga Anda tidak perlu melalui biaya dan kerumitan penyiapan replikasi berbasis SAN. Solusi replikasi SAN juga biasanya mengunci Anda menjadi vendor penyimpanan tunggal. Di atas itu, untuk mengelompokkan VM dengan menggunakan penyimpanan bersama, Anda biasanya perlu mengaktifkan Pemetaan Perangkat Baku (RDM). Ini berarti Anda kehilangan akses ke banyak fungsi VMware yang kuat, seperti vMotion. Pergi dengan konfigurasi cluster bersama-tidak ada menghilangkan tingkat penyimpanan sebagai SPOF. Pada saat yang sama memungkinkan Anda untuk menggunakan vMotion untuk memigrasi VM Anda antara host fisik. Itu menang-menang! Sebuah cluster bersama-tidak ada juga merupakan solusi yang sangat baik untuk pemulihan bencana karena VM siaga dapat berada di pusat data yang berbeda.

Tutup Semua Basa 

Aplikasi-pengelompokan failover, berlapis atas VMware HA, menawarkan yang terbaik dari kedua dunia. Anda dapat menikmati perlindungan perangkat keras dan kesadaran aplikasi built-in, fleksibilitas dan skalabilitas yang lebih besar, dan waktu pemulihan yang lebih cepat. Lebih baik lagi, solusinya tidak perlu merusak bank. Ingin memahami bagaimana Clustering Failover Dengan Ketersediaan Tinggi VMware dapat bekerja untuk proyek Anda? Periksa dengan SIOS. Direproduksi dengan izin dari LinuxClustering

Maksimalkan kinerja replikasi untuk Linux Clustering dengan Fusion-io

Tips Untuk Memaksimalkan Kinerja Replikasi Untuk Linux Clustering Dengan Fusion-io

Ketika kebanyakan orang berpikir tentang menyiapkan klaster, biasanya melibatkan dua atau lebih server, dan SAN – atau beberapa jenis penyimpanan bersama lainnya. SAN biasanya sangat mahal dan rumit untuk disiapkan dan dikelola. Juga, mereka secara teknis mewakili Potensi Titik Gagal (SPOF) potensial dalam arsitektur cluster Anda. Saat ini, semakin banyak orang yang beralih ke perusahaan seperti Fusion-io, dengan ioDrives yang cepat, untuk mempercepat aplikasi penting.  Perangkat penyimpanan ini ada di dalam server (yaitu "disk yang dibagikan"). Oleh karena itu tidak dapat digunakan sebagai disk klaster dengan banyak solusi pengelompokan tradisional. Untungnya, ada cara untuk Memaksimalkan kinerja replikasi untuk Linux Clustering dengan Fusion-io. Solusi yang memungkinkan Anda untuk membentuk kluster failover ketika tidak ada penyimpanan bersama yang terlibat – yaitu klaster "berbagi apa-apa".

Cluster Tradisional	Cluster "Dibagikan Tidak Ada"

Ketika memanfaatkan replikasi data sebagai bagian dari konfigurasi kluster, penting bahwa Anda memiliki cukup bandwidth sehingga data dapat direplikasi di seluruh jaringan secepat yang ditulis ke disk.  Berikut ini adalah kiat penyetelan yang memungkinkan Anda untuk memanfaatkan konfigurasi klaster "bersama apa-apa", ketika penyimpanan berkecepatan tinggi dilibatkan:

Jaringan

• Gunakan NIC 10Gbps: Perangkat penyimpanan berbasis flash dari Fusion-io (atau produk serupa lainnya dari OCZ, LSI, dll.) Mampu menulis data dengan kecepatan di HUNDREDS (750) MB / detik atau lebih.  NIC 1Gbps hanya dapat mendorong maksimum teoritis ~ 125 MB / detik, sehingga siapa pun yang memanfaatkan potensi ioDrive dapat dengan mudah menulis data lebih cepat daripada yang dapat didorong melalui koneksi jaringan 1 Gbps.  Untuk memastikan bahwa Anda memiliki bandwidth yang cukup antara server untuk memfasilitasi replikasi data real-time, NIC 10 Gbps harus selalu digunakan untuk membawa lalu lintas replikasi
• Aktifkan Bingkai Jumbo: Dengan asumsi bahwa Kartu Jaringan dan Switch Anda mendukungnya, memungkinkan bingkai jumbo dapat meningkatkan throughput jaringan Anda sekaligus mengurangi siklus CPU.  Untuk mengaktifkan frame jumbo, lakukan konfigurasi berikut (contoh dari server linux RedHat / CentOS / OEL)
  • ifconfig <interface_name> mtu 9000
  • Edit / etc / sysconfig / network-scripts / ifcfg- <interface_name> file dan tambahkan "MTU = 9000" sehingga perubahan tetap ada di reboot
  • Untuk memverifikasi operasi bingkai jumbo ujung-ke-ujung, jalankan perintah ini: ping -s 8900 -M lakukan <IP-dari-server lain>
• Ubah panjang antrian transmisi NIC:
  • / sbin / ifconfig <interface_name> txqueuelen 10000
  • Tambahkan ini ke /etc/rc.local untuk mempertahankan pengaturan di reboot

TCP / IP Tuning

• Ubah netdev_max_backlog NIC:
  • Set "net.core.netdev_max_backlog = 100000" di /etc/sysctl.conf
• Penyetelan TCP / IP lainnya yang telah terbukti meningkatkan kinerja replikasi:
  • Catatan: ini adalah nilai contoh dan beberapa mungkin perlu disesuaikan berdasarkan konfigurasi perangkat keras Anda
  • Edit /etc/sysctl.conf dan tambahkan parameter berikut:
    • net.core.rmem_default = 16777216
    • net.core.wmem_default = 16777216
    • net.core.rmem_max = 16777216
    • net.core.wmem_max = 16777216
    • net.ipv4.tcp_rmem = 4096 87380 16777216
    • net.ipv4.tcp_wmem = 4096 65536 16777216
    • net.ipv4.tcp_timestamps = 0
    • net.ipv4.tcp_sack = 0
    • net.core.optmem_max = 16777216
    • net.ipv4.tcp_congestion_control = htcp

Penyesuaian

Biasanya Anda juga perlu melakukan penyesuaian pada konfigurasi kluster Anda, yang akan bervariasi berdasarkan teknologi pengelompokan dan replikasi yang Anda putuskan untuk diterapkan.  Dalam contoh ini, saya menggunakan SteelEye Protection Suite untuk Linux (alias SPS, alias LifeKeeper), dari SIOS Technologies. Ini memungkinkan pengguna untuk membentuk cluster failover memanfaatkan hampir semua jenis penyimpanan back-end: Fibre Channel SAN, iSCSI, NAS, atau, yang paling relevan dengan artikel ini, disk lokal yang perlu disinkronkan / direplikasi secara real time antara node cluster.  SPS untuk Linux termasuk terintegrasi, fungsi replikasi data tingkat blok yang membuatnya sangat mudah untuk men-setup cluster ketika tidak ada penyimpanan bersama yang terlibat.

Rekomendasi

Untuk Memaksimalkan kinerja replikasi untuk Linux Clustering dengan Fusion-io, mari coba ini. SteelEye Protection Suite (SPS) untuk rekomendasi konfigurasi Linux:

• Alokasikan partisi disk kecil (~ 100 MB), yang terletak di drive Fusion-io untuk menempatkan file bitmap.  Buat filesystem di partisi ini dan pasang, misalnya, di / bitmap:
  • # mount | grep / bitmap
  • / dev / fioa1 pada / bitmap type ext3 (rw)
• Sebelum membuat mirror Anda, sesuaikan parameter berikut di / etc / default / LifeKeeper
  • Sisipkan: LKDR_CHUNK_SIZE = 4096
    • Nilai default adalah 64
  • Edit: LKDR_SPEED_LIMIT = 1500000
    • (Nilai default adalah 50000)
    • LKDR_SPEED_LIMIT menentukan bandwidth maksimum yang akan dilakukan ulang oleh resync – ini harus diatur cukup tinggi untuk memungkinkan resyncs berjalan pada kecepatan maksimum yang mungkin
  • Edit: LKDR_SPEED_LIMIT_MIN = 200000
    • (Nilai default adalah 20000)
    • LKDR_SPEED_LIMIT_MIN menentukan seberapa cepat resync harus dibiarkan pergi ketika ada I / O lain terjadi pada saat yang sama – sebagai aturan praktis, ini harus diset ke setengah atau kurang dari throughput tulis maksimum drive untuk menghindari kelaparan keluar aktivitas I / O normal ketika resync terjadi

Dari sini, lanjutkan dan buat mirror Anda dan konfigurasikan kluster seperti biasa. Tertarik untuk Memaksimalkan Kinerja Replikasi Untuk Linux Clustering Dengan Fusion-io, lihat apa lagi yang dapat ditawarkan SIOS. Direproduksi dengan izin dari LinuxClustering

Memindahkan Formulir Google di Antara Domain Google

Memindahkan Formulir Google di Antara Domain Google

Jika Anda seperti saya, Anda mungkin memiliki beberapa akun Google yang berbeda yang Anda kerjakan secara rutin. Baru-baru ini, saya membutuhkan bantuan dalam Memindahkan Formulir Google Antara Google Domains. Saya menghabiskan cukup banyak waktu untuk membuat Google Formulir. Hanya untuk menyadari saya melakukan ini saat masuk dengan akun pribadi saya daripada akun kerja saya. Saya benar-benar tidak ingin mengulang pekerjaan yang telah saya lakukan. Saya mencoba mencari jawaban secara online tetapi tidak ada yang spesifik yang muncul untuk mengatasi situasi saya. Itu tidak sulit dilakukan. Saya pikir saya akan menuliskannya untuk berjaga-jaga jika itu terjadi pada Anda. Saya menemukan perbaikan hanya dengan mencoba beberapa hal. Anggaplah ini adalah bentuk baru tanpa data. Dalam Memindahkan Formulir Google Antara Google Domain, yang harus Anda lakukan adalah sebagai berikut:

1. Tambahkan akun Google kedua Anda sebagai Kolaborator pada formulir
2. Masuk ke akun Google kedua Anda, buka formulir dan "Buat salinan" formulir

Itu dia! Sekarang Anda memiliki salinan formulir di akun Google kedua Anda. Tentu saja jika Anda sudah mengumpulkan beberapa data pada formulir pertama, Anda ingin menyalin Lembar itu. Taruh juga di akun Google kedua Anda dan lampirkan formulir ke salinan data tersebut. Pastikan untuk menghapus formulir lama agar Anda tidak secara tidak sengaja menggunakan formulir lama. Baca tips seperti Memindahkan Formulir Google Antara Google Domains di sini Diproduksi ulang dengan izin dari Clusteringformeremortals

Menerima Email Alerts Dengan SIOS DataKeeper

Menerima Email Alerts Dengan SIOS DataKeeper

Selama beberapa minggu terakhir, saya menulis seri 3-bagian tentang cara mengkonfigurasi pemberitahuan melalui email berdasarkan Penghitung Perfmon, Entri Log Event Sistem, dan Acara Khusus Layanan Windows Start atau Stop. Panduan ini relevan untuk lingkungan apa pun. Semua contoh saya diarahkan untuk memantau SIOS DataKeeper. Juga, ia memiliki beberapa permintaan pelanggan tertentu termasuk pemantauan Layanan DataKeeper SIOS, serta diberitahu jika RPO melebihi 5 detik. Saya juga memasukkan pemantauan peristiwa DataKeeper dasar yang ingin Anda ketahui. Video ini menunjukkan beberapa peringatan dalam aksi ini.

Memicu Pemberitahuan Email Saat Layanan Windows Tertentu Mulai Atau Berhenti

Step-By-Step: Cara Memicu Peringatan Email Saat Layanan Windows Tertentu Mulai Atau Berhenti Pada Windows Server 2016

Berbeda dari posting saya sebelumnya di mana saya menunjukkan kepada Anda bagaimana cara mengirim surel surel berdasarkan Windows EventID tertentu yang dicatat dalam Windows Event Log, kali ini saya akan membagikan cara Memicu Peringatan Email Saat Layanan Windows Khusus Mulai Atau Berhenti. Ini berfungsi baik untuk sebagian besar acara. Meskipun perhatikan itu tidak ideal jika Anda ingin diberitahu ketika Layanan Windows tertentu mulai atau berhenti. Ketika Layanan Windows mulai atau berhenti, EventID 7036 dari Sumber "Service Control Manager" dicatat dalam Log Sistem Windows. Sekarang kita bisa mengatur pemicu untuk mengirim email setiap kali EventID tersebut dicatat seperti yang saya jelaskan di posting saya sebelumnya. Namun, Anda mungkin tidak ingin menerima email saat SETIAP Windows Service dimulai atau berhenti. Untuk mendapatkan sedikit lebih spesifik, kita harus mengedit data XML yang terkait dengan Filter Acara Windows ketika kita mengatur pemicu. Ini untuk melihat sedikit lebih dalam pada Properti Acara dan menyaring di EventData yang hanya ditampilkan ketika Anda melihat Tampilan XML pada tab Rincian dari Peristiwa Windows. Pekerjaan ini telah diverifikasi pada Windows Server 2016, tetapi saya menduga itu seharusnya bekerja pada Windows Server 2012 R2 dan Windows Server 2019 juga. Jika Anda membuatnya bekerja di platform lain, silakan beri komentar dan beri tahu kami jika Anda harus mengubah apa pun.

Langkah 1 – Tulis A Script Powershell

Hal pertama yang perlu Anda lakukan adalah menulis skrip Powershell yang ketika dijalankan dapat mengirim email. Anda memerlukan email tersebut untuk memicu Pemberitahuan Email Saat Layanan Windows Khusus Mulai Atau Berhenti. Ada banyak cara untuk menyelesaikan tugas ini. Saya akan menunjukkan kepada Anda hanya 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 kata sandi ke akun email yang diautentikasi ke server SMTP dalam teks biasa. Jika Anda khawatir bahwa seseorang mungkin memiliki akses ke skrip Anda dan menemukan kata sandi Anda maka Anda akan ingin mengenkripsi kredensial Anda. Gmail membutuhkan dan koneksi SSL sehingga kata sandi Anda harus aman pada kabel, sama seperti klien email lainnya. Berikut ini contoh skrip Powershell yang ketika digunakan bersama dengan Penjadwal Tugas yang akan mengirim peringatan email secara otomatis ketika Peristiwa tertentu dicatat dalam Log Peristiwa Windows. Di lingkungan saya, saya menyimpan skrip ini ke C: Alerts ServiceAlert.ps1

$ filter = "* [System [EventID = 7036] dan EventData [Data = 'SIOS DataKeeper']]"
$ A = Dapatkan-WinEvent -LogName System -MaxEvents 1 -FilterXPath $ filter
$ 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` n $ 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, EventID, dan EventDataspecified. Kemudian mem-parsing event tersebut dan memberikan variabel EventID, Source, MachineName dan Message ke yang akan digunakan untuk menulis email. Anda akan melihat bahwa LogName, EventID dan EventData yang ditentukan sama dengan yang akan Anda tetapkan ketika Anda mengatur Tugas Terjadwal di Langkah 2. Sementara EventID, LogName mungkin akrab bagi Anda, EventData mungkin tidak familiar. Untuk melihat EventData yang terkait dengan Peristiwa tertentu, Anda harus membuka Acara di Peraga Peristiwa, lihat tab Detail dan kemudian pilih tampilan XML. Dari tampilan XML Anda dapat melihat semua data yang disertakan dengan suatu peristiwa. Di dekat bagian bawah XML Anda akan melihat berbagai data yang disebut <EventData>. Di sana Anda akan menemukan Data Peristiwa tambahan yang disimpan sebagai parameter. Seperti yang ditunjukkan di bawah ini, di "param1" kita akan menemukan nama Layanan yang berhenti atau dimulai.

Langkah 2 – Mengatur Jadwal Tugas

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 Anda dapat mulai menyiapkan pemicu yang memantau 7036 seperti yang saya jelaskan dalam artikel saya sebelumnya. Namun, antarmuka GUI Filter tidak memungkinkan kami untuk menentukan Nama Layanan yang disimpan di Param1 dari EventData seperti yang saya jelaskan sebelumnya. Untuk memantau hanya layanan tertentu yang kami inginkan, kami perlu mengedit XML secara langsung seperti yang ditunjukkan di bawah ini. Jika Anda lebih suka langsung melompat ke pengejaran, silakan menyalin XML saya di bawah dan ganti ‘SIOS DataKeeper’ dengan data peristiwa yang disimpan dalam param1 dari Peristiwa yang ingin Anda pantau.

   <QueryList>
   <Query Id = "0" Path = "System">
   <Pilih Path = "System"> * [System [(Level = 4 atau Level = 0) dan (EventID = 7036)]] 
   dan * [EventData [Data [1] = 'SIOS DataKeeper']] </ Select>
   </ Query>
   </ QueryList>

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) -Berbaiki Microsoft -Windows – Distributedcom Event ID: 10016 Error

Secara teori, jika Anda melakukan semuanya dengan benar, Anda sekarang harus mulai menerima email setiap saat salah satu peristiwa yang Anda pantau akan dicatat dalam log kejadian.  Namun, saya mengalami masalah izin aneh pada salah satu server saya yang harus saya alamat sebelum semuanya bekerja. Saya tidak yakin apakah Anda akan mengalami masalah ini, tetapi untuk berjaga-jaga apakah ini adalah perbaikannya. Dalam kasus saya ketika saya secara manual memicu acara, atau jika saya menjalankan skrip Powershell secara langsung, semuanya bekerja seperti yang diharapkan dan saya 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 yang dicatat dalam log peristiwa Sistem saya setiap kali saya mengharapkan Pemicu Tugas untuk mendeteksi peristiwa yang dicatat.

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 
address LocalHost (Menggunakan LRPC) 
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 dan termasuk instruksi tentang cara menekan kesalahan daripada memperbaikinya. Namun, saya cukup yakin kesalahan ini adalah penyebab kegagalan saya saat ini untuk dapat mengirim pemberitahuan email dari Acara Terjadwal yang dipicu dari entri Log Peristiwa yang dipantau. Saya perlu memperbaikinya. 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. Pada 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, tetapi saya pikir sebaiknya saya menulis semuanya jika itu terjadi lagi karena saya butuh waktu lama untuk mengetahuinya.

Langkah 4- Mengotomasi Penempatan

Jika Anda perlu mengaktifkan peringatan yang sama pada beberapa sistem, Anda cukup mengekspor Tugas Anda ke file XML dan Impor di sistem lain. Ekspor [/ caption] Impor [/ caption] Atau bahkan lebih baik lagi , otomatisasi 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 "DataKeeper Service Alerts" -Pengguna datakeeper  dave 
-Password MyDomainP @ 55W0rd –Force

Akhirnya, Sebuah Pemberitahuan Email Ketika Layanan Windows Khusus Mulai Atau Berhenti

Semoga apa yang telah saya berikan akan memberi Anda semua yang Anda perlukan untuk mulai menerima surel pemberitahuan pemberitahuan tentang Layanan Windows mana yang membuat Anda terjaga pada malam hari. Ini menyimpulkan seri saya tentang konfigurasi pemberitahuan email. Dalam seri ini saya telah membahas secara tertutup konfigurasi peringatan berdasarkan penghitung Perfmon, Entri Log Peristiwa dan dalam artikel ini peristiwa Windows Service Start dan Stop. Tentu saja Anda dapat memperpanjang skrip Powershell yang dijelaskan dalam artikel ini untuk melakukan lebih dari sekadar mengirim email. Banyak peringatan atau penghentian layanan yang tidak diharapkan pada umumnya memerlukan beberapa perbaikan. Mengapa tidak skrip saja langkah-langkah pemulihan dan biarkan tugas yang dipicu mengurus masalah untuk Anda? Secara pribadi saya menyarankan Anda berinvestasi di SCOM, SolarWinds atau Sistem Manajemen Perusahaan lainnya, tetapi jika itu tidak ada di kartu tempat Anda bekerja, maka artikel ini dapat membantu dalam keadaan darurat. Untuk mempelajari lebih banyak kiat tentang Email Alert Ketika Layanan Windows Khusus Mulai Atau Berhenti, hubungi kami Direproduksi dengan izin dari Clusteringformeremortals.com