SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

กุมภาพันธ์ 14, 2021

เกี่ยวกับการใช้ Amazon FSX สำหรับ SQL Server Failover Cluster Instance

เกี่ยวกับการใช้ Amazon FSX สำหรับ SQL Server Failover Cluster Instance

การใช้ Amazon FSX สำหรับอินสแตนซ์คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์ SQL – สิ่งที่คุณต้องรู้!

หากคุณกำลังพิจารณาปรับใช้อินสแตนซ์ Microsoft SQL Server ของคุณเองใน AWS EC2 คุณมีการตัดสินใจบางอย่างเกี่ยวกับความยืดหยุ่นของโซลูชัน แน่นอนว่า AWS จะเสนอ SLA 99.99% ให้กับทรัพยากรการประมวลผลของคุณหากคุณปรับใช้สองอินสแตนซ์ขึ้นไปในโซนความพร้อมใช้งานที่แตกต่างกัน แต่อย่าเพิ่งหลงเชื่อมีปัจจัยอื่น ๆ อีกมากมายที่คุณต้องพิจารณาเมื่อคำนวณความพร้อมใช้งานของแอปพลิเคชันที่แท้จริง ฉันเพิ่งเขียนบล็อกเกี่ยวกับวิธีคำนวณความพร้อมใช้งานแอปพลิเคชันของคุณในระบบคลาวด์ คุณควรอ่านบทความนั้นอย่างรวดเร็วก่อนที่จะดำเนินการต่อ

เมื่อพูดถึงการตรวจสอบให้แน่ใจว่าอินสแตนซ์ Microsoft SQL Server ของคุณพร้อมใช้งานสูงจริงๆแล้วจะมีตัวเลือกพื้นฐานสองตัวเลือก: Always On Availability Group (AG) หรือ SQL Server Failover Cluster Instance (FCI) หากคุณกำลังอ่านบทความนี้ฉันตั้งสมมติฐานว่าคุณทราบดีถึงตัวเลือกทั้งสองนี้และกำลังพิจารณาอย่างจริงจังที่จะใช้อินสแตนซ์คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์ SQL แทน SQL Server Always On AG

ประโยชน์ของอินสแตนซ์คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์ SQL ของ Microsoft

รายการต่อไปนี้สรุปสิ่งที่ AWS กล่าวว่าเป็นประโยชน์ของ SQL Server FCI:

โดยทั่วไปแล้ว FCI เป็นที่ต้องการมากกว่า AG สำหรับการปรับใช้ SQL Server ที่มีความพร้อมใช้งานสูงเมื่อสิ่งต่อไปนี้เป็นข้อกังวลลำดับความสำคัญสำหรับกรณีการใช้งานของคุณ:

ประสิทธิภาพต้นทุนใบอนุญาต: คุณต้องมีสิทธิ์การใช้งาน Enterprise Edition ของ SQL Server เพื่อเรียกใช้ AGs ในขณะที่คุณต้องการเพียงสิทธิ์การใช้งาน Standard Edition เพื่อเรียกใช้ FCI โดยทั่วไปแล้วราคาถูกกว่า Enterprise Edition 50–60% แม้ว่าคุณจะสามารถเรียกใช้ AG รุ่นพื้นฐานบน Standard Edition ได้โดยเริ่มจาก SQL Server 2016 แต่ก็มีข้อ จำกัด ในการรองรับฐานข้อมูลเพียงฐานข้อมูลเดียวต่อ AG สิ่งนี้อาจกลายเป็นความท้าทายเมื่อต้องจัดการกับแอปพลิเคชันที่ต้องใช้ฐานข้อมูลหลายฐานข้อมูลเช่น SharePoint

การป้องกันระดับอินสแตนซ์เทียบกับการป้องกันระดับฐานข้อมูล: ด้วย FCI อินสแตนซ์ทั้งหมดจะได้รับการป้องกัน – หากโหนดหลักไม่พร้อมใช้งานอินสแตนซ์ทั้งหมดจะถูกย้ายไปยังโหนดสแตนด์บาย สิ่งนี้จะดูแลการล็อกอินของ SQL Server งาน SQL Server Agent ใบรับรอง ฯลฯ ที่เก็บไว้ในฐานข้อมูลระบบซึ่งจัดเก็บทางกายภาพในที่เก็บข้อมูลแบบแบ่งใช้ ในทางกลับกันด้วย AG ในทางกลับกันเฉพาะฐานข้อมูลในกลุ่มเท่านั้นที่ได้รับการปกป้องและไม่สามารถเพิ่มฐานข้อมูลระบบลงใน AG ได้ – อนุญาตให้ใช้เฉพาะฐานข้อมูลผู้ใช้เท่านั้น เป็นความรับผิดชอบของผู้ดูแลระบบฐานข้อมูลในการทำซ้ำการเปลี่ยนแปลงอ็อบเจ็กต์ระบบในการจำลอง AG ทั้งหมด สิ่งนี้ทำให้ความเป็นไปได้ที่จะเกิดข้อผิดพลาดของมนุษย์ซึ่งทำให้ฐานข้อมูลไม่สามารถเข้าถึงแอปพลิเคชันได้

การสนับสนุนคุณลักษณะ DTC: หากคุณใช้ SQL Server 2012 หรือ 2014 และแอปพลิเคชันของคุณใช้ Distributed Transaction Coordinator (DTC) คุณจะไม่สามารถใช้ AG ได้เนื่องจากไม่ได้รับการสนับสนุน ใช้ FCI ในสถานการณ์นี้

https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/

ความท้าทายกับ FCI ในคลาวด์

แน่นอน. ความท้าทายในการสร้าง FCI ที่ครอบคลุมโซนความพร้อมใช้งานคือการขาดอุปกรณ์จัดเก็บข้อมูลที่ใช้ร่วมกันซึ่งโดยปกติจำเป็นต้องใช้ เนื่องจากโหนดของคลัสเตอร์ถูกกระจายไปตามศูนย์ข้อมูลหลายแห่ง SAN แบบดั้งเดิมจึงไม่ใช่ตัวเลือกที่ใช้ได้สำหรับพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน นั่นทำให้เรามีทางเลือกสองทางสำหรับการจัดเก็บคลัสเตอร์: ทรัพยากรระดับพื้นที่เก็บข้อมูลของบุคคลที่สามเช่น SIOS DataKeeper หรือ Amazon FSx ใหม่

มาดูสิ่งที่คุณต้องรู้ก่อนตัดสินใจเลือก

ข้อตกลงระดับการให้บริการ

ตามที่ฉันเขียนไว้ในวิธีคำนวณความพร้อมใช้งานแอปพลิเคชันของคุณ SLA แอปพลิเคชันโดยรวมของคุณนั้นดีพอ ๆ กับลิงก์ที่อ่อนแอที่สุดของคุณ ในกรณีนี้ FSx SLA 99.9%

โดยปกติความพร้อมใช้งาน 99.99% หมายถึงจุดเริ่มต้นของสิ่งที่ถือว่า "พร้อมใช้งานสูง" นี่คือสิ่งที่ AWS สัญญากับคุณสำหรับทรัพยากรการประมวลผลของคุณเมื่อมีการปรับใช้สองรายการขึ้นไปในโซนความพร้อมใช้งานที่แตกต่างกัน

ในกรณีที่คุณไม่ทราบความแตกต่างระหว่างสามเก้ากับสี่เก้า …

  • ความพร้อมใช้งาน 99.9% ช่วยให้หยุดทำงานได้ 43.83 นาทีต่อเดือน
  • ความพร้อมใช้งาน 99.99% ช่วยให้หยุดทำงานได้เพียง 4.38 นาทีต่อเดือน

ด้วยการโฮสต์พื้นที่จัดเก็บคลัสเตอร์ของคุณบน FSx แม้ว่าคุณจะมีความพร้อมในการประมวลผล 99.99% ความพร้อมใช้งานแอปพลิเคชันโดยรวมของคุณจะเป็น 99.9% ในทางตรงกันข้ามไดรฟ์ข้อมูล EBS ที่ครอบคลุมโซนความพร้อมใช้งานเช่นในการปรับใช้ DataKeeper จะมีคุณสมบัติสำหรับ SLA 99.99% ทั้งในชั้นพื้นที่จัดเก็บข้อมูลและการประมวลผล ซึ่งหมายความว่าความพร้อมใช้งานโดยรวมของคุณคือ 99.99%

สถานที่จัดเก็บ

เมื่อกำหนดค่า FSx เพื่อความพร้อมใช้งานสูงคุณจะต้องเปิดใช้งานการสนับสนุนหลาย AZ การเปิดใช้งานหลาย AZ จะทำให้คุณมี AZ ที่ "ต้องการ" และ AZ "สแตนด์บาย" ได้อย่างมีประสิทธิภาพ เมื่อคุณปรับใช้โหนด SQL Server FCI ของคุณคุณจะต้องการกระจายโหนดเหล่านั้นใน AZ เดียวกัน

ในสถานการณ์ปกติคุณจะต้องตรวจสอบให้แน่ใจว่าโหนดคลัสเตอร์ที่ใช้งานอยู่อยู่ใน AZ เดียวกับโหนดหน่วยเก็บข้อมูล FSx ที่ต้องการ นี่คือการลดระยะทางและเวลาแฝงในการจัดเก็บข้อมูลของคุณ แต่ยังช่วยลดค่าใช้จ่ายที่เกี่ยวข้องกับการถ่ายโอนข้อมูลข้าม AZ ด้วย ตามที่ระบุไว้ในคู่มือราคา FSx“ ค่าธรรมเนียมการถ่ายโอนข้อมูลมาตรฐานใช้สำหรับการเข้าถึงระบบไฟล์ระหว่าง AZ หรือระหว่างภูมิภาค”

ในสถานการณ์ที่โชคร้ายที่คุณมีความล้มเหลวของ SQL Server FCI แต่ไม่ใช่ความล้มเหลว FSx ไม่มีกลไกใดที่จะผูกทั้งพื้นที่จัดเก็บและคำนวณเข้าด้วยกัน ในกรณีที่ FSx ล้มเหลวจะกลับไปที่โซนความพร้อมใช้งานหลักโดยอัตโนมัติ อย่างไรก็ตามแนวทางปฏิบัติที่ดีที่สุดกำหนดให้ SQL FCI ยังคงทำงานบนโหนดรองจนกว่าจะมีการวิเคราะห์สาเหตุรากและโดยทั่วไปแล้วการล้มเหลวจะถูกกำหนดให้เกิดขึ้นในช่วงระยะเวลาการบำรุงรักษา ซึ่งจะทำให้คุณตกอยู่ในสถานการณ์ที่พื้นที่เก็บข้อมูลของคุณอยู่ใน AZ อื่นซึ่งจะต้องเสียค่าใช้จ่ายเพิ่มเติม ปัจจุบันค่าใช้จ่ายในการถ่ายโอนข้อมูลข้าม AZ ทั้งขาเข้าและขาออกคือ 0.01 ดอลลาร์ / GB

หากไม่จับตาดูสถานะ FSx และ SQL Server FCI ของคุณอย่างใกล้ชิดคุณอาจไม่รู้ด้วยซ้ำว่ากำลังทำงานอยู่ในภูมิภาคต่างๆจนกว่าคุณจะเห็นค่าธรรมเนียมการถ่ายโอนข้อมูลเมื่อสิ้นเดือน

ในทางตรงกันข้ามในคอนฟิกูเรชันที่ใช้ SIOS DataKeeper การล้มเหลวของหน่วยเก็บข้อมูลเป็นส่วนหนึ่งของการกู้คืน SQL Server FCI เพื่อให้แน่ใจว่าที่เก็บข้อมูลมักจะล้มเหลวด้วยอินสแตนซ์ SQL Server สิ่งนี้ทำให้มั่นใจได้ว่า SQL Server จะอ่านและเขียนไปยังไดรฟ์ข้อมูล EBS ที่เชื่อมต่อโดยตรงกับโหนดที่ใช้งานอยู่ โปรดทราบว่า DataKeeper จะต้องเสียค่าใช้จ่ายในการถ่ายโอนข้อมูลที่เกี่ยวข้องกับการดำเนินการเขียนซึ่งจำลองแบบระหว่าง AZ หรือภูมิภาค ต้นทุนการถ่ายโอนข้อมูลนี้สามารถลดลงได้ด้วยการใช้การบีบอัดที่มีอยู่ใน DataKeeper

การควบคุมล้มเหลว

ในคอนฟิกูเรชันหลายซับเน็ต FSx มีโซนความพร้อมใช้งานที่ต้องการและความพร้อมใช้งานสแตนด์บาย หากไฟล์เซิร์ฟเวอร์ FSx ในโซนความพร้อมใช้งานที่ต้องการประสบกับความล้มเหลวเซิร์ฟเวอร์ไฟล์ใน AZ สแตนด์บายจะกู้คืน AWS รายงานว่าเวลาในการกู้คืนนี้ใช้เวลาประมาณ 30 วินาทีกับการแชร์มาตรฐาน ด้วยการใช้การแชร์ไฟล์ที่มีอยู่อย่างต่อเนื่อง Microsoft รายงานว่าเวลาเฟลโอเวอร์นี้อาจใกล้ถึง 15 วินาที ในช่วงเวลาล้มเหลวนี้จะมีไฟดับที่เกิดขึ้นเมื่อการอ่านและการเขียนหยุดชั่วคราว แต่จะดำเนินต่อไปเมื่อการกู้คืนเสร็จสมบูรณ์

FSx หลายไซต์เปิดใช้งานข้อผิดพลาดอัตโนมัติ ซึ่งหมายความว่าสำหรับ FSx ที่ไม่ได้วางแผนไว้ทุกครั้งคุณจะมีข้อผิดพลาดที่ไม่ได้วางแผนไว้ด้วย ในทางตรงกันข้ามโดยทั่วไปเมื่อ SQL Server FCI ประสบกับความล้มเหลวที่ไม่ได้วางแผนไว้คุณอาจจะปล่อยให้มันทำงานในลำดับรองหรือกำหนดเวลาการล้มเหลวหลังจากชั่วโมงหรือในช่วงการบำรุงรักษาถัดไป

บริการวิเคราะห์เซิร์ฟเวอร์ SQL คลัสเตอร์ไม่รองรับ FSX

หากคุณต้องการคลัสเตอร์ SSAS คุณจะต้องมีทรัพยากรดิสก์แบบคลัสเตอร์เช่น SIOS DataKeeper เอกสารไวท์เปเปอร์ How to Cluster SQL Server Analysis Server ระบุอย่างชัดเจนว่าไม่สามารถใช้ SMB ได้และต้องใช้คลัสเตอร์ไดรฟ์ที่มีอักษรระบุไดรฟ์ ในทางตรงกันข้ามทรัพยากร DataKeeper Volume จะแสดงตัวเองเป็นดิสก์คลัสเตอร์และสามารถใช้กับ SSAS ได้

สรุป

แม้ว่า FSx จะเหมาะสมกับการใช้งาน SMB ทั่วไปเช่นไฟล์ผู้ใช้ Windows และบริการอื่น ๆ ที่ไม่สำคัญซึ่ง SLA ความพร้อมใช้งาน 99.9% เพียงพอ แต่ FSx เป็นตัวเลือกที่ยอดเยี่ยมหากแอปพลิเคชันของคุณต้องการความพร้อมใช้งานสูง (99.99%) หรือโซลูชัน HA / DR ที่ครอบคลุม ภูมิภาค SIOS DataKeeper คือขนาดที่เหมาะสม

ทำซ้ำโดยได้รับอนุญาตจาก Clusteringformeremortals
กุมภาพันธ์ 6, 2021

SIOS Protection Suite สำหรับ Linux Quick Service Protection

วิธีเพิ่มการรองรับแอปพลิเคชันแบบกำหนดเองให้กับ SIOS Protection Suite - SIOS Protection Suite สำหรับ Linux Quick Service Protection

การใช้ SIOS Protection Suite สำหรับ Linux Quick Service Protection Resource

ในการมีส่วนร่วมกับทีม SIOS Professional Services เมื่อเร็ว ๆ นี้ลูกค้าได้สอบถามเกี่ยวกับวิธีป้องกันแอปพลิเคชันที่กำหนดเองด้วยโซลูชัน SIOS Protection Suite สำหรับ Linux หนึ่งในผู้เชี่ยวชาญด้านความพร้อมใช้งานที่มีประสบการณ์สูงที่ SIOS Technology Corp. ได้ช่วยทำความเข้าใจแอปพลิเคชันของลูกค้าและกำหนดวิธีการที่ SIOS มีให้สำหรับการสนับสนุนแอปพลิเคชันที่กำหนดเอง

SIOS Protection Suite สำหรับ Linux มีหลายวิธีในการเพิ่มความพร้อมใช้งานสูงและการตรวจสอบแอปพลิเคชันให้กับแอปพลิเคชันแบบกำหนดเองตัวเลือกเหล่านี้มีดังต่อไปนี้:

  • การสร้างชุดการกู้คืนแอปพลิเคชันแบบกำหนดเอง (ARK) 1
  • การสร้างลำดับชั้นทรัพยากรแอปพลิเคชันทั่วไป
  • การสร้างทรัพยากรการป้องกันบริการด่วน
ประเภท ความซับซ้อนของการเข้ารหัส การตรวจสอบ การกู้คืน
ทรัพยากรชุดการกู้คืนแอปพลิเคชันแบบกำหนดเอง 1 สูงสุด สูงสุด สูงสุด
ทรัพยากรแอปพลิเคชันทั่วไป ปานกลาง สูง สูง
ทรัพยากรการป้องกันบริการด่วน ต่ำ ปานกลาง ปานกลาง

คำจำกัดความที่ใช้ในแผนภูมิ

การตรวจสอบ – หมายถึงความสามารถในการกำหนดความพร้อมการเข้าถึงและการทำงานของแอปพลิเคชันฐานข้อมูลหรือบริการที่ได้รับการป้องกันการตรวจสอบแอปพลิเคชันฐานข้อมูลหรือบริการในระดับต่ำให้ความครอบคลุมพื้นฐานเช่นการตรวจสอบกระบวนการที่กำลังทำงานอยู่การมีอยู่ของ pid_file หรือคำสั่งสถานะจะส่งคืนผลลัพธ์เป็น "จริง" เมื่อดำเนินการหมายเหตุ: โค้ดส่งคืน "จริง" หรือ "0 (ศูนย์)" ไม่ได้หมายความว่าแอปพลิเคชันฐานข้อมูลหรือบริการกำลังทำงานอยู่ แต่มีเพียงคำสั่งที่ดำเนินการเท่านั้นที่สามารถดำเนินการได้สำเร็จด้วยผลลัพธ์สถานะบวก ("จริง" หรือ "0 (ศูนย์)")ระดับสูงสุดของการตรวจสอบบ่งชี้ว่าความรู้เฉพาะของแอปพลิเคชันถูกนำไปใช้เพื่อกำหนดความสมบูรณ์และการทำงานของแอปพลิเคชันนอกเหนือจากวิธีการระดับล่างเช่นสถานะของกระบวนการเอาต์พุต ps หรือการคืนสถานะ systemdระดับสูงสุดของการเฝ้าติดตามโดยทั่วไปจะใช้ความรู้เกี่ยวกับลำดับการดำเนินการตรวจสุขภาพที่แนะนำความรู้เกี่ยวกับการพึ่งพาและการวิเคราะห์ผลลัพธ์ที่ได้รับจากสถานะและคำสั่งการตรวจสอบ

การกู้คืน – หมายถึงความสามารถในการรีสตาร์ทแอปพลิเคชันฐานข้อมูลหรือบริการที่ล้มเหลวความสามารถในการกู้คืนในระดับต่ำหมายความว่ามีการออกคำสั่งสำหรับการรีสตาร์ทและผลลัพธ์ที่คาดหวังจะได้รับจากการออกคำสั่งระดับสูงสุดของการตรวจสอบบ่งชี้ว่าความรู้เฉพาะแอปพลิเคชันถูกนำไปใช้เพื่อกำหนดวิธีการเริ่มการรีสตาร์ทแอปพลิเคชันฐานข้อมูลหรือบริการตามลำดับซึ่งอาจต้องใช้ความรู้เกี่ยวกับลำดับการดำเนินการที่แนะนำการอ้างอิงการย้อนกลับหรือการแก้ไขอื่น ๆ ที่เกี่ยวข้องของความล้มเหลว บริการ.

วิธีแก้ไข: ทรัพยากรการป้องกันบริการด่วน

ในการมีส่วนร่วมนี้แอปพลิเคชันของลูกค้ามีความเข้ากันได้ของระบบ จากข้อกำหนดโดยรวมในการหลีกเลี่ยงการเข้ารหัสความต้องการการตรวจสอบขั้นต่ำและขั้นตอนการกู้คืนอย่างง่ายเราขอแนะนำทรัพยากร Quick Service Protection (QSP)

ทรัพยากร QSP ทำงานเพื่อเพิ่มการสนับสนุนของบริการ systemd ไปยัง SIOS Protection Suite สำหรับการปกป้องทรัพยากร Linux อย่างรวดเร็วในกรณีของ Customer Example.com พวกเขามีบริการที่เข้ากันได้กับ systemd โดยมีข้อกำหนดขั้นต่ำที่จำเป็นในการเริ่มและหยุดแอปพลิเคชัน

[Unit]

Description = SIOS 'as-is' Example Service 2020

หลังจาก = network.target

พ[Service]ิมพ์ = ง่าย

รีสตาร์ท = เสมอ

RestartSec = 3

ผู้ใช้ = root

ExecStart = / example_app / bin / exampleapp เริ่มต้น

ExecStop = / example_app / bin / exampleapp หยุด[Install]

WantedBy = multi-user.target

ไฟล์ Example.com systemd

SIOS ขอแนะนำว่าก่อนที่จะพยายามป้องกันทรัพยากรด้วยผลิตภัณฑ์ SIOS Protection Suite สำหรับ Linux ให้ตรวจสอบผ่าน systemctl ว่าแอปพลิเคชันตัวอย่างหยุดทำงานและเริ่มทำงานตามนั้น:

# systemctl ตัวอย่างสถานะ

* example.service – SIOS "ตามสภาพ" บริการตัวอย่างปี 2020

โหลดแล้ว: โหลดแล้ว (/usr/lib/systemd/system/example.service; ปิดใช้งานพรีเซ็ตผู้ขาย: ปิดใช้งาน)

ใช้งาน: ไม่ใช้งาน (ตาย)

# systemctl start ตัวอย่าง

# systemctl ตัวอย่างสถานะ

* example.service – SIOS "ตามสภาพ" บริการตัวอย่างปี 2020

โหลดแล้ว: โหลดแล้ว (/usr/lib/systemd/system/example.service; ปิดใช้งานพรีเซ็ตผู้ขาย: ปิดใช้งาน)

ใช้งาน: ใช้งานอยู่ (ทำงาน) ตั้งแต่ศ. 2020-08-21 14:53:27 EDT; 5 วินาทีที่ผ่านมา

PID หลัก: 19937 (exampleapp)

กลุ่ม CG: /system.slice/example.service

`-19937 / usr / bin / perl / example_app / bin / exampleapp เริ่มต้น

# systemctl stop ตัวอย่าง

# systemctl ตัวอย่างสถานะ

* example.service – SIOS "ตามสภาพ" บริการตัวอย่างปี 2020

โหลดแล้ว: โหลดแล้ว (/usr/lib/systemd/system/example.service; ปิดใช้งานพรีเซ็ตผู้ขาย: ปิดใช้งาน)

ใช้งานอยู่: ไม่ใช้งาน (ตาย)

หลังจากตรวจสอบว่าแอปพลิเคชันทำงานอย่างถูกต้องผ่าน systemd ให้เริ่มบริการใหม่และตรวจสอบให้แน่ใจว่าบริการกำลังทำงานอยู่

# systemctl start ตัวอย่าง

# systemctl ตัวอย่างสถานะ

* example.service – SIOS "ตามสภาพ" บริการตัวอย่างปี 2020

โหลดแล้ว: โหลดแล้ว (/usr/lib/systemd/system/example.service; ปิดใช้งานพรีเซ็ตผู้ขาย: ปิดใช้งาน)

ใช้งาน: ใช้งานอยู่ (ทำงาน) ตั้งแต่ศ. 2020-08-21 15:59:44 EDT; 3 นาที 2 วินาทีที่แล้ว

PID หลัก: 30740 (exampleapp)

โปรดดูเอกสารประกอบ SIOS Protection Suite สำหรับ Linux Quick Service Protection Suite สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับกระบวนการสร้างทรัพยากร

การใช้ SPS-L UI เลือกตัวเลือกสร้างที่ระบุใน Global UI Resource Toolbar โดยไอคอนต่อไปนี้:

เมื่อSIOS Global US Resourceเปิดตัวช่วยสร้างให้เลือกตัวเลือก Quick Service Protection ในหน้าต่าง Create Resource Wizard

ในข้อความแจ้งถัดไปสำหรับ "Switchback Type" ให้เลือกว่าคุณจะใช้การสลับกลับอัจฉริยะหรือการสลับกลับอัตโนมัติ

หลังจากเลือก "Switchback Type" กล่องโต้ตอบเซิร์ฟเวอร์จะปรากฏขึ้นเพื่อให้คุณสามารถเลือกเซิร์ฟเวอร์หลักสำหรับแอปพลิเคชันที่กำหนดเองได้

(หมายเหตุ: หากบริการต้องการพื้นที่จัดเก็บโปรดเลือกเซิร์ฟเวอร์หลักเดียวกันกับที่เลือกไว้ก่อนหน้านี้สำหรับทรัพยากรหน่วยเก็บข้อมูล)

ในกล่องโต้ตอบชื่อบริการค้นหาบริการสำหรับแอปพลิเคชันแบบกำหนดเองของคุณ

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

จากนั้นเลือกแท็กทรัพยากรแท็กทรัพยากรควรเป็นชื่อที่มีความหมายซึ่งจะช่วยให้ทีมไอทีของคุณระบุได้อย่างรวดเร็วว่าทรัพยากร SPS-L ใดที่ปกป้องแอปพลิเคชันหรือบริการของคุณ

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

หมายเหตุ:

1 การสร้างชุดการกู้คืนแอปพลิเคชันของลูกค้าสามารถทำได้โดยการมีส่วนร่วมกับทีมบริการระดับมืออาชีพของ SIOS Technology Corp.สำหรับข้อมูลเพิ่มเติมโปรดติดต่อ professional-services@us.sios.com

2 QuickCheck ของ QSP Recovery Kit สามารถดำเนินการด้านสุขภาพอย่างง่ายเท่านั้น (โดยใช้การดำเนินการ "สถานะ" ของคำสั่งบริการ) QSP ไม่รับประกันว่ามีการให้บริการหรือกระบวนการทำงาน หากจำเป็นต้องเริ่มต้นและ / หรือหยุดที่ซับซ้อนหรือจำเป็นต้องมีการตรวจสอบความสมบูรณ์ที่มีประสิทธิภาพมากขึ้นขอแนะนำให้ใช้ Generic Application หรือ Custom Application ARK

ผลิตซ้ำจาก SIOS
มกราคม 29, 2021

วิธีทำความเข้าใจและตอบสนองต่อการแจ้งเตือนความพร้อมใช้งาน

ความล้มเหลวที่ประสบความสำเร็จ

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

ย้อนกลับไปในปี 1970:

“ การปั่นป่วนเป็นประจำของถังออกซิเจนทำให้ฉนวนสายไฟชำรุดเสียหายภายในถังทำให้เกิดการระเบิดซึ่งทำให้เนื้อหาของถังออกซิเจน (SM) ของโมดูลบริการ (Service Module) ทั้งสองไปอยู่ในอวกาศ หากไม่มีออกซิเจนซึ่งจำเป็นสำหรับการหายใจและในการสร้างพลังงานไฟฟ้าระบบขับเคลื่อนและช่วยชีวิตของ SM ไม่สามารถทำงานได้ ระบบของโมดูลคำสั่ง (CM) ต้องปิดตัวลงเพื่อสงวนทรัพยากรที่เหลือไว้สำหรับการส่งกลับโดยบังคับให้ลูกเรือย้ายไปยัง Lunar Module (LM) เป็นเรือชูชีพ เมื่อยกเลิกการลงจอดบนดวงจันทร์ผู้ควบคุมภารกิจจึงทำงานเพื่อนำลูกเรือกลับบ้าน”

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

คุณจะทำอย่างไรเมื่อมีการแจ้งเตือนในสภาพแวดล้อมของคุณ?

เอ;

การเดินในอวกาศเป็นหนทางที่ห่างไกลจากกิจกรรมประจำวันของเราเองเว้นแต่คุณจะทำงานให้กับ NASA แต่บล็อกล่าสุดเกี่ยวกับ Apollo 13 ทำให้เกิดคำถามที่เกี่ยวข้องกับความพร้อมใช้งานคุณจะทำอย่างไรเมื่อมีการแจ้งเตือนเกิดขึ้นในสภาพแวดล้อมของคุณ? ทำเป็นเฉยๆไปหรือเปล่า?คุณมองข้ามมันไปรอดูว่าการแจ้งเตือนข้อความบันทึกหรือตัวบ่งชี้อื่น ๆ จะหายไปหรือไม่?คุณติดต่อฝ่ายสนับสนุนผู้จำหน่ายของคุณเพื่อทำความเข้าใจว่าคุณสามารถปิดใช้งานการแจ้งเตือนคำเตือนและข้อความเหล่านี้ได้อย่างไรหรือคุณพูดว่า“ เรามีปัญหาที่นี่และเราจำเป็นต้องแก้ไข”

ในฐานะรองประธานฝ่ายประสบการณ์ลูกค้าของ SIOS Technology Corp. เราได้รับการแจ้งเตือนและตัวบ่งชี้ทั้งสองด้านเราดำเนินการอย่างระมัดระวังกับลูกค้าที่เลือกที่จะเพิกเฉยต่อคำเตือนโดยปิดการแจ้งเตือนที่สำคัญที่ระบุปัญหาต่างๆตั้งแต่เกณฑ์การใช้งานไปจนถึงความไม่เสถียรของเครือข่ายไปจนถึงข้อมูลที่อาจไม่สอดคล้องกันและเรายังได้เห็นลูกค้าที่ติดตามการแจ้งเตือนของพวกเขาตรวจสอบว่าเหตุใดสัญญาณเตือนของพวกเขาจึงดับลงโดยเปิดเผยสาเหตุที่แท้จริงและมีความสุขกับผลงานของพวกเขาผลไม้นี้มักจะเป็นรางวัลอันหอมหวานของความมั่นคงนวัตกรรมและการเรียนรู้ที่ดีขึ้นหรือการหลีกเลี่ยงหายนะ

4 สิ่งที่คุณทำได้เมื่อผลิตภัณฑ์พร้อมจำหน่ายของคุณเรียกการแจ้งเตือน

1. ตรวจสอบว่าประเภทและความสำคัญของการแจ้งเตือนความพร้อมใช้งานหรือไม่

การแจ้งเตือนหรือข้อผิดพลาดบ่งบอกถึงคำเตือนข้อผิดพลาดหรือปัญหาร้ายแรงหรือไม่ สถานที่ที่ดีในการช่วยเหลือคุณและทีมของคุณด้วยความเข้าใจที่สำคัญคือการปรึกษากับเอกสารที่มีอยู่ ตรวจสอบเอกสารผลิตภัณฑ์ฟอรัมออนไลน์บทความฐานความรู้ (KBA) และข้อมูลภายในทีมและคู่มือการดำเนินการ

2. ประเมินความฉับไวของการแจ้งเตือน

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

3. ปรึกษาแหล่งข้อมูลเพิ่มเติม

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

4. ติดต่อฝ่ายสนับสนุน

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

ผู้จำหน่ายที่มีประสบการณ์เช่น SIOS สามารถช่วยคุณระบุสาเหตุของปัญหาได้อย่างรวดเร็วและแนะนำวิธีแก้ไขปัญหาที่ดีที่สุด

การเพิกเฉยต่อปัญหาในสภาพแวดล้อมความพร้อมใช้งานของคุณซ้ำ ๆ อาจทำให้เกิดปัญหาที่ไม่คาดคิด แต่ผลลัพธ์ที่ร้ายแรงไม่น้อยกว่า การจัดการปัญหาที่ระบุโดยการแจ้งเตือนข้อความบันทึกตัวบ่งชี้คำเตือนหรือตัวบ่งชี้อื่น ๆ ที่ติดตั้งและกำหนดค่าไว้จะช่วยให้ลูกค้าของคุณธุรกิจของคุณทีมของคุณและตัวคุณเองมี“ โอกาสในการแก้ไขปัญหา” ก่อนที่จะเกิดภัยพิบัติ และในขณะเดียวกันก็เพิ่มความแข็งแกร่งให้กับกลยุทธ์ความพร้อมใช้งานและโครงสร้างพื้นฐานของคุณคุณจะเลือกแบบไหน?

– Cassius Rhue รองประธานฝ่ายประสบการณ์ลูกค้า

ผลิตซ้ำจาก SIOS

 
มกราคม 23, 2021

ฉันต้องการซอฟต์แวร์ความพร้อมใช้งานสูงในระบบคลาวด์หรือไม่?

ฉันต้องการซอฟต์แวร์ความพร้อมใช้งานสูงในระบบคลาวด์หรือไม่?

ให้ฉันเขย่าความทรงจำของคุณ . .

บางทีวันนี้คุณไม่มีความล้มเหลวในช่วงหลายสิบเดือนหรือมากกว่านั้นและทันใดนั้นการต่ออายุ slam dunk สำหรับใบอนุญาตซอฟต์แวร์ที่มีความพร้อมใช้งานสูงของคุณก็อยู่ภายใต้เส้นแดงของปากกาของ CFOหรืออาจเป็นเพราะส่วนหนึ่งมาจากการใช้คำศัพท์มากเกินไปการตลาดที่ชาญฉลาดหรือการนิยามความพร้อมใช้งานสูง CIO ของคุณซึ่งครั้งหนึ่งเคยเป็นพัดลมที่มีความพร้อมใช้งานยากที่สุดได้เริ่มลังเลกับคุณค่าของมันหรือบางทีอาจไม่ใช่ CFO หรือ CIO แต่เป็นคุณที่ตัดสินใจว่าคุณอาจมี HA เพียงพอโดยไม่จำเป็นต้องมีซอฟต์แวร์ที่พร้อมใช้งานสูงหรือสูงกว่าในสมการ

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

นี่คือเหตุผล 7 ประการที่คุณยังต้องการซอฟต์แวร์ที่มีความพร้อมใช้งานสูงกว่าในระบบคลาวด์:

1. เพื่อเพิ่มความลึกและความครอบคลุมของแอปพลิเคชันสำหรับแอปพลิเคชันระดับองค์กรที่สำคัญที่สุดของคุณ

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

2. สำหรับการกู้คืนแอปพลิเคชันอัตโนมัติและชาญฉลาดของระบบทรัพยากรและการอ้างอิง

ผู้ขายระบบคลาวด์รู้เรื่องเมฆ ผู้ขายที่มีความพร้อมใช้งานสูงทราบดีเกี่ยวกับความพร้อมใช้งานสูงของแอปพลิเคชัน เมื่อใดหากความล้มเหลวเกิดขึ้นในระบบคลาวด์แอปพลิเคชันของคุณต้องการการกู้คืนส่วนประกอบที่ล้มเหลวอย่างชาญฉลาด ระบบทรัพยากรแอปพลิเคชันส่วนประกอบโครงสร้างพื้นฐานและการอ้างอิงในฐานะผู้เชี่ยวชาญด้านความพร้อมใช้งานผู้จำหน่ายซอฟต์แวร์ของคุณมีความรู้ที่ครอบคลุมในการป้องกันแอปพลิเคชัน ในผลิตภัณฑ์ SIOS Protection Suite สำหรับ Linux ระบบอัตโนมัติที่ใช้วิซาร์ดโดยใช้แนวทางปฏิบัติที่ดีที่สุดในอุตสาหกรรมและประวัติอันยาวนานของความเชี่ยวชาญด้านแอปพลิเคชันช่วยผลักดันการกู้คืนแอปพลิเคชันโดยอัตโนมัติอย่างชัดเจนในสถานการณ์ความล้มเหลว

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

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

4. สำหรับกลไกการตอบสนองที่เร็วขึ้นสำหรับการตรวจจับและแก้ไขปัญหา

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

5. สำหรับแหล่งข้อมูลเพิ่มเติมที่สามารถขุดและตรวจสอบได้เพื่อช่วยทำนายสุขภาพและความมั่นคงขององค์กรของคุณ

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

6. สำหรับมุมมองที่สมดุลและเป็นความจริงและภูมิปัญญาเสริมที่จำเป็นสำหรับองค์กรของคุณ

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

7. เพื่อลดเวลาหยุดทำงานของการบำรุงรักษาตามแผน

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

ใช่คลาวด์ได้เพิ่มความเสถียรของฮาร์ดแวร์และแพลตฟอร์มสำหรับแอปพลิเคชันนักพัฒนาและผู้ใช้ระดับองค์กร แต่ถ้าคุณเริ่มคิดว่าไม่ต้องการความพร้อมใช้งานสูงคุณกำลังมุ่งหน้าไปตามตรอกมืดที่จบลงด้วยความสิ้นหวังในช่วงสาย คืนพิซซ่าเย็น ๆ ทำให้แอปพลิเคชันกลับมาออนไลน์อธิบายถึงสิ่งที่อธิบายไม่ได้และใคร่ครวญถึงการปัดฝุ่นเรซูเม่ขอบคุณมากที่ให้ฉันเขย่าความทรงจำของคุณ . .คุณและซอฟต์แวร์ HA ของคุณต้องการกันและกันแม้กระทั่งในระบบคลาวด์

– Cassius Rhue รองประธานฝ่ายประสบการณ์ลูกค้า

ทำซ้ำโดยได้รับอนุญาตจาก SIOS

 
มกราคม 16, 2021

ฉันควรใช้ Zabbix ใน AWS หรือไม่

ฉันควรใช้ Zabbix ใน AWS หรือไม่

ฉันควรใช้ Zabbix ใน AWS หรือไม่

การตรวจสอบ Amazon EC2

Zabbix มีส่วนแบ่งการตลาดสูงในฐานะเครื่องมือตรวจสอบ OSS ในตัวแม้ว่าจะมีการใช้กันอย่างแพร่หลายในสภาพแวดล้อมภายในองค์กร แต่ก็มีตัวอย่างมากมายของ Zabbix ที่ใช้ในสภาพแวดล้อม AWSแม้ว่า AWS จะมีบริการตรวจสอบเช่น Amazon CloudWatch ด้วยเหตุใดคุณจึงควรใช้ Zabbixส่วนนี้อธิบายถึงประโยชน์ของการมอนิเตอร์อินสแตนซ์ EC2 และอินสแตนซ์อื่น ๆ ตลอดจนกระบวนการกำหนดค่า

เหตุใดจึงต้องใช้ Zabbix แทน Amazon CloudWatch

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

Zabbix มีข้อได้เปรียบในการตรวจสอบไม่เพียง แต่ในสถานที่ แต่ยังรวมถึงสภาพแวดล้อมระบบคลาวด์และเสมือนในลักษณะบูรณาการ

ในขณะที่มาตรฐาน Amazon CloudWatch จำกัด เฉพาะการตรวจสอบทรัพยากร AWS (CPU หน่วยความจำ ฯลฯ ) Zabbix ช่วยให้คุณสามารถตรวจสอบสถานะของแอปพลิเคชันของคุณได้อย่างละเอียด

ต่อไปนี้เป็นรายการข้อดีอื่น ๆ ของ Zabbix

การตรวจสอบสภาพแวดล้อมแบบบูรณาการกับบัญชี AWS หลายบัญชี

Amazon CloudWatch ทำการตรวจสอบตามบัญชี AWSZabbix สามารถตรวจสอบสภาพแวดล้อมของบัญชี AWS หลายบัญชีซึ่งสามารถตรวจสอบระบบธุรกิจที่ประกอบด้วยหลายบัญชีนอกจากนี้ยังสามารถตรวจจับความผิดปกติไม่เพียง แต่โดยการแจ้งเตือนธรรมดาตามเกณฑ์เท่านั้น แต่ยังรวมถึงเกณฑ์และเงื่อนไขหลายรายการร่วมกัน 

สามารถกำหนดค่าด้วยการแจ้งเตือนโดยละเอียดเพื่อให้เหมาะกับสภาพการทำงานจริง

Amazon CloudWatch สามารถแจ้งเตือนคุณด้วยข้อความในกรณีที่เกิดความผิดปกติตัวอย่างเช่นหากระบบของคุณหยุดการบำรุงรักษาคุณไม่จำเป็นต้องได้รับการแจ้งเตือนทางข้อความนี่คือจุดที่ Zabbix อนุญาตให้คุณกำหนดค่ากรณีเหล่านี้ในลักษณะที่ช่วยให้คุณสามารถระงับข้อความที่ไม่ต้องการวิธีนี้จะช่วยให้มั่นใจได้ว่าคุณจะได้รับการแจ้งเตือนเมื่อมีสิ่งผิดปกติที่จำเป็นต้องได้รับการแก้ไขเท่านั้น

ไม่มีระยะเวลาการเก็บรักษาสำหรับเมตริก (บันทึกการตรวจสอบ)

ด้วย Amazon CloudWatch สามารถจัดเก็บเมตริกได้นานถึง 15 เดือนยิ่งไปกว่านั้นคุณสามารถจัดเก็บเมตริกได้ทีละชั่วโมงเป็นเวลา 15 เดือนและหากกำหนดช่วงเวลาการตรวจสอบไว้น้อยกว่า 60 วินาทีคุณจะจัดเก็บได้สูงสุด 3 ชั่วโมงเท่านั้นZabbix ช่วยให้สามารถจัดเก็บเมตริกได้ในระยะยาวโดยไม่ต้องเปลี่ยนรายละเอียดของข้อมูล

วิธีตรวจสอบสภาพแวดล้อม AWS ด้วย Zabbix

หากคุณต้องการใช้ Zabbix ใน AWS คุณจะต้องสร้างอินสแตนซ์ Amazon EC2 และ DB และติดตั้ง Zabbixหลังการติดตั้งขั้นตอนการกำหนดค่า Zabbix จะเหมือนกับในองค์กรยกเว้นว่าคุณจะต้องตั้งค่าสิ่งต่อไปนี้

  1. บัญชีผู้ใช้ (นอกเหนือจากผู้ใช้ผู้ดูแลระบบของ Zabbix คุณจะต้องสร้างผู้ใช้สำหรับการใช้งานจริง)
  2. ตัวแทนโฮสต์ Zabbix (กำหนดว่าจะรวบรวมข้อมูลจากที่ใด)
  3. รายการ (ตั้งค่าข้อมูลที่จะรวบรวม)
  4. ทริกเกอร์ (กำหนดสถานะของข้อมูลที่ผิดปกติ)
  5. การดำเนินการ (กำหนดการดำเนินการเมื่อเกิดข้อผิดพลาด)

นอกจากนี้คุณสามารถกำหนดการตั้งค่าเฉพาะ AWS ได้เช่นการสร้างผู้ใช้ใน AWS IAM ด้วยสิทธิ์ที่จำเป็นสำหรับ Zabbix ซึ่งจะช่วยให้ Zabbix ตรวจสอบแอปพลิเคชันและสภาพแวดล้อม AWS ในแง่มุมอื่น ๆ

ใช้เครื่องมือที่เหมาะสมกับความต้องการในการตรวจสอบของคุณ

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

ในทางกลับกัน Zabbix มีตัวเลือกการกำหนดค่ามากมายดังนั้นคุณจะต้องตัดสินใจว่าจะตรวจสอบอะไรอย่างไรและเงื่อนไขใดที่ผิดปกติ

ในทางกลับกัน Zabbix มีการตั้งค่ามากมายดังนั้นคุณต้องออกแบบการทำงานให้ชัดเจนว่าจะตรวจสอบอะไรและจะทำอย่างไรกับมันและจะทำอย่างไรกับมัน แน่นอนว่าสำหรับระบบที่สำคัญการออกแบบนั้นเป็นสิ่งสำคัญอย่างไรก็ตามสำหรับระบบที่ค่อนข้างเรียบง่ายเช่น“ ถ้ากระบวนการหยุดเพียงแค่เริ่มต้นใหม่” จะไม่มีการตรวจสอบ Zabbix ที่ตรงกันSIOS AppKeeper เป็นทางออกที่ดีสำหรับกรณีดังกล่าวเนื่องจากตรวจสอบบริการ (กระบวนการ) ของแอปพลิเคชันที่ทำงานบนอินสแตนซ์ EC2 และรีสตาร์ทแอปพลิเคชันหากตรวจพบปัญหา ทำให้สามารถตรวจสอบและใช้งานได้ง่าย

แน่นอนว่าการใช้ Zabbix ในทุกระบบนั้นไม่ "บังคับ"ด้วยการใช้เครื่องมือที่เหมาะสมสำหรับการตรวจสอบแต่ละประเภทคุณจะสามารถใช้งานระบบของคุณได้อย่างมีประสิทธิภาพมากขึ้น

เพิ่ม SIOS AppKeeper ในการตรวจสอบและการกู้คืน EC2 ของคุณ

ผลิตซ้ำจาก SIOS
  • Results 316-320 of 943
  • < Page 64 of 189 >

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