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
  • ไทย

คลัสเตอร์ล้มเหลวเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์ที่มีคุณสมบัติ Azure ILB ใหม่

เมษายน 14, 2019 by Jason Aw Leave a Comment

คุณสมบัติ Azure ILB ใหม่ให้คุณสร้างคลัสเตอร์ Failover SQL Server แบบหลายอินสแตนซ์

ที่ Microsoft Ignite เมื่อเดือนกันยายนที่ผ่านมา Microsoft ได้ประกาศเกี่ยวกับ Azure หนึ่งในประกาศเหล่านี้คือความพร้อมใช้งานทั่วไปของวีไอพีหลาย ๆ ตัวเกี่ยวกับตัวโหลดบาลานซ์ภายใน เหตุใดจึงสำคัญกับ SQL Server DBA จนถึงตอนนี้ถ้าคุณต้องการปรับใช้ SQL Server ที่มีความพร้อมใช้งานสูงใน Azure คุณจะถูก จำกัด ให้ใช้ FCI เซิร์ฟเวอร์ SQL เดียวต่อหนึ่งคลัสเตอร์หรือกลุ่มผู้ฟังกลุ่มความพร้อมใช้งานเพียงครั้งเดียว ข้อ จำกัด นี้บังคับให้คุณปรับใช้คลัสเตอร์ใหม่สำหรับแต่ละอินสแตนซ์ของ SQL Server ที่คุณต้องการป้องกันใน Failover Cluster นอกจากนี้ยังบังคับให้คุณจัดกลุ่มฐานข้อมูลทั้งหมดของคุณลงในกลุ่มความพร้อมใช้งานเดียวหากคุณต้องการการเปลี่ยนเส้นทางอัตโนมัติและการเปลี่ยนเส้นทางไคลเอ็นต์ในการกำหนดค่า AlwaysOn AG ของคุณ

วิธีออกจากข้อ จำกัด เหล่านี้

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

เริ่มต้นด้วยคลัสเตอร์ล้มเหลวเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์

สร้างอินสแตนซ์พื้นฐานเดียวของ SQL Server FCI ใน Azure ตามที่อธิบายในโพสต์ของฉันการปรับใช้ Microsoft SQL Server 2014 Failover Clusters ใน Azure Resource Manager โพสต์นั้นอธิบายกระบวนการสร้างคลัสเตอร์ Failover Cluster Server แบบหลายอินสแตนซ์ ใช้ DataKeeper เพื่อสร้างทรัพยากรโวลุ่มที่จำลองแบบแล้วซึ่งใช้ในคลัสเตอร์ลองสร้าง Internal Load Balancer (ILB) แล้วแก้ไขทรัพยากร IP ของคลัสเตอร์ SQL Server Cluster เพื่อทำงานกับ ILB หากคุณต้องการข้ามกระบวนการนั้นและเริ่มต้นการกำหนดค่าของคุณคุณสามารถใช้เทมเพลตการปรับใช้ Azure ที่สร้าง FCI เซิร์ฟเวอร์ SQL แบบ 2 โหนดโดยใช้ SIOS DataKeeper สมมติว่าตอนนี้คุณมีโหนดพื้นฐาน SQL Server FCI สองขั้นตอนแล้ว อินสแตนซ์มีดังนี้:

  1. สร้าง DataKeeper Volume Resource อื่นในโวลุ่มอื่นที่ไม่ได้ใช้งานอยู่ในปัจจุบัน คุณอาจต้องเพิ่มดิสก์เพิ่มเติมในอินสแตนซ์ Azure ของคุณหากคุณไม่มีโวลุ่มที่พร้อมใช้งาน เป็นส่วนหนึ่งของกระบวนการสร้างโวลุ่มนี้ทรัพยากร DataKeeper Volume ใหม่จะถูกลงทะเบียนใน Available Storage ในคลัสเตอร์ อ้างถึงบทความที่อ้างถึงก่อนหน้านี้สำหรับรายละเอียด
  2. ติดตั้งอินสแตนซ์ที่มีชื่อของ SQL Server บนโหนดแรกโดยระบุ DataKeeper Volume ที่เราเพิ่งสร้างเป็นที่เก็บข้อมูล
  3. “ เพิ่มโหนด” ในคลัสเตอร์บนโหนดที่สอง
  4. ล็อคหมายเลขพอร์ตของอินสแตนซ์ที่มีชื่อใหม่นี้ลงในพอร์ตที่ไม่ได้ใช้งาน ในตัวอย่างของฉันฉันใช้พอร์ต 1440

ปรับ ILB เป็นอินสแตนซ์ที่สอง

ต่อไปเราต้องปรับ ILB เพื่อเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังอินสแตนซ์ที่สองนี้ นี่คือขั้นตอนที่คุณต้องทำตาม: เพิ่มที่อยู่ IP ส่วนหน้าซึ่งเหมือนกับที่อยู่ IP ของคลัสเตอร์ SQL ที่คุณใช้สำหรับอินสแตนซ์ที่สองของ SQL Server ดังที่แสดงด้านล่าง คลัสเตอร์ล้มเหลวเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์ที่มีคุณสมบัติ Azure ILB ใหม่ ต่อไปเราจะต้องเพิ่มโพรบอื่นเนื่องจากอินสแตนซ์อาจทำงานบนเซิร์ฟเวอร์อื่น ดังที่แสดงด้านล่างฉันเพิ่มโพรบที่โพรบพอร์ต 59998 (แทนที่จะเป็น 59999 ปกติ) เราจะต้องตรวจสอบให้แน่ใจว่ากฎใหม่อ้างอิงการสอบสวนนี้ เราจะต้องจำหมายเลขพอร์ตนั้นเนื่องจากเราจะต้องอัปเดตที่อยู่ IP ที่เชื่อมโยงกับอินสแตนซ์นี้ในระหว่างขั้นตอนสุดท้ายของกระบวนการนี้ คลัสเตอร์ล้มเหลวเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์ที่มีคุณสมบัติ Azure ILB ใหม่ ตอนนี้เราจำเป็นต้องเพิ่มกฎใหม่สองข้อใน ILB เพื่อให้ปริมาณข้อมูลตรงที่กำหนดไว้สำหรับ SQL ลำดับที่ 2 นี้ แน่นอนว่าเราต้องเพิ่มกฎเพื่อเปลี่ยนเส้นทางพอร์ต TCP 1440 (พอร์ตที่ฉันใช้สำหรับอินสแตนซ์ที่มีชื่อของ SQL) แต่เนื่องจากตอนนี้เราใช้อินสแตนซ์ที่ตั้งชื่อแล้วเราจะต้องมีพอร์ตเพื่อรองรับบริการเบราว์เซอร์เซิร์ฟเวอร์ SQL พอร์ต UDP 1434 ในภาพด้านล่างแสดงกฎสำหรับบริการเซิร์ฟเวอร์เบราว์เซอร์ SQL โปรดทราบว่าที่อยู่ IP ของ Front End อ้างอิงที่อยู่ FrontendIP ใหม่ (10.0.0.201), พอร์ต UDP 1434 สำหรับทั้งพอร์ตและพอร์ตแบ็กเอนด์ ในกลุ่มคุณจะต้องระบุเซิร์ฟเวอร์สองตัวในคลัสเตอร์และในที่สุดให้แน่ใจว่าคุณเลือก Health Probe ใหม่ที่เราเพิ่งสร้างขึ้น คลัสเตอร์ล้มเหลวเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์ที่มีคุณสมบัติ Azure ILB ใหม่ ตอนนี้เราจะเพิ่มกฎสำหรับ TCP / 1440 ดังแสดงในภาพด้านล่างเพิ่มกฎใหม่สำหรับพอร์ต TCP 1440 หรือพอร์ตใด ๆ ที่ถูกล็อคไว้สำหรับอินสแตนซ์ที่มีชื่อของ SQL Server ตรวจสอบให้แน่ใจว่าได้เลือกที่อยู่ IP FrontEnd ใหม่และ Health Probe ใหม่ (59998) ตรวจสอบให้แน่ใจด้วยว่า IP แบบลอยตัว (การส่งคืนเซิร์ฟเวอร์โดยตรง) ถูกเปิดใช้งาน คลัสเตอร์ล้มเหลวเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์ที่มีคุณสมบัติ Azure ILB ใหม่

ขั้นตอนสุดท้าย

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

# กำหนดตัวแปร

$ ClusterNetworkName =“”

# ชื่อเครือข่ายคลัสเตอร์ 
(ใช้ Get-ClusterNetwork บน Windows Server 2012 ขึ้นไปเพื่อค้นหาชื่อ)

$ IPResourceName =“”

# ชื่อทรัพยากรที่อยู่ IP ของอินสแตนซ์ที่สองของ SQL Server

$ ILBIP =“”

# ที่อยู่ IP ของอินสแตนซ์ที่สองของ SQL 
ซึ่งควรจะเหมือนกับที่อยู่ IP ของ Frontend ใหม่เช่นกัน

Import-Module FailoverClusters

# ถ้าคุณใช้ Windows Server 2012 หรือสูงกว่า:

รับ-ClusterResource $ IPResourceName | 
Set-ClusterParameter -Multiple @ {ที่อยู่ = $ ILBIP; ProbePort = 59998;
SubnetMask = "255.255.255.255"; เครือข่าย = $ ClusterNetworkName; EnableDHCP = 0}

# หากคุณใช้ Windows Server 2008 R2 ให้ใช้สิ่งนี้:

#cluster res $ IPResourceName / priv enabledhcp = 0 ที่อยู่ = $ ILBIP probeport = 59998  
SubnetMask = 255.255.255.255

ตอนนี้คุณมี SQLI FC Server หลายอินสแตนซ์ที่ทำงานได้อย่างสมบูรณ์ใน Azure แจ้งให้เราทราบหากคุณมีคำถามใด ๆ ในการสร้างคลัสเตอร์ Failover Cluster Server แบบหลายอินสแตนซ์พร้อมด้วยคุณสมบัติ Azure ILB ที่สร้างขึ้นใหม่จาก Clusteringformeremortals.com

Filed Under: Datakeeper, ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: ILB, เซิร์ฟเวอร์ SQL หลายอินสแตนซ์

คลัสเตอร์ล้มเหลวเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์ที่มีคุณสมบัติ Azure ILB ใหม่

เมษายน 14, 2019 by Jason Aw Leave a Comment

คุณสมบัติ Azure ILB ใหม่ให้คุณสร้างคลัสเตอร์ Failover SQL Server แบบหลายอินสแตนซ์

ที่ Microsoft Ignite เมื่อเดือนกันยายนที่ผ่านมา Microsoft ได้ประกาศเกี่ยวกับ Azure หนึ่งในประกาศเหล่านี้คือความพร้อมใช้งานทั่วไปของวีไอพีหลาย ๆ ตัวเกี่ยวกับตัวโหลดบาลานซ์ภายใน เหตุใดจึงสำคัญกับ SQL Server DBA จนถึงตอนนี้ถ้าคุณต้องการปรับใช้ SQL Server ที่มีความพร้อมใช้งานสูงใน Azure คุณจะถูก จำกัด ให้ใช้ FCI เซิร์ฟเวอร์ SQL เดียวต่อหนึ่งคลัสเตอร์หรือกลุ่มผู้ฟังกลุ่มความพร้อมใช้งานเพียงครั้งเดียว ข้อ จำกัด นี้บังคับให้คุณปรับใช้คลัสเตอร์ใหม่สำหรับแต่ละอินสแตนซ์ของ SQL Server ที่คุณต้องการป้องกันใน Failover Cluster นอกจากนี้ยังบังคับให้คุณจัดกลุ่มฐานข้อมูลทั้งหมดของคุณลงในกลุ่มความพร้อมใช้งานเดียวหากคุณต้องการการเปลี่ยนเส้นทางอัตโนมัติและการเปลี่ยนเส้นทางไคลเอ็นต์ในการกำหนดค่า AlwaysOn AG ของคุณ

วิธีออกจากข้อ จำกัด เหล่านี้

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

เริ่มต้นด้วยคลัสเตอร์ล้มเหลวเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์

สร้างอินสแตนซ์พื้นฐานเดียวของ SQL Server FCI ใน Azure ตามที่อธิบายในโพสต์ของฉันการปรับใช้ Microsoft SQL Server 2014 Failover Clusters ใน Azure Resource Manager โพสต์นั้นอธิบายกระบวนการสร้างคลัสเตอร์ Failover Cluster Server แบบหลายอินสแตนซ์ ใช้ DataKeeper เพื่อสร้างทรัพยากรโวลุ่มที่จำลองแบบแล้วซึ่งใช้ในคลัสเตอร์ลองสร้าง Internal Load Balancer (ILB) แล้วแก้ไขทรัพยากร IP ของคลัสเตอร์ SQL Server Cluster เพื่อทำงานกับ ILB หากคุณต้องการข้ามกระบวนการนั้นและเริ่มต้นการกำหนดค่าของคุณคุณสามารถใช้เทมเพลตการปรับใช้ Azure ที่สร้าง FCI เซิร์ฟเวอร์ SQL แบบ 2 โหนดโดยใช้ SIOS DataKeeper สมมติว่าตอนนี้คุณมีโหนดพื้นฐาน SQL Server FCI สองขั้นตอนแล้ว อินสแตนซ์มีดังนี้:

  1. สร้าง DataKeeper Volume Resource อื่นในโวลุ่มอื่นที่ไม่ได้ใช้งานอยู่ในปัจจุบัน คุณอาจต้องเพิ่มดิสก์เพิ่มเติมในอินสแตนซ์ Azure ของคุณหากคุณไม่มีโวลุ่มที่พร้อมใช้งาน เป็นส่วนหนึ่งของกระบวนการสร้างโวลุ่มนี้ทรัพยากร DataKeeper Volume ใหม่จะถูกลงทะเบียนใน Available Storage ในคลัสเตอร์ อ้างถึงบทความที่อ้างถึงก่อนหน้านี้สำหรับรายละเอียด
  2. ติดตั้งอินสแตนซ์ที่มีชื่อของ SQL Server บนโหนดแรกโดยระบุ DataKeeper Volume ที่เราเพิ่งสร้างเป็นที่เก็บข้อมูล
  3. “ เพิ่มโหนด” ในคลัสเตอร์บนโหนดที่สอง
  4. ล็อคหมายเลขพอร์ตของอินสแตนซ์ที่มีชื่อใหม่นี้ลงในพอร์ตที่ไม่ได้ใช้งาน ในตัวอย่างของฉันฉันใช้พอร์ต 1440

ปรับ ILB เป็นอินสแตนซ์ที่สอง

ต่อไปเราต้องปรับ ILB เพื่อเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังอินสแตนซ์ที่สองนี้ นี่คือขั้นตอนที่คุณต้องทำตาม: เพิ่มที่อยู่ IP ส่วนหน้าซึ่งเหมือนกับที่อยู่ IP ของคลัสเตอร์ SQL ที่คุณใช้สำหรับอินสแตนซ์ที่สองของ SQL Server ดังที่แสดงด้านล่าง คลัสเตอร์ล้มเหลวเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์ที่มีคุณสมบัติ Azure ILB ใหม่ ต่อไปเราจะต้องเพิ่มโพรบอื่นเนื่องจากอินสแตนซ์อาจทำงานบนเซิร์ฟเวอร์อื่น ดังที่แสดงด้านล่างฉันเพิ่มโพรบที่โพรบพอร์ต 59998 (แทนที่จะเป็น 59999 ปกติ) เราจะต้องตรวจสอบให้แน่ใจว่ากฎใหม่อ้างอิงการสอบสวนนี้ เราจะต้องจำหมายเลขพอร์ตนั้นเนื่องจากเราจะต้องอัปเดตที่อยู่ IP ที่เชื่อมโยงกับอินสแตนซ์นี้ในระหว่างขั้นตอนสุดท้ายของกระบวนการนี้ คลัสเตอร์ล้มเหลวเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์ที่มีคุณสมบัติ Azure ILB ใหม่ ตอนนี้เราจำเป็นต้องเพิ่มกฎใหม่สองข้อใน ILB เพื่อให้ปริมาณข้อมูลตรงที่กำหนดไว้สำหรับ SQL ลำดับที่ 2 นี้ แน่นอนว่าเราต้องเพิ่มกฎเพื่อเปลี่ยนเส้นทางพอร์ต TCP 1440 (พอร์ตที่ฉันใช้สำหรับอินสแตนซ์ที่มีชื่อของ SQL) แต่เนื่องจากตอนนี้เราใช้อินสแตนซ์ที่ตั้งชื่อแล้วเราจะต้องมีพอร์ตเพื่อรองรับบริการเบราว์เซอร์เซิร์ฟเวอร์ SQL พอร์ต UDP 1434 ในภาพด้านล่างแสดงกฎสำหรับบริการเซิร์ฟเวอร์เบราว์เซอร์ SQL โปรดทราบว่าที่อยู่ IP ของ Front End อ้างอิงที่อยู่ FrontendIP ใหม่ (10.0.0.201), พอร์ต UDP 1434 สำหรับทั้งพอร์ตและพอร์ตแบ็กเอนด์ ในกลุ่มคุณจะต้องระบุเซิร์ฟเวอร์สองตัวในคลัสเตอร์และในที่สุดให้แน่ใจว่าคุณเลือก Health Probe ใหม่ที่เราเพิ่งสร้างขึ้น คลัสเตอร์ล้มเหลวเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์ที่มีคุณสมบัติ Azure ILB ใหม่ ตอนนี้เราจะเพิ่มกฎสำหรับ TCP / 1440 ดังแสดงในภาพด้านล่างเพิ่มกฎใหม่สำหรับพอร์ต TCP 1440 หรือพอร์ตใด ๆ ที่ถูกล็อคไว้สำหรับอินสแตนซ์ที่มีชื่อของ SQL Server ตรวจสอบให้แน่ใจว่าได้เลือกที่อยู่ IP FrontEnd ใหม่และ Health Probe ใหม่ (59998) ตรวจสอบให้แน่ใจด้วยว่า IP แบบลอยตัว (การส่งคืนเซิร์ฟเวอร์โดยตรง) ถูกเปิดใช้งาน คลัสเตอร์ล้มเหลวเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์ที่มีคุณสมบัติ Azure ILB ใหม่

ขั้นตอนสุดท้าย

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

# กำหนดตัวแปร

$ ClusterNetworkName =“”

# ชื่อเครือข่ายคลัสเตอร์ 
(ใช้ Get-ClusterNetwork บน Windows Server 2012 ขึ้นไปเพื่อค้นหาชื่อ)

$ IPResourceName =“”

# ชื่อทรัพยากรที่อยู่ IP ของอินสแตนซ์ที่สองของ SQL Server

$ ILBIP =“”

# ที่อยู่ IP ของอินสแตนซ์ที่สองของ SQL 
ซึ่งควรจะเหมือนกับที่อยู่ IP ของ Frontend ใหม่เช่นกัน

Import-Module FailoverClusters

# ถ้าคุณใช้ Windows Server 2012 หรือสูงกว่า:

รับ-ClusterResource $ IPResourceName | 
Set-ClusterParameter -Multiple @ {ที่อยู่ = $ ILBIP; ProbePort = 59998;
SubnetMask = "255.255.255.255"; เครือข่าย = $ ClusterNetworkName; EnableDHCP = 0}

# หากคุณใช้ Windows Server 2008 R2 ให้ใช้สิ่งนี้:

#cluster res $ IPResourceName / priv enabledhcp = 0 ที่อยู่ = $ ILBIP probeport = 59998  
SubnetMask = 255.255.255.255

ตอนนี้คุณมี SQLI FC Server หลายอินสแตนซ์ที่ทำงานได้อย่างสมบูรณ์ใน Azure แจ้งให้เราทราบหากคุณมีคำถามใด ๆ ในการสร้างคลัสเตอร์ Failover Cluster Server แบบหลายอินสแตนซ์พร้อมด้วยคุณสมบัติ Azure ILB ที่สร้างขึ้นใหม่จาก Clusteringformeremortals.com

Filed Under: Datakeeper, ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: ILB, เซิร์ฟเวอร์ SQL หลายอินสแตนซ์

Cloud Witness สร้าง SQL Server Failover Cluster ใน SQL Server แบบหลายกรณี

กันยายน 10, 2018 by Jason Aw Leave a Comment

คุณสมบัติ Azure ILB ใหม่ช่วยให้คุณสามารถสร้างคลัสเตอร์ล้มเหลว SQL Server แบบหลายกรณีใน Azure

คุณสมบัติ Azure ILB ใหม่ช่วยให้คุณสามารถสร้างคลัสเตอร์ล้มเหลว SQL Server แบบหลายกรณีใน Azure

คุณลักษณะใหม่ Cloud Witness เป็นที่ชื่นชอบในขณะนี้ ก่อนที่เราจะดูที่คุณลักษณะใหม่ขององค์ประชุมใน Windows Server 2016 ฉันคิดว่าสิ่งสำคัญคือต้องรู้ว่าเรามาจากที่ใด ในบทความก่อนหน้าของฉันการทำความเข้าใจเกี่ยวกับองค์รวมของเซิร์ฟเวอร์ Windows Server 2003 ในคลัสเตอร์ Windows Server 2012 ฉันเข้าสู่รายละเอียดบางอย่างเกี่ยวกับประวัติและวิวัฒนาการของ quorum ของคลัสเตอร์ ขอแนะนำให้คุณตรวจสอบว่าโพสต์เข้าใจว่าโควรัมทำงานได้อย่างไรใน Windows Server 2012 R2 นอกจากนี้คุณลักษณะใหม่ ๆ ของ Windows Server 2016 จะทำให้การปรับใช้คลัสเตอร์ของคุณมีความยืดหยุ่นมากขึ้นได้อย่างไร

พยานเมฆ

พยาน Cloud ช่วยให้คุณสามารถใช้ Azure Blob Storage เพื่อทำหน้าที่เป็นพยานให้กับกลุ่มของคุณได้ พยานคนนี้จะอยู่ในสถานที่ของพยานดิสก์หรือแบ่งปันไฟล์พยาน การกำหนดค่าของ Cloud Witness ทำได้ง่ายมาก จากประสบการณ์ของฉันค่าใช้จ่ายถัดไปไม่มีอะไรที่จะเป็นเจ้าภาพใน Azure ข้อเสียเพียงอย่างเดียวคือโหนดคลัสเตอร์จะต้องสามารถสื่อสารผ่านอินเทอร์เน็ตได้ด้วย Azure Blob Storage ของคุณ บ่อยครั้งที่โหนดคลัสเตอร์ห้ามไม่ให้สื่อสารกับอินเทอร์เน็ตสาธารณะ ดังนั้นคุณจะต้องประสานงานกับทีมรักษาความปลอดภัยของคุณหากคุณต้องการเปิดใช้งาน Cloud Witness มีเหตุผลที่น่าสนใจมากมายสำหรับการใช้ Cloud Witness เพื่อสร้างคลัสเตอร์ล้มเหลวของ SQL Server แบบหลายอินสแตนซ์ใน Azure แต่สำหรับฉันมันทำให้รู้สึกมากที่สุดในสามสภาพแวดล้อมที่เฉพาะเจาะจงมาก: Failover Cluster ใน Azure, Branch Office Clusters และ Multisite Clusters

เมื่อมองใกล้

ลองดูที่แต่ละสถานการณ์เพื่อดูว่า Cloud Witness สามารถช่วยได้อย่างไร รูปที่ 1 – เมื่อคุณกำลังพยายามสร้าง SQL Serveคุณลักษณะ ILB ใหม่สำหรับคลัสเตอร์ Failover SQL Server แบบหลายอินสแตนซ์ใน Azurer Failover Cluster แบบหลายอินสแตนซ์ใน Azure บัญชีเก็บข้อมูลระบบคลาวด์ควรได้รับการกำหนดค่าที่เก็บข้อมูลแบบ redundant Storage ตามปกติ (LRS) [/ คำอธิบาย]

การใช้งานที่มีการใช้งานสูง

หากคุณกำลังย้ายไปที่ Azure (หรือผู้ให้บริการระบบคลาวด์จริงๆ) คุณจะต้องการให้แน่ใจว่าการปรับใช้ของคุณมีให้ใช้งานได้มาก หากคุณกำลังดำเนินการเกี่ยวกับ SQL Server, File Servers, SAP หรือภาระงานอื่น ๆ ที่รวมกลุ่มกันแบบคลัสเตอร์กับ Windows Server Failover Clustering คุณจะต้องใช้พยานแชร์ไฟล์หรือ Cloud Witness เนื่องจากไม่สามารถใช้ Disk Witness ใน Azure ได้ ด้วย Windows Server 2012 R2 หรือ Windows Server 2008 R2 คุณจะต้องใช้ Share Share Share กับ Witness Windows Server 2016 ทำให้สามารถใช้ Cloud Witness ได้ ข้อได้เปรียบของ Cloud Witness คือคุณไม่จำเป็นต้องรักษาอินสแตนซ์อื่นของ Windows ใน Azure เพื่อโฮสต์ไฟล์แชร์ แต่ Microsoft ช่วยให้คุณสามารถใช้ประโยชน์จากพื้นที่เก็บข้อมูลแบบหยดได้  วิธีนี้จะช่วยให้คุณได้รับโซลูชันที่มีราคาไม่แพงซึ่งเป็นวิธีที่ง่ายในการจัดการและยืดหยุ่นมากขึ้น

ที่ตั้ง

เมื่อมองไปที่การปรับใช้คลัสเตอร์ในสำนักงานสาขาค่าใช้จ่ายและการบำรุงรักษาอยู่เสมอพิจารณา สำหรับห่วงโซ่การค้าปลีกที่มีสถานที่นับร้อยหรือหลายพันแห่งการมี SAN ในแต่ละตำแหน่งอาจเป็นสิ่งที่ต้องห้ามปราม แต่ละตำแหน่งอาจเรียกใช้โหนดคลัสเตอร์ Hyper-V สองโหนดในคอนฟิกูเรชันที่ผสานรวม Hyper-S2D หรือโซลูชันการจำลองแบบของ บริษัท อื่นเพื่อโฮสต์เครื่องเสมือนหลายเครื่อง ตอนนี้สิ่งที่ Cloud Witness สามารถทำได้คือช่วยให้ธุรกิจหลีกเลี่ยงค่าใช้จ่ายในการเพิ่มเซิร์ฟเวอร์ทางกายภาพเพิ่มเติมในแต่ละตำแหน่งเพื่อทำหน้าที่เป็น Share Share Share หรือเพิ่มต้นทุนในการเพิ่ม SAN ไปยังสถานที่แต่ละแห่ง

ขจัดความต้องการศูนย์ข้อมูลที่ 3

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

การรับรู้ไซต์

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

โดเมนข้อบกพร่อง

การสร้างความตระหนักในไซต์เป็นโดเมนฟอรัม โดเมนข้อบกพร่องจะไปอีกขั้นและช่วยให้คุณสามารถกำหนดตำแหน่งโหนด Chasse และ Rack นอกเหนือจากไซต์ได้ โดเมนข้อบกพร่องมีประโยชน์สามประการคือความเกี่ยวข้องกับการจัดเก็บในกลุ่มแบบยืดอายุการเก็บข้อมูลที่เพิ่มขึ้นทำให้พื้นที่เก็บข้อมูลมีความยืดหยุ่นเพิ่มขึ้น ช่วยเพิ่มการแจ้งเตือนเกี่ยวกับบริการสุขภาพโดยการรวมข้อมูลเมตาเกี่ยวกับตำแหน่งของแหล่งข้อมูลที่เกี่ยวข้องซึ่งเป็นการปลุก ความเกี่ยวข้องในการจัดเก็บจะช่วยให้แน่ใจได้ว่ากลุ่มงานและพื้นที่เก็บข้อมูลของคุณทำงานอยู่ในตำแหน่งเดียวกัน คุณไม่ต้องการให้ VM อ่านและเขียนข้อมูลที่อยู่ใน CSV ในเมืองอื่น อย่างไรก็ตามผมคิดว่าผู้ชนะที่ใหญ่ที่สุดในที่นี้คือ Space Space Storage (S2D) SD2 จะใช้ประโยชน์จากข้อมูลที่คุณระบุเกี่ยวกับตำแหน่งของคลัสเตอร์โหนด (ไซต์แร็คแชสซี) เพื่อให้แน่ใจว่าสำเนาข้อมูลที่เขียนขึ้นเพื่อความซ้ำซ้อนทั้งหมดจะอยู่ในโดเมนฟอรัมที่แตกต่างกัน ช่วยให้แน่ใจได้ว่าการจัดวางข้อมูลได้รับการปรับให้เหมาะสมเพื่อให้ความล้มเหลวของ Single Node, Chassis, Rack หรือ Site ไม่สามารถลดการใช้งาน S2D ทั้งหมดได้  คอสมอสดาร์วินมีวิดีโอยอดเยี่ยมในช่อง 9 ซึ่งอธิบายถึงแนวคิดนี้อย่างละเอียด

สรุป

Windows Server 2016 เพิ่มการปรับปรุงใหม่ ๆ ให้กับองค์รวมของคลัสเตอร์ซึ่งจะให้ประโยชน์ในทันทีกับการปรับใช้คลัสเตอร์ของคุณ นอกจากนี้โปรดตรวจสอบการปรับปรุงคลัสเตอร์ใหม่ ๆ ที่น่าสนใจอื่น ๆ เช่นการปรับรุ่นระบบกลิ้ง, ความยืดหยุ่นของเครื่องเสมือน, Workgroup และกลุ่มโดเมนหลายแห่งและอื่น ๆ หากต้องการอ่านเกี่ยวกับเคล็ดลับอื่น ๆ เช่นการสร้าง SQL Server Failover Cluster In-One แบบหลายอินสแตนซ์ใน Azure กับ Cloud Witness โปรดอ่านบทความของเรา ทำซ้ำโดยได้รับอนุญาตจาก Clusteringformeremortals.com

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: Load Balance, PowerShell, Windows Server 2012, การทำซ้ำ, การปรับใช้, ตัวจัดการการกำหนดค่าระบบศูนย์, ผู้จัดการทรัพยากร Azure, พยานเมฆ, เซิร์ฟเวอร์ SQL หลายอินสแตนซ์

โพสต์ล่าสุด

  • กลยุทธ์การอัพเกรดแบบโรลลิ่งที่ดีที่สุดเพื่อปรับปรุงความต่อเนื่องทางธุรกิจ
  • วิธีการแก้ไขโดยไม่ต้องหยุดชะงัก: เวลาหยุดทำงานที่แทบจะเป็นศูนย์ด้วย HA
  • การสาธิต SIOS LifeKeeper: การอัปเดตแบบต่อเนื่องและการสำรองข้อมูลช่วยปกป้อง PostgreSQL ใน AWS ได้อย่างไร
  • วิธีการประเมินว่าการ์ดเครือข่ายของฉันจำเป็นต้องเปลี่ยนหรือไม่
  • SIOS Technology จะสาธิตซอฟต์แวร์คลัสเตอร์ความพร้อมใช้งานสูงสำหรับแอปพลิเคชันที่สำคัญต่อภารกิจในงาน Red Hat Summit, Milestone Technology Day และ XPerience Day และ SQLBits 2025

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

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

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