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

มีนาคม 31, 2019 by Jason Aw 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

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

สมการความพร้อมใช้งาน – โซลูชั่นความพร้อมใช้งานสูง

ธันวาคม 9, 2018 by Jason Aw Leave a Comment

สมการความพร้อมใช้งาน - High Availability Solutions.jpg

สมการความพร้อมใช้งาน

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

TRESTORE = TDETECT + TRECOVER

แนวคิดหลักของโซลูชันด้านความพร้อมในการใช้งานสูง

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

การตรวจจับและการกู้คืนในเครื่อง

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

มันทำงานอย่างไร

การใช้การตรวจจับและกู้คืนในระดับท้องถิ่นโซลูชันการจัดกลุ่มขั้นสูงจะติดตั้งตัวแทนการตรวจสอบด้านสุขภาพภายในเซิร์ฟเวอร์คลัสเตอร์แต่ละเครื่องเพื่อตรวจสอบส่วนประกอบต่างๆของระบบต่างๆเช่นระบบไฟล์ฐานข้อมูลแอพพลิเคชันระดับผู้ใช้ที่อยู่ IP เป็นต้น ตัวแทนเหล่านี้ใช้ heuristics ที่เฉพาะเจาะจงกับส่วนประกอบที่ได้รับการตรวจสอบ ดังนั้นตัวแทนสามารถทำนายและตรวจพบปัญหาการดำเนินงานและดำเนินการแก้ไขปัญหาที่เหมาะสมที่สุด บ่อยครั้งวิธีการกู้คืนที่มีประสิทธิภาพที่สุดคือการหยุดและรีสตาร์ทระบบย่อยปัญหาบนเซิร์ฟเวอร์เดียวกัน เวลาในการกู้คืนแอปพลิเคชันต่อความพร้อมใช้งานของผู้ใช้จะลดลงอย่างมากโดยทำให้การกู้คืนภายในเซิร์ฟเวอร์ทางกายภาพเดียวกัน นอกจากนี้โดยการตรวจจับความล้มเหลวในระดับละเอียดมากขึ้นกว่าเพียงแค่การสังเกต heartbeats ระดับเซิร์ฟเวอร์ โซลูชันเช่น SteelEye Protection Suite สำหรับ Linux จาก SIOS ให้การตรวจจับและกู้คืนระดับนี้สำหรับสภาพแวดล้อมของคุณ  ตรวจสอบให้แน่ใจว่าโซลูชัน HA ใดที่คุณใช้สามารถใช้ในการตรวจจับและกู้คืนข้อมูลในท้องถิ่นได้ คุณต้องการที่จะเพลิดเพลินไปกับการแก้ปัญหาความพร้อมใช้งานสูงสำหรับโครงการของคุณ? เช็คอินกับเรา ต้องการข้อมูลเพิ่มเติมนี่คือเรื่องราวความสำเร็จของเรา ทำซ้ำโดยได้รับอนุญาตจาก Linuxclustering

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

เพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io

พฤศจิกายน 27, 2018 by Jason Aw Leave a Comment

เพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io

เคล็ดลับเพื่อเพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io

เมื่อคนส่วนใหญ่คิดถึงการตั้งค่าคลัสเตอร์เซิร์ฟเวอร์จะมีเซิร์ฟเวอร์มากกว่าสองเครื่องและ SAN หรือบางส่วนของที่เก็บข้อมูลที่แชร์กัน SAN มีค่าใช้จ่ายสูงมากและซับซ้อนในการติดตั้งและบำรุงรักษา นอกจากนี้ยังแสดงให้เห็นถึงเทคนิคที่เป็นไปได้ในจุดเดียวของความล้มเหลว (SPOF) ในสถาปัตยกรรมคลัสเตอร์ของคุณ ทุกวันนี้ผู้คนจำนวนมากหันไปหา บริษัท อย่าง Fusion-io พร้อมด้วย ioDrives ที่เร็วที่สุดเพื่อเร่งการใช้งานที่สำคัญ  อุปกรณ์จัดเก็บข้อมูลเหล่านี้นั่งอยู่ภายในเซิร์ฟเวอร์ (เช่นไม่ใช่ "ดิสก์ที่ใช้ร่วมกัน") ดังนั้นจึงไม่สามารถใช้เป็นดิสก์คลัสเตอร์กับโซลูชันการจัดกลุ่มแบบเดิม ๆ ได้ โชคดีที่มีวิธีเพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io โซลูชันที่ช่วยให้คุณสามารถสร้างคลัสเตอร์ failover ได้เมื่อไม่มีที่เก็บข้อมูลที่ใช้ร่วมกันนั่นคือกลุ่ม "ไม่มีการแชร์อะไร"

กลุ่มแบบดั้งเดิม เพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io - Cluster แบบดั้งเดิม  กลุ่ม "Shared Nothing"เพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io - Shared Cluster

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

เครือข่าย

  • ใช้ 10Gbps NIC: อุปกรณ์จัดเก็บข้อมูลแบบ Flash จาก Fusion-io (หรือผลิตภัณฑ์อื่นที่คล้ายคลึงกันจาก OCZ, LSI และอื่น ๆ ) สามารถเขียนข้อมูลด้วยความเร็วใน HUNDREDS (750) MB / วินาทีหรือมากกว่า  NIC ขนาด 1Gbps สามารถดันสูงสุดได้ถึง 125 เมกะไบต์ต่อวินาทีดังนั้นทุกคนที่ใช้ประโยชน์จากศักยภาพของ ioDrive สามารถเขียนข้อมูลได้เร็วกว่าที่จะถูกผลักผ่านการเชื่อมต่อเครือข่าย 1 Gbps  เพื่อให้แน่ใจว่าคุณมีแบนด์วิธที่เพียงพอระหว่างเซิร์ฟเวอร์เพื่ออำนวยความสะดวกในการจำลองแบบข้อมูลแบบเรียลไทม์ควรใช้ NIC ขนาด 10 Gbps เพื่อรับข้อมูลการจำลองแบบ
  • เปิดใช้งานกรอบ Jumbo: สมมติว่าการ์ดเครือข่ายและสวิทช์ของคุณสนับสนุนการเปิดใช้งานเฟรม jumbo สามารถเพิ่มประสิทธิภาพการทำงานของเครือข่ายของคุณได้มากขึ้นในขณะเดียวกันก็ลดรอบการทำงานของ CPU  หากต้องการเปิดใช้งานเฟรม jumbo ให้ใช้การกำหนดค่าต่อไปนี้ (ตัวอย่างจากเซิร์ฟเวอร์ RedHat / CentOS / OEL linux)
    • ifconfig <interface_name> mtu 9000
    • แก้ไขไฟล์ / etc / sysconfig / network-scripts / ifcfg- <interface_name> และเพิ่ม "MTU = 9000" เพื่อให้การเปลี่ยนแปลงยังคงอยู่ในการเริ่มต้นใหม่
    • เมื่อต้องการตรวจสอบการดำเนินการของกรอบ jumbo แบบ end-to-end ให้เรียกใช้คำสั่งนี้: ping -s 8900 -M do <IP-of-other-server>
  • เปลี่ยนความยาวคิวส่งของ NIC:
    • / sbin / ifconfig <interface_name> txqueuelen 10000
    • เพิ่มข้อมูลนี้ใน /etc/rc.local เพื่อรักษาการตั้งค่าข้ามการเริ่มระบบใหม่

TCP / IP Tuning

  • เปลี่ยน netdev_max_backlog ของ NIC:
    • ตั้งค่า "net.core.netdev_max_backlog = 100000" ใน /etc/sysctl.conf
  • การปรับแต่ง TCP / IP อื่น ๆ ที่ได้รับการแสดงเพื่อเพิ่มประสิทธิภาพการจำลองแบบ:
    • หมายเหตุ: เป็นค่าตัวอย่างและอาจจำเป็นต้องปรับเปลี่ยนตามการกำหนดค่าฮาร์ดแวร์ของคุณ
    • แก้ไข /etc/sysctl.conf และเพิ่มพารามิเตอร์ต่อไปนี้:
      • net.core.rmem_default = 16777216
      • net.core.wmem_default = 16777216
      • net.core.rmem_max = 16777216
      • net.core.wmem_max = 16777216
      • net.ipv4.tcp_rmem = 4096 87380 16777216
      • net.ipv4.tcp_wmem = 4096 65536 16777216
      • net.ipv4.tcp_timestamps = 0
      • net.ipv4.tcp_sack = 0
      • net.core.optmem_max = 16777216
      • net.ipv4.tcp_congestion_control = HTCP

การปรับ

โดยปกติคุณจะต้องปรับเปลี่ยนการกำหนดค่าคลัสเตอร์ของคุณซึ่งจะแตกต่างกันไปขึ้นอยู่กับเทคโนโลยีการจัดกลุ่มและจำลองข้อมูลที่คุณตัดสินใจใช้  ในตัวอย่างนี้ฉันใช้ SteelEye Protection Suite สำหรับ Linux (SPS หรือ aka LifeKeeper) จาก SIOS Technologies จะช่วยให้ผู้ใช้สามารถสร้างกลุ่ม failover ที่ใช้ประโยชน์จากประเภทจัดเก็บข้อมูลแบบแบ็คเอนด์: Fibre Channel SAN, iSCSI, NAS หรือส่วนใหญ่ที่เกี่ยวข้องกับบทความนี้ดิสก์ในเครื่องที่ต้องมีการซิงโครไนซ์ / จำลองแบบเรียลไทม์ระหว่างโหนดคลัสเตอร์  SPS for Linux รวมถึงฟังก์ชันการทำสำเนาข้อมูลระดับบล็อคที่ทำให้การติดตั้งคลัสเตอร์เป็นเรื่องง่ายเมื่อไม่มีที่เก็บข้อมูลที่ใช้ร่วมกัน

ข้อเสนอแนะ

เพื่อเพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io ให้มากที่สุดลองใช้วิธีนี้ SteelEye Protection Suite (SPS) สำหรับคำแนะนำการกำหนดค่า Linux:

  • จัดสรรพาร์ติชันดิสก์ขนาดเล็ก (~ 100 MB) ที่อยู่ในไดรฟ์ Fusion-io เพื่อวางไฟล์บิตแมป  สร้างระบบแฟ้มบนพาร์ติชันนี้และติดตั้งตัวอย่างเช่นที่ / bitmap:
    • # mount | grep / bitmap
    • / dev / fioa1 on / ประเภทบิตแมป ext3 (rw)
  • ก่อนที่จะสร้างกระจกของคุณปรับพารามิเตอร์ต่อไปนี้ใน / etc / default / LifeKeeper
    • แทรก: LKDR_CHUNK_SIZE = 4096
      • ค่าดีฟอลต์คือ 64
    • แก้ไข: LKDR_SPEED_LIMIT = 1500000
      • (ค่าเริ่มต้นคือ 50000)
      • LKDR_SPEED_LIMIT ระบุแบนด์วิดท์สูงสุดที่ resync จะใช้เวลา – ควรตั้งค่าสูงพอที่จะทำให้ resyncs ไปที่ความเร็วสูงสุดเท่าที่จะเป็นไปได้
    • แก้ไข: LKDR_SPEED_LIMIT_MIN = 200000
      • (ค่าดีฟอลต์คือ 20000)
      • LKDR_SPEED_LIMIT_MIN ระบุความเร็วที่ควรจะได้รับอนุญาตให้ทำซ้ำเมื่อมี I / O อื่น ๆ เกิดขึ้นพร้อม ๆ กัน – ตามกฎของหัวแม่มือนี้ควรตั้งค่าให้เขียนได้ไม่เกินครึ่งหรือน้อยกว่าเพื่อหลีกเลี่ยงความอดอยาก ออกกิจกรรม I / O ตามปกติเมื่อเกิดการ resync

จากนี้ไปข้างหน้าและสร้างกระจกเงาของคุณและกำหนดค่าคลัสเตอร์ตามปกติ สนใจที่จะเพิ่มประสิทธิภาพการจำลองแบบสูงสุดสำหรับการทำคลัสเตอร์ Linux ด้วย Fusion-io ดูว่า SIOS สามารถให้อะไรได้อีก ทำซ้ำโดยได้รับอนุญาตจาก LinuxClustering

Filed Under: Datakeeper, ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: Fusion-io, การทำซ้ำ, ลินุกซ์, เพิ่มประสิทธิภาพการจำลองแบบสำหรับการจัดกลุ่ม linux ด้วย io แบบฟิวชั่น

ฉันสามารถนำพยานร่วมแบ่งปันไฟล์ของฉันเข้าร่วม DFS ได้หรือไม่?

ตุลาคม 22, 2018 by Jason Aw Leave a Comment

ฉันสามารถนำพยานร่วมแบ่งปันไฟล์ของฉันเข้าร่วม DFS ได้หรือไม่?

ฉันสามารถนำพยานร่วมแบ่งปันไฟล์ของฉันเข้าร่วม DFS ได้หรือไม่?

ฉันได้รับคำถามนี้ตลอดเวลา – เพียงที่สามารถใส่พยานร่วมกันแฟ้มของฉันในหุ้น DFS คนกังวลเกี่ยวกับการสูญเสียพยานร่วมกันของไฟล์ ดังนั้นเหมือนหลายหุ้นอื่น ๆ ของพวกเขาที่พวกเขาต้องการที่จะยกระดับ DFS สำหรับว่างเพิ่มเติมบางอย่าง นี่เป็นแนวคิดที่ไม่ดีและไม่ได้รับการสนับสนุน Microsoft ได้เผยแพร่บทความเกี่ยวกับบล็อกที่ยอดเยี่ยมซึ่งอธิบายว่าทำไม Share Share Share On Share DFS Share ไม่ได้รับการสนับสนุน https://blogs.msdn.microsoft.com/clustering/2018/04/13/failover-cluster-file-share-witness-and-dfs/ ส่วนมากของบทความนี้จะใช้กับคนที่ถามว่าสามารถใช้ DataKeeper จำลองทรัพยากรแบบไดรฟ์เป็น Disk Share มันสมเหตุสมผล คุณสามารถใช้ทรัพยากรไดรฟ์ข้อมูลของ DataKeeper แทนที่ดิสก์ Physical Disk สำหรับเวิร์กโหลดอื่น ๆ ได้ดังนั้นทำไมไม่ใช้ Disk Witness? ปัญหานี้เหมือนกับปัญหา DFS ในกรณีที่การสื่อสารสูญหายระหว่างเซิร์ฟเวอร์ทั้งสองเซิร์ฟเวอร์ไม่มีอะไรที่จะรับประกันได้ว่าไดรฟ์ข้อมูลจะไม่มาแบบออนไลน์บนเซิร์ฟเวอร์ทั้งสองเครื่อง อาจส่งผลให้เกิดภาวะสมองแตกได้ ทรัพยากร Physical Disk จะข้ามปัญหานี้โดยใช้การจอง SCSI เพื่อให้มั่นใจว่าดิสก์สามารถเข้าถึงได้โดยโหนดหนึ่งโหนดเท่านั้น ข่าวดีก็คือ Microsoft ได้บล็อกคุณจากการพยายามใช้ทรัพยากร DataKeeper Volume ที่จำลองแบบแล้ว และมาใน Windows Server 2019 ดูเหมือนว่าจะขัดขวางคุณจากการใช้ส่วนแบ่ง DFS เป็น Share Share Witness

"Failover Clustering และ Netwoฉันสามารถนำพยานร่วมแบ่งปันไฟล์ของฉันเข้าร่วม DFS ได้หรือไม่?rk Load Balancing Team โพสต์บล็อก" Failover Cluster File Share Witness และ DFS

มีคำถามเช่นนี้เกี่ยวกับการใส่ Share Share Share Share on ShareDFS Share? อ่านบล็อกของเราหรือติดต่อเรา! ทำซ้ำโดยได้รับอนุญาตจาก ClusteringForMereMortals.com

Filed Under: Datakeeper, ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: แชร์ DFS, แชร์ไฟล์บน dfs share, แชร์ไฟล์พยาน

S2D สำหรับ SQL Server Failover Cluster Instances 

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

พื้นที่จัดเก็บข้อมูลโดยตรง (S2D) สำหรับอินสแตนซ์คลัสเตอร์ของ SQL Server Failover Cluster

พื้นที่เก็บข้อมูลโดยตรงสำหรับ SQL Server Failover Cluster Instances

ด้วยการนำเสนอ Windows Server 2016 Datacenter Edition คุณลักษณะใหม่ที่เรียกว่า Storage Spaces Direct (S2D) ในระดับที่สูงมาก S2D สำหรับอินสแตนซ์คลัสเตอร์ล้มเหลวของ SQL Server ช่วยให้คุณสามารถรวมแอ็ตทริบิวต์ที่เก็บอยู่ในระบบและนำเสนอไปยังคลัสเตอร์เป็น CSV เพื่อใช้ใน Scale Out File Server จากนั้นจะสามารถเข้าถึงได้ผ่าน SMB 3 และใช้เพื่อเก็บข้อมูลคลัสเตอร์เช่นไฟล์ Hyper-V VMDK นอกจากนี้ยังสามารถกำหนดค่าในรูปแบบ Hyper-converged (HCI) เพื่อให้แอ็พพลิเคชันและข้อมูลสามารถทำงานได้บนชุดเซิร์ฟเวอร์เดียวกัน  นี่เป็นคำอธิบายง่ายกว่าที่เข้าใจง่าย แต่สำหรับรายละเอียดคุณจะต้องการดูที่นี่

พื้นที่เก็บข้อมูลกองโดยตรง ภาพที่ถ่ายจาก https://docs.microsoft.com/th-th/windows-server/storage/storage-spaces/storage-spaces-direct-overview กรณีการใช้งานหลักที่กำหนดเป้าหมายเป็นโครงสร้างพื้นฐานแบบ hyper-converged สำหรับการใช้งาน Hyper-V อย่างไรก็ตามมีกรณีการใช้งานอื่น ๆ รวมถึงการใช้ประโยชน์จากพื้นที่จัดเก็บ SMB นี้เพื่อจัดเก็บข้อมูล SQL Server เพื่อใช้ในอินสแตนซ์ของคลัสเตอร์ล้มเหลวของ SQL Server

ทำไมทุกคนต้องการทำอย่างนั้น?

ดีสำหรับตอนเริ่มต้นคุณสามารถสร้าง SQL Server Failover Cluster Instance (2) โหนด SQL Server Edition (FCI) พร้อม SQL Server Standard Edition ได้โดยไม่ต้องใช้ที่เก็บข้อมูลที่ใช้ร่วมกัน ก่อนหน้านี้ถ้าคุณต้องการ HA โดยไม่ใช้ SAN คุณจะได้รับสิทธิซื้อ SQL Server Enterprise Edition และใช้ Always On Availability Groups หรือซื้อ SIOS DataKeeper และใช้โซลูชันของ บริษัท อื่นซึ่งช่วยให้คุณสามารถสร้างกลุ่ม SANless กับ Windows หรือ Windows รุ่นใดก็ได้ SQL Server SQL Server Enterprise Edition สามารถขับค่าใช้จ่ายของโครงการของคุณได้โดยเฉพาะอย่างยิ่งหากคุณซื้อเฉพาะสำหรับคุณลักษณะกลุ่มการมีส่วนร่วมเท่านั้น นอกเหนือจากค่าใช้จ่ายที่เกี่ยวข้องกับกลุ่มความพร้อมใช้แล้วมีสาเหตุทางเทคนิคอื่น ๆ อีกหลายประการที่ทำให้คุณอาจต้องการ Failover Cluster ผ่าน AG ความเข้ากันได้ของแอ็พพลิเคชันเช่นกับการป้องกันระดับฐานข้อมูลฐานข้อมูลจำนวนมากการสนับสนุน DTC พนักงานที่ผ่านการฝึกอบรม ฯลฯ เป็นเพียงเหตุผลทางเทคนิคบางประการที่คุณอาจต้องการติดตั้ง Failover Cluster Instance

โซลูชัน DataScheeper ของ SIOS กับ S2D สำหรับอินสแตนซ์คลัสเตอร์ล้มเหลวของ SQL Server 

Microsoft แสดงทั้งโซลูชัน SIOS DataKeeper และโซลูชัน S2D เป็นสองโซลูชันที่สนับสนุนสำหรับ SQL Server FCI ในเอกสารของตนที่นี่ S2D สำหรับ SQL Server Failover Cluster Instances  https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-high-availability-dr เมื่อเปรียบเทียบสองโซลูชันนี้คุณต้องคำนึงถึงว่า SIOS ได้อนุญาตให้คุณสร้าง SANless Clusters ตั้งแต่ปี 2542 แต่ S2D สำหรับ SQL Server Failover Cluster Instances ยังอยู่ในวัยเด็ก  มีกล่าวว่ามีขอบเขตเป็นบางพื้นที่ที่ S2D มีบาง catching ถึงทำ. หรือเพียงแค่คุณลักษณะที่พวกเขาไม่เคยสนับสนุนเพียงเพราะข้อ จำกัด ของเทคโนโลยี

ก่อนที่จะเลือกโซลูชันคลัสเตอร์ SANless ของคุณ

ดูตารางต่อไปนี้เพื่อดูภาพรวมของสิ่งที่คุณควรพิจารณาก่อนที่คุณจะเลือกโซลูชันคลัสเตอร์ SANless ของคุณ S2D สำหรับ SQL Server Failover Cluster Instances  ถ้าเราดูกราฟนี้เราจะเห็นว่า SIOS DataKeeper มีข้อได้เปรียบที่สำคัญอย่างชัดเจน สำหรับหนึ่ง DataKeeper สนับสนุนช่วงกว้างมากของแพลตฟอร์มไปตลอดทางกลับไปที่ Windows Server 2008 R2 และ SQL Server 2008 R2 โซลูชัน S2D รองรับเฉพาะรุ่นล่าสุดของ Windows และ SQL Server 2016/2017 เท่านั้น นอกจากนี้ S2D ยังต้องการ Windows Datacenter Edition ซึ่งจะช่วยเพิ่มค่าใช้จ่ายในการติดตั้งของคุณได้เป็นอย่างมาก นอกจากนี้ SIOS ยังให้บริการโซลูชัน HA / DR สำหรับ SQL Server บน Linux ที่ใช้งานได้ทั้งบน prem และในระบบคลาวด์

การวิเคราะห์ความแตกต่าง

แต่นอกเหนือจากข้อ จำกัด ด้านค่าใช้จ่ายและแพลตฟอร์มฉันคิดว่าช่องว่างที่แจ่มชัดที่สุดเกิดขึ้นเมื่อเราเริ่มพิจารณาตัวเลือกการกู้คืนระบบสำหรับกลุ่ม SANless ของคุณ Allan Hirt, guru กลุ่ม SQL Server และเพื่อน Microsoft Cloud และ Datacenter Management MVP โพสต์เมื่อเร็ว ๆ นี้เกี่ยวกับข้อ จำกัด S2D นี้ ในบทความของเขา Revisiting Storage Space ตรงและ SQL Server FCIs Allan ชี้ให้เห็นว่าเนื่องจากการขาดการสนับสนุนสำหรับการยืดกลุ่ม S2D ข้ามไซต์หรือรวมกลุ่มที่ใช้ S2D เป็นส่วนหนึ่งของ Always On Availability Group ตัวเลือกที่ดีที่สุดสำหรับ DR ใน สถานการณ์ S2D เป็น log shipping! อย่าทำให้ฉันผิด การจัดส่งบันทึกได้รับรอบตลอดไปและอาจจะเป็นรอบนานหลังจากที่ฉันไป แต่นั่นก็เป็นก้าวที่ยิ่งใหญ่เมื่อเราคิดถึงโซลูชันการกู้คืนระบบทั้งหมดที่เราคุ้นเคยเช่นกลุ่มไซต์หลายแห่งกลุ่มความพร้อมใช้งาน ฯลฯ ตรงกันข้ามโซลูชั่น SIOS DataKeeper รองรับ Always On Availability Groups ยังดีกว่า – สามารถช่วยให้คุณสามารถยืด FCI ข้ามไซต์เพื่อให้ได้โซลูชัน HA / DR ที่ดีที่สุดที่คุณอาจหวังว่าจะบรรลุในแง่ของ RTO / RPO ในสภาพแวดล้อม Azure DataKeeper ยังสนับสนุน Azure Site Recovery (ASR) ทำให้คุณมีทางเลือกมากขึ้นในการกู้คืนระบบ ส่วนที่เหลือของแผนภูมินี้เป็นคำอธิบายที่น่าสนใจ โดยทั่วไปจะประกอบด้วยฮาร์ดแวร์รายการความต้องการในการเก็บข้อมูลและระบบเครือข่ายที่ต้องได้รับก่อนที่คุณจะสามารถใช้งานกลุ่ม S2D ได้ มีการเก็บรักษารายการข้อกำหนด S2D อย่างละเอียดไว้ที่นี่  https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-hardware-requirements

SIatus Datakeeper อะไรดี

โซลูชั่น SIOS DataKeeper มีมากขึ้นผ่อนปรน สนับสนุนการจัดเก็บข้อมูลที่แนบมาภายในเครื่องและตราบเท่าที่ฮาร์ดแวร์ผ่านการตรวจสอบคลัสเตอร์เป็นการกำหนดค่าคลัสเตอร์ที่สนับสนุน โซลูชันการจำลองแบบระดับบล็อกทำงานได้ดีตั้งแต่ 1 Gbps ถือว่าเป็น LAN ที่รวดเร็วและการเชื่อมต่อ T1 WAN ถือเป็นความหรูหรา การจัดกลุ่มแบบไม่ใช้ SAN เป็นสิ่งที่น่าสนใจอย่างยิ่งสำหรับการใช้งานระบบคลาวด์ ระบบคลาวด์ไม่ได้เสนอทางเลือกในการจัดเก็บข้อมูลแบบเดิมสำหรับกลุ่ม ดังนั้นสำหรับผู้ใช้ที่อยู่ตรงกลางของ "ยกและเปลี่ยน" ไปยังคลาวด์ที่ต้องการนำกลุ่มของพวกเขาเข้ากับพวกเขาพวกเขาต้องมองหาโซลูชันการจัดเก็บสำรอง สำหรับการใช้งานระบบคลาวด์ SIOS ได้รับการรับรองสำหรับ Azure, AWS และ Google และพร้อมให้บริการในตลาดคลาวด์ที่เกี่ยวข้อง แม้ว่าจะไม่มีอะไรที่ขัดขวางการใช้งานกลุ่มที่ใช้ S2D ใน Azure หรือ Google แต่ก็มีข้อบกพร่องที่ชัดเจนในเอกสารเกี่ยวกับเอกสารหรือคำชี้แจงสนับสนุนจาก Microsoft สำหรับแพลตฟอร์มเหล่านั้น

สร้างทางเลือกที่ปลอดภัย

SIOS DataKeeper ทำเช่นนี้ตั้งแต่ปี 2542 SIOS ได้ฟังคำขอคุณลักษณะทั้งหมดเปิดเผยข้อบกพร่องทั้งหมดและมีโซลูชันแบบ solid solid สำหรับกลุ่ม SANless ที่ผ่านการทดสอบและพิสูจน์แล้ว ในขณะที่ Microsoft S2D เป็นเทคโนโลยีที่มีแนวโน้มว่าจะเป็นผลิตภัณฑ์รุ่นที่ 1 ฉันจะรอจนกว่าฝุ่นจะตกลงและช่องว่างบางช่องว่างจะปิดก่อนที่ฉันจะพิจารณาการใช้งานที่สำคัญทางธุรกิจของฉัน

หากต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับ S2D สำหรับ SQL Server Failover Cluster Instances โปรดดูที่นี่ SIOS DataKeeper ทำซ้ำโดยได้รับอนุญาตจาก Clusteringformeremortals.com

Filed Under: Datakeeper, ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: s2d สำหรับอินสแตนซ์ของคลัสเตอร์ failover เซิร์ฟเวอร์ sql, SIOS, SQL Server Failover Cluster

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • …
  • 8
  • Next Page »

โพสต์ล่าสุด

  • การสืบทอด DataKeeper
  • ความพร้อมใช้งานสูง (High Availability) กับการทนต่อความผิดพลาด (Fault Tolerance): ความแตกต่างที่สำคัญ อธิบายไว้แล้ว
  • 業務連續性計劃,以實現高可用性和災難復原
  • 3 ข้อผิดพลาดในการกำหนดค่าทั่วไปที่ทำให้คลัสเตอร์ล่ม
  • คู่มือ: การติดตั้งใช้งาน SQL Server FCI แบบหลายโซนและหลายภูมิภาคใน Azure

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

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

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