SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Major Cloud Outage ส่งผลกระทบต่อ Google Compute Engine – คุณเตรียมไว้หรือยัง 

by Leave a Comment

การหยุดทำงานของระบบคลาวด์ที่สำคัญส่งผลกระทบต่อ Google Compute Engine เมื่อคุณเตรียมการ

Major Cloud Outage ส่งผลกระทบต่อ Google Compute Engine – คุณเตรียมไว้หรือยัง

Google รายงาน "ปัญหา" ครั้งแรกเมื่อวันที่ 2 มิถุนายน 2019 เวลา 12:25 PDT ตามที่พบเห็นได้ทั่วไปในภัยพิบัติประเภทใดรายงานของไฟดับนี้ปรากฏขึ้นครั้งแรกบนโซเชียลมีเดีย โซเชียลมีเดียดูเหมือนจะเป็นสถานที่ที่น่าเชื่อถือที่สุดในการรับข้อมูลทุกประเภทตั้งแต่เกิดภัยพิบัติตอนนี้

Twitter กำลังกลายเป็นแหล่งข้อมูลแรกอย่างรวดเร็วในทุกสิ่งตั้งแต่การปฏิวัติภัยพิบัติทางธรรมชาติไปจนถึงการขาดเมฆ [/ caption]

บริการหลายอย่างที่ต้องพึ่งพา Google Compute Engine ได้รับผลกระทบ ฉันมีลูกวัยรุ่นสามคนที่บ้าน มีบางอย่างเกิดขึ้นเมื่อเด็กทั้งสามคนโผล่ออกมาจากถ้ำอาคานอนในเวลาเดียวกันพร้อมกับดูใบหน้าที่เป็นกังวล Snapchat, Youtube และ Discord ล้วน แต่ออฟไลน์! พวกเขาต้องคิดว่านี่เป็นสัญญาณแรกของการเปิดเผย ฉันให้ความมั่นใจกับพวกเขาว่านี่ไม่ใช่จุดเริ่มต้นของยุคมืดใหม่ และพวกเขาควรออกไปข้างนอกเพื่อทำงานที่บ้าน นั่นทำให้พวกเขากลัวกลับสู่ความเป็นจริงและพวกเขาก็รีบออกไปหาสิ่งอื่นเพื่อใช้เวลาของพวกเขา ทั้งหมดล้อเล่นกันมีการบริการจำนวนมากถูกรายงานว่าเป็นลงหรือมีให้เฉพาะในบางพื้นที่ ฝุ่นยังคงตั้งอยู่บนสาเหตุความกว้างและขอบเขตของไฟดับ แต่ดูเหมือนว่าการหยุดทำงานนั้นค่อนข้างสำคัญในด้านขนาดและขอบเขตซึ่งส่งผลกระทบต่อลูกค้าและบริการจำนวนมากรวมถึง Gmail และบริการ G-Suite อื่น ๆ Vimeo และอีกมากมาย

บริการหลายอย่างได้รับผลกระทบจากไฟดับ Gmail, YouTube และ SnapChat เพียงเพื่อตั้งชื่อไม่กี่ [/ caption]

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

คุณเตรียมพร้อมสำหรับการหยุดทำงานของคลาวด์นี้หรือไม่?

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

มีแผนกู้คืนภัยพิบัติทางเสียง

ใช้ประโยชน์จากโครงสร้างพื้นฐานของคลาวด์ลดความเสี่ยงด้วยการจำลองข้อมูลที่สำคัญอย่างต่อเนื่องระหว่างโซนความพร้อมใช้งานภูมิภาคหรือแม้แต่ผู้ให้บริการคลาวด์ นอกเหนือจากการปกป้องข้อมูลแล้วการมีกระบวนการในการกู้คืนแอปพลิเคชันที่สำคัญทางธุรกิจอย่างรวดเร็วเป็นส่วนสำคัญของแผนการกู้คืนความเสียหายใด ๆ มีตัวเลือกการจำลองแบบและการกู้คืนที่หลากหลาย ซึ่งรวมถึงบริการที่จัดทำโดยผู้จำหน่ายคลาวด์เองเช่น Azure Site Recovery สำหรับโซลูชันเฉพาะแอปพลิเคชันเช่น SQL Server Always On Availability Group ไปยังโซลูชันของบุคคลที่สามเช่น SIOS DataKeeper ที่ปกป้องแอปพลิเคชันหลากหลาย การมีกลยุทธ์การกู้คืนความเสียหายที่ขึ้นอยู่กับผู้ให้บริการคลาวด์ทั้งหมดทำให้คุณไวต่อสถานการณ์ที่อาจส่งผลกระทบหลายภูมิภาคภายในคลาวด์เดียว ภัยพิบัติหลายดาต้าเซ็นเตอร์หรือหลายภูมิภาคไม่น่าจะเกิดขึ้น อย่างไรก็ตามอย่างที่เราเห็นเมื่อไม่นานมานี้และการล่มสลายของ Azure เมื่อฤดูใบไม้ร่วงที่ผ่านมาแม้ว่าความล้มเหลวจะเกิดขึ้นภายในดาต้าเซ็นเตอร์เดียวผลกระทบก็สามารถเข้าถึงได้กว้างในศูนย์ข้อมูลหลายแห่งหรือภูมิภาคภายในคลาวด์ ในการลดความเสี่ยงให้พิจารณาสถานการณ์สมมติหลายคลาวด์หรือไฮบริดคลาวด์ซึ่งไซต์การกู้คืนความเสียหายอยู่นอกแพลตฟอร์มคลาวด์หลักของคุณ คลาวด์นั้นไวต่อการหยุดชะงักเช่นเดียวกับดาต้าเซ็นเตอร์ของคุณ คุณต้องทำตามขั้นตอนเพื่อเตรียมการสำหรับภัยพิบัติ ฉันขอแนะนำให้คุณเริ่มต้นด้วยการดูแอพที่สำคัญที่สุดทางธุรกิจของคุณก่อน คุณจะทำอย่างไรถ้าพวกเขาออฟไลน์และพอร์ทัลคลาวด์ในการจัดการพวกเขายังไม่สามารถใช้ได้ คุณสามารถกู้คืนได้หรือไม่ คุณจะบรรลุวัตถุประสงค์ RTO และ RPO ของคุณหรือไม่ มิฉะนั้นอาจถึงเวลาที่ต้องประเมินกลยุทธ์การกู้คืนความเสียหาย

“ การไม่เตรียมตัวคุณกำลังเตรียมตัวล้มเหลว” – เบนจามินแฟรงคลิน

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

by Leave a Comment

ทีละขั้นตอน: วิธีการกำหนดค่าอินสแตนซ์ของคลัสเตอร์ล้มเหลว 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

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

by 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

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

by 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

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

by Leave a Comment

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

หากคุณต้องการคำแนะนำกำหนดค่าอินสแตนซ์ของคลัสเตอร์เซิร์ฟเวอร์ล้มเหลว SQL ใน Azure คุณอาจยังใช้ SQL Server 2008/2008 R2 อยู่ และต้องการใช้ประโยชน์จากการปรับปรุงความปลอดภัยเพิ่มเติมที่ Microsoft เสนอให้หากคุณย้าย SQL Server 2008/2008 R2 ไปยัง Azure ก่อนหน้านี้ฉันเคยเขียนเกี่ยวกับหัวข้อนี้ในโพสต์บล็อกนี้ คุณอาจสงสัยว่าจะต้องแน่ใจได้อย่างไรว่าอินสแตนซ์ของคลัสเตอร์เซิร์ฟเวอร์ล้มเหลว SQL ของคุณยังคงพร้อมใช้งานสูงเมื่อคุณย้ายไปยัง Azure วันนี้คนส่วนใหญ่มีธุรกิจที่สำคัญ SQL Server 2008/2008 R2 กำหนดค่าเป็นอินสแตนซ์คลัสเตอร์ (SQL Server FCI) ในศูนย์ข้อมูลของพวกเขา เมื่อดูที่ Azure คุณอาจเข้าใจว่าเนื่องจากการขาดพื้นที่เก็บข้อมูลที่ใช้ร่วมกันอาจดูเหมือนว่าคุณไม่สามารถนำ SQL Server FCI ของคุณไปยังกลุ่มเมฆ Azure อย่างไรก็ตามนั่นไม่ใช่กรณีที่ต้องขอบคุณ SIOS DataKeeper SIOS DataKeeper ช่วยให้คุณสามารถสร้างอินสแตนซ์ของคลัสเตอร์เซิร์ฟเวอร์ล้มเหลวของ SQL ใน Azure, AWS, Google Cloud หรือที่อื่นใดที่ไม่มีที่เก็บข้อมูลที่ใช้ร่วมกันหรือที่คุณต้องการกำหนดค่าหลายไซต์คลัสเตอร์ DataKeeper เปิดใช้งาน SANless clusters สำหรับ Windows และ Linux ตั้งแต่ปี 1999 Microsoft จัดทำเอกสารการใช้ SIOS DataKeeper สำหรับอินสแตนซ์ของคลัสเตอร์เซิร์ฟเวอร์ล้มเหลวของ SQL ในเอกสารประกอบ: ความพร้อมใช้งานสูงและการกู้คืนความเสียหายสำหรับ SQL Server ในเครื่องเสมือน Azure ฉันเคยเขียนเกี่ยวกับ SQL Server FCI ที่เคยทำงานใน Azure มาก่อน แต่ฉันไม่เคยเผยแพร่คู่มือแบบทีละขั้นตอนเฉพาะสำหรับ SQL Server 2008/2008 R2 ข่าวดีก็คือมันใช้งานได้ดีกับ SQL 2008/2008 R2 เช่นเดียวกับ SQL 2012/2014/2016/2017 และจะเปิดตัวเร็ว ๆ นี้ 2019 นอกจากนี้ไม่ว่ารุ่นของ Windows Server (2008/2012/2016/2019) หรือ SQL Server (2008/2012/2014/2016/2017) กระบวนการกำหนดค่าจะคล้ายกันมากพอที่คู่มือนี้ควรจะเพียงพอที่จะให้คุณผ่าน การกำหนดค่า หากรสชาติของ SQL หรือ Windows ของคุณไม่ครอบคลุมในคำแนะนำใด ๆ ของฉันอย่ากลัวที่จะกระโดดเข้ามาและสร้าง SQL Server FCI และอ้างอิงคู่มือนี้ฉันคิดว่าคุณจะเข้าใจถึงความแตกต่างและถ้าคุณติดอยู่ ยื่นมือมาหาฉันทาง Twitter @davberm และฉันยินดีที่จะให้คุณ คู่มือนี้ใช้ SQL Server 2008 R2 กับ Windows Server 2012 R2 เวลาเขียนนี้ฉันไม่เห็นภาพ Azure Marketplace ของ SQL 2008 R2 บน Windows Server 2012 R2 ดังนั้นฉันต้องดาวน์โหลดและติดตั้ง SQL 2008 R2 ด้วยตนเอง ส่วนตัวแล้วฉันชอบชุดค่าผสมนี้ แต่ถ้าคุณจำเป็นต้องใช้ Windows Server 2008 R2 หรือ Windows 212 ที่ใช้ได้ หากคุณใช้ Windows Server 2008 R2 อย่าลืมติดตั้ง kb3125574 Conveience Rollup Update สำหรับ Windows Server 2008 R2 SP1 หรือถ้าคุณติดกับ Server 2012 (ไม่ใช่ R2) คุณต้องใช้ Hotfix ใน kb2854082 อย่าหลงกลโดยบทความนี้ที่บอกว่าคุณต้องติดตั้ง kb2854082 ในอินสแตนซ์ของ SQL Server 2008 R2 ของคุณ หากคุณเริ่มค้นหาการอัปเดตนั้นสำหรับ Windows Server 2008 R2 คุณจะพบว่ามีเฉพาะรุ่นสำหรับ Server 2012 เท่านั้น โปรแกรมแก้ไขด่วนนั้นสำหรับ Server 2008 R2 นั้นจะรวมอยู่ในการยกเลิกการปรับปรุงการยกเลิกการอำนวยความสะดวกสำหรับ Windows Server 2008 R2 SP1 แทน

การจัดเตรียม AZURE

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

ความผิดพลาดในโดเมนหรือพื้นที่ว่างหรือไม่

เพื่อให้แน่ใจว่าอินสแตนซ์ของ SQL Server ของคุณพร้อมใช้งานสูงคุณต้องตรวจสอบให้แน่ใจว่าโหนดคลัสเตอร์ของคุณอยู่ใน Fault Domains (FD) หรือโซนความพร้อมใช้งาน (AZ) ที่แตกต่างกัน อินสแตนซ์ของคุณไม่เพียง แต่ต้องอาศัยอยู่ใน FD หรือ AZ ที่ต่างกัน แต่ File Share Witness (ดูด้านล่าง) ยังต้องอยู่ใน FD หรือ AZ ที่แตกต่างจากโหนดคลัสเตอร์ของคุณ นี่คือสิ่งที่ฉันทำ AZs เป็นคุณลักษณะใหม่ล่าสุดของ Azure แต่ได้รับการสนับสนุนในภูมิภาคต่างๆ AZs ให้ SLA ที่สูงขึ้น (99.99%) จากนั้น FDs (99.95%) และปกป้องคุณจากการขาดของคลาวด์ที่ฉันอธิบายในโพสต์ Azure Outage Post-Mortem ของฉัน หากคุณสามารถปรับใช้ในภูมิภาคที่รองรับ AZ ได้ฉันขอแนะนำให้คุณใช้ AZs ในคู่มือนี้ฉันใช้ AZ ซึ่งคุณจะเห็นเมื่อคุณไปที่ส่วนในการกำหนดค่าตัวโหลดบาลานซ์ อย่างไรก็ตามหากคุณใช้ FD ทุกอย่างจะเหมือนกันทุกประการยกเว้นการกำหนดค่าโหลดบาลานเซอร์จะอ้างอิงชุดความพร้อมใช้งานแทนโซนความพร้อมใช้งาน

อะไรคือสิ่งที่แบ่งปันให้คุณถาม?

การทำคลัสเตอร์ Windows Server Failover Clustering (WSFC) จะทำให้คุณต้องกำหนดค่า "พยาน" เพื่อให้แน่ใจว่าการทำงานล้มเหลวอย่างถูกต้อง Windows Server Failover Clustering รองรับพยานสามชนิด: ดิสก์, การแชร์ไฟล์, คลาวด์ เนื่องจากเราอยู่ใน Azure จึงไม่สามารถเป็นพยานได้ Cloud Witness นั้นมีเฉพาะใน Windows Server 2016 และใหม่กว่าเท่านั้นดังนั้นเราจึงมี File Share Witness หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับโควรัมกลุ่มตรวจสอบการโพสต์ของฉันในบล็อก Microsoft Press จาก MVPs: ทำความเข้าใจกับ Quorum คลัสเตอร์เซิร์ฟเวอร์ Windows ล้มเหลวใน Windows Server 2012 R2

เพิ่มการจัดเก็บลงในเซิร์ฟเวอร์ SQL ของคุณ

เมื่อคุณจัดเตรียมอินสแตนซ์ SQL Server ของคุณคุณจะต้องการเพิ่มดิสก์เพิ่มเติมให้กับแต่ละอินสแตนซ์ น้อยที่สุดคุณจะต้องมีหนึ่งดิสก์สำหรับข้อมูล SQL และไฟล์บันทึกหนึ่งดิสก์สำหรับ Tempdb คุณควรมีดิสก์แยกต่างหากสำหรับไฟล์บันทึกและข้อมูลบ้างหรือไม่เมื่อใช้งานในระบบคลาวด์ ที่ปลายด้านหลังพื้นที่เก็บข้อมูลทั้งหมดมาจากที่เดียวกันและขนาดอินสแตนซ์ของคุณจะ จำกัด IOPS ทั้งหมดของคุณ ในความคิดของฉันไม่มีค่าใด ๆ ในการแยกไฟล์บันทึกและข้อมูลของคุณเพราะคุณไม่สามารถมั่นใจได้ว่าไฟล์เหล่านั้นกำลังทำงานอยู่ในดิสก์ที่มีอยู่จริงสองชุด ฉันจะปล่อยให้คุณตัดสินใจ แต่ฉันใส่บันทึกและข้อมูลทั้งหมดในปริมาณเดียวกัน โดยทั่วไปแล้ว SQL Server 2008 R2 FCI จะทำให้คุณต้องวาง tempdb ลงในดิสก์ที่ทำคลัสเตอร์ อย่างไรก็ตาม SIOS DataKeeper มีคุณสมบัติที่ดีมาก ๆ ที่เรียกว่า DataKeeper Non-Mirrored Volume Resource คู่มือนี้ไม่ครอบคลุมถึงการย้าย tempdb ไปยังทรัพยากรปริมาณที่ไม่ใช่มิร์เรอร์ แต่เพื่อประสิทธิภาพที่ดีที่สุดคุณควรทำเช่นนี้ ไม่มีเหตุผลที่ดีที่จะทำซ้ำ tempdb เนื่องจากมันถูกสร้างขึ้นใหม่เมื่อเกิดความล้มเหลว เท่าที่เกี่ยวข้องกับการจัดเก็บคุณสามารถใช้ประเภทการจัดเก็บใด ๆ แต่แน่นอนใช้ดิสก์ที่มีการจัดการเมื่อใดก็ตามที่เป็นไปได้ ตรวจสอบให้แน่ใจว่าแต่ละโหนดในคลัสเตอร์มีการกำหนดค่าการจัดเก็บข้อมูลเหมือนกัน เมื่อคุณเปิดใช้งานอินสแตนซ์คุณจะต้องแนบดิสก์เหล่านี้และฟอร์แมต NTFS ตรวจสอบให้แน่ใจว่าแต่ละอินสแตนซ์ใช้อักษรระบุไดรฟ์เดียวกัน

เครือข่าย

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

การรักษาความปลอดภัย

ตามค่าเริ่มต้นการสื่อสารระหว่างโหนดในเครือข่ายเสมือนเดียวกันจะเปิดกว้าง แต่ถ้าคุณล็อค Azure Security Group ของคุณไว้คุณจะต้องรู้ว่าพอร์ตใดที่จะต้องเปิดระหว่างโหนดคลัสเตอร์และปรับกลุ่มความปลอดภัยของคุณ จากประสบการณ์ของฉันปัญหาเกือบทั้งหมดที่คุณจะพบเมื่อสร้างคลัสเตอร์ใน Azure อาจเกิดจากพอร์ตที่ถูกบล็อก DataKeeper มีบางพอร์ตที่จำเป็นต้องเปิดระหว่างอินสแตนซ์ของคลัสเตอร์ พอร์ตเหล่านั้นมีดังนี้: UDP: 137, 138 TCP: 139, 445, 9999 รวมถึงพอร์ตในช่วง 10,000 ถึง 10025 คลัสเตอร์ Failover มีชุดข้อกำหนดของพอร์ตของตัวเองที่ฉันจะไม่พยายามทำเอกสารที่นี่ บทความนี้ดูเหมือนจะมีที่ครอบคลุม http://dsfnet.blogspot.com/2013/04/windows-server-clustering-sql-server.html นอกจากนี้ Load Balancer ที่อธิบายในภายหลังจะใช้พอร์ตโพรบที่ต้องอนุญาตการรับส่งข้อมูลขาเข้าในแต่ละโหนด พอร์ตที่ใช้กันทั่วไปและอธิบายไว้ในคู่มือนี้คือ 59999 และในที่สุดถ้าคุณต้องการให้ลูกค้าของคุณสามารถเข้าถึงอินสแตนซ์ SQL Server ของคุณคุณต้องการให้แน่ใจว่าพอร์ต SQL Server ของคุณเปิดอยู่ซึ่งโดยค่าเริ่มต้นคือ 1433 จำไว้ว่าพอร์ตเหล่านี้สามารถบล็อกได้โดย Windows Firewall หรือ Azure Security Groups ดังนั้นเพื่อให้แน่ใจว่าได้ตรวจสอบทั้งสองอย่างเพื่อให้แน่ใจว่าสามารถเข้าถึงได้

เข้าร่วม DOMAIN

ข้อกำหนดสำหรับ SQL Server 2008 R2 FCI คืออินสแตนซ์นั้นต้องอยู่ในโดเมน Windows Server เดียวกัน ดังนั้นหากคุณยังไม่ได้ดำเนินการตรวจสอบให้แน่ใจว่าคุณได้เข้าร่วมอินสแตนซ์กับโดเมน Windows ของคุณ

บัญชีบริการท้องถิ่น

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

กลุ่มความปลอดภัยระดับโลก DOMAIN

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

ข้อกำหนดล่วงหน้าอื่น ๆ

คุณต้องเปิดใช้งานทั้ง Failover Clustering และ. Net 3.5 ในแต่ละอินสแตนซ์ของสองอินสแตนซ์ของคลัสเตอร์ เมื่อคุณเปิดใช้งานการทำคลัสเตอร์เข้าแทนที่ให้ตรวจสอบให้แน่ใจว่าได้เปิดใช้งานตัวเลือก "เซิร์ฟเวอร์การทำงานอัตโนมัติล้มเหลวแบบคลัสเตอร์" สิ่งนี้จำเป็นสำหรับคลัสเตอร์ SQL Server 2008 R2 ใน Windows Server 2012 R2

สร้างกลุ่มทรัพยากรและฐานข้อมูลปริมาณ

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

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

หลังจากสร้างคลัสเตอร์แล้วให้รัน Test-Cluster จำเป็นต้องมีก่อนที่จะติดตั้ง SQL Server

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

คุณจะได้รับคำเตือนเกี่ยวกับการจัดเก็บและระบบเครือข่าย โชคดีที่คุณสามารถเพิกเฉยสิ่งที่คาดหวังในคลัสเตอร์ SANless ใน Azure อย่างไรก็ตามให้จัดการกับคำเตือนหรือข้อผิดพลาดอื่น ๆ ก่อนดำเนินการ หลังจากสร้างคลัสเตอร์แล้วคุณจะต้องเพิ่ม File Share Witness บนเซิร์ฟเวอร์ที่สามที่เราระบุว่าเป็นพยานการแชร์ไฟล์ให้สร้างการแชร์ไฟล์และให้สิทธิ์ในการอ่าน / เขียนไปยังวัตถุคอมพิวเตอร์คลัสเตอร์ที่เราเพิ่งสร้างขึ้น ในกรณีนี้ $ Cluster1 จะเป็นชื่อของวัตถุคอมพิวเตอร์ที่ต้องการสิทธิ์อ่าน / เขียนที่ระดับความปลอดภัยที่ใช้ร่วมกันและ NTFS เมื่อสร้างการแชร์แล้วคุณสามารถใช้ Configure Cluster Quorum Wizard ดังแสดงด้านล่างเพื่อกำหนดค่าพยานการแชร์ไฟล์

ติดตั้ง DATAKEEPER

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

บัญชีที่คุณระบุด้านล่างจะต้องเป็นบัญชีโดเมน ต้องเป็นส่วนหนึ่งของกลุ่ม Local Administrators ในแต่ละโหนดคลัสเตอร์

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

สร้างปริมาณข้อมูล DATAKEEPER

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

หากทุกอย่างทำอย่างถูกต้องรายงานภาพรวมเซิร์ฟเวอร์ควรมีลักษณะเช่นนี้

ตอนนี้คุณสามารถสร้างงานแรกของคุณตามที่แสดงด้านล่าง

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

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

เมื่อคุณทำกระบวนการนี้เสร็จสิ้นให้เปิด Failover Cluster Manager และค้นหาใน Disk คุณควรเห็นทรัพยากร DataKeeper Volume ใน Available Storage เมื่อถึงจุดนี้ WSFC จะถือว่านี่เป็นทรัพยากรดิสก์คลัสเตอร์ปกติ

SLIPSTREAM SP3 ไปยัง SQL 2008 R2 ติดตั้งสื่อ

SQL Server 2008 R2 รองรับ Windows Server 2012 R2 ที่มี SQL Server SP2 หรือใหม่กว่าเท่านั้น น่าเสียดายที่ Microsoft ไม่เคยเผยแพร่สื่อการติดตั้ง SQL Server 2008 R2 ที่มี SP2 หรือ SP3 แต่คุณต้องส่งเซอร์วิสแพ็คลงบนสื่อบันทึกการติดตั้งก่อนทำการติดตั้ง หากคุณพยายามทำการติดตั้งด้วยสื่อบันทึก SQL Server 2008 R2 มาตรฐานคุณจะพบปัญหาทุกประเภท ฉันจำข้อผิดพลาดที่แน่นอนที่คุณจะเห็น แต่ฉันจำได้ว่าพวกเขาไม่ได้ชี้ไปที่ปัญหาที่แท้จริง คุณจะเสียเวลามากพอที่จะคิดออกว่าเกิดอะไรขึ้น ณ วันที่เขียนนี้ Microsoft ไม่มี Windows Server 2012 R2 พร้อม SQL Server 2008 R2 ที่เสนอใน Azure Marketplace ทำใบอนุญาต SQL ของคุณเองถ้าคุณต้องการเรียกใช้ SQL 2008 R2 บน Windows Server 2012 R2 ใน Azure หากพวกเขาเพิ่มอิมเมจนั้นในภายหลังหรือถ้าคุณเลือกที่จะใช้ SQL 2008 R2 บนอิมเมจ Windows Server 2008 R2 คุณต้องถอนการติดตั้งอินสแตนซ์แบบสแตนด์อโลนที่มีอยู่ของ SQL Server ก่อนที่จะดำเนินการต่อ ฉันทำตามคำแนะนำในตัวเลือกที่ 1 ของบทความนี้เพื่อส่ง SP3 บนสื่อการติดตั้ง SQL 2008 R2 ของฉัน แน่นอนว่าคุณจะต้องปรับเปลี่ยนบางสิ่งเนื่องจากบทความนี้อ้างอิง SP2 แทน SP3 ตรวจสอบให้แน่ใจว่าคุณ slipstream SP3 บนสื่อการติดตั้งที่เราจะใช้สำหรับทั้งสองโหนดของคลัสเตอร์ เมื่อเสร็จแล้วให้ทำตามขั้นตอนต่อไป

ติดตั้งเซิร์ฟเวอร์ SQL บนโหนดแรก

การใช้สื่อ SQL Server 2008 R2 กับ SP3 slipstreamed ให้รันการติดตั้งและติดตั้งโหนดแรกของคลัสเตอร์ดังที่แสดงด้านล่าง

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

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

ดังที่ฉันได้กล่าวก่อนหน้านี้ SQL Server 2008 R2 ใช้กลุ่มความปลอดภัยของโฆษณา หากคุณยังไม่ได้สร้างพวกเขาไปข้างหน้าและสร้างพวกเขาในขณะนี้ตามที่แสดงด้านล่างก่อนที่จะดำเนินการขั้นตอนต่อไปในการติดตั้ง SQL

ระบุกลุ่มความปลอดภัยที่คุณสร้างไว้ก่อนหน้า

ตรวจสอบให้แน่ใจว่าบัญชีบริการที่คุณระบุเป็นสมาชิกของกลุ่มความปลอดภัยที่เกี่ยวข้อง

ระบุผู้ดูแลระบบ SQL Server ของคุณที่นี่

หากทุกอย่างเป็นไปด้วยดีตอนนี้คุณก็พร้อมที่จะติดตั้ง SQL Server บนโหนดที่สองของคลัสเตอร์

ติดตั้งเซิร์ฟเวอร์ SQL บนโหนดที่สอง

หนึ่งโหนดที่สองให้เรียกใช้ SQL Server 2008 R2 ด้วยการติดตั้ง SP3 และเลือกเพิ่มโหนดไปยังอินสแตนซ์ของการทำคลัสเตอร์การเฟลโอเวอร์ของเซิร์ฟเวอร์ SQL

ดำเนินการติดตั้งตามที่แสดงในภาพหน้าจอต่อไปนี้

สมมติว่าทุกอย่างเป็นไปด้วยดีตอนนี้คุณควรมีคลัสเตอร์สองโหนดของ SQL Server 2008 R2 ที่ได้รับการกำหนดค่าซึ่งมีลักษณะดังนี้

อย่างไรก็ตามคุณอาจสังเกตเห็นว่าคุณสามารถเชื่อมต่อกับอินสแตนซ์ SQL Server จากโหนดคลัสเตอร์ที่ใช้งานอยู่เท่านั้น ปัญหาคือว่า Azure ไม่รองรับ ARP ฟรีลูกค้าของคุณอาจไม่สามารถเชื่อมต่อโดยตรงกับที่อยู่ IP ของคลัสเตอร์ ไคลเอ็นต์ต้องเชื่อมต่อกับ Azure Load Balancer แทนซึ่งจะเปลี่ยนเส้นทางการเชื่อมต่อไปยังโหนดที่ใช้งานอยู่ ในการทำให้งานนี้มีสองขั้นตอน: สร้าง Load Balancer และแก้ไข IP ของคลัสเตอร์ SQL Server เพื่อตอบสนองต่อโพรบ Load Balancer และใช้ 255net5.255.255 Subnet mask ขั้นตอนเหล่านั้นอธิบายไว้ด้านล่าง

สร้างยอดคงเหลือ AZURE

ฉันจะถือว่าลูกค้าของคุณสามารถสื่อสารโดยตรงไปยังที่อยู่ IP ภายในของคลัสเตอร์ SQL มาก่อนกันเพื่อสร้าง Internal Load Balancer (ILB) ในคู่มือนี้ หากคุณต้องการเปิดเผยอินสแตนซ์ SQL ของคุณบนอินเทอร์เน็ตสาธารณะให้ใช้ Public Load Balancer แทน ในพอร์ทัล Azure ให้สร้าง Load Balancer ใหม่ตามภาพหน้าจอดังที่แสดงด้านล่าง Azure portal UI เปลี่ยนไปอย่างรวดเร็ว เปลี่ยนภาพหน้าจอเหล่านี้ควรให้ข้อมูลมากพอที่จะทำสิ่งที่คุณต้องทำ ฉันจะโทรออกการตั้งค่าที่สำคัญในขณะที่เราไปพร้อมกัน ที่นี่เราสร้าง ILB สิ่งสำคัญที่ควรทราบบนหน้าจอนี้คือคุณต้องเลือก“ การกำหนดที่อยู่ IP แบบคงที่” ระบุที่อยู่ IP เดียวกับที่เราใช้ระหว่างการติดตั้ง SQL Cluster ด้วย เนื่องจากฉันใช้โซนความพร้อมใช้งานฉันจึงเห็นตัวเลือก Zone Redundant หากคุณใช้ชุดความพร้อมใช้งานชุดประสบการณ์ของคุณจะแตกต่างกันเล็กน้อย

ในพูลแบ็คเอนด์ให้แน่ใจว่าได้เลือกอินสแตนซ์ของ SQL Server สองอิน คุณไม่ต้องการเพิ่ม File Share Witness ในพูล

ที่นี่เรากำหนดค่าโพรบสุขภาพ เอกสาร Azure ส่วนใหญ่ใช้พอร์ต 59999 ดังนั้นเราจะยึดกับพอร์ตนั้นสำหรับการกำหนดค่าของเรา

จากนั้นเราจะเพิ่มกฎการปรับสมดุลโหลด ในกรณีของเราเราต้องการเปลี่ยนเส้นทางการรับส่งข้อมูลเซิร์ฟเวอร์ SQL ทั้งหมดไปยังพอร์ต TCP 1433 ของโหนดที่ใช้งานอยู่ สิ่งสำคัญคือคุณต้องเลือก IP แบบลอยตัว (Direct Server Return) เป็น Enabled

เรียกใช้ POWERSHELL SCRIPT เพื่ออัปเดตการเข้าถึงลูกค้า SQL

ตอนนี้เราต้องเรียกใช้สคริปต์ Powershell บนหนึ่งในโหนดคลัสเตอร์เพื่อให้ตัวตรวจสอบการโหลดบาลานซ์ตรวจสอบว่าโหนดใดที่ทำงานอยู่ สคริปต์ยังตั้ง Subnet Mask ของที่อยู่ IP ของ SQL Cluster เป็น 255.255.255.255.255 เพื่อหลีกเลี่ยงข้อขัดแย้งที่อยู่ IP กับ Load Balancer ที่เราเพิ่งสร้างขึ้น

# กำหนดตัวแปร
$ ClusterNetworkName =“” 
# ชื่อเครือข่ายคลัสเตอร์ (ใช้ Get-ClusterNetwork บน Windows Server 2012 
สูงกว่าเพื่อค้นหาชื่อ)
$ IPResourceName =“” 
# ชื่อทรัพยากรที่อยู่ IP 
$ ILBIP =“” 
# ที่อยู่ IP ของ Internal Load Balancer (ILB) และ SQL Cluster
Import-Module FailoverClusters
# ถ้าคุณใช้ Windows Server 2012 หรือสูงกว่า:
รับ-ClusterResource $ IPResourceName | ตั้ง ClusterParameter 
-Multiple @ {ที่อยู่ = $ 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

คุณอาจสังเกตเห็นว่าจุดสิ้นสุดของสคริปต์นั้นมีบรรทัดของรหัสที่ใส่ความเห็นหากคุณใช้งานบน Windows Server 2008 R2 ใช้ Windows Server 2008 R2 หรือไม่ ตรวจสอบให้แน่ใจว่าคุณเรียกใช้รหัสเฉพาะสำหรับ Windows Server 2008 R2 ที่พรอมต์คำสั่งไม่ใช่ Powershell

ขั้นตอนถัดไป

คุณไม่ใช่คนแรกหากมาถึงจุดนี้และคุณยังไม่สามารถเชื่อมต่อกับคลัสเตอร์ได้จากระยะไกล มีหลายสิ่งหลายอย่างที่อาจผิดพลาดได้ในเรื่องความปลอดภัยโหลดบาลานเซอร์พอร์ต SQL ฯลฯ ฉันเขียนคู่มือนี้เพื่อช่วยแก้ไขปัญหาการเชื่อมต่อ อันที่จริงฉันเจอปัญหาแปลก ๆ ในแง่ของคุณสมบัติ TCP / IP ของ SQL Server ในตัวจัดการการกำหนดค่าเซิร์ฟเวอร์ SQL เมื่อฉันดูคุณสมบัติฉันไม่เห็นที่อยู่ IP ของ SQL Server Cluster เป็นหนึ่งในที่อยู่ที่ฟังอยู่ เช่นฉันต้องเพิ่มมันด้วยตนเอง ฉันไม่แน่ใจว่าเป็นความผิดปกติหรือไม่ แม้ว่ามันจะเป็นปัญหาที่ฉันต้องแก้ไขก่อนที่ฉันจะสามารถเชื่อมต่อกับคลัสเตอร์จากไคลเอนต์ระยะไกลได้ อย่างที่ฉันได้กล่าวไปแล้วการปรับปรุงอื่นที่คุณสามารถทำได้กับการติดตั้งนี้คือการใช้ DataKeeper Non-Mirrored Volume Resource สำหรับ TempDB หากคุณติดตั้งโปรดระวังปัญหาการกำหนดค่าสองประการต่อไปนี้ซึ่งคนทั่วไปมักพบเจอ ปัญหาแรกคือถ้าคุณย้าย tempdb ไปยังโฟลเดอร์บนโหนดที่ 1 คุณต้องแน่ใจว่าได้สร้างโครงสร้างโฟลเดอร์เดียวกันที่แน่นอนบนโหนดที่สอง หากคุณไม่ทำเช่นนั้นเมื่อคุณพยายามล้มเหลว SQL Server จะไม่สามารถออนไลน์ได้เนื่องจากไม่สามารถสร้าง TempDB ได้ ปัญหาที่สองเกิดขึ้นเมื่อใดก็ตามที่คุณเพิ่ม DataKeeper Volume Resource ลงใน SQL Cluster หลังจากสร้างคลัสเตอร์แล้ว คุณต้องเข้าไปในคุณสมบัติของทรัพยากรคลัสเตอร์ของ SQL Server และทำให้มันขึ้นอยู่กับทรัพยากร DataKeeper ปริมาณใหม่ที่คุณเพิ่ม สิ่งนี้เป็นจริงสำหรับวอลุ่ม TempDB และไดรฟ์ข้อมูลอื่น ๆ ที่คุณอาจตัดสินใจที่จะเพิ่มหลังจากสร้างคลัสเตอร์แล้ว หากคุณมีคำถามใด ๆ เกี่ยวกับการกำหนดค่านี้หรือการกำหนดค่าคลัสเตอร์อื่น ๆ โปรดติดต่อฉันที่ Twitter @DaveBerm

https://clusteringformeremortals.com/2016/01/06/troubleshooting-azure-ilb-connection-issues-in-a-sql-server-alwayson-fci-cluster/
ทำซ้ำโดยได้รับอนุญาตจาก Clusteringformeremortals.com