กุมภาพันธ์ 13, 2024 |
ความท้าทายของการใช้ Amazon EBS Multi-Attach สำหรับคลัสเตอร์ Failover ของ Microsoftความท้าทายของการใช้ Amazon EBS Multi-Attach สำหรับคลัสเตอร์ Failover ของ Microsoftภาพรวมของคลัสเตอร์ Amazon EBS และ Microsoft Failoverวอลุ่ม Amazon EBS Multi-Attach และ Microsoftคลัสเตอร์ล้มเหลวเป็นเครื่องมืออันทรงพลังในโลกของการประมวลผลแบบคลาวด์และการจัดการข้อมูล อย่างไรก็ตาม การบูรณาการเทคโนโลยีทั้งสองนี้อาจเต็มไปด้วยความท้าทาย โพสต์บนบล็อกนี้จะเจาะลึกว่าทำไมการใช้ Amazon EBS Multi-Attach สำหรับ Microsoft Failover Clusters จึงมักไม่ใช่ตัวเลือกที่ดีที่สุด ข้อจำกัด AZ เดียวสำหรับคลัสเตอร์ Failover ที่แข็งแกร่งข้อจำกัดที่สำคัญของไดรฟ์ข้อมูล Amazon EBS คือการจำกัดให้อยู่ใน Availability Zone (AZ) เดียว สำหรับคลัสเตอร์เฟลโอเวอร์ที่มีประสิทธิภาพ การปรับใช้อินสแตนซ์ในหลาย AZ ถือเป็นแนวปฏิบัติที่ดีที่สุดที่แนะนำ ซึ่งเป็นสิ่งที่วอลุ่ม EBS ไม่สามารถรองรับได้โดยตรง ข้อกังวล SLA ความพร้อมใช้งานสูงในขณะที่ปริมาณ EBS มีSLA ความพร้อมใช้งาน 99.9%ซึ่งต่ำกว่าที่คาดไว้โดยทั่วไปสำหรับโซลูชันที่มีความพร้อมใช้งานสูงถึง 99.99% AWS รับประกัน SLA ที่สูงขึ้นนี้เมื่อปรับใช้อินสแตนซ์ในหลาย AZ ซึ่งสิทธิประโยชน์จะไม่ขยายไปถึงการปรับใช้ AZ เดียว ผลกระทบด้านต้นทุนของปริมาณ IO2คลัสเตอร์ Windows Failover ที่มีไดรฟ์ข้อมูล EBS แบบหลายไฟล์แนบจำเป็นต้องใช้ไดรฟ์ข้อมูล IO2 ซึ่งมีราคาแพงกว่าไดรฟ์ข้อมูล GP3 ที่มีขนาดและประสิทธิภาพใกล้เคียงกันประมาณเก้าเท่า ความแตกต่างของต้นทุนนี้มีความสำคัญ โดยเฉพาะอย่างยิ่งสำหรับการใช้งานขนาดใหญ่ ความซับซ้อนในการกำหนดค่าคลัสเตอร์ AWSอาคารคลัสเตอร์ใน AWSด้วยโหนดใน AZ เดียวกันจำเป็นต้องแบ่ง AZ ออกเป็นหลายเครือข่ายย่อยเพื่อรองรับที่อยู่ IP เสมือน (VIP) ที่แตกต่างกันในคลัสเตอร์ Windows ความซับซ้อนนี้ควบคู่ไปกับการไม่สามารถแชร์ VIP เดียวข้ามโหนดคลัสเตอร์ได้ ทำให้เกิดความท้าทายในการกำหนดค่า SIOS DataKeeper: ทางเลือกที่เหนือกว่าโปรแกรมรักษาข้อมูล SIOSกลายเป็นโซลูชันที่เหนือกว่า ช่วยให้คลัสเตอร์ขยายเครือข่ายย่อยในขณะที่มี SLA ความพร้อมใช้งาน 99.99% ที่ต้องการ ไม่เพียงแต่ให้ตัวเลือกการจัดเก็บข้อมูลที่ยืดหยุ่นมากขึ้น รวมถึงการใช้ดิสก์ GPT3 เท่านั้น แต่ยังคุ้มค่ากว่ามากอีกด้วย คลัสเตอร์ที่ใช้ SIOS DataKeeper พร้อมดิสก์ GPT3 สามารถมีราคาประมาณ 20% ของต้นทุนของคลัสเตอร์ที่ใช้ IO2 ที่คล้ายกัน พร้อมความพร้อมใช้งานที่ได้รับการปรับปรุง ความพร้อมใช้งานสูงที่เหนือกว่าด้วย SIOSการใช้ไดรฟ์ข้อมูล Amazon EBS Multi-Attach ใน Microsoft Failover Clusters ทำให้เกิดความท้าทายที่สำคัญหลายประการ ตั้งแต่ตัวเลือกการปรับใช้ AZ ที่จำกัดและ SLA ความพร้อมใช้งานที่ลดลง ไปจนถึงต้นทุนที่สูงขึ้นและความซับซ้อนในการกำหนดค่าที่เพิ่มขึ้น SIOS DataKeeper นำเสนอทางเลือกที่น่าสนใจ โดยรักษาสมดุลระหว่างต้นทุน ความยืดหยุ่น และความน่าเชื่อถือได้อย่างมีประสิทธิภาพมากขึ้น สำหรับองค์กรที่มองหาความพร้อมใช้งานสูงและคุ้มค่าคุ้มราคา การสำรวจตัวเลือกต่างๆ นอกเหนือจาก EBS Multi-Attach ถือเป็นกลยุทธ์ที่รอบคอบติดต่อ SIOSสำหรับข้อมูลเพิ่มเติม. ทำซ้ำโดยได้รับอนุญาตจากSIOS |
กุมภาพันธ์ 5, 2024 |
วิดีโอ: ความพร้อมใช้งานสูงของแอปพลิเคชันจะกลายเป็นสากล | การคาดการณ์จากเทคโนโลยี SIOSวิดีโอ: ความพร้อมใช้งานสูงของแอปพลิเคชันจะกลายเป็นสากล | การคาดการณ์จากเทคโนโลยี SIOSSIOS Technology คือบริษัทโซลูชันความพร้อมใช้งานสูง (HA) และการกู้คืนระบบ (DR) ที่ให้บริการความพร้อมใช้งานของแอปพลิเคชันสำหรับฐานข้อมูล แอปพลิเคชัน และบริการที่มีความสำคัญต่อภารกิจที่สำคัญสำหรับลูกค้าทั่วทั้งระบบ Windows และ Linux และแพลตฟอร์มคลาวด์ที่หลากหลายแคสเซียส รูรองประธานฝ่ายประสบการณ์ลูกค้าที่ SIOS Technology แบ่งปันการคาดการณ์ในปี 2024 ของเขา เนื่องจากการพึ่งพาแอปพลิเคชันยังคงเพิ่มขึ้นอย่างต่อเนื่อง จะมีแรงกดดันเพิ่มขึ้นต่อทีมไอทีในการส่งมอบความพร้อมใช้งานสูงและการกู้คืนระบบที่มีประสิทธิภาพสำหรับแอปพลิเคชันที่แต่ก่อนถือว่าไม่จำเป็น นอกเหนือจากแอปพลิเคชันที่มีความสำคัญต่อภารกิจ เนื่องจากการเปลี่ยนแปลงนี้ เราน่าจะเห็นการขยายตัวของโซลูชันซอฟต์แวร์และบริการที่มีความพร้อมใช้งานสูงเพื่อตอบสนองความคาดหวังนี้ เนื่องจากมีบริษัทต่างๆ ขยายไปสู่ระบบคลาวด์และระบบปฏิบัติการที่แตกต่างกันมากขึ้น จึงคาดว่าทีมงานจะครอบคลุมชุดระบบปฏิบัติการ แอปพลิเคชัน และแพลตฟอร์มคลาวด์ที่หลากหลายมากขึ้น ทีมงานจะมองหาแอปพลิเคชันและโซลูชันที่สอดคล้องกันในระบบปฏิบัติการและสภาพแวดล้อมคลาวด์ที่แตกต่างกันเหล่านี้ เพื่อลดความซับซ้อนและปรับปรุงประสิทธิภาพด้านต้นทุน โซลูชัน HA จะต้องสอดคล้องกันทั้งระบบปฏิบัติการและสภาพแวดล้อมคลาวด์ และเราจะเห็นการขับเคลื่อนไปสู่ HA ที่ไม่เชื่อเรื่องพระเจ้าบนคลาวด์ บริษัทต่างๆ ต้องการโซลูชัน HA และ DR ที่เรียบง่าย อัตโนมัติ รวดเร็ว และชาญฉลาด เนื่องจากองค์กรต่างๆ จำนวนมากย้ายไปยังระบบคลาวด์ พวกเขาจะต้องแน่ใจว่าข้อมูลจะไม่สูญหายไปในกระบวนการนี้ โซลูชัน HA จะต้องเชื่อมช่องว่างระหว่างระบบเก่ากับระบบที่ทันสมัยกว่า ปี 2024 จะเห็นการมุ่งเน้นที่เพิ่มขึ้นในการเก็บรักษาข้อมูล การควบคุมการเข้าถึงความปลอดภัย และการอนุญาต กระตุ้นให้องค์กรต่างๆ รวมมาตรการรักษาความปลอดภัยที่ได้รับการปรับปรุงมากขึ้นเข้ากับโซลูชัน บริการ และกลยุทธ์การกู้คืนความเสียหายและมีความพร้อมใช้งานสูง เนื่องจากปริมาณข้อมูลที่ถูกรวบรวมยังคงเพิ่มขึ้น องค์กรต่างๆ ยังต้องการข้อมูลเพิ่มเติมเกี่ยวกับสาเหตุที่เกิดความล้มเหลวอีกด้วย เครื่องมืออัตโนมัติและการจัดประสานมีแนวโน้มที่จะมีบทบาทสำคัญในการปรับปรุงการวิเคราะห์สาเหตุที่แท้จริงและให้การตอบสนองที่ชาญฉลาด SIOS Technology จะยังคงมุ่งเน้นไปที่ลูกค้าต่อไปในปีหน้า โดยช่วยให้พวกเขาหลีกเลี่ยงและลดเวลาหยุดทำงาน และสร้างความมั่นใจว่าข้อมูลและแอปพลิเคชันจะพร้อมใช้งานในเวลาที่ธุรกิจต้องการมากที่สุด บริษัทจะยังคงเพิ่มประสิทธิภาพโซลูชันของตนต่อไป โดยให้บริการเพิ่มเติมที่เกี่ยวข้องเพื่อเป็นประโยชน์ต่อลูกค้า ตลอดจนช่วยเหลือผู้ให้บริการแอปพลิเคชันและผู้ให้บริการคลาวด์ในการสร้างกลยุทธ์ HA ที่มีประสิทธิผล ทำซ้ำโดยได้รับอนุญาตจากSIOS |
กุมภาพันธ์ 2, 2024 |
มิตซูบิชิ มอเตอร์ส ย้ายระบบที่สำคัญไปยังคลาวด์ด้วย LifeKeeper เพื่อการปกป้องความพร้อมใช้งานสูงมิตซูบิชิ มอเตอร์ส ย้ายระบบที่สำคัญไปยังคลาวด์ด้วย LifeKeeper เพื่อการปกป้องความพร้อมใช้งานสูงเมื่อ Mitsubishi Motors Corporation ปรับปรุงระบบการจัดการคลังสินค้าในสถานที่ตั้งสามแห่งด้วยระบบบนคลาวด์ใหม่ พวกเขาต้องการวิธีใหม่ในการให้บริการความพร้อมใช้งานสูงโดยไม่ต้องเพิ่มความซับซ้อนหรือทำให้ประสิทธิภาพช้าลง “แม้ว่าจะมีปัญหาเกิดขึ้น LifeKeeper จะเฟลโอเวอร์จากโหนดเซิร์ฟเวอร์หลักไปยังโหนดรองโดยอัตโนมัติระบบในทันทีและการดำเนินงานดำเนินต่อไปโดยไม่มีความล่าช้าอย่างเห็นได้ชัดสำหรับผู้ใช้ ช่วยประหยัดเวลาด้านไอทีและลดการหยุดชะงักของบริการสำหรับลูกค้า” ฮิโรมาสะ สึโบชิมะ ผู้จัดการฝ่ายไอทีธุรกิจ แผนกไอทีระดับโลก มิตซูบิชิ มอเตอร์ส กล่าว สิ่งแวดล้อม คลังสินค้าของ Mitsubishi Motors แต่ละแห่งอาศัยระบบการจัดการที่จัดการคำสั่งซื้อและสินค้าคงคลังสำหรับชิ้นส่วนและอุปกรณ์เสริมของรถยนต์ที่จำหน่ายโดยตัวแทนจำหน่าย เช่น พรมปูพื้นและแร็คหลังคา โดยจะจัดการการรับชิ้นส่วนและวัสดุ การจัดการการจัดส่งสำหรับคำสั่งซื้อในประเทศและต่างประเทศจากตัวแทนจำหน่าย และการจัดการสินค้าคงคลังและการจัดสรรภายในที่ตั้งคลังสินค้าเอง ระบบเดิมทำงานบนฮาร์ดแวร์เซิร์ฟเวอร์ภายในองค์กรที่ล้าสมัย ซึ่งมีแนวโน้มมากขึ้นที่จะเกิดปัญหาซึ่งทำให้เสียเวลาด้านไอทีในการแก้ไขปัญหา และทำให้การดำเนินงานหยุดชะงักบ่อยครั้ง ระบบที่มีอยู่ใช้ความซ้ำซ้อนที่เป็นกรรมสิทธิ์ของผู้ผลิตฮาร์ดแวร์เพื่อลดเวลาหยุดทำงาน หากเกิดปัญหากับระบบเดิม เจ้าหน้าที่ไอทีจะต้องหยุดระบบด้วยตนเองและสลับการทำงานไปใช้ฮาร์ดแวร์สำรองจนกว่าปัญหาจะได้รับการแก้ไข ซึ่งเป็นกระบวนการที่ต้องใช้เวลาสองถึงสี่ชั่วโมงของเจ้าหน้าที่ไอที มิตซูบิชิมอเตอร์สจะต้องตรวจสอบให้แน่ใจว่าชิ้นส่วนหรืออุปกรณ์เสริมใดๆ ที่สั่งซื้อภายในระยะเวลาการยอมรับที่กำหนดจะถูกจัดส่งไปยังตัวแทนจำหน่ายในวันถัดไป ดังนั้นการหยุดทำงานของระบบที่มีความสำคัญต่อภารกิจเหล่านี้แม้ในช่วงเวลาสั้นๆ ก็สามารถส่งผลกระทบอย่างมีนัยสำคัญต่อธุรกิจได้ ระบบการจัดการคลังสินค้ามีบทบาทสำคัญในการรับประกันว่าคำสั่งซื้อทั้งหมดจะได้รับการประมวลผลทันเวลาตามกำหนดการส่งมอบ ตัวอย่างเช่น เพื่อให้แน่ใจว่าคำสั่งซื้อที่ป้อนไว้จะจัดส่งในวันถัดไปเวลา 16:29 น. ระบบการจัดการคลังสินค้าจะต้องประมวลผลและแสดงผลภายในเวลา 16:40 น. เพื่อให้สามารถนำไปขึ้นรถบรรทุกหรือเที่ยวบินสุดท้ายของวันได้ “เราต้องฟื้นตัวภายในไม่ถึง 10 นาที” อิวาซากิกล่าว ความท้าทาย ฮิโรมาสะ สึโบชิมะ ผู้จัดการแผนกไอทีธุรกิจ แผนกไอทีทั่วโลก บริษัท มิตซูบิชิ มอเตอร์ส คอร์ปอเรชั่น กล่าวว่า “ระบบที่มีอยู่ของเราในคลังสินค้า 3 แห่งจากทั้งหมด 6 แห่งของเรานั้นใช้ฮาร์ดแวร์ตั้งแต่ปี 2012 เราจำเป็นต้องแทนที่ด้วยระบบใหม่ที่จะช่วยลดปัญหาการระบายของเสีย ทรัพยากรไอทีและลดผลกระทบด้านลบต่อการดำเนินงาน” การค้นหาโซลูชันความพร้อมใช้งานสูงสำหรับระบบคลังสินค้าบนคลาวด์ใหม่ถือเป็นสิ่งสำคัญต่อความสำเร็จของโครงการ ซาโตชิ อิวาซากิ สมาชิกแผนกไอทีธุรกิจในแผนกไอทีทั่วโลกของบริษัท มิตซูบิชิ มอเตอร์ส คอร์ปอเรชั่น กล่าวว่า “ตามนโยบายทั่วทั้งบริษัท เราจำเป็นต้องย้ายจากระบบภายในองค์กรแบบเดิมไปยังคลาวด์สาธารณะทุกครั้งที่เราสร้างระบบใหม่ ” ซอฟต์แวร์ความพร้อมใช้งานสูง เมื่อย้ายระบบการจัดการคลังสินค้าไปยังคลาวด์สาธารณะ Mitsubishi Motor ได้ปรึกษาที่ปรึกษาด้านไอทีภายนอกที่แนะนำ SIOS LifeKeeper สำหรับ Linux เพื่อความพร้อมใช้งานสูง “จากประสบการณ์ที่ผ่านมา เราใช้โซลูชันฮาร์ดแวร์เพื่อความพร้อมใช้งานสูงเสมอ” นายอิวาซากิกล่าว “ฉันมีคำถามเชิงลึกมากมายสำหรับตัวแทน SIOS เกี่ยวกับการใช้ซอฟต์แวร์สำหรับ HA และ SIOS ให้คำตอบที่ถูกต้องและครบถ้วน ซึ่งทำให้ฉันไว้วางใจ SIOS LifeKeeper” ปัจจัยสำคัญอีกประการหนึ่งในการตัดสินใจเลือก LifeKeeper คือบริการเสริม LifeKeeper Professional Service ซึ่งจัดเตรียมชุดกู้คืนที่รับรู้ถึงแอปพลิเคชัน (ARK) ซึ่งปรับให้เหมาะกับความต้องการระบบคลังสินค้าเฉพาะของ Mitsubishi SIOS ARK ช่วยให้ LifeKeeper สามารถตรวจสอบสแต็กแอปพลิเคชันทั้งหมดเพื่อหาปัญหาการหยุดทำงานที่อาจเกิดขึ้น พวกเขายังประสานการเฟลโอเวอร์ของแอปพลิเคชันตามแนวทางปฏิบัติที่ดีที่สุดเพื่อการทำงานที่ราบรื่นบนโหนดรอง “เราสามารถปรับแต่งและพัฒนา LifeKeeper ให้ตรงตามความต้องการของเราได้ และ SIOS ก็สามารถตอบสนองคำขอของเราทั้งหมดได้” นายอิวาซากิกล่าว เฟลโอเวอร์อัตโนมัติที่รวดเร็ว “แม้ว่าจะเกิดปัญหา LifeKeeper จะเฟลโอเวอร์จากโหนดเซิร์ฟเวอร์หลักไปยังโหนดรองโดยอัตโนมัติในทันที และการดำเนินการจะดำเนินต่อไปโดยไม่มีความล่าช้าที่เห็นได้ชัดเจนสำหรับผู้ใช้ ช่วยประหยัดเวลาด้านไอทีและลดการหยุดชะงักของบริการสำหรับลูกค้า” นายสึโบชิมะกล่าว คุณสึโบชิมะมีหน้าที่ดูแลระบบบางส่วนในแผนกไอทีระดับโลก ก่อนการอัปเกรดโปรเจ็กต์ เขาเคยได้รับการแจ้งเตือนความล้มเหลวตลอดทั้งคืนซึ่งจำเป็นต้องได้รับการดูแลทันที ในปัจจุบัน ในกรณีที่เกิดความล้มเหลว เขาเพียงได้รับการแจ้งเตือนเกี่ยวกับการเฟลโอเวอร์ และระบบจะยังคงทำงานต่อไปโดยไม่มีการแทรกแซง โซลูชัน SIOS ช่วยให้ Mr. Tsuboshima และทีมไอทีคนอื่นๆ ประหยัดเวลาอันมีค่าได้หลายชั่วโมง และขจัดปัญหาการหยุดชะงักในการให้บริการ ผลลัพธ์ ประโยชน์ของการย้ายระบบการจัดการคลังสินค้าไปยังคลาวด์พร้อมทั้งรับประกันความพร้อมใช้งานสูงด้วย LifeKeeper นั้นชัดเจนในการตอบสนองต่อการแพร่ระบาดในปี 2020 ‘การมีระบบของเราในระบบคลาวด์ทำให้เราสามารถจัดการระบบจากระยะไกลได้ “หากเรายังคงใช้ระบบเดิมในองค์กร เราอาจเผชิญกับความเสี่ยงที่เพิ่มขึ้นอย่างมากในการเข้ามาที่สำนักงานในช่วงภาวะฉุกเฉินด้านโควิด-19 เพื่อแก้ไขปัญหาหรือจัดการระบบ” นายอิวาซากิกล่าว แม้ว่า Mitsubishi Motors จะยังคงเปลี่ยนมาใช้ระบบคลาวด์สาธารณะ แต่ระบบจำนวนมากยังคงใช้เมนเฟรม “ในขณะที่เราพิจารณาย้ายระบบที่มีความสำคัญต่อภารกิจของเรา ให้ห่างจากระบบโฮสต์เหล่านี้และเข้าสู่คลาวด์ เราจะมองหา LifeKeeper สำหรับการป้องกันที่มีความพร้อมใช้งานสูง” นายอิวาซากิกล่าว เราจะแนะนำเรื่องนี้ให้กับบริษัทในอนาคตครับ” เรียนรู้เพิ่มเติมเกี่ยวกับ SIOS LifeKeeper สำหรับ Linux เรียนรู้เพิ่มเติมเกี่ยวกับSIOS Protection Suite รวมถึง SIOS LifeKeeper, SIOS DataKeeper และชุดการกู้คืนแอปพลิเคชัน SIOS ทำซ้ำโดยได้รับอนุญาตจากSIOS |
มกราคม 30, 2024 |
วิธีการตั้งค่า DataKeeper Cluster Edition (คลัสเตอร์ DKCE)วิธีการตั้งค่า DataKeeper Cluster Edition (คลัสเตอร์ DKCE)คลัสเตอร์ DKCE คืออะไรDKCE เป็นตัวย่อสำหรับรุ่นคลัสเตอร์ DataKeeper. DKCE เป็นซอฟต์แวร์ SIOS ที่รวมการใช้ DataKeeper เข้ากับคุณสมบัติของการทำคลัสเตอร์ Windows Failoverเพื่อให้ความพร้อมใช้งานสูงผ่านการจำลองข้อมูลตามการย้ายข้อมูล ขั้นตอนในการสร้างคลัสเตอร์ DKCEสำหรับตัวอย่างนี้ ฉันจะตั้งค่าคลัสเตอร์แบบสามโหนดโดยมีโหนดที่สามที่ดูแลโหนดส่วนใหญ่ ขั้นตอนที่ 1:คุณต้องติดตั้ง DataKeeper บน 2/3 ของระบบเพื่อตั้งค่าคลัสเตอร์ DKCE คลิกลิงก์ต่อไปนี้เพื่อปฏิบัติตามคู่มือเริ่มต้นใช้งานฉบับย่อของเราเพื่อทำการติดตั้งให้เสร็จสิ้น:https://docs.us.sios.com/dkce/8.10.0/en/topic/datakeeper-cluster-edition-quick-start-guide ขั้นตอนที่ 2:เพิ่มเซิร์ฟเวอร์ที่คุณวางแผนจะจัดการในตัวจัดการเซิร์ฟเวอร์ สิ่งนี้จะต้องดำเนินการบนเซิร์ฟเวอร์ทั้งหมดที่คุณวางแผนจะเพิ่มลงในคลัสเตอร์ บนเซิร์ฟเวอร์ของคุณไปที่ Server Manager คลิก “เพิ่มเซิร์ฟเวอร์อื่นเพื่อจัดการ” ฉันเพิ่มเซิร์ฟเวอร์ตามชื่อของพวกเขาที่นี่ ในการดำเนินการนี้ คุณจะต้องยืนยันชื่อระบบและรายการ IP ของคุณในไฟล์โฮสต์ ซึ่งอยู่ที่นี่: C:\Windows\System32\drivers\etc\hosts หลังจากเพิ่มเซิร์ฟเวอร์ทั้งหมดแล้ว คุณสามารถตรวจสอบได้โดยไปที่ “เซิร์ฟเวอร์ทั้งหมด” ในตัวจัดการเซิร์ฟเวอร์ ขั้นตอนที่ 3:คุณอาจสังเกตเห็นข้อผิดพลาด winRM เพื่อข้ามการรันคำสั่งนี้ใน PS ในฐานะผู้ดูแลระบบ รันคำสั่งนี้เพื่อเพิ่มเซิร์ฟเวอร์ในคลัสเตอร์ของคุณเป็นโฮสต์ที่เชื่อถือได้ คำสั่งนี้จะต้องรันบนทุกระบบในคลัสเตอร์ของคุณ ตั้งค่ารายการ WSMan:\localhost\Client\TrustedHosts -ค่า ‘<ชื่อของเซิร์ฟเวอร์ 1>,<ชื่อของเซิร์ฟเวอร์ 2>’ ขั้นตอนที่ 4:ติดตั้งคลัสเตอร์ล้มเหลว ติดตามขั้นตอนเหล่านี้เพื่อติดตั้งการทำคลัสเตอร์ล้มเหลว. ขั้นตอนที่ 5:นำทางไปยังตัวจัดการคลัสเตอร์ล้มเหลว ขั้นตอนที่ 6:คลิก “สร้างคลัสเตอร์” ขั้นตอนที่ 7:จากนั้นเพิ่มเซิร์ฟเวอร์ที่ควรอยู่ในคลัสเตอร์แล้วคลิก “เพิ่ม” หลังจากแต่ละรายการ ขั้นตอนที่ 8:รายการควรจะคล้ายกับรายการในภาพต่อไปนี้ ขั้นตอนที่ 9:เลือก “เรียกใช้การทดสอบทั้งหมด” สำหรับการทดสอบการตรวจสอบ และคลิกถัดไป ขั้นตอนที่ 10:เมื่อการทดสอบเสร็จสิ้นให้คลิก “เสร็จสิ้น” ขั้นตอนที่ 11:ตั้งชื่อคลัสเตอร์ของคุณ ฉันตั้งชื่อคลัสเตอร์นี้ว่า “Cluster1” แล้วคลิก “ถัดไป” ขั้นตอนที่ 12:ตรวจสอบว่าได้เลือก “เพิ่มพื้นที่เก็บข้อมูลที่มีสิทธิ์ทั้งหมดลงในคลัสเตอร์” แล้วคลิก “ถัดไป” ขั้นตอนที่ 13:เมื่อขั้นตอนที่ 12 เสร็จสิ้น คลิก “เสร็จสิ้น” ขั้นตอนที่ 14:ใน Failover Cluster Manager คลัสเตอร์จะเริ่มต้นออฟไลน์ ฉันจะกำหนด IP ที่ไม่ได้ใช้เพื่อนำมาออนไลน์ ใน “ทรัพยากรหลักของคลัสเตอร์” ให้คลิกขวาที่ทรัพยากรที่อยู่ IP และเลือกคุณสมบัติ ในแผงคุณสมบัติ ซับเน็ตมาสก์ของฉันคือ /28 ดังนั้นฉันจะเลือก IP ที่ใช้งานได้ภายในช่วง 12.0.0.14 คลิก “สมัคร” ใน “ทรัพยากรหลักของคลัสเตอร์” ให้คลิกขวาที่คลัสเตอร์แล้วเลือก “นำออนไลน์” ทรัพยากรควรออนไลน์แล้ว ขั้นตอนที่ 15:นำทางไปยัง DataKeeper ขั้นตอนที่ 16:คลิกขวาที่งานแล้วคลิก “สร้างงาน” เพื่อเริ่มสร้างมิเรอร์แรกของเรา ตั้งชื่องาน ฉันตั้งชื่องานของฉันว่า “job1” แล้วคลิก “สร้างงาน” เลือกแหล่งที่มาและปริมาณที่จะจำลองข้อมูล ฉันเลือก Box1 เป็นแหล่งของฉัน และเล่ม D คลิก “ถัดไป” จากนั้นเลือกเซิร์ฟเวอร์และโวลุ่มที่จะเป็นเป้าหมาย ฉันเลือก Box2 และเล่ม D ข้อความแจ้งจะปรากฏขึ้นเพื่อขอให้คุณลงทะเบียนวอลุ่มที่คุณสร้างเป็นโวลุ่ม WSFC โดยอัตโนมัติ เลือก “ใช่” เพื่อทำให้โวลุ่มนี้พร้อมใช้งานสูง ใน DataKeeper คุณจะเห็นว่าโวลุ่มกำลังมิเรอร์อยู่ ขั้นตอนที่ 17:ใน Failover Cluster Manager ให้ไปที่ Storage จากนั้นเลือก Disks คุณจะเห็นวอลุ่มที่คุณลงทะเบียนอัตโนมัติคือ WSFC ขั้นตอนที่ 18:มาตรวจสอบเจ้าของที่ควรตรวจสอบกัน คลิกขวาที่โวลุ่มแล้วคลิก “คุณสมบัติ” เนื่องจากฉันต้องการหนึ่งในสามเพื่อเป็นพยานและรักษาส่วนใหญ่ของโหนด Box3 จะต้องไม่ถูกเลือก / คงไม่ถูกเลือก ขั้นตอนที่ 19:ตอนนี้เราสามารถทดสอบการย้ายข้อมูลผ่าน Failover Cluster Manager ได้ ไปที่ File Explorer และสร้างไฟล์ข้อความใหม่ในโวลุ่มที่กำลังทำมิเรอร์อยู่ ทำสิ่งนี้กับแหล่งที่มาของคุณ ไปที่ Failover Cluster Manager คลิก “DataKeeper Volume D” และเลือก “ย้ายที่เก็บข้อมูลที่มีอยู่” จากบานหน้าต่างการดำเนินการ คลิกขวาที่ “โหนดที่ดีที่สุดที่เป็นไปได้” สิ่งนี้ควรย้ายไปยังเป้าหมายของคุณโดยอัตโนมัติ ใน Failover Cluster Manager ให้ตรวจสอบว่าเจ้าของ “DataKeeper Volume D” เป็นโหนดเป้าหมายแล้ว ไปที่ DataKeeper เพื่อตรวจสอบว่าเป้าหมายของคุณเป็นแหล่งที่มาแล้ว และในทางกลับกัน การตั้งค่าคลัสเตอร์ DKCE สำเร็จคุณตั้งค่าคลัสเตอร์ DKCE เสร็จแล้ว SIOS จัดให้ทรัพยากรและการฝึกอบรมสำหรับผลิตภัณฑ์ทั้งหมดของเรา ทำซ้ำโดยได้รับอนุญาตจากSIOS
|
มกราคม 24, 2024 |
รับรองการเข้าถึงแอปพลิเคชันทางการศึกษาที่สำคัญรับรองการเข้าถึงแอปพลิเคชันทางการศึกษาที่สำคัญการศึกษาและเทคโนโลยีสารสนเทศ (IT) เป็นสิ่งที่แยกไม่ออกมากขึ้น ไม่ว่าจะเป็นแอปพลิเคชันที่รองรับไวท์บอร์ดในห้องเรียน ฐานข้อมูลที่รองรับระบบการลงทะเบียนของมหาวิทยาลัย ระบบบริหารจัดการการเรียนรู้ (LMS) หรือระบบบำรุงรักษาอาคารที่ควบคุมการเข้าถึงห้องปฏิบัติการ หอพัก และห้องอาหารของนักเรียน หากเป็นองค์ประกอบหลัก โครงสร้างพื้นฐานด้านไอทีของคุณก็มืดลงทันที ทั้งครู ผู้บริหาร และนักเรียนไม่สามารถบรรลุสิ่งที่พวกเขาต้องการให้สำเร็จได้ ภารกิจของสถาบันถูกขัดจังหวะ หากการหยุดชะงักเกิดขึ้นบ่อยเกินไป หากประสบการณ์ของนักเรียน ครู และผู้บริหารต้องทนทุกข์ทรมาน ชื่อเสียงของสถาบันเองก็อาจเสียหายได้เช่นกัน โครงสร้างพื้นฐานด้านไอทีที่ออกแบบมาเพื่อให้แน่ใจว่าแอปพลิเคชันมีความพร้อมใช้งานสูง (HA) ซึ่งมีความสำคัญต่อประสบการณ์การศึกษาสามารถลดความเสี่ยงของการหยุดชะงักและการสูญเสียชื่อเสียงที่อาจเกิดขึ้นได้หากระบบเหล่านี้ไม่ตอบสนองไม่ว่าด้วยเหตุผลใดก็ตาม ในกรณีนี้ โครงสร้างพื้นฐาน HA ได้รับการกำหนดให้เป็นโครงสร้างพื้นฐานที่สามารถรับประกันความพร้อมใช้งานของแอปพลิเคชันหลักได้ไม่น้อยกว่า 99.99% ของเวลา กล่าวอีกนัยหนึ่ง นั่นหมายความว่าแอปพลิเคชันที่สำคัญของคุณจะไม่ออฟไลน์โดยไม่คาดคิดนานกว่าสี่นาทีต่อเดือน คุณบรรลุ HA ได้อย่างไร? คำถามนั้นได้รับคำตอบทันที แต่ไม่ใช่คำถามเดียวที่คุณต้องถาม สิ่งสำคัญไม่แพ้กันคือ: แอปพลิเคชันใดบ้างที่สำคัญมากจนรับประกันการกำหนดค่า HA หัวใจหลักคือโครงสร้างพื้นฐานด้านไอทีที่กำหนดค่าสำหรับ HA มีชุดเซิร์ฟเวอร์รองและระบบย่อยการจัดเก็บข้อมูลหนึ่งชุดขึ้นไปซึ่งตั้งอยู่ในตำแหน่งที่แตกต่างกันทางภูมิศาสตร์ (ซึ่งอาจเป็นศูนย์ข้อมูลระยะไกลหากเซิร์ฟเวอร์หลักของคุณอยู่ในสถานที่หรือในความพร้อมใช้งานแยกต่างหาก โซน [AZ] หากเซิร์ฟเวอร์ของคุณอยู่ในระบบคลาวด์) หากมีบางอย่างทำให้แอปพลิเคชันที่ทำงานบนเซิร์ฟเวอร์หลักหยุดการตอบสนอง ซอฟต์แวร์ HA ที่จัดการแอปพลิเคชันของคุณจะล้มเหลวผ่านแอปพลิเคชันไปยังเซิร์ฟเวอร์รองทันที ซึ่งแอปพลิเคชันที่สำคัญของคุณจะเริ่มต้นใหม่อีกครั้งจากจุดที่เซิร์ฟเวอร์หลักหยุดการตอบสนอง ขึ้นอยู่กับขนาดและคุณลักษณะด้านประสิทธิภาพของเซิร์ฟเวอร์หลักที่คุณวางแผนจะทำซ้ำ เซิร์ฟเวอร์รองนั้นอาจมีค่าใช้จ่ายสูง ดังนั้นจึงไม่น่าที่คุณจะกำหนดค่าแอปพลิเคชันทางวิชาการทั้งหมดสำหรับ HA เมื่อคุณกำหนดได้ว่าแอปพลิเคชันใดที่รับประกันการลงทุนใน HA คุณจะรู้ว่าคุณต้องสร้างสภาพแวดล้อม HA ที่ใด ทางเลือกเพื่อให้ได้ความพร้อมใช้งานสูงเมื่อคุณเลือกแอปพลิเคชันที่คุณต้องการปกป้องแล้ว ตัวเลือกในการบรรลุ HA จะชัดเจนยิ่งขึ้น พวกเขาทำงานบน Windows หรือ Linux หรือไม่? ระบบจัดการฐานข้อมูล (DBMS) ของคุณรองรับการกำหนดค่า HA ในตัวหรือไม่ หากเป็นเช่นนั้น มีข้อจำกัดอะไรบ้าง? หากแอปพลิเคชันที่สำคัญของคุณทำงานบน Windows และ SQL Server คุณสามารถเปิดใช้งาน HA ได้โดยใช้คุณสมบัติ Availability Group (AG) ของ SQL Server เอง หรือคุณสามารถกำหนดค่า HA โดยใช้เครื่องมือการทำคลัสเตอร์ SANless ของบริษัทอื่น ซึ่งเสนอตัวเลือกที่บริการ AG ใน SQL Server ไม่มี หากคุณกำลังพยายามปกป้องเซิร์ฟเวอร์ฐานข้อมูลจากผู้ขายหลายราย หรือหากแอปพลิเคชันที่สำคัญบางแอปพลิเคชันของคุณทำงานบน Windows ในขณะที่แอปพลิเคชันอื่นๆ ทำงานบน Linux ความสามารถในการจัดการ HA ของคุณจะได้รับการอำนวยความสะดวกโดยการใช้โซลูชัน HA ที่รองรับ DBMS และ OS หลายตัว แพลตฟอร์ม การเลือกใช้โซลูชันคลัสเตอร์ที่รองรับแพลตฟอร์ม DBMS และ OS ที่หลากหลายทำให้การจัดการง่ายขึ้น ตรงกันข้ามกับความซับซ้อนและความยุ่งยากที่อาจเกิดขึ้นในการจัดการบริการ HA ที่ใช้ฐานข้อมูลหลายรายการพร้อมกัน รับประกันความพร้อมใช้งานสูงผ่านโซลูชัน HA แบบเนทีฟฐานข้อมูลหากคุณใช้โซลูชัน HA ดั้งเดิมของฐานข้อมูล เช่น คุณลักษณะ AG ของ SQL Server ซอฟต์แวร์จะจำลองข้อมูลทั้งหมดในฐานข้อมูล SQL Server หลักของคุณไปยังอินสแตนซ์ที่เหมือนกันของฐานข้อมูลนั้นบนเซิร์ฟเวอร์ระบบรอง หากมีบางอย่างทำให้เซิร์ฟเวอร์หลักหยุดการตอบสนอง คุณลักษณะการตรวจสอบในส่วนประกอบ AG จะทำให้เซิร์ฟเวอร์รองเข้าควบคุมโดยอัตโนมัติ เนื่องจากฟีเจอร์ AG ได้จำลองข้อมูลทั้งหมดแบบเรียลไทม์ เซิร์ฟเวอร์รองจึงสามารถเข้าควบคุมได้ทันที และแทบไม่มีการหยุดชะงักของบริการหรือข้อมูลสูญหาย เครื่องมือ HA ที่ใช้ฐานข้อมูลจำนวนมากทำงานในลักษณะเดียวกัน อย่างไรก็ตาม เมื่อพิจารณาถึงแนวทางแบบเนทีฟของฐานข้อมูล มีข้อควรพิจารณาบางประการ: หากบริการ HA รวมเข้ากับ DBMS เอง บริการเหล่านั้นอาจจำลองเฉพาะข้อมูลที่เกี่ยวข้องกับ DBMS นั้นเท่านั้น หากมีข้อมูลสำคัญอื่นๆ อยู่บนเซิร์ฟเวอร์หลักของคุณ ข้อมูลนั้นจะไม่ถูกจำลองไปยังเซิร์ฟเวอร์รองในสถานการณ์ HA ดั้งเดิมของฐานข้อมูล อาจมีข้อจำกัดอื่นๆ เกี่ยวกับสิ่งที่บริการดั้งเดิมของฐานข้อมูลจะทำซ้ำเช่นกัน ถ้าคุณใช้ฟังก์ชัน Basic AG ที่รวมอยู่ใน SQL Server Standard Edition ตัวอย่างเช่น แต่ละ AG สามารถจำลองแบบฐานข้อมูล SQL เดียวเท่านั้นไปยังตำแหน่งรองเดียวได้ คุณสามารถสร้าง AG พื้นฐานได้หลายรายการหากแอปพลิเคชันของคุณเกี่ยวข้องกับฐานข้อมูล SQL หลายฐานข้อมูล แต่คุณไม่สามารถควบคุมได้ว่า AG แต่ละอันจะล้มเหลวพร้อมกันในสถานการณ์เฟลโอเวอร์หรือไม่ และปัญหาอาจเกิดขึ้นได้หากไม่เป็นเช่นนั้น วิธีหนึ่งในการหลีกเลี่ยงข้อจำกัดนี้คือการใช้ฟังก์ชัน Always On AG ที่รวมอยู่ใน SQL Server Enterprise Edition ซึ่งช่วยให้สามารถจำลองฐานข้อมูล SQL หลายฐานข้อมูลไปยังเซิร์ฟเวอร์รองหลายเครื่องได้ แต่อาจมีราคาแพงมากจากมุมมองของสิทธิ์การใช้งานหากแอปพลิเคชันของคุณไม่ มิฉะนั้นให้ใช้คุณสมบัติใด ๆ ของ SQL Server Enterprise Edition โซลูชัน HA แบบเนทีฟฐานข้อมูลอื่นๆ อาจมีข้อจำกัดที่คล้ายกัน ดังนั้น โปรดทำความเข้าใจก่อนตัดสินใจลงทุนในแนวทางดังกล่าว รับประกันความพร้อมใช้งานสูงผ่านการทำคลัสเตอร์แบบไร้ SANอีกทางเลือกหนึ่งนอกเหนือจากแนวทางแบบเนทิฟฐานข้อมูลสำหรับ HA คุณสามารถใช้เครื่องมือของบริษัทอื่นเพื่อสร้างคลัสเตอร์แบบ SANless เช่นเดียวกับในการกำหนดค่า AG ที่อธิบายไว้ข้างต้น ซอฟต์แวร์การทำคลัสเตอร์ SANless จะทำการจำลองข้อมูลแบบซิงโครนัสจากเซิร์ฟเวอร์หลักไปยังเซิร์ฟเวอร์รองโดยอัตโนมัติ นอกจากนี้ยังจัดเตรียมการเฟลโอเวอร์ทันทีไปยังเซิร์ฟเวอร์รองหากเซิร์ฟเวอร์หลักไม่ตอบสนอง เนื่องจากการเฟลโอเวอร์ใช้เวลาเพียงไม่กี่วินาที การเข้าถึงแอปพลิเคชันที่สำคัญของผู้ดูแลระบบ คณาจารย์ และนักศึกษาจึงยังคงไม่หยุดชะงัก ความแตกต่างที่สำคัญระหว่างการทำคลัสเตอร์แบบ SANless และแนวทางการใช้ฐานข้อมูลนั้นอยู่ที่รายละเอียดเชิงปฏิบัติ วิธีการจัดกลุ่ม SANless นั้นไม่เชื่อเรื่องฐานข้อมูล โดยจะจำลองข้อมูลใดๆ บนโวลุ่มการจัดเก็บข้อมูลที่กำหนด ซึ่งอาจรวมถึงฐานข้อมูลหลายฐานข้อมูลจากผู้ขายหลายราย ไฟล์ข้อความ ไฟล์วิดีโอ หรือทรัพย์สินทางการศึกษาอื่นๆ ที่มีความสำคัญต่อความพร้อมใช้งาน วิธีนี้สามารถประหยัดเงินให้สถาบันได้เป็นจำนวนมาก หากแนวทางการใช้ฐานข้อมูลแบบเนทีฟสำหรับ HA จำเป็นต้องอัปเกรดเป็นฐานข้อมูลรุ่นที่มีราคาแพงกว่า สุดท้ายนี้ ตามที่ระบุไว้ก่อนหน้านี้ หากคุณกำลังพยายามปกป้องแอปพลิเคชันและข้อมูลที่ทำงานในสภาพแวดล้อมการทำงานที่หลากหลาย วิธีการจัดคลัสเตอร์แบบไร้ SAN อาจจัดการได้ดีกว่าวิธีฐานข้อมูลแบบเนทิฟแต่ละวิธี คุณสามารถใช้การทำคลัสเตอร์แบบไม่ใช้ SAN เพื่อให้แน่ใจว่า HA ในสภาพแวดล้อม Windows หรือ Linux ซึ่งสามารถขจัดความซับซ้อนที่อาจมาพร้อมกับการปรับใช้แนวทางแบบเนทีฟฐานข้อมูลที่แตกต่างกันไปตามสภาพแวดล้อมการทำงาน ทำซ้ำโดยได้รับอนุญาตจากSIOS |