ทีละขั้นตอน: วิธีการกำหนดค่าอินสแตนซ์ของคลัสเตอร์ล้มเหลว SQL Server 2008 R2 บน Windows Server 2008 R2 ใน Azure

Intro

ในวันที่ 9 กรกฎาคม 2019 การสนับสนุนสำหรับ SQL Server 2008 และ 2008 R2 จะสิ้นสุดลง นั่นหมายถึงการสิ้นสุดการอัพเดตความปลอดภัยปกติ อย่างไรก็ตามหากคุณย้ายอินสแตนซ์ SQL Server เหล่านั้นไปยัง Azure Microsoft จะให้การปรับปรุงความปลอดภัยเสริมสามปีโดยไม่มีค่าใช้จ่ายเพิ่มเติม หากคุณกำลังเรียกใช้ SQL Server 2008/2008 R2 อยู่และคุณไม่สามารถอัปเดตเป็น SQL Server รุ่นใหม่กว่าก่อนวันที่ 9 กรกฎาคมคุณจะต้องใช้ประโยชน์จากข้อเสนอนี้แทนที่จะเสี่ยงกับความเสี่ยงที่จะเกิดช่องโหว่ด้านความปลอดภัยในอนาคต . อินสแตนซ์ที่ไม่ตรงกันของ SQL Server อาจนำไปสู่การสูญเสียข้อมูลการหยุดทำงานหรือการทำลายข้อมูลที่ร้ายแรง

หนึ่งในความท้าทายที่คุณจะเผชิญเมื่อใช้งาน SQL Server 2008/2008 R2 ใน Azure คือสร้างความมั่นใจว่ามีความพร้อมใช้งานสูง ในสถานที่คุณอาจใช้งานอินสแตนซ์ SQL Server Failover Cluster (FCI) เพื่อความพร้อมใช้งานสูงหรืออาจเป็นไปได้ว่าคุณกำลังเรียกใช้ SQL Server ในเครื่องเสมือนและอาศัย VMware HA หรือคลัสเตอร์ Hyper-V เพื่อความพร้อมใช้งาน เมื่อย้ายไปยัง Azure จะไม่มีตัวเลือกใด ๆ การหยุดทำงานใน Azure เป็นไปได้จริงมากที่คุณต้องทำตามขั้นตอนเพื่อลด

เพื่อลดความเป็นไปได้ของการหยุดทำงานและมีสิทธิ์ได้รับ SLA ของ Azure 99.95% หรือ 99.99% คุณต้องใช้ SIOS DataKeeper DataKeeper เอาชนะการขาดพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของ Azure และช่วยให้คุณสามารถสร้าง SQL Server FCI ใน Azure ที่ใช้ประโยชน์พื้นที่เก็บข้อมูลที่เชื่อมต่อแบบโลคัลในแต่ละอินสแตนซ์ SIOS DataKeeper ไม่เพียง แต่รองรับ SQL Server 2008 R2 และ Windows Server 2008 R2 ตามที่ระบุไว้ในคู่มือนี้เท่านั้น แต่รองรับ Windows Server ทุกรุ่นตั้งแต่ 2008 R2 ถึง Windows Server 2019 และ SQL Server ทุกรุ่นตั้งแต่ SQL Server 2008 ถึง SQL Server 2019 .

คู่มือนี้จะอธิบายถึงกระบวนการสร้าง SQL Server 2008 R2 Failover Cluster Instance (FCI) แบบสองโหนดใน Azure ที่ทำงานบน Windows Server 2008 R2 แม้ว่า SIOS DataKeeper ยังสนับสนุนกลุ่มที่ขยายโซนความพร้อมใช้งานหรือภูมิภาคคู่มือนี้จะถือว่าแต่ละโหนดอยู่ในภูมิภาค Azure เดียวกัน แต่เป็นโดเมนความผิดพลาดที่แตกต่างกัน SIOS DataKeeper จะถูกใช้แทนที่ที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งปกติแล้วจะต้องใช้เพื่อสร้าง SQL Server 2008 R2 FCI

สร้างอินสแตนซ์ของเซิร์ฟเวอร์ SQL แรกใน Azure

คู่มือนี้จะใช้ประโยชน์จาก SQL Server 2008R2SP3 ในอิมเมจ Windows Server 2008R2 ที่เผยแพร่ใน Azure Marketplace

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

เพิ่มดิสก์เพิ่มเติมให้กับแต่ละอินสแตนซ์ แนะนำให้ใช้ Premium หรือ Ultra SSD ปิดใช้งานการแคชบนดิสก์ที่ใช้สำหรับไฟล์บันทึก SQL เปิดใช้งานการแคชแบบอ่านอย่างเดียวบนดิสก์ที่ใช้สำหรับไฟล์ข้อมูล SQL อ้างอิงถึงแนวทางการปฏิบัติงานสำหรับ SQL Server ใน Azure Virtual Machines สำหรับข้อมูลเพิ่มเติมเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดในการจัดเก็บ

หากคุณยังไม่ได้กำหนดค่าเครือข่ายเสมือนให้อนุญาตวิซาร์ดการสร้างเพื่อสร้างใหม่สำหรับคุณ

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

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

สร้างอินสแตนซ์ของเซิร์ฟเวอร์ SQL ปลายทางใน Azure

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

สร้างอินสแตนซ์แชร์ไฟล์พยาน (FSW)

เพื่อให้ Windows Server Failover Cluster (WSFC) ทำงานได้อย่างมีประสิทธิภาพคุณจำเป็นต้องสร้างอินสแตนซ์ของ Windows Server อื่นและวางไว้ในชุดความพร้อมใช้งานเดียวกันกับอินสแตนซ์ของ SQL Server ด้วยการวางไว้ในชุดความพร้อมใช้งานเดียวกันคุณมั่นใจได้ว่าแต่ละโหนดคลัสเตอร์และ FSW อยู่ในโดเมนความผิดพลาดที่แตกต่างกัน ด้วยเหตุนี้จึงมั่นใจได้ว่าคลัสเตอร์ของคุณยังคงออนไลน์หากโดเมนความผิดทั้งหมดหายไป อินสแตนซ์นี้ไม่ต้องการ SQL Server มันสามารถเป็น Windows Server แบบง่าย ๆ เพียงแค่มีการแชร์ไฟล์อย่างง่าย

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

ถอนการติดตั้ง SQL Server 2008 R2

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

เมื่อคุณเรียกใช้ setup.exe / Action-RunDiscovery คุณจะเห็นทุกอย่างที่ติดตั้งไว้ล่วงหน้า 

setup.exe / Action-RunDiscovery

การใช้งาน setup.exe / Action = ถอนการติดตั้ง / คุณสมบัติ = SQL, AS, RS, IS, เครื่องมือ / INSTANCENAME = MSSQLSERVER เริ่มต้นกระบวนการถอนการติดตั้ง

setup.exe / Action = ถอนการติดตั้ง / คุณสมบัติ = SQL, AS, RS, IS, เครื่องมือ / INSTANCENAME = MSSQLSERVER

การรัน setup.exe / Action-RunDiscovery ยืนยันว่าการถอนการติดตั้งเสร็จสิ้น

setup.exe / Action-RunDiscovery

เรียกใช้กระบวนการถอนการติดตั้งนี้อีกครั้งในอินสแตนซ์ที่ 2

เพิ่มอินสแตนซ์ให้กับโดเมน

อินสแตนซ์ทั้งสามเหล่านี้จะต้องถูกเพิ่มลงในโดเมน Windows

เพิ่มคุณสมบัติการทำคลัสเตอร์ Windows Failover

ต้องเพิ่มคุณสมบัติการทำคลัสเตอร์เข้าแทนที่ในอินสแตนซ์ของ SQL Server สองอิน

Add-WindowsFeature Failover-Clustering

ปิดไฟร์วอลล์ Windows

เพื่อความง่ายให้ปิดไฟร์วอลล์ Windows ในระหว่างการติดตั้งและกำหนดค่าของ SQL Server FCI ศึกษาแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยของเครือข่าย Azure สำหรับคำแนะนำเกี่ยวกับการรักษาความปลอดภัยทรัพยากร Azure ของคุณ รายละเอียดเกี่ยวกับพอร์ต Windows ที่ต้องการสามารถพบได้ที่นี่พอร์ต SQL Server ที่นี่และพอร์ต SIOS DataKeeper ที่นี่ The Internal Load Balancer ที่เราจะกำหนดค่าในภายหลังและต้องมีการเข้าถึงพอร์ต 59999 ดังนั้นโปรดตรวจสอบให้แน่ใจว่าบัญชีของคุณมีการกำหนดค่าความปลอดภัย

NetSh Advfirewall ตั้งค่าสถานะ allprofiles

ติดตั้งการปรับปรุงการยกเลิกการอำนวยความสะดวกสำหรับ Windows Server 2008 R2 SP1

มีการปรับปรุงที่สำคัญ (kb2854082) ที่จำเป็นเพื่อกำหนดค่าอินสแตนซ์ของ Windows Server 2008 R2 ใน Azure การอัปเดตและอื่น ๆ อีกมากมายนั้นรวมอยู่ในการปรับปรุงการยกเลิกการอำนวยความสะดวกสำหรับ Windows Server 2008 R2 SP1 ติดตั้งโปรแกรมปรับปรุงนี้บนแต่ละอินสแตนซ์ของ SQL Server สองอิน

จัดรูปแบบการจัดเก็บ

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

แนวทางปฏิบัติที่ดีที่สุดของ Microsoft กล่าวต่อไปนี้ …

“ ขนาดหน่วยการจัดสรร NTFS: เมื่อทำการฟอร์แมตดิสก์ข้อมูลขอแนะนำให้คุณใช้ขนาดหน่วยการจัดสรร 64-KB สำหรับข้อมูลและไฟล์บันทึกเช่นเดียวกับ TempDB”

เรียกใช้การตรวจสอบคลัสเตอร์

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

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

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

แนวทางปฏิบัติที่ดีที่สุดสำหรับการสร้างคลัสเตอร์ใน Azure คือการใช้ Powershell ดังที่แสดงด้านล่าง Powershell ช่วยให้เราสามารถระบุที่อยู่ IP แบบคงที่ในขณะที่วิธีการ GUI ไม่ได้ น่าเสียดายที่การใช้ DHCP ของ Azure ทำงานได้ไม่ดีกับ Windows Server Failover Clustering หากคุณใช้วิธี GUI คุณจะปิดท้ายด้วยที่อยู่ IP ที่ซ้ำกันเป็นที่อยู่ IP ของคลัสเตอร์ มันไม่ใช่จุดจบของโลก แต่คุณจะต้องแก้ไขปัญหาดังที่ฉันแสดง

ดังที่ฉันได้กล่าวไว้แล้ววิธี Powershell นั้นใช้งานได้ดีที่สุด อย่างไรก็ตามด้วยเหตุผลบางอย่างดูเหมือนว่าจะล้มเหลวใน Windows Server 2008 R2 ดังที่แสดงด้านล่าง

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

คุณสามารถลองใช้วิธีการนี้และถ้ามันเหมาะกับคุณ – เยี่ยมมาก! ฉันต้องย้อนกลับไปและตรวจสอบเรื่องนี้อีกเล็กน้อยเพื่อดูว่ามันเป็นความบังเอิญหรือไม่ ตัวเลือกอื่นที่ฉันต้องสำรวจหาก Powershell ไม่ทำงานคือ Cluster.exe กำลังรันคลัสเตอร์ / สร้าง /? ให้ไวยากรณ์ที่เหมาะสมที่จะใช้สำหรับการสร้างกลุ่มด้วยคำสั่งเลิกใช้ cluster.exe

อย่างไรก็ตามหาก Powershell หรือ Cluster.exe ล้มเหลวคุณขั้นตอนด้านล่างแสดงวิธีการสร้างคลัสเตอร์ผ่านทาง Windows Server Failover Clustering UI รวมถึงการแก้ไขที่อยู่ IP ที่ซ้ำกันซึ่งจะถูกกำหนดให้กับคลัสเตอร์

จำไว้ว่าชื่อที่คุณระบุในที่นี้เป็นเพียงชื่อวัตถุคลัสเตอร์ (CNO) นี่ไม่ใช่ชื่อที่ไคลเอ็นต์ SQL ของคุณจะใช้เพื่อเชื่อมต่อกับคลัสเตอร์ เราจะกำหนดว่าในระหว่างการตั้งค่าคลัสเตอร์ SQL Server ในขั้นตอนภายหลัง 

ณ จุดนี้คลัสเตอร์ถูกสร้างขึ้น แต่คุณอาจไม่สามารถเชื่อมต่อกับคลัสเตอร์ได้ด้วย Windows Server Failover Clustering UI เนื่องจากปัญหาที่อยู่ IP ที่ซ้ำกัน

แก้ไขที่อยู่ IP ที่ซ้ำกัน

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

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

เน็ตเริ่ม clussvc / fq

ในโหนดเดียวกันนั้นตอนนี้คุณควรจะสามารถเชื่อมต่อกับ Windows Server Failover Clustering UI ที่ซึ่งคุณจะเห็นที่อยู่ IP ล้มเหลวในการออนไลน์

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

นำทรัพยากรชื่อออนไลน์

เพิ่มการแชร์ไฟล์พยาน

ต่อไปเราต้องเพิ่ม File Share Witness บนเซิร์ฟเวอร์ตัวที่ 3 ที่เราจัดเตรียมไว้เป็น FSW ให้สร้างโฟลเดอร์และแชร์มันดังที่แสดงด้านล่าง คุณจะต้องให้สิทธิ์การอ่าน / เขียน Cluster Name Object (CNO) ทั้งระดับการแบ่งปันและความปลอดภัยดังที่แสดงด้านล่าง

เมื่อสร้างการแชร์แล้วให้รันวิซาร์ด Configure Cluster Quorum บนหนึ่งในโหนดคลัสเตอร์และทำตามขั้นตอนที่แสดงด้านล่าง

สร้างบัญชีบริการสำหรับ DataKeeper

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

ติดตั้ง DataKeeper

ติดตั้ง DataKeeper บนโหนดคลัสเตอร์ SQL Server สองโหนดดังที่แสดงด้านล่าง

นี่คือที่เราจะระบุบัญชีโดเมนที่เราเพิ่มลงในกลุ่มผู้ดูแลโดเมนท้องถิ่นแต่ละกลุ่ม

กำหนดค่า DataKeeper

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

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

ก่อนอื่นคุณต้องเชื่อมต่อกับแต่ละโหนดทั้งสอง

หากการกำหนดค่าทุกอย่างถูกต้องคุณควรดูสิ่งต่อไปนี้ในรายงานภาพรวมเซิร์ฟเวอร์

จากนั้นสร้างงานใหม่และทำตามขั้นตอนด้านล่าง

เลือกใช่ที่นี่เพื่อลงทะเบียนทรัพยากร DataKeeper Volume ใน Available Storage

ทำตามขั้นตอนด้านบนสำหรับแต่ละไดรฟ์ เมื่อเสร็จแล้วคุณควรเห็นสิ่งต่อไปนี้ใน Windows Server Failover Clustering UI

ตอนนี้คุณพร้อมที่จะติดตั้ง SQL Server ในคลัสเตอร์

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

ติดตั้ง SQL Server บนโหนดแรก

บนโหนดแรกเรียกใช้การตั้งค่าเซิร์ฟเวอร์ SQL

เลือกการติดตั้งคลัสเตอร์เซิร์ฟเวอร์ล้มเหลว SQL ใหม่และทำตามขั้นตอนตามที่แสดงในรูป

เลือกตัวเลือกที่คุณต้องการเท่านั้น 

โปรดทราบว่าเอกสารนี้ถือว่าคุณใช้อินสแตนซ์เริ่มต้นของ SQL Server ถ้าคุณใช้อินสแตนซ์ที่มีชื่อคุณต้องตรวจสอบให้แน่ใจว่าคุณล็อกพอร์ตที่ฟังอยู่และใช้พอร์ตนั้นในภายหลังเมื่อคุณกำหนดค่าตัวโหลดบาลานซ์ คุณจะต้องสร้างกฎตัวโหลดบาลานซ์สำหรับ SQL Server Browser Service (UDP 1434) เพื่อเชื่อมต่อกับ Named Instance ข้อกำหนดทั้งสองนี้ไม่ได้กล่าวถึงในคู่มือนี้ แต่ถ้าคุณต้องการ Named Instance มันจะทำงานถ้าคุณทำตามสองขั้นตอนเพิ่มเติมนั้น

ที่นี่คุณจะต้องระบุที่อยู่ IP ที่ไม่ได้ใช้

ไปที่แท็บ Data Directories และย้ายข้อมูลและไฟล์บันทึก ในตอนท้ายของคู่มือนี้เราพูดคุยเกี่ยวกับการย้าย tempdb ไปยังไดรฟ์ข้อมูล DataKeeper ที่ไม่ใช่มิร์เรอร์เพื่อประสิทธิภาพที่ดีที่สุด สำหรับตอนนี้ให้เก็บไว้ในดิสก์ที่ทำคลัสเตอร์อย่างใดอย่างหนึ่ง

ติดตั้ง SQL บนโหนดที่สอง

เรียกใช้การตั้งค่าเซิร์ฟเวอร์ SQL อีกครั้งบนโหนดที่สอง จากนั้นเลือกเพิ่มโหนดใน SQL Server Failover Cluster

ยินดีด้วยคุณเกือบจะเสร็จแล้ว! อย่างไรก็ตามเนื่องจาก Azure ขาดการสนับสนุน ARP ที่ไม่มีค่าใช้จ่ายเราจะต้องกำหนดค่า Internal Load Balancer (ILB) เพื่อช่วยในการเปลี่ยนเส้นทางลูกค้าดังที่แสดงในขั้นตอนต่อไป

อัปเดตที่อยู่ IP ของคลัสเตอร์ SQL

เพื่อให้ ILB ทำงานได้อย่างถูกต้องคุณต้องรันคำสั่งต่อไปนี้จากหนึ่งในโหนดคลัสเตอร์ มัน SQL Cluster IP เปิดใช้งานที่อยู่ IP ของ SQL Cluster เพื่อตอบสนองต่อ ILB health probe ในขณะที่ตั้ง subnet mask เป็น 255.255.255.255 เพื่อหลีกเลี่ยง IP address ที่ขัดแย้งกับโพรบ health

res res คลัสเตอร์ <IPResourceName> / priv enabledhcp = 0 address = <ILBIP> probeport = 59999 subnetmask = 255.255.255.255

หมายเหตุ – ฉันไม่รู้ว่าเป็นความบังเอิญหรือไม่ ในบางครั้งฉันเรียกใช้คำสั่งนี้และดูเหมือนว่าจะใช้งานได้ แต่มันไม่ทำงานจนเสร็จและฉันต้องเริ่มใหม่อีกครั้ง วิธีที่ฉันสามารถบอกได้ว่าทำงานได้หรือไม่โดยดูที่ Subnet Mask ของทรัพยากร IP ของเซิร์ฟเวอร์ SQL หากไม่ใช่ 255.255.255.255 แสดงว่าคุณไม่สามารถทำงานได้สำเร็จ  อาจเป็นปัญหาการรีเฟรช GUI ลองรีสตาร์ทคลัสเตอร์ GUI เพื่อตรวจสอบว่ามีการอัปเดตซับเน็ตมาสก์แล้ว

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

สร้างโหลดบาลานเซอร์

ขั้นตอนสุดท้ายคือการสร้าง load balancer ในกรณีนี้เรากำลังสมมติว่าคุณกำลังใช้งานอินสแตนซ์เริ่มต้นของ SQL Server โดยฟังที่พอร์ต 1433

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

เพิ่มอินสแตนซ์ของ SQL Server เพียงสองอินสแตนซ์ให้กับพูลแบ็คเอนด์ ห้ามเพิ่ม FSW ลงในพูลแบ็คเอนด์

ในกฎดุลการโหลดนี้คุณต้องเปิดใช้ IP แบบลอย

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

การทดสอบที่ง่ายที่สุดคือการเปิด Studio จัดการเซิร์ฟเวอร์ SQL บนโหนดแฝงและเชื่อมต่อกับคลัสเตอร์ ขอแสดงความยินดี! คุณทำทุกอย่างถูกต้องในขณะที่มันเชื่อมต่อ! หากคุณไม่สามารถเชื่อมต่อได้โปรดอย่ากลัว ฉันเขียนบทความบล็อกเพื่อช่วยแก้ไขปัญหา การจัดการคลัสเตอร์นั้นเหมือนกับการจัดการคลัสเตอร์การจัดเก็บข้อมูลแบบเดิม ทุกอย่างถูกควบคุมผ่าน Failover Cluster Manager

ไม่บังคับ – ย้าย TempDB

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

หลังจากที่คุณสร้าง Non-Mirrored Volume Resource ของโลคัล SSD ทำตามขั้นตอนในบทความนี้เพื่อย้าย tempdb สคริปต์เริ่มต้นที่อธิบายไว้ในบทความนั้นจะต้องเพิ่มในแต่ละโหนดคลัสเตอร์

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