มองหาบทความทีละขั้นตอนเกี่ยวกับวิธีกำหนดค่า DHCP ในศูนย์ข้อมูลและ / หรือไม่มีที่เก็บข้อมูลที่ใช้ร่วมกันในอนาคตอันใกล้นี้โดยใช้ Windows Server Failover Clustering และ SteelEye DataKeeper Cluster Edition ในระหว่างนี้ให้ดูวิดีโอนี้ที่แสดงกลุ่ม DHCP ที่ใช้ฐานข้อมูล DHCP ที่จำลองแบบแทนดิสก์ที่ใช้ร่วมกันในคลัสเตอร์

ทำซ้ำโดยได้รับอนุญาตจาก https://clusteringformeremortals.com/2009/11/23/dhcp-cluster-without-shared-storage-andor-across-data-centers/

มีการเผยแพร่ข้อมูลเกี่ยวกับการดำเนินการโยกย้ายข้อมูลเสมือนจริงผ่านศูนย์ข้อมูลระยะไกลซึ่งสนับสนุนการสนับสนุน vMotion ในศูนย์ข้อมูลหรือ "vMotion ทางไกล" ตามที่ฉันได้เห็น รายละเอียดของโซลูชันสามารถดูได้จากเว็บไซต์ของ Cisco ที่นี่ แม้ว่าฉันคิดว่าเป็นเรื่องที่เยี่ยมยอด แต่ฉันอยากเตือนคนอื่นว่า Microsoft Hyper-V มีฟังก์ชันการทำงานเหมือนกันในปัจจุบันและมีข้อกำหนดและข้อ จำกัด น้อยกว่า vMotion ทางไกลของ VMware

ในกรณีที่ VMware มี VMwareHA, vMotion และ Site Recovery Manager (SRM) เพื่อดูแลเรื่องความพร้อมใช้งานของเครื่องเสมือน Microsoft มีฟังก์ชันการทำงานเดียวกันกับ Windows Server Failover Clustering และในความเป็นจริงแล้วในบางกรณีสามารถทำได้มากกว่าที่ VMware สามารถให้บริการได้ในแง่ของความพร้อมใช้งานของเครื่องเสมือน ฉันอธิบายไว้ในโพสต์ก่อนหน้านี้

สิ่งที่ฉันต้องการเน้นในวันนี้คือข้อเสนอของไมโครซอฟท์ในการแข่งขันเพื่อ "vMotion ทางไกล" คุณสามารถปรับใช้คลัสเตอร์ Hyper-V หลายไซต์โดยใช้ Windows Server Failover Clustering และโฮสต์หรือโซลูชันการจำลองแบบพื้นที่เก็บข้อมูลที่คุณโปรดปรานซึ่งได้รับการรับรองให้ทำงานในคลัสเตอร์ multi-site ของ Windows Server 2008 ด้วยวิธีนี้คุณสามารถใช้โครงสร้างพื้นฐานเครือข่ายที่มีอยู่และโครงสร้างพื้นฐานที่มีอยู่ของคุณเพื่อทำ Live Migrations ผ่านศูนย์ข้อมูล ตามความต้องการจริงๆเหมือนกันกับกลุ่มไซต์หลายแห่งยกเว้นฉันขอแนะนำให้คุณขยายเครือข่ายย่อยเพื่อหลีกเลี่ยงปัญหาการเชื่อมต่อไคลเอ็นต์ที่เกิดขึ้นเมื่อย้ายเครื่องเสมือนไปยังเครือข่ายย่อยใหม่เนื่องจากไคลเอ็นต์อาจแคชเก่า ที่อยู่ IP จนกว่า TTL จะหมดอายุ

วิดีโอสาธิตเกี่ยวกับการย้ายข้อมูลแบบสดผ่านศูนย์ข้อมูลโดยใช้ Windows Server 2008 R2 Hyper-V และ SteelEye DataKeeper Cluster Edition สามารถดูได้ที่นี่

ทำซ้ำโดยได้รับอนุญาตจาก https://clusteringformeremortals.com/2009/09/17/hyper-v-live-migration-across-data-centers/

สร้างการกำหนดค่าคลัสเตอร์ความพร้อมใช้งานสูง

เมื่อเราสร้างการกำหนดค่าคลัสเตอร์ความพร้อมใช้งานสูงความพร้อมใช้งานของแอปพลิเคชันของคุณจะดีเท่ากับลิงค์ที่อ่อนแอที่สุด สิ่งนี้หมายความว่าถ้าคุณซื้อเซิร์ฟเวอร์ที่ยอดเยี่ยมที่มีทุกสิ่งที่ซ้ำซ้อน (CPU, พัดลม, พลังงาน, RAID, RAM, ฯลฯ ) และ Super Deluxe SAN ที่มีการเชื่อมต่อแบบหลายเส้นทาง เมื่อรวมกับสวิตช์ SAN หลายตัวและจัดกลุ่มแอปพลิเคชันของคุณด้วยซอฟต์แวร์การจัดกลุ่มที่คุณชื่นชอบ คุณอาจมีแอปพลิเคชั่นที่น่าเชื่อถือมากใช่ไหม ก็ไม่จำเป็น เซิร์ฟเวอร์เชื่อมต่อกับ UPS เดียวกันหรือไม่ พวกเขาอยู่บนสวิตช์เครือข่ายเดียวกันหรือไม่ พวกเขาเย็นโดยหน่วย AC เดียวกันหรือไม่ พวกเขาอยู่ในอาคารเดียวกันหรือไม่ SAN ของคุณน่าเชื่อถืออย่างแท้จริงหรือไม่? หนึ่งในปัญหาเหล่านี้ในหมู่อื่น ๆ เป็นจุดหนึ่งของความล้มเหลวในการกำหนดค่าคลัสเตอร์ความพร้อมใช้งานสูง

ค้นหาและลบลิงค์ที่อ่อนแอที่สุดในการกำหนดค่าคลัสเตอร์

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

โปรดทราบว่าฉันไม่ได้พูดถึงโซลูชัน OEM iSCSI ที่สร้างขึ้นในเทคโนโลยี failover และ / หรือคุณลักษณะความพร้อมใช้งานอื่น ๆ หรือแม้แต่โซลูชันระบบจัดเก็บข้อมูลเสมือนจริงเช่น FalconStor ฉันกำลังพูดถึงคนที่มีเซิร์ฟเวอร์ที่ใช้ Windows Server 2008 ว่าเขาโหลดมาพร้อมกับพื้นที่เก็บข้อมูลและต้องการเปลี่ยนเป็นเป้าหมาย iSCSI นี่ยอดเยี่ยมในแล็บ แต่ถ้าคุณจริงจังกับฮาคุณควรคิดอีกครั้ง แม้ Microsoft จะให้ซอฟต์แวร์เป้าหมายของ iSCSI แก่ผู้สร้าง OEM ที่มีคุณสมบัติเหมาะสมที่มีประสบการณ์ในการส่งอาร์เรย์จัดเก็บข้อมูลระดับองค์กร

สิ่งที่คุณได้รับจริง

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

ซอฟต์แวร์เป้าหมายของ Enterprise Class iSCSI ประกอบด้วยซอฟต์แวร์จำลองแบบซิงโครนัสและ / หรือแบบอะซิงโครนัสและความสามารถในการทำ snapshot ฟังก์ชั่นนี้ช่วยในเรื่องของจุดกู้คืน (RPO) ของคุณอย่างแน่นอน แม้ว่ามันจะไม่ช่วยวัตถุประสงค์เวลากู้คืน (RTO) ของคุณเว้นแต่ว่าการเฟลโอเวอร์เป็นไปโดยอัตโนมัติและราบรื่นสำหรับซอฟต์แวร์การจัดกลุ่มของคุณ สมมติว่าอาร์เรย์หน่วยเก็บข้อมูลหลัก iSCSI ล้มเหลวในตอนกลางคืน ใครจะไปที่นั่นเพื่อเปิดใช้งานสำเนาที่ทำซ้ำ คุณอาจหยุดลงก่อนที่คุณจะรู้ว่ามีปัญหา อีกครั้งนี้อาจจะ "ดีพอ"; คุณเพียงแค่ต้องตระหนักถึงสิ่งที่คุณกำลังลงทะเบียน นั่นเป็น High Configuration Cluster ที่คุณต้องการหรือไม่?

SIOS DataKeeper

สิ่งหนึ่งที่คุณสามารถทำได้เพื่อปรับปรุงความน่าเชื่อถือของเซิร์ฟเวอร์เป้าหมายของ iSCSI คือการใช้ผลิตภัณฑ์จำลองแบบเช่น SteelEye DataKeeper Cluster Edition เพื่อขจัดจุดบกพร่องเพียงจุดเดียว ให้ฉันอธิบาย

หากเราใช้การกำหนดค่าเดียวกันที่แสดงด้านบนและเพิ่มเป้าหมาย iSCSI แบบสแตนด์อะโลนโดยใช้ SteelEye DataKeeper Cluster Edition เพื่อทำการจำลองแบบและการล้มเหลวอัตโนมัติคุณเพิ่งให้โซลูชัน iSCSI เป้าหมายสู่ระดับความพร้อมใช้งานทั้งหมด โซลูชันดังกล่าวจะมีลักษณะแบบนี้มาก

ความแตกต่างที่สำคัญในโซลูชันที่ใช้ SteelEye DataKeeper Cluster Edition กับโซลูชันการจำลองแบบโดยผู้ขายเป้าหมาย iSCSI บางรายอยู่ในการทำงานร่วมกับ WSFC คำถามที่ถามเกี่ยวกับผู้จำหน่ายโซลูชัน iSCSI ของคุณคือ …

จะเกิดอะไรขึ้นถ้าฉันดึงสายไฟบนเซิร์ฟเวอร์เป้าหมาย iSCSI ที่ใช้งานอยู่?

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

สนทนากับเราเพื่อให้บรรลุการกำหนดค่าคลัสเตอร์ความพร้อมใช้งานสูง

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

ผมยินดีที่จะแจ้งให้ทราบว่า Windows IT Pro ได้รับรางวัล SteelEye DataKeeper Cluster Edition ซึ่งมีความพร้อมใช้งานสูงสุดและผลิตภัณฑ์สำหรับการกู้คืนความเสียหายในสองประเภท รางวัล Community Choice Gold Award และรางวัล Silver Award ที่ดีที่สุดของบรรณาธิการ

ผมภูมิใจเป็นอย่างยิ่งที่ได้เป็นส่วนหนึ่งของทีม SteelEye DataKeeper และขอขอบคุณทุกชุมชน Windows IT Pro ที่ลงคะแนนให้เราในรางวัล Community Choice!

ทำซ้ำโดยได้รับอนุญาตจาก https://clusteringformeremortals.com/2009/11/20/steeleye-datakeeper-cluster-edition-wins-windows-it-pro-best-high-availabilitydisaster-recovery-awards/

ฉันถูกถามคำถามนี้มากกว่าสองครั้งดังนั้นฉันคิดว่าฉันจะตอบคำถามนี้ในโพสต์บล็อกฉบับแรกของฉัน  คำตอบพื้นฐานคือใช่คุณสามารถสูญเสียข้อมูลในความล้มเหลวที่ไม่คาดคิดเมื่อใช้การจำลองแบบอะซิงโครนัสในคลัสเตอร์แบบ multi-site  ในโลกที่เหมาะทุก บริษัท จะมีการเชื่อมต่อกับเครือข่ายไฟเบอร์ออฟติคัลไปยังไซต์ DR ของตนและใช้การจำลองแบบซิงโครนัสกับกลุ่มไซต์หลายแห่งเพื่อลดความเป็นไปได้ที่ข้อมูลจะสูญหาย  อย่างไรก็ตามในความเป็นจริงในหลาย ๆ กรณีการเชื่อมต่อ WAN ไปยังไซต์ DR มีความแฝงมากเกินไปเพื่อสนับสนุนการจำลองแบบซิงโครนัส  ในกรณีเช่นนี้การจำลองแบบอะซิงโครนัสเป็นทางเลือกที่ดี

มีอยู่มากกว่าสองสามตัวเลือกเมื่อเลือกโซลูชันการจำลองแบบอะซิงโครนัสเพื่อใช้กับคลัสเตอร์ multi-site WSFC ของคุณซึ่งรวมถึงโซลูชันที่ใช้อาร์เรย์จาก บริษัท ต่างๆเช่น EMC IBM HP เป็นต้น และโซลูชันจากโฮสต์เช่นเดียวกับที่ใกล้และเป็นที่รักของฉัน "SteelEye DataKeeper Cluster Edition"  ตั้งแต่ฉันรู้ดีที่สุด DataKeeper ฉันจะอธิบายวิธีการทั้งหมดนี้ทำงานจาก DataKeeper ในอนาคต

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

ขณะที่อยู่ในสถานะ "หยุดชั่วคราว" DataKeeper ช่วยให้คิว async ระบายออกไปจนกว่าเราจะมาถึง "เครื่องหมายน้ำต่ำ" เมื่อถึงจุดนี้กระจกจะเข้าสู่สถานะ "resync" จนกว่าข้อมูลทั้งหมดจะซิงค์กัน  เมื่อถึงจุดนั้นกระจกจะอยู่ในสถานะ "mirroring" อีกครั้งและระบบ failover อัตโนมัติจะเปิดใช้งานอีกครั้ง

ตราบเท่าที่ลิงก์ WAN ของคุณไม่อิ่มตัวหรือเสียคุณไม่ควรเห็นมากกว่าเขียนไม่กี่ที่เวลาใดก็ตามในคิว async นี้   ในความล้มเหลวที่ไม่คาดคิด (คิดดึงสายไฟ) คุณจะสูญเสียการเขียนใด ๆ ที่อยู่ในคิว async  นี่คือการค้าที่คุณทำเมื่อคุณต้องการเป้าหมายการกู้คืนที่น่าประทับใจ (RPO) และวัตถุประสงค์การกู้เวลา (RTO) ที่คุณได้รับจากกลุ่มไซต์หลายแห่ง แต่ลิงก์ WAN ของคุณมีความล่าช้ามากเกินไปในการสนับสนุนการจำลองแบบซิงโครนัสอย่างมีประสิทธิภาพ
ถ้าคุณใช้เวลาในการตรวจสอบคิว Async DataKeeper ผ่านทางบันทึกผลการปฏิบัติงานของ Windows และการแจ้งเตือนฉันคิดว่าคุณจะต้องประหลาดใจมากที่พบว่าเวลาส่วนใหญ่คิว async ว่างเปล่าเนื่องจากประสิทธิภาพของเครื่องมือจำลองข้อมูลของ DataKeeper  แม้ในช่วงที่มีการเขียนอย่างหนักแถว async จะโตขึ้นมากและมักระบายเกือบจะในทันทีดังนั้นจำนวนข้อมูลที่มีความเสี่ยงในเวลาใดก็ตามจึงน้อยที่สุด  เมื่อคุณพิจารณาทางเลือกในภัยพิบัติอาจจะเรียกคืนจากการสำรองข้อมูลคืนที่ผ่านมาจำนวนการเขียนที่คุณอาจสูญเสียในความล้มเหลวที่ไม่คาดคิดโดยใช้การจำลองแบบอะซิงโครนัสมีน้อย!

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

ทำซ้ำโดยได้รับอนุญาตจาก https://clusteringformeremortals.com/2009/07/