SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • Products
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • การทดสอบอาหารสัตว์
  • ข่าวสารและกิจกรรม
  • ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์
  • เรื่องราวความสำเร็จ
  • ติดต่อเรา
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor

พฤศจิกายน 10, 2018 by Jason Aw Leave a Comment

เรียกใช้การแจ้งเตือนทางอีเมลจากการตรวจสอบประสิทธิภาพของ Windows

ทีละขั้นตอน: วิธีเรียก Trigger Alerts จาก Windows Performance Monitor

ทีละขั้นตอน: วิธีเรียก Trigger Alerts จาก Windows Performance Monitor

เรียกใช้การแจ้งเตือนทางอีเมลจากการตรวจสอบประสิทธิภาพของ Windows

ทีละขั้นตอน: วิธีเรียก Trigger Alerts จาก Windows Performance Monitor

การแจ้งเตือนตัวนับประสิทธิภาพของ Windows สามารถกำหนดค่าให้เรียกใช้ตัวตรวจสอบประสิทธิภาพ (Perfmon) Counter ผ่านการใช้ชุดผู้รวบรวมข้อมูลที่กำหนดโดยผู้ใช้ อย่างไรก็ตามหากคุณต้องการรับการแจ้งเตือนทางอีเมลเมื่อมีการแจ้งเตือนคุณจะต้องใช้ Perfmon, Task Scheduler และ Powershell ที่ดี ทำตามขั้นตอนด้านล่างเพื่อเรียกใช้การแจ้งเตือนทางอีเมลจาก Windows Performance Monitor

ขั้นตอนที่ 1 – เขียนสคริปต์ Powershell

สิ่งแรกที่คุณต้องทำก็คือเขียนสคริปต์ Powershell ซึ่งเมื่อรันสามารถส่งอีเมลได้ ขณะที่ค้นคว้าสิ่งนี้ฉันค้นพบหลายวิธีเพื่อให้บรรลุภารกิจนี้ สิ่งที่ฉันกำลังจะแสดงให้คุณเห็นเป็นเพียงวิธีหนึ่ง แต่คุณสามารถทดลองและใช้สิ่งที่เหมาะสมกับสภาพแวดล้อมของคุณได้ ในห้องทดลองของฉันฉันไม่ได้ใช้เซิร์ฟเวอร์ SMTP ของตนเอง ฉันเขียนสคริปต์ที่สามารถใช้ประโยชน์จากบัญชี Gmail ของฉันได้ คุณจะเห็นในสคริปต์ Powershell ของฉันรหัสผ่านไปยังบัญชีอีเมลที่ตรวจสอบสิทธิ์กับเซิร์ฟเวอร์ SMTP อยู่ในรูปแบบข้อความล้วน หากคุณกังวลว่าบางคนอาจเข้าถึงสคริปต์ของคุณและค้นพบรหัสผ่านของคุณคุณจะต้องการเข้ารหัสข้อมูลรับรองของคุณ Gmail ต้องการและการเชื่อมต่อ SSL รหัสผ่านของคุณควรปลอดภัยบนสายเช่นเดียวกับโปรแกรมรับส่งอีเมลอื่น ๆ นี่คือตัวอย่างของสคริปต์ Powershell เมื่อใช้ร่วมกับ Task Scheduler และ Perfmon ร่วมกันสามารถส่งการแจ้งเตือนทางอีเมลโดยอัตโนมัติเมื่อมีการปฏิบัติตามเงื่อนไขข้อผิดพลาดของตัวนับของเกณฑ์ผู้ใช้ที่กำหนดไว้ ในสภาพแวดล้อมของฉันฉันตั้งค่านี้เป็น C: Alerts Alerts.ps1

$ 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 = "การแจ้งเตือนจาก $ FileName"
$ body = "ข้อมูลและเวลาของการแจ้งเตือน: $ dtandtime`nPerfmon Counter: $ ctr_value`n ค่าเกณฑ์: $ threshold` nCurrent Value: $ 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, $ หัวเรื่อง, $ Body)

ตัวอย่างอีเมลที่สร้างขึ้นจากสคริปต์ Powershell นั้นมีลักษณะดังนี้ วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor คุณอาจสังเกตเห็นว่าสคริปต์ Powershell นี้ใช้อาร์กิวเมนต์ทั้งสี่ข้อ นอกจากนี้ยังกำหนดให้ตัวแปรที่ใช้ในการส่งออก จะบันทึกชื่อคอมพิวเตอร์ให้เป็นตัวแปรที่ใช้เป็นส่วนหนึ่งของเอาท์พุท ด้วยการทำเช่นนี้สคริปต์สามารถใช้เพื่อส่งอีเมลไปยังตัวเตือน Perfmon Alert และเซิร์ฟเวอร์ใดก็ได้โดยไม่ต้องปรับแต่งเพิ่มเติม

ขั้นตอนที่ 2 – ตั้งค่างานที่กำหนดเวลาไว้

ใน Task Scheduler เราจะสร้างงานใหม่ตามที่แสดงในภาพหน้าจอต่อไปนี้ วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor กำหนดชื่องานคุณจะต้องจดจำไว้สำหรับขั้นตอนต่อไป วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor โปรดสังเกตว่าไม่มี Triggers ภารกิจนี้จะถูกเรียกใช้ผ่านการแจ้งเตือนเคาน์เตอร์ Perfmon ซึ่งเราจะตั้งค่าในขั้นตอนที่ 3 วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor คุณต้องการกำหนดการกระทำใหม่ในแท็บการกระทำ การดำเนินการจะเป็นการเริ่มต้นโปรแกรมและใช้อินพุทต่อไปนี้ โปรดปรับเปลี่ยนสภาพแวดล้อมเฉพาะของคุณ โปรแกรมสคริปต์: C: Windows System32 WindowsPowerShell v1.0 powershell.exe เพิ่มอาร์กิวเมนต์: -File C: Alerts Alerts.ps1 $ (Arg0) วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor

ขั้นที่ 3 – สร้างตัวนับประสิทธิภาพ

สร้างชุดเครื่องมือเก็บข้อมวิธีเรียก Trigger Email Alerts จาก Windows Performance Monitorูวิธีเรียก Trigger Email Alerts จาก Windows Performance Monitorลวิธีเรียก Trigger Email Alerts จาก Windows Performance Monitorใหม่เพิ่มตัวนับประสิทธิภาพใด ๆ ที่คุณต้องการตรวจสอบและตั้งค่าเกณฑ์การแจ้งเตือน วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor เมื่อคุณสร้าง Data Collector Set เข้าไปในคุณสมบัติของมันแล้วตรวจสอบให้แน่ใจว่าได้ตั้งค่า Alerting threshold และ Sample Interval ไว้อย่างถูกต้องสำหรับแต่ละ Performance Counter โปรดจำไว้ว่าถ้าคุณลองตัวอย่างทุกๆ 10 วินาทีคุณควรคาดหวังว่าจะได้รับอีเมลทุกๆ 10 วินาทีตราบใดที่ตัวนับประสิทธิภาพเกินเกณฑ์ที่คุณตั้งไว้ วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor ถ้าคุณเลือกบันทึกรายการในแฟ้มบันทึกเหตุการณ์ของแอพลิเคชันไม่คาดว่าจะเห็นรายการใด ๆ ในแฟ้มบันทึกเหตุการณ์ของแอพลิเคชันปกติ จะถูกเขียนลงในบันทึกของ Microsoft-Windows-Diagnosis-PLA / Operational ในไดเร็กทอรีล็อกแอ็พพลิเคชันและบริการ วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor จากนั้นเราจะต้องตั้งค่าภารกิจการแจ้งเตือนที่จะเรียกใช้ Task Scheduled (EmailAlert) ที่เราสร้างขึ้นในขั้นตอนที่ 2 คุณเห็นว่าเรายังผ่านบางส่วนของอาร์กิวเมนต์งานที่ใช้โดยสคริปต์ Powershell เพื่อกำหนดอีเมลที่มีเงื่อนไขข้อผิดพลาดที่แน่นอนที่เกี่ยวข้องกับการแจ้งเตือน วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor เมื่อมีการกำหนดค่าตัวเก็บรวบรวมข้อมูลอย่างถูกต้องคุณจะต้องเริ่มต้น วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor หากคุณกำหนดค่าทุกอย่างอย่างถูกต้องคุณควรเริ่มเห็นอีเมลทุกครั้งที่พบเกณฑ์การแจ้งเตือน ถ้าดูเหมือนว่าไม่ได้ผลให้ตรวจสอบสิ่งต่อไปนี้ …

  • เรียกใช้สคริปต์ Powershell ด้วยตนเองเพื่อให้มั่นใจว่าใช้ได้ คุณอาจต้องตั้งค่าบางตัวแปรด้วยตนเองเพื่อวัตถุประสงค์ในการทดสอบ ในกรณีของฉันต้องใช้การปรับแต่งเล็กน้อยเพื่อให้สคริปต์ Powershell ทำงานได้ถูกต้องดังนั้นให้เริ่มต้นด้วย
  • ตรวจสอบประวัติงานเพื่อให้แน่ใจว่า Alert Counter กำลังเรียกใช้ Task วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor
  • เรียกใช้งานด้วยตนเองและดูว่าจะเรียก Powershell หรือไม่

ขั้นที่ 4 – ตั้งค่าตัวนับประสิทธิภาพการทำงานให้โดยอัตโนมัติ

ถ้าคุณคิดว่าคุณพร้อมที่จะเรียกใช้การแจ้งเตือนทางอีเมลจาก Windows Performance Monitor คุณจะมีขั้นตอนอีกขั้นหนึ่ง เมื่อใดก็ตามที่คุณรีบูตเซิร์ฟเวอร์การแจ้งเตือนเคาน์เตอร์ Perfmon จะไม่เริ่มทำงานโดยอัตโนมัติ เพื่อให้สามารถรีบูตเครื่องได้คุณต้องรันคำสั่งต่อไปนี้ที่พรอมต์คำสั่ง หมายเหตุ "การแจ้งเตือน" ที่อ้างอิงในสคริปต์ด้านล่างคือชื่อของผู้ใช้ของฉันที่กำหนดไว้ชุดเครื่องเก็บข้อมูล

schtasks / create / tn การแจ้งเตือน / sc onstart / tr "logman start Alerts" / ru ระบบ

มีบางกรณีขอบที่คุณอาจต้องสร้าง Trigger อื่นเพื่อเริ่มชุด Data Collector ตัวอย่างเช่นเคาน์เตอร์ SIOS DataKeeper Perfmon เก็บเฉพาะข้อมูลจากแหล่งที่มาของกระจก ถ้าคุณพยายามเริ่มต้นชุดรวบรวมข้อมูลบนเซิร์ฟเวอร์เป้าหมายคุณจะเห็นว่าไม่ได้เริ่มทำงาน อย่างไรก็ตามหากกลุ่มของคุณล้มเหลวเหนือเป้าหมายเดิมตอนนี้จะกลายเป็นแหล่งที่มาของกระจกดังนั้นคุณจะต้องการเริ่มต้นการตรวจสอบเคาน์เตอร์ DataKeeper ในแหล่งที่มาใหม่ คุณสามารถสร้างทรัพยากรสคริปต์ทั่วไปของคลัสเตอร์ที่เริ่มต้นชุดตัวเก็บรวบรวมข้อมูลเมื่อมีการโอนย้ายข้อมูลล้มเหลว แต่เป็นหัวข้อสำหรับเวลาอื่น วิธีที่ง่ายกว่านี้เพื่อให้แน่ใจว่า Counter ทำงานอยู่ใน Source ใหม่คือการตั้งค่า Task Scheduled ที่ถูกทริกเกอร์โดย EventID ที่ระบุว่าเซิร์ฟเวอร์กำลังเป็นแหล่งที่มาของกระจก ในกรณีนี้ให้ตั้งค่าทริกเกอร์บนทั้งสองระบบเพื่อให้แต่ละครั้ง EventID 23 เกิดทริกเกอร์เรียกใช้ Logman เพื่อเริ่มชุด Data Collector ทุกครั้งที่เกิด failover เกิดขึ้น Event ID 23 จะถูกบันทึกลงในระบบใหม่เมื่อมันกลายเป็น source ดังนั้นชุด Data Collector จะเริ่มทำงานโดยอัตโนมัติ วิธีเรียก Trigger Email Alerts จาก Windows Performance Monitorวิธีเรียก Trigger Email Alerts จาก Windows Performance Monitor ตอนนี้คุณสามารถรับอีเมลแจ้งเตือนได้โดยตรงจากเซิร์ฟเวอร์ของคุณหากเคาน์เตอร์ Perfmon ใด ๆ ที่คุณสนใจจะเริ่มต้นจากมือ

คุณชอบอ่านวิธีการเรียกใช้การแจ้งเตือนทางอีเมลจากการตรวจสอบประสิทธิภาพของ Windows หรือไม่? คลิกที่นี่เพื่อหาข้อมูลเพิ่มเติม. ทำซ้ำโดยได้รับอนุญาตจาก Clusteringformeremortals.com

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: การตรวจสอบประสิทธิภาพของ Windows, เรียกเตือนอีเมลจาก Windows Performance Monitor

วิธีเรียก Trigger Email Alerts จาก Windows Event โดยใช้ Windows Server 2016

พฤศจิกายน 9, 2018 by Jason Aw Leave a Comment

เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016

ทีละขั้นตอน: วิธีการเรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows ที่มีรายละเอียดของเหตุการณ์โดยใช้ Windows Server 2016

บทนำ

การแจ้งเตือนอีเมลแจ้งเตือนจากเหตุการณ์ Windows โดยใช้ Windows Server 2016 ต้องการเพียงไม่กี่ขั้นตอน ระบุการดำเนินการที่จะเกิดขึ้นเมื่อ Task ถูกเรียกใช้งาน เนื่องจาก Microsoft ได้ตัดสินใจยกเลิกการใช้งาน "ส่งอีเมล" ตัวเลือกเดียวที่เรามีคือ Start a Program ในกรณีของเราโปรแกรมดังกล่าวจะเป็นสคริปต์ Powershell เพื่อรวบรวมข้อมูลบันทึกเหตุการณ์และแยกวิเคราะห์ ด้วยวิธีนี้เราจะสามารถส่งอีเมลที่มีรายละเอียด Log Event ที่สำคัญ งานนี้ได้รับการยืนยันใน Windows Server 2016 แต่ฉันสงสัยว่าควรจะทำงานบน Windows Server 2012 R2 และ Windows Server 2019 เช่นกัน ถ้าคุณใช้งานได้กับแพลตฟอร์มอื่นโปรดแสดงความคิดเห็นและแจ้งให้เราทราบหากคุณต้องเปลี่ยนแปลงอะไร

ขั้นตอนที่ 1- เขียนสคริปต์ Powershell

สิ่งแรกที่ต้องทำคือการเขียนสคริปต์ Powershell ที่เมื่อรันสามารถส่งอีเมลได้ ขณะที่ค้นคว้าข้อมูลนี้ฉันค้นพบวิธีต่างๆมากมายในการทำให้งานนี้สำเร็จดังนั้นสิ่งที่ฉันกำลังจะแสดงให้คุณเห็นเป็นเพียงวิธีหนึ่ง แต่คุณสามารถทดลองและใช้สิ่งที่เหมาะสมกับสภาพแวดล้อมของคุณได้ ในห้องทดลองของฉันฉันไม่ได้ใช้เซิร์ฟเวอร์ SMTP ของตนเองดังนั้นฉันจึงต้องเขียนสคริปต์ที่สามารถใช้ประโยชน์จากบัญชี Gmail ของฉันได้ คุณจะเห็นในสคริปต์ Powershell ของฉันว่ารหัสผ่านไปยังบัญชีอีเมลที่ตรวจสอบสิทธิ์กับเซิร์ฟเวอร์ SMTP อยู่ในรูปแบบข้อความล้วน หากคุณกังวลว่าอาจมีบุคคลอื่นเข้าถึงสคริปต์ของคุณและค้นพบรหัสผ่านของคุณให้เข้ารหัสข้อมูลประจำตัวของคุณ Gmail ต้องการและการเชื่อมต่อ SSL รหัสผ่านของคุณควรปลอดภัยบนสายเช่นเดียวกับโปรแกรมรับส่งอีเมลอื่น ๆ ฉันมีตัวอย่างของสคริปต์ Powershell เมื่อใช้ร่วมกับ Task Scheduler ระบบจะส่งอีเมลแจ้งเตือนโดยอัตโนมัติเมื่อมีการบันทึกเหตุการณ์ใด ๆ ไว้ใน Windows Event Log ในสภาพแวดล้อมของฉันฉันบันทึกสคริปต์นี้ไว้ที่ C: Alerts DataKeeper.ps1

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

$ A = Get-WinEvent -MaxEvents 1 -FilterHashTable @ {Logname = "ระบบ"; ID = $ EventId}
$ Message = $ A.Message
$ EventID = $ A.Id
$ MachineName = $ A.MachineName
$ แหล่งที่มา = $ A.ProviderName


$ EmailFrom = "sios@medfordband.com"
$ EmailTo = "sios@medfordband.com"
$ Subject = "การแจ้งเตือนจาก $ MachineName"
$ Body = "EventID: $ EventID`nSource: $ แหล่งที่มา` nMachineName: $ MachineName `nMessage: $ ข้อความ"
$ 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, $ หัวเรื่อง, $ Body)

ตัวอย่างอีเมลที่สร้างขึ้นจากสคริปต์ Powershell นั้นมีลักษณะดังนี้ เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016 คุณอาจสังเกตเห็นว่าสคริปต์ Powershell นี้ใช้ cmdlet Get-WinEvent เพื่อคว้ารายการบันทึกเหตุการณ์ล่าสุดจาก LogName, Source และ eventIDs ที่ระบุไว้ จากนั้นจะแยกวิเคราะห์เหตุการณ์และกำหนด EventID, Source, MachineName และ Message ให้เป็นตัวแปรที่จะใช้ในการเขียนอีเมล คุณจะเห็นว่า LogName, Source และ eventIDs ที่ระบุจะเหมือนกับที่คุณจะระบุเมื่อคุณตั้งค่า Scheduled Task ในขั้นตอนที่ 2

ขั้นตอนที่ 2 – ตั้งค่างานที่กำหนดเวลาไว้

ใน Task Scheduler สร้างงานตามที่แสดงในภาพหน้าจอต่อไปนี้

  1. สร้างงานตเรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016รวจสอบว่างานถูกตั้งค่าเป็นเรียกใช้ว่าผู้ใช้ล็อกอินหรือไม่ เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016
  2.  ในแท็บทริกเกอร์เลือกสร้างใหม่เพื่อสร้าง Trigger ซึ่งจะเริ่มงาน "On a Event" ในตัวอย่างของฉันฉันจะสร้างเหตุการณ์ที่เรียกใช้เวลาใด ๆ DataKeeper (extmirr) บันทึกเหตุการณ์ที่สำคัญเข้าสู่บันทึกของระบบ เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016 สร้างเหตุการณ์แบบกำหนดเองและตัวกรองกิจกรรมใหม่ดังที่แสดงด้านล่เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016าง … สำหรับทริกเกอร์ของฉันฉันเรียกใช้งานการตรวจสอบโดยปกติของ SIOS DataKeeper (ExtMirr) EventIDs 16, 20, 23,150,219,220 คุณจะต้องตั้งค่ากิจกรรมเพื่อเรียกใช้กิจกรรมเฉพาะที่คุณต้องการตรวจสอบ คุณสามารถใส่ทริกเกอร์หลายรายการในงานเดียวกันได้หากต้องการรับการแจ้งเตือนเกี่ยวกับเหตุการณ์ที่มาจากบันทึกหรือแหล่งที่มาต่างๆ
    เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016
    สร้างตัวกรองกิจกรรมใหม่

     

  3. เมื่อมีการกำหนดค่าทริกเกอร์เหตุการณ์คุณจะต้องกำหนดค่าแอ็คชันที่เกิดขึ้นเมื่อมีการเรียกใช้งานเหตุการณ์ ในกรณีของเราเราจะเรียกใช้สคริปต์ Powershell ที่เราสร้างขึ้นในขั้นตอนที่ 1เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016
  4. พารามิเตอร์สภาวะดีฟอลต์ควรมีค่าเพียงพอ เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016
  5. และสุดท้ายบนแท็บการตั้งค่าให้แน่ใจว่าคุณอนุญาตให้งานสามารถเรียกใช้ตามต้องการและ "คิวใหม่อินสแตนซ์" ถ้างานกำลังทำงานอยู่

    เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016

ขั้นที่ 3 (ถ้าจำเป็น) – แก้ไขรหัสเหตุการณ์ของ Microsoft Windows DistributedCOM: 10016

ในทางทฤษฎีถ้าคุณทำทุกอย่างถูกต้องคุณควรสามารถเรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016 อย่างไรก็ตามฉันได้รับสิทธิ์ในการอนุญาตแปลก ๆ จากเซิร์ฟเวอร์ของฉัน นี่คือการแก้ไขปัญหาของฉัน หวังว่ามันจะช่วยคุณได้เช่นกัน ในกรณีของฉันเมื่อฉันเรียกใช้เหตุการณ์ด้วยตนเองหรือถ้าฉันเรียกใช้สคริปต์ Powershell โดยตรงทุกอย่างทำงานตามที่คาดไว้และฉันจะได้รับอีเมล แต่ถ้าหนึ่ง EventIDs ถูกตรวจสอบเข้าสู่บันทึกเหตุการณ์จะไม่ส่งผลให้มีการส่งอีเมล เงื่อนงำเดียวที่ฉันมีคือรหัสเหตุการณ์: 10016 ถูกบันทึกไว้ในล็อกเหตุการณ์ระบบของฉันทุกครั้งที่ฉันคาด Task Trigger ตรวจพบเหตุการณ์ที่บันทึกไว้

ชื่อการเข้าสู่ระบบ: ระบบ
แหล่งที่มา: Microsoft-Windows-DistributedCOM
วันที่: 10/27/2018 5:59:47 PM
รหัสเหตุการณ์: 10016
ประเภทงาน: ไม่มี
ระดับ: ข้อผิดพลาด
คำสำคัญ: คลาสสิก
ผู้ใช้: DATAKEEPER  dave
คอมพิวเตอร์: sql1.datakeeper.local
รายละเอียด:
การตั้งค่าสิทธิ์เฉพาะแอปพลิเคชันไม่ได้ให้สิทธิ์การเปิดใช้งาน Local Activation 
สำหรับแอ็พพลิเคชันเซิร์ฟเวอร์ COM ที่มี CLSID 
{D63B10C5-BB46-4990-A94F-E40B9D520160}
และ APPID 
{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
ให้กับผู้ใช้ DATAKEEPER  dave SID (S-1-5-21-25339xxxxx-208xxx580-6xxx06984-500) 
จากที่อยู่ LocalHost 
(ใช้ LRPC) ทำงานในคอนเทนเนอร์ของแอ็พพลิเคชัน SID (Unavailable) 
สิทธิ์การรักษาความปลอดภัยนี้สามารถแก้ไขได้โดยใช้เครื่องมือการจัดการบริการคอมโพเนนต์

ผลการค้นหา Google จำนวนมากสำหรับข้อผิดพลาดดังกล่าวบ่งชี้ว่าข้อผิดพลาดนั้นไม่เป็นพิษเป็นภัย รวมถึงคำแนะนำในการปราบปรามข้อผิดพลาดแทนที่จะแก้ไข อย่างไรก็ตามผมค่อนข้างแน่ใจว่าข้อผิดพลาดนี้เป็นสาเหตุของความล้มเหลวในปัจจุบันของฉัน ถ้าฉันไม่สามารถแก้ไขได้ถูกต้องจะเป็นการยากที่จะเรียกใช้การแจ้งเตือนทางอีเมลจาก Windows โดยใช้ Windows Server 2016 หลังจากการค้นหามากฉันสะดุดเมื่ออภิปรายกลุ่มข่าวนี้  คำตอบจาก Marc Whittlesey ชี้ไปในทิศทางที่ถูกต้อง นี่คือสิ่งที่เขาเขียน …

มีคีย์รีจิสทรี 2 ชุดที่คุณต้องตั้งค่าสิทธิ์ก่อนที่คุณจะไปที่การกำหนดค่า DCOM ในบริการคอมโพเนนต์: คีย์ CLSID และปุ่ม APPID

ผมขอแนะนำให้ทำตามขั้นตอนต่างๆเพื่อแก้ไขปัญหา:

1 กดปุ่ม Windows + R และพิมพ์ regedit แล้วกด Enter 2 ไปที่ HKEY_Classes_Root CLSID * CLSID * 3 คลิกขวาที่ไฟล์แล้วเลือกสิทธิ์ 4 คลิกล่วงหน้าและเปลี่ยนเจ้าของเป็นผู้ดูแลระบบ คลิกกล่องที่จะปรากฏใต้บรรทัดเจ้าของ 5 ใช้การควบคุมแบบเต็มรูปแบบ 6 ปิดแท็บจากนั้นไปที่ APPID * HKEY_LocalMachine Software Classes AppID * 7 คลิกขวาที่ไฟล์แล้วเลือกสิทธิ์ 8 คลิกล่วงหน้าและเปลี่ยนเจ้าของให้ผู้ดูแลระบบ 9 คลิกช่องที่จะปรากฏใต้บรรทัดเจ้าของ 10 คลิกใช้และให้สิทธิ์การควบคุมแบบเต็มรูปแบบแก่ผู้ดูแลระบบ 11 ปิดแท็บทั้งหมดและไปที่เครื่องมือการดูแลระบบ 12 เปิดบริการส่วนประกอบ 13 คลิกคอมพิวเตอร์คลิกคอมพิวเตอร์ของฉันแล้วคลิก DCOM 14 ค้นหาบริการที่เกี่ยวข้องซึ่งปรากฏในโปรแกรมดูข้อผิดพลาด 15 คลิกขวาที่คุณสมบัติแล้วคลิกคุณสมบัติ 16 คลิกแท็บความปลอดภัยแล้วคลิก Add User, Add System จากนั้นใช้ 17 ทำเครื่องหมายที่ช่อง Enable local ดังนั้นใช้คีย์ที่เกี่ยวข้องที่นี่และ DCOM Config จะทำให้คุณสามารถเข้าถึงพื้นที่ที่เป็นสีเทาได้: CLSID {DATBLE {9CA88EE3-ACB7-47C8-AFC4-AB702511C276} {D63B10C5-BB46-4990-A94F-E40B9D520160}

ฉันสามารถทำตามขั้นตอน 1-15 คำทุกคำสวย ๆ อย่างไรก็ตามเมื่อฉันไปถึงขั้นตอนที่ 16 ฉันไม่สามารถบอกได้อย่างแท้จริงว่าเขาต้องการให้ฉันทำอะไร ตอนแรกฉันได้รับ DATAKEEPER dave บัญชีผู้ใช้ Full Control ไปยัง RuntimeBroker แต่ไม่สามารถแก้ไขปัญหาได้ สุดท้ายฉันเลือก "ใช้ค่าเริ่มต้น" กับทั้งสามสิทธิ์และแก้ไขปัญหา เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016 ฉันไม่แน่ใจว่าเหตุใดจึงเกิดขึ้น ฉันคิดว่าฉันดีกว่าเขียนมันทั้งหมดลงในกรณีที่เกิดขึ้นอีกครั้งเพราะเอาฉันในขณะที่จะคิดออก

ขั้นตอนที่ 4 – ใช้การปรับใช้อัตโนมัติ

ถ้าคุณต้องการเปิดใช้งานการแจ้งเตือนเดียวกันในหลายระบบให้ส่งออกงานของคุณไปยังไฟล์ XML และนำเข้าในระบบอื่น ๆ ของคุณ เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016 หรือดียิ่งกว่านี้ ทำให้การนำเข้าเป็นส่วนหนึ่งของกระบวนการสร้างของคุณโดยใช้สคริปต์ Powershell หลังจากทำไฟล์ XML ของคุณพร้อมกับแชร์ไฟล์ดังที่แสดงในตัวอย่างต่อไปนี้

PS C: > ลงทะเบียน-ScheduledTask-Xml (รับเนื้อหา 
'\ myfileshare  tasks  DataKeeperAlerts.xml' | ออกสตริง) 
-TaskName "DataKeeperAlerts" - ผู้ใช้ datakeeper  dave 
-Password MyDomainP @ 55W0rd -Force

เรียกใช้การแจ้งเตือนทางอีเมลจากเหตุการณ์ Windows โดยใช้ Windows Server 2016

ในโพสต์ต่อไปของฉันฉันจะแสดงวิธีรับการแจ้งเตือนเมื่อบริการที่ระบุเริ่มหรือหยุด แน่นอนคุณสามารถตรวจสอบ EventID 7036 จาก Service Control Monitor ได้ แต่จะแจ้งให้คุณทราบเมื่อใดก็ตามที่บริการใด ๆ เริ่มหรือหยุดลง เราจำเป็นต้องขุดลึกขึ้นเล็กน้อยเพื่อให้แน่ใจว่าเราได้รับแจ้งเฉพาะเมื่อบริการที่เราสนใจเกี่ยวกับการเริ่มต้นหรือหยุดเท่านั้น หากคุณสนใจในบทความเกี่ยวกับวิธีใช้ของเราเช่นการแจ้งเตือนอีเมลแจ้งเตือนจากเหตุการณ์ Windows โดยใช้ Windows Server 2016 ให้คลิกที่นี่ ทำซ้ำจาก Clusteringformeremortals.com

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: Windows Server 2016, เรียกเตือนอีเมลจาก Windows Performance Monitor

Azure Outage Mortem ส่วนที่ 3

พฤศจิกายน 8, 2018 by Jason Aw Leave a Comment

สีฟ้าหมดสภาพโพสต์ชันสูตร

สรุปข้อเขียนของ Azure Post-Mortem ตอนที่ 3

โพสต์บล็อกก่อนหน้าของฉัน Azure Outage Post-Mortem – ตอนที่ 1 และ Azure Outage Post-Mortem ส่วนที่ 2 ได้ตั้งสมมติฐานขึ้นอยู่กับข้อมูลที่ จำกัด จากบล็อกโพสต์และ Twitter ฉันเพิ่งเข้าร่วมเซสชันที่ Ignite ซึ่งให้ความชัดเจนมากขึ้นเกี่ยวกับสิ่งที่เกิดขึ้นจริง ในวันพรุ่งนี้คุณควรจะสามารถดูเซสชั่นได้เอง BRK3075 – การเตรียมพร้อมสำหรับสิ่งที่ไม่คาดคิด: กายวิภาคของปัญหา Azure การวิเคราะห์สาเหตุหลักอย่างเป็นทางการจะมีการเผยแพร่ในเร็ว ๆ นี้ ในระหว่างนี้นี่เป็นข้อมูลที่รวบรวมได้จากเซสชั่น

สาเหตุ

จากการชันสูตรพลิกศพที่เกิดจากสภาพอากาศสีฟ้าการดับไฟไม่เกิดจากการชนฟ้าผ่าตามที่รายงานไว้ก่อนหน้านี้ แทนเนื่องจากลักษณะของพายุมี sags พายุไฟฟ้าและฟู เป็นผลให้มันล็อคออกโรงงานเย็นในดาต้าเซ็นเตอร์ที่ 1 ในช่วงหยุดพักครั้งแรกนี้พวกเขาสามารถกู้คืนเครื่องทำน้ำเย็นได้อย่างรวดเร็วโดยไม่มีผลกระทบที่เห็นได้ชัด หลังจากนั้นไม่นานมีการหยุดทำงานครั้งที่สองที่ศูนย์ข้อมูลที่สองซึ่งไม่สามารถกู้คืนได้อย่างถูกต้อง ที่เริ่มต้นชุดที่โชคร้ายของเหตุการณ์

2nd Outage

ในระหว่างการหยุดทำงานนี้ไมโครซอฟท์กล่าวว่า "วิศวกรไม่ได้ทำการวิเคราะห์ข้อมูลอย่างถูกต้อง – การกู้คืนโรงงานของเครื่องทำความเย็นไม่ได้ถูกจัดลำดับความสำคัญไว้" มีการแจ้งเตือนจำนวนมากถูกเรียกใช้ในขณะนี้ น่าเสียดายที่เครื่องทำความเย็นแบบออฟไลน์ไม่ได้รับความสำคัญที่ควรมี RCA ว่าเหตุใดจึงเกิดเหตุการณ์เช่นนี้อยู่ระหว่างการตรวจสอบ ไมโครซอฟท์ระบุว่าระบบทำความเย็นที่ซ้ำซ้อนแน่นอนอยู่ในสถานที่ อย่างไรก็ตามระบบระบายความร้อนไม่ได้รับการตั้งค่าให้ failover โดยอัตโนมัติ อุปกรณ์ใหม่ที่เพิ่งติดตั้งใหม่ไม่ได้รับการทดสอบอย่างสมบูรณ์ ดังนั้นจึงได้ตั้งค่าเป็นโหมดด้วยตนเองจนกว่าการทดสอบจะเสร็จสิ้น หลังจาก 45 นาทีการระบายความร้อนโดยรอบล้มเหลวการปิดระบบฮาร์ดแวร์ตัวจัดการอากาศปิดลงเนื่องจากคิดว่ามีไฟ เจ้าหน้าที่ได้รับการอพยพเนื่องจากมีสัญญาณเตือนไฟลุกลาม ในช่วงเวลานี้อุณหภูมิในศูนย์ข้อมูลเพิ่มขึ้น ฮาร์ดแวร์บางอย่างไม่ถูกปิดอย่างถูกต้องทำให้เกิดความเสียหายต่อการจัดเก็บและระบบเครือข่าย หลังจากที่รีเซ็ตเครื่องทำความเย็นด้วยตัวเองและเปิดตัวจัดการอากาศอุณหภูมิเริ่มกลับสู่ภาวะปกติ ใช้เวลาประมาณ 3 ชั่วโมง 29 นาทีก่อนที่พวกเขาจะได้เห็นภาพสถานะของดาต้าเซ็นเตอร์อย่างสมบูรณ์ ปัญหาใหญ่ที่สุดคือความเสียหายที่เกิดขึ้นกับพื้นที่เก็บข้อมูล ความกังวลหลักของ Microsoft คือการปกป้องข้อมูล Microsoft จะพยายามกู้คืนข้อมูลเพื่อไม่ให้สูญเสียข้อมูล นี้แน่นอนเอาเวลาที่ขยายความยาวโดยรวมของการหยุดทำงาน ข่าวดีก็คือไม่มีข้อมูลลูกค้าหายไป ข่าวร้ายก็คือดูเหมือนว่าจะใช้เวลา 24-48 ชั่วโมงเพื่อให้สิ่งต่างๆกลับคืนสู่สภาพปกติ ทั้งนี้ขึ้นอยู่กับสิ่งที่ฉันอ่านจาก Twitter จากลูกค้าที่บ่นเกี่ยวกับการหยุดชะงักเป็นเวลานาน

สมมติฐาน

ทุกคนคาดว่าการหยุดชะงักนี้จะส่งผลกระทบต่อลูกค้าที่เป็นเจ้าภาพในภาคกลางภาคใต้ แต่สิ่งที่พวกเขาไม่คาดหวังก็คือการหยุดชะงักจะมีผลกระทบนอกภูมิภาคนั้น ในเซสชั่น, Microsoft กล่าวถึงบางส่วนของการเข้าถึงขยายของการหยุดทำงาน

ผู้จัดการฝ่ายบริการ Azure (ASM)

ควบคุมทรัพยากร Azure "Classic", AKA, ทรัพยากรก่อน ARM ทุกคนที่ใช้ ASM อาจได้รับผลกระทบ ไม่เป็นที่ชัดเจนว่าเหตุใดจึงเกิดขึ้น ปรากฏว่าภาคกลางภาคใต้มีองค์ประกอบที่สำคัญของบริการดังกล่าวซึ่งไม่สามารถใช้งานได้

บริการทีม Visual Studio (VSTS)

ดูเหมือนว่าแหล่งข้อมูลต่างๆที่สนับสนุนบริการนี้มีอยู่ในภาคใต้ตอนล่าง การหยุดทำงานนี้ได้รับการอธิบายอย่างละเอียดโดย Buck Hodges (@tfsbuck) ผู้อำนวยการฝ่ายวิศวกรรม Azure DevOps โพสต์บล็อกนี้

POSTMORTEM: VSTS 4 กันยายน 2018

Azure Active Directory (AAD)

เมื่อภาคกลางตอนใต้ล้มเหลว AAD ทำในสิ่งที่ได้รับการออกแบบมาเพื่อให้ครบถ้วนและเริ่มส่งคำร้องขอรับรองความถูกต้องไปยังภูมิภาคอื่น ๆ ขณะที่ฝั่งตะวันออกเริ่มตื่นขึ้นและออนไลน์การเข้าชมการตรวจสอบสิทธิ์เริ่มต้นขึ้น ตอนนี้ปกติ AAD จะจัดการกับการเพิ่มขึ้นของการเข้าชมผ่าน autoscaling แต่ autoscaling มีการพึ่งพา ASM ซึ่งแน่นอนว่าออฟไลน์ หากไม่มีความสามารถในการทำสำเนาอัตโนมัติ AAD ไม่สามารถจัดการกับคำขอยืนยันข้อมูลที่เพิ่มขึ้นได้ ทำให้สถานการณ์แย่ลงคือข้อผิดพลาดในไคลเอ็นต์ Office ซึ่งทำให้มีตรรกะในการลองใหม่อย่างก้าวร้าวและไม่มีเหตุผลด้านหลัง การเข้าใช้งานการตรวจสอบสิทธิ์เพิ่มเติมนี้ทำให้ AAD เข้าสู่หัวเข่า พวกเขาหมดเวลาเพื่อพูดคุยเรื่องนี้ต่อไปในระหว่างเซสชัน Ignite คุณลักษณะหนึ่งที่พวกเขาจะแนะนำจะทำให้ผู้ใช้สามารถล็อกไฟล์ Storage ด้วยตนเองได้ในอนาคต ดังนั้นในกรณีที่เป้าหมายเวลาการกู้คืน (RTO) มีความสำคัญมากกว่า (RPO) ผู้ใช้จะมีความสามารถในการกู้คืนพื้นที่จัดเก็บข้อมูลซ้ำซ้อนที่จำลองแบบอะซิงโครนัสในศูนย์ข้อมูลสำรองหาก Microsoft ประสบปัญหาการหยุดทำงานชั่วคราวเพิ่มเติมในอนาคต

สิ่งที่คุณสามารถทำได้ตอนนี้

จนกว่าจะถึงเวลานั้นคุณจะต้องพึ่งพาโซลูชันการจำลองแบบอื่น ๆ เช่นการกู้คืนไซต์ SIOS DataKeeper Azure หรือโซลูชันการจำลองแบบเฉพาะของแอ็พพลิเคชันที่มีความสามารถในการทำซ้ำข้อมูลข้ามภูมิภาคและทำให้สามารถเรียกใช้แผนกู้คืนระบบของคุณได้ในการควบคุมของคุณ อ่านข้อมูลเพิ่มเติมเกี่ยวกับการฆาตกรรมโพสต์ภาพตัดปะของเราที่ทำด้วยทองคำได้รับอนุญาตจาก Clusteringformeremortals.com

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: สีฟ้าหมดสภาพโพสต์ชันสูตร

Azure Outage Post Mortem ส่วนที่ 2

พฤศจิกายน 7, 2018 by Jason Aw Leave a Comment

 สีฟ้าล่มส่วนที่โพสต์ชันสูตร 2

เกิดอะไรขึ้น? นี่คือบทความ Azure Outage Post Mortem ส่วนที่ 2 ของเรา

สีฟ้าล่มส่วนที่โพสต์ชันสูตร 2

เกิดอะไรขึ้น? นี่คือบทความ Azure Outage Post Mortem ส่วนที่ 2 ของเรา

โพสต์บล็อกก่อนหน้าของฉันกล่าวว่า Cloud-to-Cloud หรือ Hybrid-Cloud จะทำให้คุณได้รับความเหงามากที่สุดจากปัญหาใด ๆ ที่ CSP สามารถพบได้ อย่างไรก็ตามการหยุดทำงานส่วนใหญ่ที่เกิดจากภัยพิบัติทางธรรมชาตินี้อาจถูกหลีกเลี่ยงได้หากโซนจำหน่ายมีให้บริการในภาคกลางภาคใต้ Microsoft ได้เผยแพร่ RCA เบื้องต้นของวันที่ 4 กันยายน South Central Outage ส่วนที่สำคัญที่สุดของสรุปทั้งหมดนั้นมีดังต่อไปนี้ …

“ลดความซ้ำซ้อนในที่ทำงานมีเหตุการณ์ที่ทำให้เกิดความเย็นที่เกิดขึ้นกับตัวทำละลาย DATACENTER สามารถส่งผลกระทบต่อการทำงานของลูกค้าในเอกสารสำคัญที่ได้รับผลกระทบ”

คุณหมายถึงอะไร?

หากแอ็พพลิเคชันของคุณทำงานในดาต้าเซ็นเตอร์เดียวกันคุณจะเสี่ยงต่อการหยุดทำงานประเภทเดียวกันในอนาคต ในการป้องกันของ Microsoft สิ่งนี้ไม่ควรเป็นข่าวแก่คุณ นี่เป็นจริงเสมอไม่ว่าคุณจะทำงานใน Azure, AWS, Google หรือแม้แต่ดาต้าเซ็นเตอร์ของคุณเอง ความล้มเหลวในการวางแผนล่วงหน้าเกี่ยวกับการจำลองข้อมูลไปยังดาต้าเซ็นเตอร์อื่นและแผนในการกู้คืนแอปพลิเคชันของคุณได้อย่างรวดเร็วก็คือการขาดการวางแผนในส่วนของคุณ Microsoft ไม่ได้เผยแพร่ตำแหน่งที่ตั้งของ Availability Zone ที่แน่นอน หากคุณเชื่อว่าแผนที่นี้เผยแพร่ที่นี่คุณสามารถคาดเดาได้ว่าอาจอยู่ห่างจากที่อื่น ๆ ประมาณ 2-10 ไมล์ Azure Datacenters.png ในกรณีทั้งหมด แต่ส่วนใหญ่การจำลองข้อมูลในเขตการให้บริการควรเพียงพอสำหรับการป้องกันข้อมูล แอ็พพลิเคชันบางอย่างเช่น SQL Server ได้สร้างขึ้นในเทคโนโลยีการจำลองแบบ อย่างไรก็ตามสำหรับแอพพลิเคชันระบบปฏิบัติการและชนิดข้อมูลจำนวนมากจะตรวจสอบการจำลองแบบระดับบล็อก SANless cluster solutions โซลูชันคลัสเตอร์ SANless ได้รับการใช้แบบดั้งเดิมสำหรับกลุ่ม multisite แต่เทคโนโลยีเดียวกันนี้ยังสามารถนำมาใช้ในระบบคลาวด์ในโซนการให้บริการภูมิภาคหรือไฮบริดคลาวด์สำหรับความพร้อมใช้งานและการกู้คืนระบบที่มีประสิทธิภาพสูง การใช้คลัสเตอร์ SANless ที่ครอบคลุมเขตการให้บริการไม่ว่าจะเป็น Azure, AWS หรือ Google เป็นกระบวนการที่ค่อนข้างง่ายที่ได้รับเครื่องมือที่เหมาะสม ในฐานะที่เป็นส่วนหนึ่งของการหยุดชันสูตรพลิกศพที่กรุงปักกิ่งที่นี่มีแหล่งข้อมูลไม่กี่อย่างที่จะช่วยให้คุณเริ่มต้น ขั้นตอนทีละขั้นตอน: การกำหนดคอนฟิกคลัสเตอร์เซิร์ฟเวอร์ไฟล์ใน Azure ซึ่งครอบคลุมเขตพื้นที่ให้บริการวิธีสร้างอินสแตนซ์ของคลัสเตอร์ล้มเหลวของ SQL Server แบบ SANless ใน Google Cloud Platform MS SQL Server v.Next บน Linux พร้อมการจำลองแบบและความพร้อมใช้งานสูง #Azure #Cloud #Linux การปรับใช้คลัสเตอร์ล้มเหลวของ Microsoft SQL Server 2014 ใน #Azure Resource Manager (ARM) คลัสเตอร์เซิร์ฟเวอร์ SQL แบบไม่ใช้ SAN ใน AWS คลัสเตอร์ Linux แบบไม่มีการแจ้งเตือนใน AWS Quick Start

บทเรียนจาก Azure Outage Post Mortem

ถ้าคุณอยู่ใน Azure คุณอาจต้องการพิจารณาการกู้คืนไซต์ Azure (ASR) ASR ช่วยให้คุณทำซ้ำ VM ทั้งหมดจากพื้นที่ Azure หนึ่งไปยังพื้นที่อื่น ASR จะทำซ้ำ VMs ของคุณในแบบเรียลไทม์และอนุญาตให้คุณทำแบบทดสอบ DR ที่ไม่ก่อกวนเมื่อใดก็ตามที่คุณต้องการ รองรับเวอร์ชันล่าสุดของ Windows และ Linux และติดตั้งได้ง่ายมาก นอกจากนี้คุณยังสามารถสร้างงานจำลองแบบที่มี “Multi-VM Consistency” ซึ่งหมายความว่าเซิร์ฟเวอร์ต้องได้รับการกู้คืนจากจุดเดียวกันในเวลาที่สามารถรวบรวมไว้ในกลุ่มความสอดคล้องนี้ได้และจะมีจุดการกู้คืนเหมือนกัน ถ้าคุณสร้างคลัสเตอร์ SANless ด้วย DataKeeper ในภูมิภาคเดียวเพื่อความพร้อมใช้งานที่สูงคุณมีสองทางเลือกสำหรับ DR หนึ่งคือคุณสามารถขยาย SANless คลัสเตอร์ของคุณไปยังโหนดในพื้นที่อื่นหรือคุณสามารถใช้ ASR เพื่อทำซ้ำโหนดทั้งสองในกลุ่มที่มีความสอดคล้อง ASR

ความแตกต่างคืออะไร?

การค้าขายกับ ASR ก็คือ RPO และ RTO ไม่ดีเท่าที่คุณจะได้รับจาก SANless multi-site cluster แม้ว่าจะสามารถกำหนดค่าและใช้งานได้ง่ายเพียงใดก็ตาม เพียงระมัดระวัง ถ้าแอพพลิเคชันของคุณเกินกว่า 10 MBps ในการเขียนดิสก์เป็นประจำ ASR จะไม่สามารถติดตามได้ นอกจากนี้กลุ่มที่ใช้พื้นที่เก็บข้อมูล Spaces Direct ไม่สามารถทำซ้ำกับ ASR และโดยทั่วไปไม่มีกลยุทธ์ DR ที่ดีเมื่อใช้ใน Azure ในขณะที่หลังจากดิสก์ที่ได้รับการจัดการได้รับการปล่อยตัว ASR ไม่สนับสนุนพวกเขาทั้งหมดจนกระทั่งประมาณหนึ่งปีต่อมา การสนับสนุนดิสก์ไดรฟ์ที่มีการสนับสนุนอย่างเต็มที่คืออุปสรรคใหญ่สำหรับคนจำนวนมากที่ต้องการใช้ ASR โชคดีตั้งแต่ประมาณเดือนกุมภาพันธ์ปี 2018 ASR สนับสนุนดิสก์ที่มีการจัดการอย่างเต็มที่ อย่างไรก็ตามมีปัญหาอื่น ๆ ที่เพิ่งเปิดตัว ด้วยการเปิดตัวโซนการให้บริการ ASR ถูกจับอีกครั้งหลังเวลา ปัจจุบันพวกเขาไม่สนับสนุน VM ที่ได้รับการติดตั้งในเขตพื้นที่ให้บริการ

2018-09-25_00-10-24
สนับสนุนเมทริกซ์สำหรับการจำลองแบบจากพื้นที่ Azure หนึ่งไปยังอีกที่หนึ่ง

ฉันไปข้างหน้าและพยายามมันต่อไป ดูเหมือนว่าจะสามารถกำหนดค่าการจำลองแบบและฉันสามารถทดสอบ failover ได้

ฉันใช้ ASR เพื่อทำซ้ำ SQL1 และ SQLASR และอาริโซน่า3 จาก Central ไปตะวันออก US 2 และได้ทดสอบ failover. นอกเหนือจากการไม่วาง VMs ใน AZs ใน US US 2 ดูเหมือนว่าจะใช้ได้ผล [/ caption] ฉันหวังจะหาข้อมูลเพิ่มเติมเกี่ยวกับข้อ จำกัด นี้ในการประชุม Ignite ถึงแม้ว่าข้อ จำกัด นี้จะไม่สำคัญเท่ากับ Managed Disk’s เนื่องจากเขตปลอดอากรไม่สามารถใช้ได้อย่างกว้างขวาง ดังนั้นหวังว่า ASR จะรับการสนับสนุนพื้นที่ให้บริการในขณะที่ภูมิภาคอื่น ๆ สว่างขึ้นโซนการให้บริการและมีการใช้กันอย่างแพร่หลายมากขึ้น

อ่านข้อมูลเพิ่มเติมเกี่ยวกับการวิเคราะห์ Azure Outage Post Mortem ที่ได้รับอนุญาตจาก Clusteringformeremortals.com

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์

Azure Outage Post-Mortem ตอนที่ 1

พฤศจิกายน 6, 2018 by Jason Aw Leave a Comment

Azure-ดับ-ชันสูตรศพ-PT-1

Azure Outage Post-Mortem

การโพสต์ข้อความอย่างเป็นทางการครั้งแรกเริ่มออกมาจากไมโครซอฟต์เกี่ยวกับ Azure Outage ที่เกิดขึ้นเมื่อสัปดาห์ที่แล้ว Azure Outage Mortage ฉบับแรกนี้จะกล่าวถึงปัญหาการหยุดทำงาน Azure DevOps โดยเฉพาะ (รู้จักกันในชื่อ Visual Studio Team Service หรือ VSTS) จะทำให้เรามีข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับความกว้างและความลึกของจุดดับเพลิง ยืนยันสาเหตุของการหยุดชะงัก นอกจากนี้ยังช่วยให้เรามีข้อมูลเชิงลึกเกี่ยวกับความท้าทายต่างๆที่ Microsoft ประสบในการทำให้สิ่งต่างๆออนไลน์กลับมาอย่างรวดเร็ว นอกจากนี้ยังกล่าวถึงคุณลักษณะบางอย่าง / คุณลักษณะที่ Microsoft อาจพิจารณาในการจัดการกับสถานการณ์นี้ให้ดีขึ้นในอนาคต ดังที่ได้กล่าวไว้ในบทความก่อนหน้านี้คุณลักษณะต่างๆเช่นโซนการให้บริการใหม่ที่เปิดตัวใน Azure อาจลดผลกระทบจากการหยุดทำงานนี้ ในการโพสต์ชันสูตร Microsoft ยืนยันสิ่งที่ฉันได้กล่าวไว้ก่อนหน้านี้

โซลูชันหลักที่เรากำลังดำเนินการเพื่อปรับปรุงความล้มเหลวของดาต้าเซ็นเตอร์ในการจัดการคือโซนความพร้อมใช้งานและเรากำลังสำรวจความเป็นไปได้ของการจำลองแบบอะซิงโครนัส

ข้อกำหนดอื่น ๆ ที่ต้องทำ

จนกว่าเขตข้อมูลที่พร้อมใช้งานจะถูกส่งออกไปทั่วภูมิภาคอื่น ๆ คุณจะมีตัวเลือกการกู้คืนระบบเพียงอย่างเดียวคือข้ามภูมิภาคไฮบริดสลีเมฆหรือแม้แต่การจำลองแบบอะซิงโครนัสข้ามคลาวด์ ซอฟท์แวร์ที่ใช้โซลูชั่น #SANless clustering ในวันนี้จะช่วยให้สามารถกำหนดค่าดังกล่าวได้ ให้ RTO และ RPO ที่มีประสิทธิภาพมากแม้ว่าจะทำซ้ำระยะทางที่ดีก็ตาม ด้วยโซลูชัน SaaS / PaaS คุณจะต้องพึ่งพาผู้ให้บริการระบบคลาวด์ (Cloud Service Provider – CSP) ในการจัดเตรียมโซลูชั่น HA / DR แบบเหล็กไว้ ในกรณีนี้ดูเหมือนว่าจะมีการขาดแคลนที่สำคัญอย่างมาก เราหวังเป็นอย่างยิ่งว่าจะทำให้ซีเอสพีทุกคนมองอย่างหนักที่ข้อเสนอของ SaaS / PaaS รวมทั้งเพื่อแก้ไขปัญหาช่องว่าง HA / DR ที่อาจเกิดขึ้น จนกระทั่งถึงตอนนั้นผู้บริโภคต้องรับผิดชอบต่อความเสี่ยง พวกเขาจำเป็นต้องทำในสิ่งที่สามารถทำได้เพื่อลดความเสี่ยงของการหยุดทำงานที่ยืดเยื้อหรือเพียงแค่เลือกที่จะไม่ใช้ PaaS / SaaS จนกว่าจะมีการจัดการความเสี่ยง

RTO หรือ RPO?

การโพสต์ชันสูตรได้รับรากเหง้าของปัญหาจริงๆ … สิ่งที่คุณให้ความสำคัญกับ RTO หรือ RPO มากขึ้น?

พื้นฐานฉันไม่ต้องการตัดสินใจว่าลูกค้าจะยอมรับข้อมูลหรือไม่ ฉันมีลูกค้าบอกฉันว่าพวกเขาจะสูญเสียข้อมูลเพื่อให้ทีมงานขนาดใหญ่มีประสิทธิผลอีกครั้งอย่างรวดเร็วและลูกค้ารายอื่น ๆ บอกฉันว่าพวกเขาไม่ต้องการสูญเสียข้อมูลใด ๆ และจะรอการกู้คืนนานเท่าไร

จะเป็นไปไม่ได้ที่ซีเอสพีจะตัดสินใจได้ว่าเป็นลูกค้า CSP จะไม่ต้องการสูญเสียข้อมูลลูกค้าเว้นแต่ข้อมูลเดิมจะหายไปและไม่สามารถกู้คืนได้ ในกรณีนี้แบบจำลองเรียลไทม์แบบเรียลไทม์ใกล้เคียงกับที่คุณจะได้รับในแง่ของ RPO ในความล้มเหลวที่ไม่คาดคิด อย่างไรก็ตามความผิดพลาดนี้เกิดขึ้นได้จริงและไม่มีคำเตือน? ภาพจากดาวเทียมสมัยใหม่และการปรับปรุงสภาพอากาศในการพยากรณ์อากาศทำให้มีการเตือนอย่างเป็นรูปธรรมว่าเหตุการณ์อากาศที่เกิดขึ้นในพื้นที่มีความสำคัญ พายุเฮอร์ริเคนฟลอเรนซ์มุ่งหน้าลงตะวันออกเฉียงใต้ของสหรัฐขณะที่ฉันเขียนบทความนี้ ใช้มาตรการเชิงรุกเพื่อย้ายปริมาณงานจากพื้นที่ที่ได้รับผลกระทบหากศูนย์ข้อมูลอยู่ในเส้นทาง ประโยชน์ของการกู้คืนความเสียหายเชิงรุกและการกู้คืนความเสียหายแบบรีแอ็กทีฟเป็นจำนวนมาก ไม่มีข้อมูลสูญหายเวลาเหลือเฟือในการแก้ไขปัญหาที่ไม่คาดคิด นอกจากนี้ยังรวมถึงการจัดการทรัพยากรมนุษย์เพื่อให้พนักงานสามารถกังวลกับการดูแลครอบครัวมากกว่าที่จะทำงาน อีกครั้งการรับรองการกู้คืนระบบเชิงรุกจะเป็นการตัดสินใจที่ยากสำหรับ CSP ในการทำในนามของลูกค้าทั้งหมดของพวกเขา การอพยพตามแผนทั่วทั้งภูมิภาคจะเกิดขึ้นจากการหยุดทำงาน การตัดสินใจนี้จะต้องอยู่ในมือของลูกค้า เรียนรู้จาก Azure Outage Post-Mortem เพื่อให้ความรู้แก่ลูกค้าของคุณ

สไลด์ 2.png
ภาพจากดาวเทียมเฮอร์ริเคนฟลอเรนซ์ถ่ายจากดาวเทียม GOES-16 ใหม่โดยได้รับความอนุเคราะห์จาก Tropical Tidbits

ได้รับการปกป้อง

ดังนั้นสิ่งที่คุณสามารถทำได้เพื่อปกป้องแอพพลิเคชันและข้อมูลสำคัญของธุรกิจของคุณ? มาลองบทเรียนบางส่วนจาก Azure Outage Post-Mortem โมเดลครอสส์คลาวด์หรือไฮบริด – คลาวด์ที่ใช้โซลูชันคลัสเตอร์แบบ #SANless ที่ใช้ซอฟต์แวร์อยู่เป็นระยะทางยาวเพื่อแก้ไขปัญหาข้อกังวล HA / DR ของคุณ นอกจากนี้ยังมี RTO และ RPO ที่ยอดเยี่ยมสำหรับการใช้งาน IaaS บนระบบคลาวด์ มีทางเลือกอื่นนอกเหนือจากโซลูชันเฉพาะของแอ็พพลิเคชัน ซอฟแวร์ที่ใช้ป้องกันข้อมูลระดับการจำลองระดับเช่น SIOS DataKeeper และ SIOS Protection Suite ทำซ้ำข้อมูลทั้งหมดและให้โซลูชั่นการป้องกันข้อมูลสำหรับทั้ง Linux และ Windows แพลตฟอร์ม ลูกชายคนโตของฉันเพิ่งเริ่มปริญญาตรีด้านอุตุนิยมวิทยาที่มหาวิทยาลัย Rutgers ลองจินตนาการถึงวันที่ปัญญาประดิษฐ์ (AI) และการเรียนรู้ด้วยเครื่อง (ML) จะประมวลผลข้อมูลที่เกี่ยวข้องกับสภาพอากาศจาก NOAA พวกเขาสามารถเรียกการโยกย้ายกู้คืนความเสียหายตามแผนได้เมื่อสองวันก่อนเกิดพายุ? ฉันคิดว่าฉันเพิ่งพบหัวข้อที่สมบูรณ์แบบสำหรับวิทยานิพนธ์ปริญญาโทของเขา หรือดีกว่ายังมีเขาและเพื่อนสมาร์ทของเขาที่ WeatherWatcher LLC รับเงินทุนสำหรับการเริ่มต้นใช้งานเทคโนโลยีที่ใช้ AI และ ML เพื่อจัดการข้อมูลสภาพอากาศที่เกี่ยวข้องเพื่อควบคุมกิจกรรมการกู้คืนความเสียหายเชิงรุก ผมคิดว่าเราเป็นเพียงจุดเริ่มต้นของโซลูชันการวิเคราะห์ด้านไอที เราสามารถใช้เทคโนโลยีการเรียนรู้เครื่องจักรขั้นสูงเพื่อลดเวลาและความพยายามเพื่อให้แน่ใจได้ว่าการส่งมอบบริการแอพพลิเคชันที่สำคัญ SIOS iQ เป็นหนึ่งในโซลูชั่นที่นำทางในสาขานั้น รุกลงฟักและเตรียมพร้อม ฤดูพายุเฮอริเคนเพิ่งเริ่มต้นและเราอยู่ในป่าแล้ว หากคุณต้องการพูดคุยเกี่ยวกับกลยุทธ์ HA / DR ของคุณให้ติดต่อฉันทาง Twitter @daveberm

อ่าน Azure Outage Post-Mortem อื่นที่นี่
ทำซ้ำโดยได้รับอนุญาตจาก Clusteringformeremortals.com

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์

  • « Previous Page
  • 1
  • …
  • 85
  • 86
  • 87
  • 88
  • 89
  • …
  • 112
  • Next Page »

โพสต์ล่าสุด

  • ระบบความพร้อมใช้งานสูง (High Availability หรือ HA) คืออะไร?
  • เอาตัวรอดจากวิกฤตการณ์วันศุกร์: จากระบบคอมพิวเตอร์แบบดิบๆ สู่การจำลองข้อมูลที่ราบรื่น
  • ติดดิน: สิ่งที่การพลาดชม Percona Live Amsterdam สอนฉันเกี่ยวกับ HA
  • เปรียบเทียบ SIOS LifeKeeper กับ Red Hat High Availability Add-On:
  • สถานะของความยืดหยุ่นของแอปพลิเคชัน: ผลสำรวจความพร้อมใช้งานสูงของ SIOS ปี 2026

กระทู้ยอดนิยม

เข้าร่วมรายชื่อผู้รับจดหมายของเรา

Copyright © 2026 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in