SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

การจำลองแบบอะซิงโครนัสสามารถใช้งานได้อย่างไรในคลัสเตอร์แบบ multi-site? ไม่ใช่ข้อมูลที่ไม่ตรงกันหรือไม่?

by Leave a Comment

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

มีอยู่มากกว่าสองสามตัวเลือกเมื่อเลือกโซลูชันการจำลองแบบอะซิงโครนัสเพื่อใช้กับคลัสเตอร์ multi-site WSFC ของคุณซึ่งรวมถึงโซลูชันที่ใช้อาร์เรย์จาก บริษัท ต่างๆเช่น EMC IBM HP เป็นต้น และโซลูชันจากโฮสต์เช่นเดียวกับที่ใกล้และเป็นที่รักของฉัน "SteelEye DataKeeper Cluster Edition"  ตั้งแต่ฉันรู้ดีที่สุด DataKeeper ฉันจะอธิบายวิธีการทั้งหมดนี้ทำงานจาก DataKeeper ในอนาคต

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

ขณะที่อยู่ในสถานะ "หยุดชั่วคราว" DataKeeper ช่วยให้คิว async ระบายออกไปจนกว่าเราจะมาถึง "เครื่องหมายน้ำต่ำ" เมื่อถึงจุดนี้กระจกจะเข้าสู่สถานะ "resync" จนกว่าข้อมูลทั้งหมดจะซิงค์กัน  เมื่อถึงจุดนั้นกระจกจะอยู่ในสถานะ "mirroring" อีกครั้งและระบบ failover อัตโนมัติจะเปิดใช้งานอีกครั้ง

ตราบเท่าที่ลิงก์ WAN ของคุณไม่อิ่มตัวหรือเสียคุณไม่ควรเห็นมากกว่าเขียนไม่กี่ที่เวลาใดก็ตามในคิว async นี้   ในความล้มเหลวที่ไม่คาดคิด (คิดดึงสายไฟ) คุณจะสูญเสียการเขียนใด ๆ ที่อยู่ในคิว async  นี่คือการค้าที่คุณทำเมื่อคุณต้องการเป้าหมายการกู้คืนที่น่าประทับใจ (RPO) และวัตถุประสงค์การกู้เวลา (RTO) ที่คุณได้รับจากกลุ่มไซต์หลายแห่ง แต่ลิงก์ WAN ของคุณมีความล่าช้ามากเกินไปในการสนับสนุนการจำลองแบบซิงโครนัสอย่างมีประสิทธิภาพ
ถ้าคุณใช้เวลาในการตรวจสอบคิว Async DataKeeper ผ่านทางบันทึกผลการปฏิบัติงานของ Windows และการแจ้งเตือนฉันคิดว่าคุณจะต้องประหลาดใจมากที่พบว่าเวลาส่วนใหญ่คิว async ว่างเปล่าเนื่องจากประสิทธิภาพของเครื่องมือจำลองข้อมูลของ DataKeeper  แม้ในช่วงที่มีการเขียนอย่างหนักแถว async จะโตขึ้นมากและมักระบายเกือบจะในทันทีดังนั้นจำนวนข้อมูลที่มีความเสี่ยงในเวลาใดก็ตามจึงน้อยที่สุด  เมื่อคุณพิจารณาทางเลือกในภัยพิบัติอาจจะเรียกคืนจากการสำรองข้อมูลคืนที่ผ่านมาจำนวนการเขียนที่คุณอาจสูญเสียในความล้มเหลวที่ไม่คาดคิดโดยใช้การจำลองแบบอะซิงโครนัสมีน้อย!

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

ทำซ้ำโดยได้รับอนุญาตจาก https://clusteringformeremortals.com/2009/07/

ทำไมฉันควรจะแปลงกลุ่ม #ASURE ของฉันไปจัดการกับดิสก์วันนี้!

by Leave a Comment

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

16 มีนาคมหน่วยเก็บข้อมูล US East Storage

ผลกระทบจากลูกค้า: กลุ่มย่อยของลูกค้าที่ใช้ Storage ในภูมิภาคอเมริกาตะวันออกอาจมีข้อผิดพลาดและหมดเวลาในขณะที่เข้าถึงบัญชีพื้นที่จัดเก็บข้อมูลของตนในหน่วยเก็บข้อมูลขนาดเดียว

คุณอาจจะถามว่า "หน่วยจัดเก็บข้อมูลขนาดเดียวคืออะไร" ดีคุณสามารถคิดเป็นกลุ่มการจัดเก็บเดียวหรือ SAN เดียวหรืออย่างไรก็ตามคุณต้องการคิดเกี่ยวกับเรื่องนี้ ฉันไม่คิดว่า Azure เผยแพร่โครงสร้างพื้นฐานที่แน่นอน แต่คุณอาจจะคิดว่าเบื้องหลังพวกเขาใช้ Scale Out File Servers สำหรับการจัดเก็บแบ็กเอนด์

คำถามก็คือฉันจะมีชีวิตรอดได้อย่างไรด้วยการหยุดทำงานน้อยที่สุด? ถ้าคุณอ่านต่อไปว่าการวิเคราะห์รากสาเหตุคุณพบว่ามีนักเก็ตน้อยคนนี้

เครื่องเสมือนที่ใช้ดิสก์ที่มีการจัดการในชุดการจัดหาจะสามารถรักษาความพร้อมใช้งานได้ในระหว่างเหตุการณ์นี้

มีอะไรจัดการดิสก์ที่คุณถาม? ดีวันที่ 8 กุมภาพันธ์ Corey Sanders ประกาศ GA ของ Managed Disks คุณสามารถอ่านทั้งหมดเกี่ยวกับ Managed Disks ได้ที่นี่ https://azure.microsoft.com/en-us/services/managed-disks/

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

ก่อนที่ดิสก์ที่มีการจัดการจะพร้อมใช้งาน (ไม่มีอะไรนำไปใช้ก่อนวันที่ 2/8/2016) ไม่มีวิธีใดที่จะทำให้มั่นใจได้ว่าพื้นที่เก็บข้อมูลที่แนบกับเซิร์ฟเวอร์ของคุณจะอาศัยอยู่กับหน่วยจัดเก็บข้อมูลที่แตกต่างกัน แน่นอนว่าคุณสามารถใช้บัญชีพื้นที่จัดเก็บข้อมูลที่แตกต่างกันได้สำหรับแต่ละกรณี แต่ในความเป็นจริงไม่ได้รับประกันว่า Storage Accounts จะจัดเตรียมพื้นที่เก็บข้อมูลไว้ในหน่วยเก็บข้อมูลที่แตกต่างกัน

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

เรื่องยาวสั้นมาก … โยกย้ายไปยัง Managed Disk โดยเร็วที่สุดเพื่อช่วยลดเวลาหยุดทำงาน

https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-migrate-to-managed-disks

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

ปรับใช้คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์แฟ้ม2โหนดใน Azure ด้วย ARM

by Leave a Comment

ปรับใช้คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์แฟ้ม2โหนดใน Azure โดยใช้ ARM

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

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

เบื้องต้น

  • คุณได้ใช้พอร์ทัล Azure ก่อน และสะดวกในการปรับใช้เครื่องเสมือนใน Azure IaaS
  • ได้รับใบอนุญาตหรือใบอนุญาต eval ของ SIOS DataKeeper

การปรับใช้อินสแตนซ์คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์แฟ้ม

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

สิ่งแวดล้อมจะเป็นดังนี้:

DC1 – ควบคุมโดเมนและการแชร์ไฟล์ของเรา
SQL1 และ SQL2 – สองโหนของคลัสเตอร์เซิร์ฟเวอร์แฟ้มของเรา

การเตรียมใช้งานโหนดคลัสเตอร์ที่สอง (SQL1 และ SQL2)

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

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

3
รูปที่ 3 – เพื่อเพิ่มโหนดคลัสเตอร์และแฟ้มแบ่งปันพยานเดียวกันพร้อมตั้ง

ที่อยู่ IP แบบคง

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

4
รูปที่ 4 – ตรวจสอบว่าแต่ละคลัสเตอร์โหนใช้ IP แบบคง

เก็บ

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

5
รูปที่ 5-ให้แน่ใจว่าการเก็บข้อมูลเพิ่มเติมแต่ละโหนของคลัสเตอร์

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

สมมติว่า ทั้งสองโหนของคลัสเตอร์ (SQL1 และ SQL2) ถูกเตรียมใช้งานตามที่อธิบายไว้ข้างต้น และเพิ่มโดเมนของคุณที่มีอยู่ เราก็พร้อมที่จะสร้างคลัสเตอร์ ก่อนที่เราสร้างคลัสเตอร์ มีกี่สิ่งที่จำเป็นต้องเปิดใช้งาน คุณลักษณะเหล่านี้เป็น.Net Framework 3.5 และคลัสเตอร์ล้มเหลว คุณลักษณะเหล่านี้จำเป็นต้องเปิดใช้งานบนทั้งสองโหนดคลัสเตอร์ คุณจะต้องเปิดใช้งานแฟ้มเซิร์ฟเวอร์บทบาท

6
รูปที่ 6 – เปิดใช้งานทั้ง.Net Framework 3.5 และคลัสเตอร์ล้มเหลวและเซิร์ฟเวอร์แฟ้มบนทั้งสองโหนของคลัสเตอร์

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

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

มีผลข้างเคียงก็แปลกไป Azure มีการใช้งาน DHCP เมื่อสร้างคลัสเตอร์ Windows Server ล้มเหลวคลัสเตอร์ GUI เมื่อโฮสต์ใช้ DHCP (ซึ่งพวกเขาต้อง), ไม่มีตัวเลือกเพื่อระบุอยู่ IP ของคลัสเตอร์ แทน ที่มันอาศัยการ DHCP เพื่อรับที่อยู่ สิ่งที่แปลกคือ DHCP จะออกซ้ำ IP ที่อยู่ มักอยู่เดียวกัน IP เป็นโฮสต์ที่ร้องขออยู่ IP ใหม่ คลัสเตอร์มักจะเสร็จ สมบูรณ์ แต่คุณอาจมีข้อผิดพลาดบางอย่างผิดปกติ และคุณอาจต้องเรียกใช้ Windows Server Failover คลัสเตอร์ GUI จากโหนแตกต่างกันเพื่อที่จะได้ไปทำงาน เมื่อคุณได้รับให้ทำงานคุณจะต้องการเปลี่ยนอยู่ IP ของคลัสเตอร์ไปยังที่อยู่ที่ไม่ได้ถูกใช้บนเครือข่าย

คุณสามารถหลีกเลี่ยงระเบียบทั้งหมดที่เพียงแค่สร้างคลัสเตอร์ผ่านทาง และระบุอยู่ IP ของคลัสเตอร์เป็นส่วนหนึ่งของคำสั่ง PowerShell เพื่อสร้างคลัสเตอร์

คุณสามารถสร้างคลัสเตอร์ที่ใช้คลัสเตอร์ใหม่คำสั่งเป็นดังนี้:

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

หลังจากเสร็จสิ้นการสร้างคลัสเตอร์ คุณจะต้องการรันการตรวจสอบคลัสเตอร์ โดยการเรียกใช้คำสั่งต่อไปนี้:

คลัสเตอร์ทดสอบ

7
รูปที่ 7 – การแสดงผลของการสร้างคลัสเตอร์และคลัสเตอร์ตรวจสอบคำสั่ง

สร้างพยานแบ่งปันไฟล์

เนื่องจากมีไม่เก็บข้อมูลที่ใช้ร่วมกัน คุณจะต้องสร้างการแชร์ไฟล์บนเซิร์ฟเวอร์อื่นในชุดงานเดียวกันเป็นสองคลัสเตอร์โหน โดยใส่ในงานชุดเดียวกัน คุณสามารถมั่นใจได้ว่า คุณสูญเสียเสียงหนึ่งจากควอรัมของคุณเวลาใด ถ้าคุณไม่แน่ใจในวิธีการสร้างเป็นการแชร์ไฟล์ คุณสามารถทบทวน http://www.howtonetworking.com/server/cluster12.htm บทความนี้ ในการสาธิตของฉัน ฉันใส่แชร์ไฟล์บนตัวควบคุมโดเมน ผมได้ตีพิมพ์คำอธิบายที่ครบถ้วนสมบูรณ์ของโควรัมของคลัสเตอร์ที่ https://blogs.msdn.microsoft.com/microsoft_press/2014/04/28/from-the-mvps-understanding-the-windows-server-failover-cluster-quorum-in-windows-server-2012-r2/

การติดตั้ง

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

8
รูปที่ 8 – DataKeeper ติดตั้งหลังจากสร้างคลัสเตอร์

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

9
รูปที่ 9 – บัญชีผู้ใช้บริการต้องเป็นบัญชีโดเมนที่อยู่ในกลุ่มผู้ดูแลท้องถิ่นบนโหนแต่ละ

เมื่อติดตั้ง และได้รับใบอนุญาตในแต่ละโหน DataKeeper คุณจะต้องรีบูตเครื่องเซิร์ฟเวอร์

สร้างทรัพยากรระดับเสียง

เพื่อสร้างทรัพยากร DataKeeper ไดรฟ์ข้อมูล คุณจะต้องเริ่มต้น DataKeeper UI และเชื่อมต่อกับเซิร์ฟเวอร์ทั้งสอง
10เชื่อมต่อกับ SQL1
11

เชื่อมต่อกับ SQL2
12

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

ให้งานชื่อและคำอธิบาย
14

เลือกเซิร์ฟเวอร์ต้นทาง IP และระดับเสียง อยู่ IP ไม่ว่าจะการเดินทางการรับส่งข้อมูลการจำลองแบบ
คลัสเตอร์ล้มเหลวเซิร์ฟเวอร์15แฟ้ม

เลือกเซิร์ฟเวอร์เป้าหมายของคุณ
16

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

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

คุณจะเห็นปริมาณทรัพยากรใหม่ของ DataKeeper ในการจัดเก็บที่พร้อมใช้งาน
19

สร้างทรัพยากรคลัสเตอร์เซิร์ฟเวอร์แฟ้ม

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

เพิ่ม ClusterFileServerRole-เก็บ "DataKeeper เสียง E"-ชื่อ FS2 - StaticAddress 10.0.0.201

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

สร้างสมดุลของโหลดภายใน

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

ครั้งแรก สร้าง Balancer การโหลดใหม่
30

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

หลังจากสร้าง Balancer การโหลดภายใน (ILB) คุณจะต้องแก้ไข สิ่งแรกที่เราจะทำคือการ เพิ่มพู backend ผ่านขั้นตอนนี้ คุณจะเลือกงานตั้ง VMs คลัสเตอร์ SQL ของคุณอยู่ที่ใด อย่างไรก็ตาม เมื่อคุณเลือก VMs จริงเพิ่มพู Backend ให้แน่ใจว่า ไม่ได้แชร์ไฟล์ของคุณ เราไม่ต้องการเปลี่ยนเส้นทางการจราจรของ SQL ของการแชร์ไฟล์
32
33

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

แล้ว ในที่สุด เราต้องการโหลดดุลกฎการเปลี่ยนเส้นทางปริมาณการใช้ SMB สิ่งที่สำคัญจะสังเกตเห็นในภาพด้านล่างคือ ตรง Server กลับเปิดใช้งานพอร์ต TCP 445 ตรวจสอบให้แน่ใจว่า คุณทำการเปลี่ยน

445_ilb

แก้ไขทรัพยากร IP ของเซิร์ฟเวอร์แฟ้ม

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

# กำหนดตัวแปร
$ClusterNetworkName = "" 
#ชื่อเครือข่ายคลัสเตอร์ 
(ใช้ ClusterNetwork รับบน Windows Server 2012 ของสูงเพื่อค้นหาชื่อ)
$IPResourceName = "" 
#ชื่อทรัพยากรที่อยู่ IP 
$ILBIP = "" 
#อยู่ IP ภายใน balancer การโหลด (ILB)
โมดู FailoverClusters
#หากคุณใช้ Windows Server 2012 หรือสูงกว่า:
รับ ClusterResource $IPResourceName กรุนด์ฟอส ชุด ClusterParameter 
-หลาย @{อยู่ = $ILBIP ProbePort = 59999 SubnetMask = "255.255.255.255"
เครือข่าย = $ClusterNetworkName EnableDhcp = 0 }
#หากคุณใช้ Windows Server 2008 R2 ใช้นี้: 
#cluster res $IPResourceName /priv enabledhcp = 0 อยู่ = $ILBIP probeport = 59999  
subnetmask = 255.255.255.255

การสร้างการแชร์ไฟล์

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

โปรดสังเกตว่า ตัวเลือก "ความพร้อมใช้งานต่อเนื่อง" ของไฟล์แชร์ไม่สนับสนุนในการกำหนดค่านี้

สรุป

คุณควรจะมีการทำงานแฟ้มเซิร์ฟเวอร์คลัสเตอร์ หากคุณมีปัญหาใดๆโปรดติดต่อเราได้ที่ Twitter @daveberm จำเป็นต้องมีคีย์การประเมิน datakeeper กรอกแบบฟอร์มที่ http://us.sios.com/clustersyourway/cta/14-day-trial และ sios จะส่งคีย์การประเมินที่ส่งออกไปให้คุณ

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