ทีละขั้นตอน: กำหนดคอนฟิกคลัสเตอร์เซิร์ฟเวอร์ไฟล์ใน Azure Spanning Availability Zones

ในโพสต์นี้เราจะอธิบายรายละเอียดขั้นตอนเฉพาะที่จำเป็นสำหรับการปรับใช้คลัสเตอร์ Failover Cluster ในเซิร์ฟเวอร์ไฟล์ 2 โหนดใน Azure ซึ่งครอบคลุมพื้นที่การให้บริการใหม่ ฉันจะสมมติว่าคุณคุ้นเคยกับแนวคิดพื้นฐาน Azure และแนวคิดพื้นฐานของ Failover Cluster ฉันจะมุ่งความสนใจไปที่การปรับใช้คลัสเตอร์ Failover Cluster ของเซิร์ฟเวอร์ไฟล์ใน Azure ในโซนที่พร้อมใช้งาน หากพื้นที่ Azure ของคุณไม่สนับสนุนเขตการให้บริการคุณจะต้องใช้โดเมนฟอรัมแทนตามที่อธิบายในโพสต์ก่อนหน้านี้ ด้วย DataKeeper Cluster Edition คุณสามารถใช้ไดรฟ์ข้อมูลที่มีการแนบอยู่ภายในไม่ว่าจะเป็น Premium หรือ Standard Disks และทำซ้ำไดรฟ์เหล่านี้ทั้งแบบซิงโครนัสแบบอะซิงโครนัสหรือแบบผสมหรือทั้งสองอย่างระหว่างสองโหนดคลัสเตอร์ นอกจากนี้รีซอร์ส DataKeeper Volume ถูกลงทะเบียนใน Windows Server Failover Clustering ซึ่งใช้แทน Physical Disk resource แทนการควบคุมการจอง SCSI-3 เช่น Physical Disk Resource ไดรฟ์ DataKeeper ควบคุมทิศทางกระจก จะทำให้โหนดที่ใช้งานอยู่เสมอคือแหล่งกำเนิดของกระจก ส่วนที่เกี่ยวข้องกับ Failover Clustering จะมีลักษณะรู้สึกและมีกลิ่นคล้าย Physical Disk และใช้งานได้เช่นเดียวกับ Physical Disk Resource

requisites ก่อน

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

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

ในการสร้างอินสแตนซ์ของคลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์ไฟล์ 2 โหนดใน Azure เราจะสมมติว่าคุณมีเครือข่ายเสมือนพื้นฐานขึ้นอยู่กับ Azure Resource Manager คุณมีเครื่องเสมือนอย่างน้อยหนึ่งเครื่องทำงานและกำหนดค่าเป็น Domain Controller เมื่อคุณมีเครือข่ายเสมือนจริงและโดเมนที่กำหนดค่าคุณจะจัดหาอุปกรณ์เสมือนใหม่สองเครื่องซึ่งจะทำหน้าที่เป็นโหนดสองโหนดในกลุ่มของเรา สภาพแวดล้อมของเราจะมีลักษณะดังนี้: DC1 – ตัวควบคุมโดเมนและไฟล์ Share Witness SQL1 และ SQL2 – โหนดทั้งสองของคลัสเตอร์เซิร์ฟเวอร์ไฟล์ของเรา อย่าให้ชื่อสับสน เรากำลังสร้างคลัสเตอร์เซิร์ฟเวอร์ไฟล์ในคู่มือนี้ ในโพสต์ต่อไปฉันจะแสดงการกำหนดค่าคลัสเตอร์ SQL Server

การจัดเตรียมโหนดคลัสเตอร์ที่สอง

การใช้ Azure Portal เราจะจัดเตรียมทั้ง SQL1 และ SQL2 ในลักษณะเดียวกัน  มีตัวเลือกมากมายให้เลือก ได้แก่ ขนาดตัวอย่างตัวเลือกการจัดเก็บเป็นต้น คู่มือนี้ไม่ได้หมายถึงคู่มือที่ละเอียดอ่อนในการปรับใช้เซิร์ฟเวอร์ใน Azure มีทรัพยากรที่ดีจริงๆออกมีและเผยแพร่เพิ่มเติมทุกวัน อย่างไรก็ตามคุณควรคำนึงถึงสิ่งสำคัญบางอย่างเมื่อสร้างอินสแตนซ์โดยเฉพาะอย่างยิ่งในสภาวะแวดล้อมแบบคลัสเตอร์ โซนความพร้อมใช้งาน – เป็นสิ่งสำคัญที่ทั้ง SQL1, SQL2 อาศัยอยู่ในโซนความพร้อมที่แตกต่างกัน เพื่อประโยชน์ของคู่มือนี้เราจะถือว่าคุณกำลังใช้ Windows 2016 และจะใช้ Cloud Witness สำหรับ Cluster Quorum ถ้าคุณใช้ Windows 2012 R2 หรือ Windows Server 2008 R2 แทน Windows 2016 คุณจะต้องกำหนดค่า Share Share Share Witness ในโซนที่พร้อมใช้งานที่ 3 Cloud Witness ไม่ได้เปิดตัวจนถึง Windows Server 2016 โดยการวางโหนดคลัสเตอร์ไว้ในโซนการให้บริการที่แตกต่างกันเราจะมั่นใจได้ว่าแต่ละโหนดคลัสเตอร์อยู่ในดาต้าเซ็นเตอร์ Azure แบบอื่นในภูมิภาคเดียวกัน ใช้ประโยชน์จากพื้นที่ว่างมากกว่าโดเมนที่เก่ากว่าจะเป็นประโยชน์ มันแยกคุณจากประเภทของการหยุดทำงานที่เกิดขึ้นเพียงไม่กี่สัปดาห์ที่ผ่านมาที่นำลงทั้งภาคใต้ภาคกลางเป็นเวลาหลายวัน ให้แน่ใจว่าได้เพิ่มโหนดแต่ละโหนดเข้ากับโซนความพร้อมใช้งานที่แตกต่างกัน หากคุณใช้ประโยชน์จาก Share Share Witness ควรอยู่ในโซนที่พร้อมใช้งานครั้งที่ 3 [/ caption]

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

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

การเก็บรักษา

คุณจำเป็นต้องปรึกษาแนวทางปฏิบัติที่ดีที่สุดสำหรับ SQL Server ใน Azure Virtual Machines ไม่ว่าในกรณีใดคุณจะต้องเพิ่มดิสก์ที่มีการจัดการอย่างน้อยหนึ่งโหนดให้กับแต่ละโหนดคลัสเตอร์ของคุณ DataKeeper สามารถใช้ Basic Disk, Premium Storage หรือแม้แต่ดิสก์หลาย ๆ ที่รวมกันใน Storage Space ถ้าคุณต้องการใช้พื้นที่จัดเก็บแบบโลคัลให้ระวังเพื่อสร้างพื้นที่เก็บข้อมูลก่อนการกำหนดค่าคลัสเตอร์ใด ๆ นี่เป็นเพราะปัญหาที่ทราบเกี่ยวกับ Failover Clustering และ Storage Spaces ดิสก์ทั้งหมดควรมีรูปแบบ NTFS

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

สมมติว่าทั้งโหนดคลัสเตอร์ (SQL1 และ SQL2) ได้รับการจัดเตรียมตามที่อธิบายไว้ข้างต้นและเพิ่มลงในโดเมนที่มีอยู่แล้วของคุณเราพร้อมที่จะสร้างคลัสเตอร์แล้ว ก่อนที่เราจะสร้างคลัสเตอร์มีคุณลักษณะบางอย่างที่จำเป็นต้องเปิดใช้งาน คุณลักษณะเหล่านี้คือ .Net Framework 3.5 และ Failover Clustering คุณลักษณะเหล่านี้จำเป็นต้องเปิดใช้งานทั้งโหนดคลัสเตอร์ คุณจะต้องเปิดใช้งานบทบาทเซิร์ฟเวอร์ FIle เปิดใช้งานคุณสมบัติ .Net Framework 3.5 และ Failover Clustering และ File Server ทั้งโหนดคลัสเตอร์ [/ caption] เมื่อบทบาทและคุณสมบัติเหล่านั้นได้รับการเปิดใช้งานแล้ว คุณพร้อมที่จะสร้างกลุ่มแล้ว ขั้นตอนส่วนใหญ่ที่ฉันกำลังจะแสดงให้คุณสามารถทำได้ทั้งผ่านทาง PowerShell และ GUI อย่างไรก็ตามผมจะแนะนำว่าสำหรับขั้นตอนแรกนี้คุณใช้ PowerShell เพื่อสร้างคลัสเตอร์ของคุณ ถ้าคุณเลือกที่จะใช้ Failover Cluster Manager GUI เพื่อสร้างคลัสเตอร์คุณจะพบว่าคุณได้รับผลกระทบจากคลัสเตอร์ที่ออก IP แอดเดรสซ้ำ โดยไม่ต้องไปรายละเอียดมากสิ่งที่คุณจะพบคือ Azure VMs ต้องใช้ DHCP การระบุ "IP แบบสโตร" เมื่อเราสร้าง VM ในพอร์ทัล Azure ทั้งหมดที่เราทำคือสร้างการจัดเรียงแบบ DHCP ไม่เหมือนกับการจอง DHCP เนื่องจากการจอง DHCP จริงจะนำที่อยู่ IP ออกจากพูล DHCP แทนที่จะระบุ IP แบบคงที่ในพอร์ทัล Azure ก็หมายความว่าถ้าที่อยู่ IP นี้ยังคงพร้อมใช้งานเมื่อ VM ร้องขอให้ Azure จะออก IP ดังกล่าว อย่างไรก็ตามถ้า VM ของคุณออฟไลน์และโฮสต์อื่นมาออนไลน์ในเครือข่ายย่อยเดียวกันนั้นเป็นอย่างดีอาจจะออกที่อยู่ IP เดียวกัน

ผลข้างเคียงอีกอย่างหนึ่งต่อวิธีที่ Azure ใช้ DHCP

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

คลัสเตอร์ใหม่ -Name cluster1 -Node sql1, sql2 -StaticAddress 10.0.0.100 -NoStorage

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

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

สร้างกลุ่มควอรัมลท์

ถ้าคุณใช้ Windows 2016 หรือ 2019 คุณจะต้องสร้าง Cloud Witness สำหรับกลุ่มควอรัม ถ้าคุณใช้งาน Windows Server 2012 R2 หรือ 2008 R2 คุณจะต้องสร้าง Share Share Witness คำแนะนำโดยละเอียดเกี่ยวกับการสร้างพยานสามารถพบได้ที่นี่

ติดตั้ง DataKeeper

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

สร้างไดรฟ์ข้อมูล DataKeeper Volume

ในการสร้าง DataKeeper Volume Resource คุณจะต้องเริ่มต้น DataKeeper UI และเชื่อมต่อกับทั้งสองเซิร์ฟเวอร์ เชื่อมต่อกับ SQL2 [/ caption] เชื่อมต่อกับ SQL1 [caption id = "attach_1746" align = "alignnone" width = "453" เมื่อคุณเชื่อมต่อกับเซิร์ฟเวอร์แต่ละเครื่องคุณพร้อมที่จะสร้าง DataKeeper Volume แล้ว คลิกขวาที่งานและเลือก "สร้างงาน" ให้ชื่องานและคำอธิบาย เลือกเซิร์ฟเวอร์ต้นทาง IP และไดรฟ์ข้อมูล ที่อยู่ IP คือการรับส่งข้อมูลการจำลองแบบจะเดินทางหรือไม่ เลือกเซิร์ฟเวอร์เป้าหมายของคุณ เลือกตัวเลือกของคุณ สำหรับจุดประสงค์ของเราที่ VM ทั้งสองอยู่ในพื้นที่ทางภูมิศาสตร์เดียวกันเราจะเลือกการจำลองแบบซิงโครนัส สำหรับการจำลองแบบระยะไกลคุณจะต้องการใช้แบบอะซิงโครนัสและเปิดใช้งานการบีบอัดบางอย่าง เมื่อคลิกใช่ที่ป๊อปอัปล่าสุดคุณจะลงทะเบียนแหล่งข้อมูลไดรฟ์ DataKeeper ใหม่ในที่จัดเก็บที่พร้อมใช้งานใน Failover Clustering คุณจะเห็นแหล่งข้อมูล Volume DataKeeper ใหม่ใน Storage ที่มีอยู่

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

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

Add-ClusterFileServerRole -Storage "DataKeeper Volume E" -Name FS2 -StaticAddress 10.0.0.101

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

สร้าง Balancer โหลดภายใน

นี่คือจุดที่ failover clustering ใน Azure แตกต่างจากโครงสร้างพื้นฐาน สแต็คเครือข่าย Azure ไม่สนับสนุน ARPS ที่ให้เปล่าดังนั้นไคลเอ็นต์ไม่สามารถเชื่อมต่อโดยตรงกับที่อยู่ IP ของคลัสเตอร์ได้ แต่ลูกค้าจะเชื่อมต่อกับ balancer โหลดภายในและเปลี่ยนเส้นทางไปยังโหนดคลัสเตอร์ที่ใช้งานอยู่ สิ่งที่เราต้องทำคือสร้าง balancer โหลดภายใน ทั้งหมดนี้สามารถทำได้ผ่าน Azure Portal ดังที่แสดงด้านล่าง คุณสามารถใช้ Public Balancer โหลดถ้าไคลเอ็นต์ของคุณเชื่อมต่อผ่านทางอินเทอร์เน็ตสาธารณะ แต่สมมติว่าลูกค้าของคุณอาศัยอยู่ใน vNet เดียวกันเราจะสร้าง Internal Balancer โหลด สิ่งสำคัญที่ต้องจดบันทึกไว้ในที่นี้ก็คือ Virtual Network จะเหมือนกับเครือข่ายที่โหนดคลัสเตอร์ของคุณอาศัยอยู่ นอกจากนี้ที่อยู่ IP ส่วนตัวที่คุณระบุจะตรงเหมือนกับที่อยู่ที่คุณใช้ในการสร้างทรัพยากรเซิร์ฟเวอร์คลัสเตอร์ของไฟล์ นอกจากนี้เนื่องจากเรากำลังใช้โซนความพร้อมใช้งานเราจะสร้างโซนโหลด Balund Load Balancer ตามที่แสดงในภาพด้านล่าง หลังจากสร้าง Internal Load Balancer (ILB) แล้วคุณจะต้องแก้ไขไฟล์ สิ่งแรกที่เราจะทำคือการเพิ่มแบ็กเอนด์พูล ผ่านขั้นตอนนี้คุณจะเลือกสองโหนดคลัสเตอร์ สิ่งต่อไปที่เราจะทำคือเพิ่ม Probe การสอบสวนที่เราเพิ่มจะโพรบ Port 59999 โพรบนี้จะกำหนดโหนดที่ใช้งานอยู่ในคลัสเตอร์ของเรา จากนั้นเราจำเป็นต้องใช้กฎการกระจายการโหลดเพื่อเปลี่ยนเส้นทางการรับส่งข้อมูล SMB พอร์ต TCP 445 สิ่งสำคัญที่ควรสังเกตในภาพหน้าจอด้านล่างคือการเปิดใช้งานการส่งคืนเซิร์ฟเวอร์โดยตรง ตรวจสอบให้แน่ใจว่าคุณได้ทำการเปลี่ยนแปลงนั้น

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

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

# กำหนดตัวแปร
$ ClusterNetworkName = "" 
# ชื่อเครือข่ายคลัสเตอร์ (ใช้ Get-ClusterNetwork ใน Windows Server 2012 ที่สูงกว่าเพื่อค้นหาชื่อ)
$ IPResourceName = "" 
# ชื่อที่อยู่ IP Address 
$ ILBIP = "" 
# ที่อยู่ IP ของ Balancer โหลดภายใน (ILB)
การนำเข้าโมดูล FailoverClusters
# หากคุณใช้ Windows Server 2012 หรือสูงกว่า:
Get-ClusterResource $ IPResourceName | Set-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

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

คุณจะพบว่าการใช้ File Share Wizard ใน Failover Cluster Manager ไม่ทำงาน แทนคุณจะสร้างแฟ้มที่ใช้ร่วมกันใน Windows Explorer บนโหนดที่ใช้งานอยู่ การแบ่งกลุ่มโดยอัตโนมัติโดยอัตโนมัติจะหยิบหุ้นเหล่านั้นขึ้นโดยอัตโนมัติและทำให้พวกเขาอยู่ในกลุ่ม โปรดทราบว่าตัวเลือก "Continuous Availability" ของไฟล์แชร์ไม่ได้รับการสนับสนุนในการกำหนดค่านี้

ข้อสรุป

ขณะนี้คุณควรมีคลัสเตอร์ Failover Cluster ของเซิร์ฟเวอร์ไฟล์ที่ทำงานอยู่ใน Azure ซึ่งครอบคลุมเขตการให้บริการ หากคุณต้องการคีย์การประเมินผลของ DataKeeper โปรดกรอกแบบฟอร์มที่ http://us.sios.com/clustersyourway/cta/14-day-trial และ SIOS จะส่งรหัสประเมินผลที่ส่งถึงคุณ