Archives

Hyper-V ผ่านผ่าน Vs ประสิทธิภาพการทำงานของดิสก์ ไฟล์ VHD ขนาดถาวรและไฟล์ VHD แบบไดนามิกใน Windows Server 2008 R2

มกราคม 21, 2018 by Jason Aw Leave a Comment

ด้วยการเปิดตัว Windows Server 2008 R2 หนึ่งในการปรับปรุงคือการปรับปรุงประสิทธิภาพของไฟล์ VHD แบบไดนามิก ก่อน R2 เขียนเพื่อขยายไฟล์ VHD แบบไดนามิกอาจเป็น 3 เท่าช้ากว่าการเขียนไปยังไฟล์ VHD ที่มีขนาดคงที่เนื่องจากมีแคชข้อมูลเมตา จำกัด โดยรวมแล้ว Microsoft อ้างประสิทธิภาพของไฟล์ VHD แบบไดนามิกเทียบกับไฟล์ VHD ที่มีขนาดคงที่แทบจะเหมือนกันดิสก์ผ่านตัวเลือกเป็นตัวเลือกอื่นเมื่อกำหนดค่า Hyper-V VM ตามผลของฉันประสิทธิภาพของดิสก์ pass-through เป็นเล็กน้อยดีกว่าของไฟล์ VHD อย่างไรก็ตามหากคุณใช้ดิสก์ pass-through คุณจะสูญเสียประโยชน์ทั้งหมดของไฟล์ VHD เช่นการพกพาการถ่ายภาพนิ่งและการจัดเตรียมบางอย่าง หากพิจารณาจากข้อผิดพลาดเหล่านี้การใช้ดิสก์ผ่านจะต้องได้รับการพิจารณาหากคุณต้องการดิสก์ที่มีขนาดใหญ่กว่า 2 TB หรือถ้าแอ็พพลิเคชันของคุณเป็น I / O bound และคุณสามารถได้รับประโยชน์จาก. 1 ms ที่โกนได้ เวลาตอบสนองโดยเฉลี่ยของคุณ

ฉันคิดแทนที่จะเอาคำของ Microsoft มาใช้ฉันจะใส่ดิสก์ประเภทอื่นเพื่อทดสอบตัวเอง ฉันจะติดตั้งเครื่องเสมือน Hyper-V Windows Server 2008 R2 ที่รันอยู่ด้านบนสุดของ Windows Server 2008 R2 สำหรับ Hypervisor ของฉันฉันใช้เซิร์ฟเวอร์ Dell PowerEdge 1950 ที่ต่อกับ Dell AX150 SAN และแกะสลัก LUN 10 GB ขนาดใหญ่สำหรับใช้ในการทดสอบของฉัน ใน Hyper-V Manager ฉันได้เพิ่มดิสก์ใหม่สามแผ่นหนึ่งแผ่นดิสก์แบบไดนามิก VHD แบบไดนามิกและ VHD ขนาดคงที่ จากนั้นผมจึงใช้ IOMeter เพื่อทดสอบประสิทธิภาพของดิสก์ พารามิเตอร์ทดสอบและข้อมูลดิบสามารถดูได้ในไฟล์ CSV นี้

แผนภูมิด้านล่างสรุปผลลัพธ์ของฉัน อย่างที่คุณเห็นในสุดขีด (สูงสุด / ต่ำสุด) ดิสก์แบบพาสทรูจะได้รับรางวัลในกรณีส่วนใหญ่ อย่างไรก็ตามโดยเฉลี่ยแล้วแทบไม่มีความแตกต่างระหว่างการแสดงผลของดิสก์ประเภทต่างๆ 3 แบบ

ประสิทธิภาพของสามประเภทดิสก์ที่แตกต่างกัน -Dynamic VHD, VHD ขนาดคงที่ Pass-Through

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

โดยสรุปผมจะพิจารณาการใช้ไฟล์ VHD แบบไดนามิกเพื่อใช้งาน Hyper-V ต่อไปใน Windows Server 2008 R2

ทำซ้ำโดยได้รับอนุญาตจาก https://clusteringformeremortals.com/2009/09/25/hyper-v-pass-through-disk-performance-vs-fixed-size-vhd-files-and-dynamic-vhd-files-in- หน้าต่างเซิร์ฟเวอร์ 2008 R2 /

สร้างตัวเลือกความพร้อมในการจำลองเสมือนจริง

มกราคม 21, 2018 by Jason Aw Leave a Comment

ตัวเลือกความพร้อมในการจำลองเสมือนคืออะไร

Microsoft Windows Server 2008 R2 และ vSphere 4.0 มีการเปิดตัวใหม่ ลองดูที่บางตัวเลือกความพร้อมในการใช้งาน Virtualization เมื่อพิจารณาถึงความพร้อมใช้งานของเซิร์ฟเวอร์เสมือนและแอ็พพลิเคชันที่ใช้งานอยู่

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

วางแผนหยุดทำงาน

การย้ายข้อมูลแบบสดและ VMotion ของ VMware เป็นโซลูชันที่ช่วยให้ผู้ดูแลระบบสามารถย้ายเครื่องเสมือนจากเซิร์ฟเวอร์กายภาพหนึ่งไปยังอีกเซิร์ฟเวอร์หนึ่งโดยไม่มีการหยุดทำงานที่สังเกตเห็นได้ มีสิ่งสำคัญอย่างหนึ่งที่ควรจดจำ การย้ายต้องเป็นเหตุการณ์ที่วางแผนไว้เพื่อที่จะย้ายเครื่องเสมือนจากเซิร์ฟเวอร์เครื่องหนึ่งไปยังอีกเครื่องหนึ่งโดยไม่มีเวลาหยุดทำงานใด ๆ เหตุการณ์ที่วางแผนไว้คือหน่วยความจำของเครื่องเสมือนถูกซิงโครไนซ์ระหว่างเซิร์ฟเวอร์ก่อนที่จะเกิด switchover เกิดขึ้นจริง นี่เป็นความจริงของโซลูชันของ Microsoft และ VMware นอกจากนี้โปรดจำไว้ว่าเทคโนโลยีทั้งสองนี้ต้องการการใช้ที่จัดเก็บข้อมูลร่วมกันเพื่อเก็บฮาร์ดดิสก์เสมือนไว้ (VMDK และ VHD files) ซึ่งจะ จำกัด Live Migration และ VMotion ให้กับเครือข่ายท้องถิ่น นอกจากนี้ยังหมายความว่าจะต้องมีการจัดการกับช่วงเวลาที่หยุดทำงานสำหรับสตอเรจสตอเรจด้วยวิธีอื่น สิ่งสำคัญที่ควรทราบถ้าคุณต้องการ จำกัด การส่งผลกระทบต่อเครื่องเสมือนของคุณ

เวลาหยุดทำงานที่ไม่ได้วางแผนไว้

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

การกู้คืนระบบ

ฉันจะกู้คืนเครื่องเสมือนของฉันในกรณีที่เกิดการสูญหายของไซต์แบบสมบูรณ์ได้อย่างไร? ข่าวดีก็คือการทำให้เวอร์ช่วลไลเซชันทำให้กระบวนการนี้ง่ายขึ้นมาก เครื่องเสมือนเป็นเพียงไฟล์ที่สามารถรับและย้ายไปยังเซิร์ฟเวอร์เครื่องอื่นได้ จนถึงจุดนี้ VMware และ Microsoft มีลักษณะคล้ายคลึงกันในคุณลักษณะและฟังก์ชันการทำงานที่พร้อมใช้งาน อย่างไรก็ตามนี่เป็นที่ที่ Microsoft ส่องจริงๆ VMware มี Site Recovery Manager ซึ่งเป็นผลิตภัณฑ์ที่ดี แต่มีข้อ จำกัด ในการสนับสนุนเฉพาะโซลูชันการจำลองแบบตามอาร์เรย์ที่ได้รับการรับรอง SRM เท่านั้น นอกจากนี้กระบวนการ failover และ failback ยังไม่ง่ายนักและสามารถใช้เวลาในการเดินทางรอบโลกได้อย่างเต็มที่ตั้งแต่ไซต์ DR ไปจนถึงศูนย์ข้อมูลหลัก มันมีคุณสมบัติที่ดีบางอย่างเช่นการทดสอบ DR จากประสบการณ์ของผมในการแก้ปัญหาสำหรับการกู้คืนระบบของ Microsoft พวกเขามีทางออกที่ดีกว่ามากในการกู้คืนระบบ

โซลูชัน Hyper-V DR ของไมโครซอฟต์

โซลูชัน Hyper-V DR ของ Microsoft คือ Windows Server Failover Clustering ในการกำหนดค่าคลัสเตอร์แบบ multi-site (ดูการสาธิตวิดีโอ) ในการกำหนดค่านี้ประสิทธิภาพและลักษณะการทำงานจะเหมือนกับคลัสเตอร์ในพื้นที่ แต่สามารถขยายศูนย์ข้อมูลได้ โดยพื้นฐานแล้วคุณสามารถย้ายเครื่องเสมือนของคุณไปทั่วศูนย์ข้อมูลได้โดยไม่มีการหยุดทำงานเล็กน้อยที่มองไม่เห็น Failback เป็นกระบวนการเดียวกันเพียงแค่ชี้และคลิกเพื่อย้ายทรัพยากรเครื่องเสมือนกลับไปที่ศูนย์ข้อมูลหลัก ไม่มี "การทดสอบ DR" ในตัว แม้ว่าฉันคิดว่าดีกว่าที่จะทำแบบทดสอบ DR ที่เกิดขึ้นจริงในเวลาเพียงไม่กี่นาทีหรือสองกับการหยุดทำงานที่มองไม่เห็น

ผู้ให้บริการการจำลองแบบโฮสต์

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

Fault Tolerance

ความทนทานของข้อบกพร่องโดยทั่วไปช่วยลดความจำเป็นในการรีบูตเครื่องเสมือนในกรณีที่เกิดความล้มเหลวที่ไม่คาดคิด VMware มีจุดเด่นอยู่ที่ VMware FT มีผู้จำหน่ายฮาร์ดแวร์และซอฟต์แวร์อื่น ๆ อีก 3 รายที่เล่นในพื้นที่นี้เช่นกัน เมื่อมีการใช้ระบบ FT มีข้อ จำกัด และข้อกำหนดมากมาย นี่คือตัวเลือกถ้าคุณต้องการให้แน่ใจว่าส่วนประกอบฮาร์ดแวร์ล้มเหลวส่งผลให้เกิดการหยุดชะงักเป็นศูนย์หรือเพียงเล็กน้อยหรือสองนาทีในการบูต VM ในการกำหนดค่า HA แบบมาตรฐาน คุณอาจต้องการตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ที่มีอยู่ของคุณมีอยู่แล้วเต็มร้อนสแตนด์บายซีพียูแรมอุปกรณ์ไฟฟ้า ฯลฯ และคุณมีเส้นทางที่ซ้ำซ้อนกับเครือข่ายและพื้นที่เก็บข้อมูล มิฉะนั้นคุณอาจจะโยนเงินที่ดีหลังจากที่ไม่ดี ความทนทานต่อข้อผิดพลาดดีเยี่ยมสำหรับการป้องกันจากความล้มเหลวของฮาร์ดแวร์ จะเกิดอะไรขึ้นถ้าแอ็พพลิเคชันหรือระบบปฏิบัติการของเครื่องเสมือนมีพฤติกรรมไม่ดี นั่นคือเมื่อคุณต้องการการจัดกลุ่มระดับแอพพลิเคชันตามที่อธิบายด้านล่าง

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

ทุกอย่างที่ฉันได้กล่าวถึงมาถึงจุดนี้จริงๆจะคำนึงถึงสุขภาพของเซิร์ฟเวอร์ทางกายภาพและเครื่องเสมือนของคุณโดยรวมเท่านั้น นี่คือทั้งหมดที่ดีและดี แต่สิ่งที่เกิดขึ้นถ้าหน้าจอสีฟ้าเครื่องเสมือนของคุณ? หรือถ้าเซอร์วิสแพ็ค SQL ล่าสุดล่มแอพพลิเคชั่นของคุณ? ในกรณีเหล่านี้ไม่มีวิธีแก้ปัญหาเหล่านี้จะช่วยให้คุณได้ผลดีสักหน่อย สำหรับแอพพลิเคชันที่สำคัญที่สุดคุณจะต้องรวมกลุ่มกันที่ชั้นแอ็พพลิเคชัน ดูโซลูชันการจัดกลุ่มที่ทำงานภายในระบบปฏิบัติการบนเครื่องเสมือนเทียบกับ hypervisor ในโลกของ Microsoft หมายถึงโซลูชันการจัดกลุ่มตาม MSCS / WSFC หรือบุคคลที่สาม ตัวเลือกการจัดเก็บข้อมูลของคุณเมื่อจัดกลุ่มภายในเครื่องเสมือนมีขอบเขต จำกัด ทั้งเป้าหมาย iSCSI หรือโซลูชันการจำลองแบบบนโฮสต์ ปัจจุบันนี้ VMware ไม่สามารถแก้ปัญหานี้ได้ จะเลื่อนไปยังโซลูชันที่ทำงานภายในเครื่องเสมือนสำหรับการตรวจสอบชั้นแอ็พพลิเคชัน

สรุป

กับการถือกำเนิดของระบบเสมือนจริงจะไม่เป็นปัญหาถ้าคุณต้องการความพร้อมใช้งาน คำถามเพิ่มเติมเกี่ยวกับ Virtualization Availability Options จะช่วยตอบสนองความต้องการของ SLA และ / หรือ DR ของคุณ ฉันหวังว่าข้อมูลนี้จะช่วยให้คุณทราบตัวเลือกความพร้อมใช้งานที่มีให้คุณ

ทำซ้ำโดยได้รับอนุญาตจาก https://clusteringformeremortals.com/2009/08/14/making-sense-of-virtualization-availability-options-2/

อ่านเรื่องราวความสำเร็จของเราเพื่อทำความเข้าใจว่า SIOS สามารถช่วยคุณได้อย่างไร

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

มกราคม 21, 2018 by Jason Aw Leave a Comment

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

เมื่อเราสร้างการกำหนดค่าคลัสเตอร์ความพร้อมใช้งานสูงความพร้อมใช้งานของแอปพลิเคชันของคุณจะดีเท่ากับลิงค์ที่อ่อนแอที่สุด สิ่งนี้หมายความว่าถ้าคุณซื้อเซิร์ฟเวอร์ที่ยอดเยี่ยมที่มีทุกสิ่งที่ซ้ำซ้อน (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 เพื่อขจัดจุดบกพร่องเพียงจุดเดียว ให้ฉันอธิบาย

การกำหนดค่าที่เก็บข้อมูลทั่วไปที่ใช้ร่วมกัน — รูปที่ 1 – การกำหนดค่าที่ใช้ร่วมกันแบบทั่วไป ในกรณีที่เป้าหมาย iSCSI ไม่พร้อมใช้งานโหนดทั้งหมดจะทำงานแบบออฟไลน์

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

DataKeeper Cluster Edition - การกำหนดค่าคลัสเตอร์ความพร้อมใช้งานสูง — รูปที่ 2 – ในสถานการณ์สมมตินี้ DataKeeper Cluster Edition กำลังจำลองไดรฟ์ข้อมูลที่แนบ iSCSI บนโหนดที่ใช้งานอยู่ไปยังไดรฟ์ข้อมูลที่แนบ iSCSI บนโหนดแบบพาสซีฟซึ่งเชื่อมต่อกับเซิร์ฟเวอร์เป้าหมาย iSCSI ที่ต่างกันทั้งหมด

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

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

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

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

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

Steeleye Datakeeper Cluster Edition คว้า Windows It Pro รางวัลความพร้อมใช้งานที่ดีที่สุดและได้รับรางวัล Disaster Recovery

มกราคม 20, 2018 by Jason Aw Leave a Comment

ผมยินดีที่จะแจ้งให้ทราบว่า 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? ไม่ใช่ข้อมูลที่ไม่ตรงกันหรือไม่?

มกราคม 18, 2018 by Jason Aw Leave a Comment

ฉันถูกถามคำถามนี้มากกว่าสองครั้งดังนั้นฉันคิดว่าฉันจะตอบคำถามนี้ในโพสต์บล็อกฉบับแรกของฉัน คำตอบพื้นฐานคือใช่คุณสามารถสูญเสียข้อมูลในความล้มเหลวที่ไม่คาดคิดเมื่อใช้การจำลองแบบอะซิงโครนัสในคลัสเตอร์แบบ 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/