Amazon CloudWatch คืออะไร

คุณสามารถทำอะไรกับ CloudWatch และอุปสรรคบางอย่างที่ต้องพิจารณา

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

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

ใช้ Amazon CloudWatch เพื่อตรวจสอบสภาพแวดล้อม AWS ของคุณอย่างใกล้ชิด

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

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

ความท้าทายในการติดตั้ง Amazon CloudWatch

ในขณะที่ Amazon CloudWatch เหมาะสมอย่างยิ่งสำหรับองค์กรที่มีวิศวกรระบบคลาวด์ที่มีประสบการณ์และทีม DevOps มีบางสิ่งที่ผู้ใช้ทั่วไปควรระวัง

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

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

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

SIOS AppKeeper สำหรับตรวจสอบระบบปฏิบัติการและบริการแอพพลิเคชันที่ทำงานบน AWS

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

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

แทนที่จะใช้ Amazon CloudWatch เพื่อตรวจสอบทุกอย่างในสภาพแวดล้อม AWS ของคุณอย่างใกล้ชิดเราขอแนะนำให้คุณนำสินค้าคงคลังของสภาพแวดล้อมของคุณตาม SLA และข้อกำหนดการกู้คืนของคุณและใช้ SIOS AppKeeper เพื่อตรวจสอบระบบและแอพพลิเคชั่นที่คุณต้องการลดค่าใช้จ่าย

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

เรียนรู้เพิ่มเติมเกี่ยวกับ SIOS AppKeeper

ลงทะเบียนเพื่อทดลองใช้ฟรีของ SIOS AppKeeper

 

ระบบทดสอบ / ควบคุมคุณภาพเป็นส่วนสำคัญของความพร้อมใช้งานขององค์กร

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

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

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

ในแนวหน้าของการปรับใช้ระดับองค์กรจำนวนมาก (ระบบใหม่การโยกย้ายศูนย์ข้อมูลและการอัปเดตระบบ) ทีมงานของฉันในการสนับสนุนและบริการได้เห็นปัญหามากมายที่อาจถูกสื่อโดยการใช้ระบบทดสอบ / คลัสเตอร์

ระบบทดสอบ / คุณภาพเป็นส่วนที่มีค่าของกลยุทธ์ HA เพื่อหลีกเลี่ยงการหยุดทำงาน งานทั่วไปที่เกี่ยวข้องกับการบำรุงรักษาการปรับใช้องค์กรเช่นแพทช์การอัพเดตและการเปลี่ยนแปลงการกำหนดค่ามีความเสี่ยง ความเสี่ยงมหาศาล

ความเสี่ยงที่ระบุโดยทั่วไปของการทดสอบในการผลิตรวมถึงปัญหาร้ายแรงและความหายนะที่อาจเกิดขึ้นหลายประการ: 

• ข้อมูลที่เสียหายหรือไม่ถูกต้อง
• ข้อมูลที่มีการป้องกันรั่วไหลออกไป
• การรับรู้รายได้ไม่ถูกต้อง (คำสั่งยกเลิก ฯลฯ )
• ระบบโอเวอร์โหลด
• ผลข้างเคียงที่ไม่ตั้งใจหรือผลกระทบต่อระบบการผลิตอื่น
• อัตราความผิดพลาดสูงที่ตั้งค่าการเตือนและหน้าคนโทร
• การวิเคราะห์แบบเบ้ (ช่องทางการจราจรผลการทดสอบ A / B ฯลฯ )
• บันทึกการใช้งานที่ไม่ถูกต้องเต็มไปด้วยกิจกรรมสคริปต์และบอท (a)

หากลูกค้าพยายามใช้การเปลี่ยนแปลงที่มีความเสี่ยงในการผลิตผลลัพธ์อาจเป็นอันตรายได้ ด้านบนของรายการด้านบนมีความเสี่ยงเพิ่มขึ้นของการหยุดทำงานการทุจริตของการติดตั้งแอปพลิเคชันและในบางกรณีความเสียหายกลับไม่ได้ พิจารณากรณีของลูกค้า X (ร้านค้า SAP Enterprise ที่มีชื่อเสียงในอุตสาหกรรมการผลิต)

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

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

การใช้ระบบทดสอบ QA เพื่อปรับปรุงความพร้อมใช้งานและกระบวนการผลิต

นี่คือพื้นฐานที่ใช้ระบบทดสอบ / ควบคุมคุณภาพสามารถให้บริการสำหรับการปรับปรุงความพร้อมใช้งานและกระบวนการผลิตของคุณ สภาพแวดล้อมที่ควบคุมซึ่งคล้ายกัน (ต้องคล้ายกับการผลิตให้ใกล้เคียงที่สุด) กับสภาพแวดล้อมการผลิตให้ความสามารถในการ:

1. ทดสอบการอัพเดตเคอร์เนลและการอัพเดทความปลอดภัย
2. ตรวจสอบการตั้งค่าและการปรับแต่งค่า
3. สร้างปัญหาการผลิตซ้ำและทดสอบการปรับปรุงซอฟต์แวร์และโปรแกรมแก้ไข
4. ตรวจสอบความเข้ากันได้ของเวอร์ชันของแอปพลิเคชันและลดความเสี่ยงของการหยุดทำงานเนื่องจากการเปลี่ยนแปลงที่เข้ากันไม่ได้
5. จัดให้มีพื้นที่ปลอดภัยในการฝึกซ้อมและแก้ไขกิจกรรมการใช้ชีวิตการบำรุงรักษาการหยุดทำงานและอื่น ๆ ขององค์กร
6. อบรมพนักงานใหม่และสมาชิกในทีมโดยไม่ส่งผลกระทบต่อลูกค้าองค์กร

หากคุณมีสภาพแวดล้อม Test / QA สำหรับการปรับใช้ซอฟต์แวร์ความพร้อมใช้งานระดับองค์กรที่สำคัญของคุณฉันสามารถจูบคุณได้ทันที การมีสภาพแวดล้อมนี้ช่วยให้ทีมของคุณมีความสามารถ“ ในการทดสอบตรวจสอบและยืนยัน (2)” สถาปัตยกรรมความต้องการทางธุรกิจสถานการณ์ของผู้ใช้และการรวมทั่วไปกับระบบหรือชุดของระบบที่ใกล้เคียงกับสภาพแวดล้อมการผลิตมากที่สุด ทำให้เงิน แน่นอนคุณจะต้องกำหนดเวลา windows เพื่อบำรุงรักษาระบบการผลิตของคุณและทำการทดสอบกับพวกเขาเช่นกัน แต่หลังจากขั้นตอนบัฟเฟอร์ที่ปลอดภัยเสร็จสมบูรณ์ในระหว่างนั้น

– Cassius Rhue, VP, ประสบการณ์ของลูกค้า

—–

อ้างอิง:

1. https://opensource.com/article/19/5/dont-test-production เข้าถึง 5/4/2020
2. https://www.softwaretestingclass.com/system-testing-what-why-how/ เข้าถึง 5/4/2020

ความพร้อมใช้งานขององค์กร: บทเรียนจากศาล

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

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

ฉันเกือบจะรู้สึกได้ว่าคุณถ่ายทอดจิตวิญญาณของ AI ไม่ใช่ปัญญาประดิษฐ์ (AI), Allen Iverson (AI)  “ เรากำลังพูดถึงเรื่องการปฏิบัติ  ปฏิบัติ!” ฉันคิดว่านี่เป็นเรื่องเกี่ยวกับความพร้อมใช้งาน  ความรักในกีฬาบาสเก็ตบอลของฉันได้พบกับความหลงใหลในตัวฉันเมื่อฉันถือว่าลูกสาวและเพื่อนร่วมทีมของเธอ อย่างไร?

สามวิธีบาสเก็ตบอลเป็นเหมือนกลยุทธ์ความพร้อมใช้งาน:

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

ความพร้อมใช้งานขององค์กรต้องการแผน 

ความพร้อมใช้งานของคุณโดยเฉพาะความหายนะของคุณการบำรุงรักษาตามแผนและกลยุทธ์การกู้คืนระบบก็ดีเช่นเดียวกับที่คุณสร้างขึ้น กล่าวง่ายๆว่าแผนของคุณเกิดปัญหาไฟดับ (โน้ตเมฆล้มเหลวเซิร์ฟเวอร์ขัดข้องเครือข่ายได้รับการอิ่มตัวและความผิดพลาดของมนุษย์ – เพียงพอที่จะพูด)  คุณมีแผนเอกสารหรือไม่? คุณระบุเจ้าของและเจ้าของสำเนาสำรองหรือไม่ คุณรู้สถาปัตยกรรมและโทโพโลยีของคุณหรือไม่ (เซิร์ฟเวอร์ใดทำอะไรอยู่ที่ใดมันอยู่ในทีมใดมีฟังก์ชั่นอะไรทำหน้าที่จัดลำดับความสำคัญของธุรกิจผูกติดกับอะไรและ SLO / SLA ต้องการอะไร) ใครคือผู้จำหน่ายหลักของคุณและรายการโทรออกของพวกเขาคืออะไร? จุดตรวจแผนป้องกันข้อมูลและกลยุทธ์การสำรองข้อมูลของคุณคืออะไร? และแผนการทดสอบและแผนการตรวจสอบของคุณสำหรับการตรวจสอบของแผนนี้คืออะไร?

ความพร้อมใช้งานขององค์กรต้องการการปฏิบัติ 

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

ความพร้อมใช้งานระดับองค์กรจำเป็นต้องมีการทดสอบ 

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

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

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

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

เยี่ยมชมโพสต์หลังการทดสอบที่คุณไม่ควรหลีกเลี่ยงการจำลอง

– Cassius Rhue, VP, ประสบการณ์ของลูกค้า

บทความทำซ้ำจาก SIOS

ทีละขั้นตอน: เซิร์ฟเวอร์เป้าหมาย ISCSI ใน Azure

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

requisites ก่อน

ฉันจะสมมติว่าคุณคุ้นเคยกับ Azure และ Windows Server แล้วดังนั้นฉันจะสำรองข้อมูลบางอย่างให้คุณ สมมติว่าคุณได้ทำสิ่งต่อไปนี้เป็นสิ่งที่จำเป็นล่วงหน้าอย่างน้อย

• จัดเตรียมเซิร์ฟเวอร์สองเครื่อง (SQL1, SQL2) แต่ละเครื่องในโซนความพร้อมใช้งานที่แตกต่างกัน (ชุดความพร้อมใช้งานเป็นไปได้ แต่โซนความพร้อมใช้งานมี SLA ที่ดีกว่า)
• กำหนดที่อยู่ IP แบบคงที่ให้กับพวกเขาผ่านพอร์ทัล Azure
• เข้าร่วมเซิร์ฟเวอร์กับโดเมนที่มีอยู่
• เปิดใช้งานคุณสมบัติการทำคลัสเตอร์เข้าแทนที่และคุณสมบัติเซิร์ฟเวอร์เป้าหมาย iSCSI บนทั้งสองโหนด
• เพิ่ม Azure Premium Disk สามตัวสำหรับแต่ละโหนด
  หมายเหตุ: นี่เป็นทางเลือกหนึ่งดิสก์เป็นขั้นต่ำที่จำเป็น สำหรับ IOPS ที่เพิ่มขึ้นเราจะทำแถบดิสก์ Azure แบบพรีเมี่ยมสามตัวพร้อมกันในพูลหน่วยเก็บข้อมูลและสร้างดิสก์เสมือน (RAID 0) แบบง่าย
• SIOS DataKeeper จะถูกใช้เพื่อจัดเตรียมหน่วยความจำที่จำลองแบบแล้วที่ใช้ในคลัสเตอร์ หากคุณต้องการ DataKeeper คุณสามารถขอทดลองใช้ที่นี่

สร้างพูลหน่วยเก็บข้อมูลโลคัล

อีกครั้งขั้นตอนนี้เป็นทางเลือกที่สมบูรณ์ แต่สำหรับ IOPS ที่เพิ่มขึ้นเราจะทำการรวม Azure Premium ดิสก์สามตัวไว้ใน Storage Pool เดียว คุณอาจถูกล่อลวงให้ใช้ Dynamic Disk และไดรฟ์ข้อมูลที่ถูกขยายแทน แต่อย่าทำเช่นนั้น! หากคุณใช้ดิสก์แบบไดนามิกคุณจะพบว่ามีความไม่เข้ากันทั่วไปบางอย่างที่จะป้องกันไม่ให้คุณสร้างเป้าหมาย iSCSI ในภายหลัง

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

ข้อผิดพลาด # 1 – แม้ว่าเอกสารระบุว่าขนาดต่ำสุดสำหรับไดรฟ์ข้อมูลที่จะใช้ในพูลหน่วยเก็บข้อมูลคือ 4 GB แต่ฉันพบว่าไม่รู้จัก P1 Premium Disk (4GB) ดังนั้นในห้องแล็บของฉันฉันใช้ 16GB P3 Premium ดิสก์

ผิดพลาด # 2 – คุณต้องมีดิสก์อย่างน้อยสามแผ่นเพื่อสร้าง Storage Pool

ผิดพลาด # 3 – สร้างสระว่ายน้ำเก็บข้อมูลของคุณก่อนที่จะสร้างคลัสเตอร์ของคุณ ถ้าคุณพยายามทำมันหลังจากที่คุณสร้างคลัสเตอร์ของคุณคุณจะจบลงด้วยความยุ่งเหยิงครั้งใหญ่เนื่องจาก Microsoft พยายามสร้างพูลหน่วยเก็บข้อมูลแบบคลัสเตอร์สำหรับคุณ เราจะไม่สร้างพูลหน่วยเก็บข้อมูลแบบคลัสเตอร์ดังนั้นหลีกเลี่ยงความยุ่งเหยิงนั้นด้วยการสร้าง Storage Pool ของคุณก่อนที่คุณจะสร้างคลัสเตอร์ หากคุณต้องเพิ่ม Storage Pool หลังจากสร้างคลัสเตอร์คุณจะต้องไล่โหนดจากคลัสเตอร์จากนั้นสร้าง Storage Pool

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

คุณควรเห็น Primordial pool บนเซิร์ฟเวอร์ทั้งสอง

คลิกขวาและเลือก New Storage Pool …

เลือกสร้างดิสก์เสมือนเมื่อตัวช่วยสร้างนี้ปิด

สังเกตุที่นี่คุณสามารถสร้างระดับการจัดเก็บถ้าคุณตัดสินใจที่จะใช้การรวมกันของ Standard, Premium และ Ultra SSD

เพื่อประสิทธิภาพที่ดีที่สุดให้ใช้เค้าโครงการจัดเก็บแบบง่าย (RAID 0) ไม่ต้องกังวลเกี่ยวกับความน่าเชื่อถือเนื่องจาก Azure ดิสก์ที่มีการจัดการมีความซ้ำซ้อนสามเท่าในแบ็กเอนด์ จำเป็นต้องใช้ Simple เพื่อประสิทธิภาพที่ดีที่สุด

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

สร้างคลัสเตอร์ของคุณ

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

นี่คือตัวอย่างของรหัส Powershell เพื่อสร้างคลัสเตอร์ใหม่

 ใหม่คลัสเตอร์ - ชื่อ mycluster -NoStorage -StaticAddress 10.0.0.100 - โหนด sql1, sql2

ผลลัพธ์จะมีลักษณะเช่นนี้

PS C:  Users  dave.DATAKEEPER> คลัสเตอร์ใหม่ - ชื่อ mycluster - NoStorage 
-StaticAddress 10.0.0.100 - โหนด sql1, sql2
คำเตือน: มีปัญหาขณะสร้างบทบาทคลัสเตอร์ที่ 
อาจป้องกันไม่ให้เริ่มต้น 
สำหรับข้อมูลเพิ่มเติมดูไฟล์รายงานด้านล่าง
คำเตือน: รายงานตำแหน่งของไฟล์: C:  windows  cluster  Reports  Create Cluster 
Wizard mycluster เมื่อวันที่ 2020.05.20 
ที่ 16.54.45.htm

ชื่อ     
----     
mycluster

คำเตือนในรายงานจะบอกคุณว่าไม่มีพยาน เนื่องจากไม่มีพื้นที่เก็บข้อมูลที่ใช้ร่วมกันในคลัสเตอร์นี้คุณจะต้องสร้าง Cloud Witness หรือ File Share Witness ฉันจะไม่นำคุณไปสู่กระบวนการดังกล่าวเนื่องจากมีการบันทึกไว้อย่างดีในลิงก์เหล่านั้น

อย่าละทิ้งสิ่งนี้ไปข้างหน้าและสร้างพยานก่อนที่คุณจะย้ายไปยังขั้นตอนต่อไป!

ตอนนี้คุณควรมีคลัสเตอร์ 2 โหนดพื้นฐานที่มีลักษณะดังนี้

กำหนดค่าตัวโหลดบาลานซ์สำหรับที่อยู่ IP หลักของคลัสเตอร์

กลุ่มใน Azure มีลักษณะเฉพาะที่เครือข่ายเสมือน Azure ไม่สนับสนุน ARP ที่ให้เปล่า ไม่ต้องกังวลหากคุณไม่ทราบความหมายสิ่งที่คุณต้องรู้จริงๆก็คือไม่สามารถเข้าถึงที่อยู่ IP ของคลัสเตอร์ได้โดยตรง คุณต้องใช้ Azure Load Balancer แทนซึ่งจะเปลี่ยนเส้นทางการเชื่อมต่อไคลเอ็นต์ไปยังโหนดคลัสเตอร์ที่ใช้งานอยู่

มีสองขั้นตอนในการรับโหลดบาลานเซอร์ที่กำหนดค่าสำหรับคลัสเตอร์ใน Azure ขั้นตอนแรกคือการสร้าง load balancer ขั้นตอนที่สองคือการอัปเดตที่อยู่ IP ของคลัสเตอร์เพื่อรับฟังโพรบสุขภาพของโหลดบาลานซ์และใช้ซับเน็ตมาสก์ 255.255.255.255 ซึ่งช่วยให้คุณหลีกเลี่ยงที่อยู่ IP ที่ขัดแย้งกับ ILB

ก่อนอื่นเราจะสร้างตัวโหลดบาลานซ์สำหรับที่อยู่ IP หลักของคลัสเตอร์ หลังจากนั้นเราจะแก้ไข load balancer เพื่อระบุที่อยู่ IP ของทรัพยากรคลัสเตอร์คลัสเตอร์ iSCSI ที่เราจะสร้างขึ้นในตอนท้ายของเอกสารนี้

ขอให้สังเกตว่าที่อยู่ IP แบบคงที่เราใช้เป็นที่อยู่เดียวกับที่เราใช้ในการสร้างทรัพยากร IP ของคลัสเตอร์หลัก

เมื่อสร้าง load balancer แล้วคุณจะแก้ไข load balancer ดังที่แสดงด้านล่าง

เพิ่มโหนดคลัสเตอร์สองโหนดเข้ากับพูลแบ็คเอนด์

เพิ่มโหนดคลัสเตอร์สองโหนดเข้ากับพูลแบ็คเอนด์

เพิ่มโพรบเพื่อสุขภาพ ในตัวอย่างนี้เราใช้ 59999 เป็นพอร์ต โปรดจำไว้ว่าพอร์ตเราจะต้องใช้ในขั้นตอนต่อไป

สร้าง rue ใหม่เพื่อเปลี่ยนเส้นทางพอร์ต HA ทั้งหมดตรวจสอบให้แน่ใจว่า IP แบบลอยได้เปิดใช้งานแล้ว

ขั้นตอนที่ 2 – แก้ไขกลุ่มที่อยู่ IP ของแกนทำงานกับเครื่องชั่งแบบโหลดได้

ดังที่ฉันได้กล่าวไว้ก่อนหน้านี้มีสองขั้นตอนในการเรียกใช้ load balancer ที่กำหนดค่าให้ทำงานอย่างถูกต้อง ตอนนี้เรามี load balancer เราต้องรันสคริปต์ Powershell บนหนึ่งในโหนดคลัสเตอร์ ต่อไปนี้เป็นสคริปต์ตัวอย่างที่ต้องรันบนหนึ่งในโหนดคลัสเตอร์

$ ClusterNetworkName =“ เครือข่ายคลัสเตอร์ 1” 
$ IPResourceName =“ ที่อยู่ IP ของคลัสเตอร์” 
$ ILBIP =“ 10.0.0.100” 
Import-Module FailoverClusters
รับ - ClusterResource $ IPResourceName | ชุด ClusterParameter 
-Multiple @ {ที่อยู่ = $ ILBIP; ProbePort = 59998; SubnetMask = "255.255.255.255"
; เครือข่าย = $ ClusterNetworkName; EnableDHCP = 0} 

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

หลังจากที่คุณเรียกใช้ผลลัพธ์ควรมีลักษณะเช่นนี้

 PS C:  Users  dave.DAKEEPER> $ ClusterNetworkName =“ เครือข่ายคลัสเตอร์ 1” 
$ IPResourceName =“ ที่อยู่ IP ของคลัสเตอร์” 
$ ILBIP =“ 10.0.0.100” 
Import-Module FailoverClusters
รับ - ClusterResource $ IPResourceName | ชุด ClusterParameter 
-Multiple @ {ที่อยู่ = $ ILBIP; ProbePort = 59999; SubnetMask = "255.255.255.255"
; เครือข่าย = $ ClusterNetworkName; EnableDHCP = 0}
คำเตือน: คุณสมบัติถูกเก็บไว้ แต่การเปลี่ยนแปลงบางอย่างจะไม่มีผล 
จนกว่าที่อยู่ IP ของคลัสเตอร์จะออฟไลน์จากนั้นออนไลน์อีกครั้ง

คุณจะต้องใช้ทรัพยากรหลักของคลัสเตอร์ IP แบบออฟไลน์และนำกลับมาออนไลน์อีกครั้งก่อนที่จะทำงานได้อย่างถูกต้องกับ load balancer

สมมติว่าคุณทำทุกอย่างถูกต้องในการสร้าง load balancer ของคุณ Server Manager ของคุณบนเซิร์ฟเวอร์ทั้งสองควรแสดงรายการคลัสเตอร์ของคุณเป็นออนไลน์ดังที่แสดงด้านล่าง

ตรวจสอบ Server Manager บนโหนดคลัสเตอร์ทั้งสอง คลัสเตอร์ของคุณควรแสดงเป็น“ ออนไลน์” ภายใต้การจัดการ

ติดตั้ง DataKeeper

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

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

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

ใช้อินเทอร์เฟซ DataKeeper เพื่อเชื่อมต่อกับเซิร์ฟเวอร์ทั้งสอง

คลิกที่สร้างงานใหม่และตั้งชื่อ

คลิกใช่เพื่อลงทะเบียนไดรฟ์ข้อมูล DataKeeper ในคลัสเตอร์

เมื่อมีการลงทะเบียนไดรฟ์ข้อมูลจะปรากฏในที่เก็บข้อมูลที่พร้อมใช้งานใน Failover Cluster Manager

สร้างคลัสเตอร์เซิร์ฟเวอร์เป้าหมาย ISCSI

ในขั้นตอนต่อไปนี้เราจะสร้างบทบาทเซิร์ฟเวอร์เป้าหมาย iSCSI ในคลัสเตอร์ของเรา ในโลกอุดมคติฉันจะมีสคริปต์ Powershell ที่ทำสิ่งนี้ให้คุณ แต่เพื่อประโยชน์ของเวลาในตอนนี้ฉันจะแสดงให้คุณเห็นว่าต้องทำอย่างไรผ่าน GUI หากคุณเขียนรหัส Powershell โปรดแบ่งปันกับพวกเราที่เหลือ!

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

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

ตอนนี้คุณควรจะสามารถนำทรัพยากรคลัสเตอร์ iSCSI มาออนไลน์ได้แล้ว

ปรับปรุงตัวโหลดบาลานซ์สำหรับทรัพยากรคลัสเตอร์เซิร์ฟเวอร์เป้าหมายของ ISCSI

อย่างที่ฉันได้กล่าวไปแล้วลูกค้าไม่สามารถเชื่อมต่อโดยตรงกับที่อยู่ IP ของคลัสเตอร์ (10.0.0.110) ที่เราเพิ่งสร้างขึ้นสำหรับเซิร์ฟเวอร์เป้าหมาย iSCSI เราจะต้องอัปเดตตัวโหลดบาลานซ์ที่เราสร้างไว้ก่อนหน้าดังที่แสดงด้านล่าง

เริ่มต้นด้วยการเพิ่มที่อยู่ IP ส่วนหน้าใหม่ที่ใช้ที่อยู่ IP เดียวกันกับที่ใช้ทรัพยากร IP ของคลัสเตอร์เป้าหมาย iSCSI

เพิ่มโพรบเพื่อสุขภาพที่สองบนพอร์ตอื่น จำหมายเลขพอร์ตนี้เราจะใช้อีกครั้งในสคริปต์ PowerShell ที่เราเรียกใช้ถัดไป

เราเพิ่มกฎการปรับสมดุลภาระเพิ่มอีกหนึ่งข้อ ตรวจสอบให้แน่ใจว่าเปลี่ยนที่อยู่ IP ของ Frontend และ Health probe เพื่อใช้ที่อยู่ที่เราเพิ่งสร้างขึ้น ตรวจสอบให้แน่ใจด้วยว่าเปิดใช้งานการส่งคืนเซิร์ฟเวอร์โดยตรง

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

 $ ClusterNetworkName =“ เครือข่ายคลัสเตอร์ 1” 
$ IPResourceName =“ ที่อยู่ IP 10.0.0.0” 
$ ILBIP =“ 10.0.0.110” 
Import-Module FailoverClusters
รับ - ClusterResource $ IPResourceName | ชุด ClusterParameter 
-Multiple @ {ที่อยู่ = $ ILBIP; ProbePort = 59998; SubnetMask = "255.255.255.255"
; เครือข่าย = $ ClusterNetworkName; EnableDHCP = 0} 

ผลลัพธ์ของคุณควรมีลักษณะเช่นนี้

 PS C:  Users  dave.DAKEEPER> $ ClusterNetworkName =“ เครือข่ายคลัสเตอร์ 1” 
$ IPResourceName =“ ที่อยู่ IP 10.0.0.0” 
$ ILBIP =“ 10.0.0.110” 
Import-Module FailoverClusters
รับ - ClusterResource $ IPResourceName | ชุด ClusterParameter 
-Multiple @ {ที่อยู่ = $ ILBIP; ProbePort = 59998; SubnetMask = "255.255.255.255"
; เครือข่าย = $ ClusterNetworkName; EnableDHCP = 0}
คำเตือน: คุณสมบัติถูกเก็บไว้ แต่การเปลี่ยนแปลงบางอย่างจะไม่มีผล 
จนกว่าที่อยู่ IP 10.0.0.0 จะออฟไลน์และออนไลน์อีกครั้ง

ตรวจสอบให้แน่ใจว่าใช้ทรัพยากรออฟไลน์และออนไลน์เพื่อให้การตั้งค่ามีผล

สร้างเป้าหมาย ISCSI แบบกลุ่มของคุณ

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

หากเซิร์ฟเวอร์ใดมีปัญหาในการสอบถามชื่อคลัสเตอร์เหล่านั้นขั้นตอนต่อไปจะล้มเหลว หากมีปัญหาฉันจะตรวจสอบทุกขั้นตอนอีกครั้งเพื่อสร้าง load balancer และสคริปต์ Powershell ที่คุณรัน

ตอนนี้เราพร้อมที่จะสร้างเป้าหมาย iSCSI คลัสเตอร์แรกของเรา จากโหนดคลัสเตอร์อย่างใดอย่างหนึ่งทำตามขั้นตอนที่แสดงด้านล่างเป็นตัวอย่างเกี่ยวกับวิธีการสร้างเป้าหมาย iSCSI

แน่นอนว่าต้องกำหนดสิ่งนี้ให้กับเซิร์ฟเวอร์หรือเซิร์ฟเวอร์ใดก็ตามที่จะเชื่อมต่อกับ iSSI เป้าหมายนี้

และที่นั่นคุณก็มีตอนนี้คุณมีเซิร์ฟเวอร์เป้าหมาย iSCSI ที่ใช้งานได้ใน Azure

หากคุณสร้างสิ่งนี้ออกความคิดเห็นและฉันรู้ว่าคุณวางแผนที่จะใช้มัน!

บทความที่ทำซ้ำได้รับอนุญาตจาก Clusteringwithmeremortals

บทสรุปโซลูชัน: กลุ่ม SANless สำหรับสภาพแวดล้อมคลาวด์คลาวด์

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

ความยืดหยุ่นในการกำหนดค่า

ไม่ว่าคุณต้องการปกป้องแอปพลิเคชั่นในเซิร์ฟเวอร์ทางกายภาพ, คลาวด์ส่วนตัวภายในองค์กรของคุณ, ในระบบคลาวด์สาธารณะหรือไฮบริดคลาวด์, ซอฟต์แวร์ SIOS SANless ช่วยให้คุณมีความยืดหยุ่นในการสร้างคลัสเตอร์อัตโนมัติ ของฮาร์ดแวร์มาตรฐานอุตสาหกรรมสกีมาเรพลิเคชันและการนำไปใช้งาน (active / active, active / passive)

ซอฟต์แวร์ SIOS ช่วยให้คุณทำซ้ำระหว่างการกำหนดค่าที่คุณเลือก – ระหว่างสภาพแวดล้อม SAN และ SANless และการรวมกันของการกำหนดค่าทางกายภาพเสมือนและระบบคลาวด์ ไม่มีล็อคผู้ขาย ไม่จำเป็นต้องใช้ฮาร์ดแวร์เหมือนกันที่ต้นทางและปลายทาง

ง่ายต่อการใช้. ง่ายต่อการเป็นเจ้าของ

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

ประโยชน์ที่สำคัญ

การป้องกันภัยพิบัติ

•ใช้งานง่ายประหยัดค่าใช้จ่ายสูงและการป้องกันภัยพิบัติสำหรับแอปพลิเคชันที่สำคัญทางธุรกิจ

มีความยืดหยุ่น

•ผสมผสานสภาพแวดล้อมเซิร์ฟเวอร์และระบบคลาวด์เพื่อประสิทธิภาพสูงสุด

สะดวกในการใช้

•คอนโซลที่ใช้งานง่ายเพื่อการตรวจสอบและการจัดการอย่างต่อเนื่อง

ดาวน์โหลดบทสรุปโซลูชันบน SANless Clusters สำหรับ Hybrid Cloud En Environment