กรณีศึกษา: โซลูชันการตรวจสอบ AWS EC2 ช่วยบรรเทา บริษัท ผู้ผลิตระดับโลกจากความเครียดขณะย้ายไปไว้บนคลาวด์

Tokyo Diamond Tools Manufacturing ปกป้องแอปพลิเคชันที่สำคัญด้วย SIOS AppKeeper

Tokyo Diamond Tools ในการผลิตระดับก่อตั้งขึ้นในปี 1932 Co. , Ltd. เป็นผู้ผลิตเครื่องมือเพชรสำหรับการตัดการตัดการขัดและการเจาะในหลากหลายสาขาเช่นเครื่องใช้ไฟฟ้าในบ้านเซมิคอนดักเตอร์อุปกรณ์อิเล็กทรอนิกส์การดูแลสุขภาพและวิศวกรรมโยธา แม้ว่าจะเป็น บริษัท ที่ก่อตั้งมายาวนานและมีประวัติยาวนานกว่า 80 ปีโตเกียวไดมอนด์ยังคงแนะนำเครื่องมือไอทีใหม่ ๆ อยู่เสมอ  บริษัท ตัดสินใจย้ายไปที่ Amazon AWS และการจำลองเสมือนสำหรับความเร็วและประสิทธิภาพของการปรับปรุงธุรกิจ SIOS AppKeeper มีบทบาทสำคัญในการให้การป้องกันความพร้อมใช้งานของแอปพลิเคชันที่พวกเขาต้องการ หนึ่งในเหตุผลสำหรับการย้ายเครื่องมือเพชรของโตเกียวไปยังคลาวด์และ AWS คือแผ่นดินไหวครั้งใหญ่ทางตะวันออกของญี่ปุ่นในปี 2554  แม้ว่าจะไม่มีความเสียหายโดยตรงกับเซิร์ฟเวอร์ที่สำนักงานใหญ่ แต่อุปกรณ์ที่โรงงานเซนไดในจังหวัดมิยากิหลุดออกจากชั้นวางทำให้เกิดความเสียหายร้ายแรง  โตเกียวไดมอนด์เห็นความจำเป็นในการวางแผนความต่อเนื่องทางธุรกิจที่ดีขึ้น  นี่เป็นไดร์เวอร์หลักสำหรับการเปลี่ยนเป็นการทำเวอร์ชวลไลเซชันของระบบหลักและการใช้สภาพแวดล้อมคลาวด์

ตอนแรก บริษัท เริ่มโยกย้ายแอพพลิเคชั่นที่ค่อนข้างเล็กไปยังคลาวด์  “ เราเริ่มต้นการย้ายประมาณพฤศจิกายน 2011  ในเวลานั้นเราไม่มีทางเลือกนอกจาก AWS "คุณ Takuji Kokubo หัวหน้าฝ่าย IT Systems ของ Tokyo Diamond กล่าว  พวกเขาจัดการการดำเนินงานด้วยตนเองโดยใช้พอร์ทัลเมฆ“ Managed Cloud with AWS” ของ Sony Network Communications  Mr. Kokubo เป็นคนอธิบายการดำเนินงานด้านไอทีแบบ One Man ดังนั้นประสิทธิภาพและระบบอัตโนมัติจึงมีความสำคัญต่อการทำงานที่ราบรื่นของระบบไอทีของ บริษัท ที่ตั้งอยู่ในญี่ปุ่นและสิงคโปร์และไทย

ย้ายไปยังคลาวด์และระบุความต้องการโซลูชันการกู้คืน 

เครื่องมือเพชรดำเนินการ Amazon EC2 และ Amazon S3 ซึ่งเป็นบริการจัดเก็บข้อมูลบนคลาวด์ พวกเขาย้ายกรุ๊ปแวร์, ฝ่ายสนับสนุนการขายและระบบการประชุมทางวิดีโอไปยัง AWS  ระบบการประชุมทางวิดีโอของ Diamond Tools มีความสำคัญต่อการทำงานประจำวัน  “ เป็นเครื่องมือที่ใช้บ่อยในการประชุมและการประชุมต่าง ๆ กับสถานที่ต่างประเทศ  มันถูกใช้งานประมาณ 100 ครั้งต่อเดือนและด้วยการเปลี่ยนจากระบบ SaaS แบบจ่ายตามการใช้งานเป็น AWS แบบธรรมดาเราสามารถลดต้นทุนได้มากถึงสองล้านเยนต่อปี” นายโคกุโบกล่าว  ก่อนหน้านี้คุณภาพเสียงมักจะลดลงเมื่อผู้ใช้จำนวนมากเกินไปรวมถึง บริษัท อื่น ๆ ที่เชื่อมต่อกับระบบในเวลาเดียวกัน  จากนั้นนายโคคุโบจะได้รับการร้องเรียนจากผู้ใช้ แต่ปัญหาไม่สามารถแก้ไขได้อย่างง่ายดาย  การสร้างระบบการประชุมทางวิดีโอเฉพาะทางของ บริษัท บน AWS ทำให้คุณภาพวิดีโอและเสียงมีความเสถียรและลดการร้องเรียน

Mr. Kokubo ประสบปัญหาเกี่ยวกับสภาพแวดล้อม EC2 ในไม่ช้า “ EC2 มีเสถียรภาพเหมือนโครงสร้างพื้นฐาน อย่างไรก็ตามบางครั้งบริการที่ล้มเหลว ฉันกังวลเสมอและวันหนึ่งระหว่างการเดินทางไปทำธุรกิจในต่างประเทศฉันได้รับโทรศัพท์แจ้งว่าผู้ใช้ไม่สามารถเข้าถึงระบบได้  ฉันต้องเปิดแล็ปท็อปของฉันซึ่งฉันพกติดตัวตลอดเวลาเพื่อเชื่อมต่อกับ AWS ผ่าน VPN และกู้คืนบริการที่ล้มเหลว "Mr. Kokubo กล่าว  เห็นได้ชัดว่ากระบวนการนี้ไม่สามารถปรับขนาดได้

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

“ สิบปีที่แล้วระบบจะหยุดเมื่อมีความล้มเหลวและผู้ใช้ก็คุ้นเคยกับสิ่งนั้น อย่างไรก็ตามวันนี้ฉันได้รับการร้องเรียนทันทีที่มีอะไรหยุด ตอนนี้ระบบคาดว่าจะทำงานได้ตลอดเวลาเช่นน้ำที่ไหลออกมาจากก๊อกทุกที่ทุกเวลา  การหยุดทำงานของระบบกำลังเป็นที่ยอมรับมากขึ้นเรื่อย ๆ ” นายโคคุโบกล่าว

นาย Kokubo รู้สึกเสมอว่าเขาจะต้องดูแลปัญหาใด ๆ เมื่อบริการใดบริการหนึ่งที่ทำงานบน EC2 ล้มเหลว  การเป็นคนเดียวที่สามารถแก้ไขปัญหาใด ๆ ยังคงเป็นภาระสำหรับเขา  Mr. Kokubo กล่าวว่า“ การเป็นร้านไอทีคนเดียวฉันมักจะพิจารณาว่าคุณค่าของฉันอยู่ที่การให้บริการฟังก์ชั่นช่วยเหลือเท่านั้น  แต่มันไม่ดีฉันต้องพิจารณาว่าฉันจะทำให้ระบบของ Tokyo Diamond ทำงานได้อย่างไรโดยไม่ต้องให้การสนับสนุน”

เนื่องจากเขาเป็นมืออาชีพด้านไอทีเพียงคนเดียวใน บริษัท ที่พึ่งพาบริการคลาวด์มากขึ้นเขาจึงรู้ว่าเขาต้องการความช่วยเหลือ “ เมื่อ Sony Network Communications บอกกับฉันว่า SIOS AppKeeper ให้การดำเนินงานอัตโนมัติและการจัดการอินสแตนซ์ EC2 ฉันตัดสินใจที่จะใช้มันก่อนที่จะดูรายละเอียด หากเรามีวิธีแก้ปัญหาที่กู้คืนบริการ EC2 โดยอัตโนมัติฉันก็ไม่จำเป็นต้องแก้ไขปัญหาทุกปัญหาด้วยการเชื่อมต่อกับ VPN ในระหว่างเดินทาง "นาย Kokubo กล่าว

SIOS AppKeeper เป็นบริการคลาวด์ที่ตรวจสอบอินสแตนซ์ของ EC2 และเริ่มบริการใหม่โดยอัตโนมัติเมื่อตรวจพบความบกพร่องของระบบ  เมื่อบริการที่ถูกตรวจสอบล้มเหลว SIOS AppKeeper จะกู้คืนบริการโดยอัตโนมัติโดยไม่ต้องให้บุคลากรเข้าไปแทรกแซงด้วยตนเอง

แอปพลิเคชั่นมากกว่า 10 รายการทำงานบน AWS

โตเกียวไดมอนด์ยังคงโยกย้ายแอปพลิเคชั่นอื่นไปยัง AWS และภายในเดือนมิถุนายน 2018 มีแอปพลิเคชันมากกว่า 10 แอปพลิเคชันที่ทำงานบน AWS “ ฉันรู้สึกว่า AWS มีประโยชน์: ระบบปฏิบัติการเริ่มต้นใน 10 นาทีและทรัพยากรสามารถปรับขนาดขึ้น / ลงได้อย่างยืดหยุ่นขึ้นอยู่กับธุรกิจ เราสามารถลบทรัพยากรได้แม้ว่ามันจะไม่ทำงาน  อย่างไรก็ตามระบบหลักที่ประมวลผลข้อมูลจำนวนมากถูกย้ายไปยังสภาพแวดล้อมเสมือนจริงโดยใช้ศูนย์ข้อมูลไม่ใช่ AWS  เราใช้ทั้ง AWS และดาต้าเซ็นเตอร์เสมือนเพื่อสร้างระบบขึ้นอยู่กับการใช้งานและความต้องการ” นายโคกุโบกล่าว

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

SIOS AppKeeper เปิดใช้งานบุคลากรด้านไอทีเพื่อมุ่งเน้นงานอื่น ๆ

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

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

ต้องบอกว่านาย Kokubo ตกลงว่ามันเป็นประโยชน์อย่างมากที่เขาจะได้รับอิสระจากการแก้ไขปัญหาแอปพลิเคชันเหล่านี้  ตอนนี้เขาสามารถใช้เวลาในการจัดการมากขึ้นรวมถึงการพัฒนากลยุทธ์และการวางแผนด้านไอทีความปลอดภัยและการริเริ่ม BCP ของ Diamond Tool

แม้ว่าวันนี้เครื่องมือเพชรใช้ SIOS AppKeeper สำหรับการดำเนินงานและการจัดการของสามแอปพลิเคชัน แต่ก็มีแผนที่จะขยายความคุ้มครองของ AppKeeper ไปยังแอปพลิเคชันอื่น ๆ ในไม่ช้า  สิ่งนี้จะทำให้ Mr. Kokubo ใช้เวลากับกิจกรรมที่มีมูลค่าเพิ่ม  “ แม้ว่าเราจะพยายามจ้างเจ้าหน้าที่ระบบ แต่ก็เป็นเรื่องยากเพราะแรงงานญี่ปุ่นหดตัวลง  ในอนาคตฉันคาดหวังว่าเครื่องมือระบบจะแทนที่ผู้คนที่ใช้ AI (ปัญญาประดิษฐ์) และฉันหวังว่า SIOS AppKeeper ยังพัฒนาฟังก์ชั่นคล้าย AI เพื่อจัดการกับความล้มเหลวที่มีผลกระทบสูงโดยอัตโนมัติ” นาย Kokubo กล่าว ของการจัดการการดำเนินงานจะรับรู้

เรียนรู้เพิ่มเติมเกี่ยวกับ SIOS AppKeeper

ลงทะเบียนเพื่อทดลองใช้ฟรีของ SIOS AppKeeper

 

 

ความพร้อมใช้งานขององค์กร: บทเรียนจากศาล

ความพร้อมใช้งานขององค์กร: บทเรียนจากศาล

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

ประมาณหนึ่งในสามของการดูฉันไม่สามารถมีตัวเองได้ ฉันผิวปากและ“ แหย่” เด็กสาวคนนั้นหัวเราะครึ้มและวิ่งเหยาะๆศาลและตะโกนว่า“ วิ่ง! เร่งรีบ!" และเธอก็ทำเช่นเดียวกับเพื่อนร่วมทีมในหู  อีกไม่กี่นาทีข้างหน้าบทละครและการฝึกฝนก็เต็มไปด้วยพลังงานการตัดที่คมชัดการเคลื่อนไหวที่ราบรื่นและการขับขี่  แต่มันไม่ได้สุดท้าย  มีความต้องการเสียงนกหวีดที่เน้นหนักกว่าในการเคลื่อนย้ายและวิ่งเล่นอย่างหนักทำให้บาดแผลมีคมดำน้ำสนใจใส่ใจเรียนรู้และแก้ไขให้ถูกต้อง เมื่อเกือบสองชั่วโมงที่ผ่านมาฉันใช้ช่วงเวลาสุดท้ายของการตั้งใจเผยพระวจนะ“ วิธีที่คุณฝึกจะเป็นวิธีที่คุณเล่น!”

ฉันเกือบจะรู้สึกได้ว่าคุณถ่ายทอดจิตวิญญาณของ AI ไม่ใช่ปัญญาประดิษฐ์ (AI), Allen Iverson (AI)  “ เรากำลังพูดถึงเรื่องการปฏิบัติ  ปฏิบัติ!” ฉันคิดว่านี่เป็นเรื่องเกี่ยวกับความพร้อมใช้งาน  ความรักในกีฬาบาสเก็ตบอลของฉันได้พบกับความหลงใหลในตัวฉันเมื่อฉันถือว่าลูกสาวและเพื่อนร่วมทีมของเธอ อย่างไร?

สามวิธีบาสเก็ตบอลเป็นเหมือนกลยุทธ์ความพร้อมใช้งาน:

• ในบาสเก็ตบอลทุกทีมต้องมีแผนรองรับสำหรับความพร้อมขององค์กร
• ในบาสเก็ตบอลทุกทีมจำเป็นต้องฝึกซ้อมแผนนั้นเช่นเดียวกับความพร้อมใช้งานการกู้คืนความเสียหายและการบำรุงรักษาตามแผนที่กำหนดไว้
• ในบาสเก็ตบอลแผนเมื่อทดสอบภายใต้ไฟจะทำให้ได้ผลที่ดีตามแผนนั้นเท่านั้น
  

ความพร้อมใช้งานขององค์กรต้องการแผน 

ความพร้อมใช้งานของคุณโดยเฉพาะความหายนะของคุณการบำรุงรักษาตามแผนและกลยุทธ์การกู้คืนระบบก็ดีเช่นเดียวกับที่คุณสร้างขึ้น กล่าวง่ายๆว่าแผนของคุณเกิดปัญหาไฟดับ (โน้ตเมฆล้มเหลวเซิร์ฟเวอร์ขัดข้องเครือข่ายได้รับการอิ่มตัวและความผิดพลาดของมนุษย์ – เพียงพอที่จะพูด)  คุณมีแผนเอกสารหรือไม่? คุณระบุเจ้าของและเจ้าของสำเนาสำรองหรือไม่ คุณรู้สถาปัตยกรรมและโทโพโลยีของคุณหรือไม่ (เซิร์ฟเวอร์ใดทำอะไรอยู่ที่ใดมันอยู่ในทีมใดมีฟังก์ชั่นอะไรทำหน้าที่จัดลำดับความสำคัญของธุรกิจผูกติดกับอะไรและ SLO / SLA ต้องการอะไร) ใครคือผู้จำหน่ายหลักของคุณและรายการโทรออกของพวกเขาคืออะไร? จุดตรวจแผนป้องกันข้อมูลและกลยุทธ์การสำรองข้อมูลของคุณคืออะไร? และแผนการทดสอบและแผนการตรวจสอบของคุณสำหรับการตรวจสอบของแผนนี้คืออะไร?

ความพร้อมใช้งานขององค์กรต้องการการปฏิบัติ 

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

ความพร้อมใช้งานระดับองค์กรจำเป็นต้องมีการทดสอบ 

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

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

ในบาสเก็ตบอลแผนที่อยู่ภายใต้ไฟจะถือได้ดีเช่นเดียวกับที่ฝึกซ้อม  เมื่อมีการนำแผนการกู้คืนและภัยพิบัติมาใช้แผนและการตรวจสอบที่ดีนั้นเป็นกุญแจสำคัญ แต่การปฏิบัติที่ดีคือกษัตริย์

ติดต่อตัวแทนที่ SIOS เพื่อเรียนรู้ว่าผู้เชี่ยวชาญด้านความพร้อมใช้งานและผลิตภัณฑ์ของเราสามารถช่วยคุณในการวางแผนขั้นตอนและการปฏิบัติอย่างไร

เยี่ยมชมโพสต์หลังการทดสอบที่คุณไม่ควรหลีกเลี่ยงการจำลอง

– Cassius Rhue, VP, ประสบการณ์ของลูกค้า

บทความทำซ้ำจาก SIOS

ทีละขั้นตอน: เซิร์ฟเวอร์เป้าหมาย ISCSI ใน Azure

ทีละขั้นตอน: เซิร์ฟเวอร์เป้าหมาย ISCSI ใน Azure

ฉันเพิ่งช่วยคนสร้างคลัสเตอร์เซิร์ฟเวอร์เป้าหมาย iSCSI ใน Azure และรู้ว่าฉันไม่เคยเขียนคำแนะนำทีละขั้นตอนสำหรับการกำหนดค่านั้น ดังนั้นเพื่อแก้ไขว่านี่คือคำแนะนำทีละขั้นตอนในกรณีที่คุณต้องทำด้วยตัวเอง

requisites ก่อน

ฉันจะสมมติว่าคุณคุ้นเคยกับ Azure และ Windows Server แล้วดังนั้นฉันจะสำรองข้อมูลบางอย่างให้คุณ สมมติว่าคุณได้ทำสิ่งต่อไปนี้เป็นสิ่งที่จำเป็นล่วงหน้าอย่างน้อย

• จัดเตรียมเซิร์ฟเวอร์สองเครื่อง (SQL1, SQL2) แต่ละเครื่องในโซนความพร้อมใช้งานที่แตกต่างกัน (ชุดความพร้อมใช้งานเป็นไปได้ แต่โซนความพร้อมใช้งานมี SLA ที่ดีกว่า)
• กำหนดที่อยู่ IP แบบคงที่ให้กับพวกเขาผ่านพอร์ทัล Azure
• เข้าร่วมเซิร์ฟเวอร์กับโดเมนที่มีอยู่
• เปิดใช้งานคุณสมบัติการทำคลัสเตอร์เข้าแทนที่และคุณสมบัติเซิร์ฟเวอร์เป้าหมาย iSCSI บนทั้งสองโหนด
• เพิ่ม Azure Premium Disk สามตัวสำหรับแต่ละโหนด
  หมายเหตุ: นี่เป็นทางเลือกหนึ่งดิสก์เป็นขั้นต่ำที่จำเป็น สำหรับ IOPS ที่เพิ่มขึ้นเราจะทำแถบดิสก์ Azure แบบพรีเมี่ยมสามตัวพร้อมกันในพูลหน่วยเก็บข้อมูลและสร้างดิสก์เสมือน (RAID 0) แบบง่าย
• SIOS DataKeeper จะถูกใช้เพื่อจัดเตรียมหน่วยความจำที่จำลองแบบแล้วที่ใช้ในคลัสเตอร์ หากคุณต้องการ DataKeeper คุณสามารถขอทดลองใช้ที่นี่

สร้างพูลหน่วยเก็บข้อมูลโลคัล

อีกครั้งขั้นตอนนี้เป็นทางเลือกที่สมบูรณ์ แต่สำหรับ IOPS ที่เพิ่มขึ้นเราจะทำการรวม Azure Premium ดิสก์สามตัวไว้ใน Storage Pool เดียว คุณอาจถูกล่อลวงให้ใช้ Dynamic Disk และไดรฟ์ข้อมูลที่ถูกขยายแทน แต่อย่าทำเช่นนั้น! หากคุณใช้ดิสก์แบบไดนามิกคุณจะพบว่ามีความไม่เข้ากันทั่วไปบางอย่างที่จะป้องกันไม่ให้คุณสร้างเป้าหมาย iSCSI ในภายหลัง

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

ข้อผิดพลาด # 1 – แม้ว่าเอกสารระบุว่าขนาดต่ำสุดสำหรับไดรฟ์ข้อมูลที่จะใช้ในพูลหน่วยเก็บข้อมูลคือ 4 GB แต่ฉันพบว่าไม่รู้จัก P1 Premium Disk (4GB) ดังนั้นในห้องแล็บของฉันฉันใช้ 16GB P3 Premium ดิสก์

ผิดพลาด # 2 – คุณต้องมีดิสก์อย่างน้อยสามแผ่นเพื่อสร้าง Storage Pool

ผิดพลาด # 3 – สร้างสระว่ายน้ำเก็บข้อมูลของคุณก่อนที่จะสร้างคลัสเตอร์ของคุณ ถ้าคุณพยายามทำมันหลังจากที่คุณสร้างคลัสเตอร์ของคุณคุณจะจบลงด้วยความยุ่งเหยิงครั้งใหญ่เนื่องจาก Microsoft พยายามสร้างพูลหน่วยเก็บข้อมูลแบบคลัสเตอร์สำหรับคุณ เราจะไม่สร้างพูลหน่วยเก็บข้อมูลแบบคลัสเตอร์ดังนั้นหลีกเลี่ยงความยุ่งเหยิงนั้นด้วยการสร้าง Storage Pool ของคุณก่อนที่คุณจะสร้างคลัสเตอร์ หากคุณต้องเพิ่ม Storage Pool หลังจากสร้างคลัสเตอร์คุณจะต้องไล่โหนดจากคลัสเตอร์จากนั้นสร้าง Storage Pool

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

คุณควรเห็น Primordial pool บนเซิร์ฟเวอร์ทั้งสอง

คลิกขวาและเลือก New Storage Pool …

เลือกสร้างดิสก์เสมือนเมื่อตัวช่วยสร้างนี้ปิด

สังเกตุที่นี่คุณสามารถสร้างระดับการจัดเก็บถ้าคุณตัดสินใจที่จะใช้การรวมกันของ Standard, Premium และ Ultra SSD

เพื่อประสิทธิภาพที่ดีที่สุดให้ใช้เค้าโครงการจัดเก็บแบบง่าย (RAID 0) ไม่ต้องกังวลเกี่ยวกับความน่าเชื่อถือเนื่องจาก Azure ดิสก์ที่มีการจัดการมีความซ้ำซ้อนสามเท่าในแบ็กเอนด์ จำเป็นต้องใช้ Simple เพื่อประสิทธิภาพที่ดีที่สุด

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

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

ตอนนี้แต่ละเซิร์ฟเวอร์แต่ละตัวมีไดรฟ์ 45 GB X ของตัวเองเรากำลังจะสร้างคลัสเตอร์พื้นฐาน การสร้างคลัสเตอร์ใน Azure ทำได้ดีที่สุดผ่าน Powershell เพื่อให้เราสามารถระบุที่อยู่ IP แบบคงที่ได้ หากคุณทำผ่าน GUI คุณจะรู้ว่า Azure กำหนด IP คลัสเตอร์ของคุณเป็นที่อยู่ IP ที่ซ้ำกันซึ่งคุณจะต้องล้างข้อมูลดังนั้นอย่าทำเช่นนั้น!

นี่คือตัวอย่างของรหัส Powershell เพื่อสร้างคลัสเตอร์ใหม่

 ใหม่คลัสเตอร์ - ชื่อ mycluster -NoStorage -StaticAddress 10.0.0.100 - โหนด sql1, sql2

ผลลัพธ์จะมีลักษณะเช่นนี้

PS C:  Users  dave.DATAKEEPER> คลัสเตอร์ใหม่ - ชื่อ mycluster - NoStorage 
-StaticAddress 10.0.0.100 - โหนด sql1, sql2
คำเตือน: มีปัญหาขณะสร้างบทบาทคลัสเตอร์ที่ 
อาจป้องกันไม่ให้เริ่มต้น 
สำหรับข้อมูลเพิ่มเติมดูไฟล์รายงานด้านล่าง
คำเตือน: รายงานตำแหน่งของไฟล์: C:  windows  cluster  Reports  Create Cluster 
Wizard mycluster เมื่อวันที่ 2020.05.20 
ที่ 16.54.45.htm

ชื่อ     
----     
mycluster

คำเตือนในรายงานจะบอกคุณว่าไม่มีพยาน เนื่องจากไม่มีพื้นที่เก็บข้อมูลที่ใช้ร่วมกันในคลัสเตอร์นี้คุณจะต้องสร้าง Cloud Witness หรือ File Share Witness ฉันจะไม่นำคุณไปสู่กระบวนการดังกล่าวเนื่องจากมีการบันทึกไว้อย่างดีในลิงก์เหล่านั้น

อย่าละทิ้งสิ่งนี้ไปข้างหน้าและสร้างพยานก่อนที่คุณจะย้ายไปยังขั้นตอนต่อไป!

ตอนนี้คุณควรมีคลัสเตอร์ 2 โหนดพื้นฐานที่มีลักษณะดังนี้

กำหนดค่าตัวโหลดบาลานซ์สำหรับที่อยู่ IP หลักของคลัสเตอร์

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

มีสองขั้นตอนในการรับโหลดบาลานเซอร์ที่กำหนดค่าสำหรับคลัสเตอร์ใน Azure ขั้นตอนแรกคือการสร้าง load balancer ขั้นตอนที่สองคือการอัปเดตที่อยู่ IP ของคลัสเตอร์เพื่อรับฟังโพรบสุขภาพของโหลดบาลานซ์และใช้ซับเน็ตมาสก์ 255.255.255.255 ซึ่งช่วยให้คุณหลีกเลี่ยงที่อยู่ IP ที่ขัดแย้งกับ ILB

ก่อนอื่นเราจะสร้างตัวโหลดบาลานซ์สำหรับที่อยู่ IP หลักของคลัสเตอร์ หลังจากนั้นเราจะแก้ไข load balancer เพื่อระบุที่อยู่ IP ของทรัพยากรคลัสเตอร์คลัสเตอร์ iSCSI ที่เราจะสร้างขึ้นในตอนท้ายของเอกสารนี้

ขอให้สังเกตว่าที่อยู่ IP แบบคงที่เราใช้เป็นที่อยู่เดียวกับที่เราใช้ในการสร้างทรัพยากร IP ของคลัสเตอร์หลัก

เมื่อสร้าง load balancer แล้วคุณจะแก้ไข load balancer ดังที่แสดงด้านล่าง

เพิ่มโหนดคลัสเตอร์สองโหนดเข้ากับพูลแบ็คเอนด์

เพิ่มโหนดคลัสเตอร์สองโหนดเข้ากับพูลแบ็คเอนด์

เพิ่มโพรบเพื่อสุขภาพ ในตัวอย่างนี้เราใช้ 59999 เป็นพอร์ต โปรดจำไว้ว่าพอร์ตเราจะต้องใช้ในขั้นตอนต่อไป

สร้าง rue ใหม่เพื่อเปลี่ยนเส้นทางพอร์ต HA ทั้งหมดตรวจสอบให้แน่ใจว่า IP แบบลอยได้เปิดใช้งานแล้ว

ขั้นตอนที่ 2 – แก้ไขกลุ่มที่อยู่ IP ของแกนทำงานกับเครื่องชั่งแบบโหลดได้

ดังที่ฉันได้กล่าวไว้ก่อนหน้านี้มีสองขั้นตอนในการเรียกใช้ load balancer ที่กำหนดค่าให้ทำงานอย่างถูกต้อง ตอนนี้เรามี load balancer เราต้องรันสคริปต์ Powershell บนหนึ่งในโหนดคลัสเตอร์ ต่อไปนี้เป็นสคริปต์ตัวอย่างที่ต้องรันบนหนึ่งในโหนดคลัสเตอร์

$ ClusterNetworkName =“ เครือข่ายคลัสเตอร์ 1” 
$ IPResourceName =“ ที่อยู่ IP ของคลัสเตอร์” 
$ ILBIP =“ 10.0.0.100” 
Import-Module FailoverClusters
รับ - ClusterResource $ IPResourceName | ชุด ClusterParameter 
-Multiple @ {ที่อยู่ = $ ILBIP; ProbePort = 59998; SubnetMask = "255.255.255.255"
; เครือข่าย = $ ClusterNetworkName; EnableDHCP = 0} 

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

หลังจากที่คุณเรียกใช้ผลลัพธ์ควรมีลักษณะเช่นนี้

 PS C:  Users  dave.DAKEEPER> $ ClusterNetworkName =“ เครือข่ายคลัสเตอร์ 1” 
$ IPResourceName =“ ที่อยู่ IP ของคลัสเตอร์” 
$ ILBIP =“ 10.0.0.100” 
Import-Module FailoverClusters
รับ - ClusterResource $ IPResourceName | ชุด ClusterParameter 
-Multiple @ {ที่อยู่ = $ ILBIP; ProbePort = 59999; SubnetMask = "255.255.255.255"
; เครือข่าย = $ ClusterNetworkName; EnableDHCP = 0}
คำเตือน: คุณสมบัติถูกเก็บไว้ แต่การเปลี่ยนแปลงบางอย่างจะไม่มีผล 
จนกว่าที่อยู่ IP ของคลัสเตอร์จะออฟไลน์จากนั้นออนไลน์อีกครั้ง

คุณจะต้องใช้ทรัพยากรหลักของคลัสเตอร์ IP แบบออฟไลน์และนำกลับมาออนไลน์อีกครั้งก่อนที่จะทำงานได้อย่างถูกต้องกับ load balancer

สมมติว่าคุณทำทุกอย่างถูกต้องในการสร้าง load balancer ของคุณ Server Manager ของคุณบนเซิร์ฟเวอร์ทั้งสองควรแสดงรายการคลัสเตอร์ของคุณเป็นออนไลน์ดังที่แสดงด้านล่าง

ตรวจสอบ Server Manager บนโหนดคลัสเตอร์ทั้งสอง คลัสเตอร์ของคุณควรแสดงเป็น“ ออนไลน์” ภายใต้การจัดการ

ติดตั้ง DataKeeper

ฉันจะไม่ทำตามทุกขั้นตอนที่นี่ แต่โดยพื้นฐานแล้ว ณ จุดนี้คุณพร้อมที่จะติดตั้ง SIOS DataKeeper บนโหนดคลัสเตอร์ทั้งสอง เป็นการตั้งค่าที่ค่อนข้างง่ายเพียงแค่เรียกใช้การตั้งค่าและเลือกค่าเริ่มต้นทั้งหมด หากคุณพบปัญหาใด ๆ กับ DataKeeper มันมักจะเป็นหนึ่งในสองสิ่ง ปัญหาแรกคือบัญชีบริการ คุณต้องตรวจสอบให้แน่ใจว่าบัญชีที่คุณใช้เพื่อเรียกใช้บริการ DataKeeper อยู่ในกลุ่ม Local Administrators ของแต่ละโหนด

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

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

ใช้อินเทอร์เฟซ DataKeeper เพื่อเชื่อมต่อกับเซิร์ฟเวอร์ทั้งสอง

คลิกที่สร้างงานใหม่และตั้งชื่อ

คลิกใช่เพื่อลงทะเบียนไดรฟ์ข้อมูล DataKeeper ในคลัสเตอร์

เมื่อมีการลงทะเบียนไดรฟ์ข้อมูลจะปรากฏในที่เก็บข้อมูลที่พร้อมใช้งานใน Failover Cluster Manager

สร้างคลัสเตอร์เซิร์ฟเวอร์เป้าหมาย ISCSI

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

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

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

ตอนนี้คุณควรจะสามารถนำทรัพยากรคลัสเตอร์ iSCSI มาออนไลน์ได้แล้ว

ปรับปรุงตัวโหลดบาลานซ์สำหรับทรัพยากรคลัสเตอร์เซิร์ฟเวอร์เป้าหมายของ ISCSI

อย่างที่ฉันได้กล่าวไปแล้วลูกค้าไม่สามารถเชื่อมต่อโดยตรงกับที่อยู่ IP ของคลัสเตอร์ (10.0.0.110) ที่เราเพิ่งสร้างขึ้นสำหรับเซิร์ฟเวอร์เป้าหมาย iSCSI เราจะต้องอัปเดตตัวโหลดบาลานซ์ที่เราสร้างไว้ก่อนหน้าดังที่แสดงด้านล่าง

เริ่มต้นด้วยการเพิ่มที่อยู่ IP ส่วนหน้าใหม่ที่ใช้ที่อยู่ IP เดียวกันกับที่ใช้ทรัพยากร IP ของคลัสเตอร์เป้าหมาย iSCSI

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

เราเพิ่มกฎการปรับสมดุลภาระเพิ่มอีกหนึ่งข้อ ตรวจสอบให้แน่ใจว่าเปลี่ยนที่อยู่ IP ของ Frontend และ Health probe เพื่อใช้ที่อยู่ที่เราเพิ่งสร้างขึ้น ตรวจสอบให้แน่ใจด้วยว่าเปิดใช้งานการส่งคืนเซิร์ฟเวอร์โดยตรง

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

 $ ClusterNetworkName =“ เครือข่ายคลัสเตอร์ 1” 
$ IPResourceName =“ ที่อยู่ IP 10.0.0.0” 
$ ILBIP =“ 10.0.0.110” 
Import-Module FailoverClusters
รับ - ClusterResource $ IPResourceName | ชุด ClusterParameter 
-Multiple @ {ที่อยู่ = $ ILBIP; ProbePort = 59998; SubnetMask = "255.255.255.255"
; เครือข่าย = $ ClusterNetworkName; EnableDHCP = 0} 

ผลลัพธ์ของคุณควรมีลักษณะเช่นนี้

 PS C:  Users  dave.DAKEEPER> $ ClusterNetworkName =“ เครือข่ายคลัสเตอร์ 1” 
$ IPResourceName =“ ที่อยู่ IP 10.0.0.0” 
$ ILBIP =“ 10.0.0.110” 
Import-Module FailoverClusters
รับ - ClusterResource $ IPResourceName | ชุด ClusterParameter 
-Multiple @ {ที่อยู่ = $ ILBIP; ProbePort = 59998; SubnetMask = "255.255.255.255"
; เครือข่าย = $ ClusterNetworkName; EnableDHCP = 0}
คำเตือน: คุณสมบัติถูกเก็บไว้ แต่การเปลี่ยนแปลงบางอย่างจะไม่มีผล 
จนกว่าที่อยู่ IP 10.0.0.0 จะออฟไลน์และออนไลน์อีกครั้ง

ตรวจสอบให้แน่ใจว่าใช้ทรัพยากรออฟไลน์และออนไลน์เพื่อให้การตั้งค่ามีผล

สร้างเป้าหมาย ISCSI แบบกลุ่มของคุณ

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

หากเซิร์ฟเวอร์ใดมีปัญหาในการสอบถามชื่อคลัสเตอร์เหล่านั้นขั้นตอนต่อไปจะล้มเหลว หากมีปัญหาฉันจะตรวจสอบทุกขั้นตอนอีกครั้งเพื่อสร้าง load balancer และสคริปต์ Powershell ที่คุณรัน

ตอนนี้เราพร้อมที่จะสร้างเป้าหมาย iSCSI คลัสเตอร์แรกของเรา จากโหนดคลัสเตอร์อย่างใดอย่างหนึ่งทำตามขั้นตอนที่แสดงด้านล่างเป็นตัวอย่างเกี่ยวกับวิธีการสร้างเป้าหมาย iSCSI

แน่นอนว่าต้องกำหนดสิ่งนี้ให้กับเซิร์ฟเวอร์หรือเซิร์ฟเวอร์ใดก็ตามที่จะเชื่อมต่อกับ iSSI เป้าหมายนี้

และที่นั่นคุณก็มีตอนนี้คุณมีเซิร์ฟเวอร์เป้าหมาย iSCSI ที่ใช้งานได้ใน Azure

หากคุณสร้างสิ่งนี้ออกความคิดเห็นและฉันรู้ว่าคุณวางแผนที่จะใช้มัน!

บทความที่ทำซ้ำได้รับอนุญาตจาก Clusteringwithmeremortals

บทสรุปโซลูชัน: กลุ่ม SANless สำหรับสภาพแวดล้อมคลาวด์คลาวด์

บทสรุปโซลูชัน: กลุ่ม SANless สำหรับสภาพแวดล้อมคลาวด์คลาวด์

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

ความยืดหยุ่นในการกำหนดค่า

ไม่ว่าคุณต้องการปกป้องแอปพลิเคชั่นในเซิร์ฟเวอร์ทางกายภาพ, คลาวด์ส่วนตัวภายในองค์กรของคุณ, ในระบบคลาวด์สาธารณะหรือไฮบริดคลาวด์, ซอฟต์แวร์ SIOS SANless ช่วยให้คุณมีความยืดหยุ่นในการสร้างคลัสเตอร์อัตโนมัติ ของฮาร์ดแวร์มาตรฐานอุตสาหกรรมสกีมาเรพลิเคชันและการนำไปใช้งาน (active / active, active / passive)

ซอฟต์แวร์ SIOS ช่วยให้คุณทำซ้ำระหว่างการกำหนดค่าที่คุณเลือก – ระหว่างสภาพแวดล้อม SAN และ SANless และการรวมกันของการกำหนดค่าทางกายภาพเสมือนและระบบคลาวด์ ไม่มีล็อคผู้ขาย ไม่จำเป็นต้องใช้ฮาร์ดแวร์เหมือนกันที่ต้นทางและปลายทาง

ง่ายต่อการใช้. ง่ายต่อการเป็นเจ้าของ

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

ประโยชน์ที่สำคัญ

การป้องกันภัยพิบัติ

•ใช้งานง่ายประหยัดค่าใช้จ่ายสูงและการป้องกันภัยพิบัติสำหรับแอปพลิเคชันที่สำคัญทางธุรกิจ

มีความยืดหยุ่น

•ผสมผสานสภาพแวดล้อมเซิร์ฟเวอร์และระบบคลาวด์เพื่อประสิทธิภาพสูงสุด

สะดวกในการใช้

•คอนโซลที่ใช้งานง่ายเพื่อการตรวจสอบและการจัดการอย่างต่อเนื่อง

ดาวน์โหลดบทสรุปโซลูชันบน SANless Clusters สำหรับ Hybrid Cloud En Environment

บทสรุปโซลูชัน: โซลูชั่น SANless Cluster สำหรับสภาพแวดล้อมเซิร์ฟเวอร์เสมือน

บทสรุปโซลูชัน: โซลูชั่น SANless Cluster สำหรับสภาพแวดล้อมเซิร์ฟเวอร์เสมือน

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

เครื่องเสมือนคลัสเตอร์

ซอฟต์แวร์ SIOS SANless ช่วยให้คุณสร้างคลัสเตอร์โดยใช้เครื่องเสมือนซึ่งอยู่ด้านบนของไฮเปอร์ไวเซอร์ใด ๆ (VMware, Xen, Microsoft Hyper-V และอื่น ๆ ) โดยใช้การจำลองแบบเรียลไทม์เพื่อซิงโครไนซ์ที่เก็บข้อมูลบน VM หลักกับที่เก็บข้อมูลบน VM สแตนด์บายที่อยู่ในศูนย์ข้อมูลเดียวกันในไซต์กู้คืนความเสียหายหรือทั้งสอง ในกรณีที่เกิดภัยพิบัติ VM สแตนด์บายสามารถให้บริการได้ทันทีโดยไม่ต้องใช้เวลาในการเรียกคืนจากสื่อสำรองข้อมูล คุณเพียงแค่เข้าถึง VM ที่จำลองแบบแล้วในไซต์ DR โดยตรง

การทำคลัสเตอร์โฮสต์ Hyper-V ที่รองรับ Live Migrations

ในสภาพแวดล้อม Microsoft Hyper-V ซอฟต์แวร์ SIOS SANless ช่วยให้คุณสามารถจัดกลุ่มเครื่องโฮสต์ Hyper-V ทั้งหมดที่ระดับไฮเปอร์ไวเซอร์เพื่อการพกพา VM ที่สมบูรณ์และการป้องกันความล้มเหลว ด้วยการเก็บสำเนา VM ที่ทำงานอยู่แบบเรียลไทม์บนโฮสต์ Hyper-V สำรองซอฟต์แวร์ SIOS ช่วยให้คุณสามารถล้มเหลวได้อย่างง่ายดายหรือ Live Migrate VM จากโฮสต์ Hyper-V หนึ่งไปยังอีกโฮสต์หนึ่ง คุณได้รับการพกพาที่สมบูรณ์เพื่อย้าย VM แต่ละรายการหรือ VM ทั้งหมดบนโฮสต์ไปยังโฮสต์ Hyper-V อื่นในคลัสเตอร์

สร้างคลัสเตอร์ SIOS SANless โดยใช้เซิร์ฟเวอร์เสมือน (A) ในสภาพแวดล้อม Microsoft Hyper-V (B), SIOS SANless clusters สามารถใช้ที่ระดับเครื่องเสมือนเพื่อการโยกย้ายสดแบบง่ายและการพกพาเซิร์ฟเวอร์ที่สมบูรณ์

การทดสอบการกู้คืนความเสียหายง่าย ๆ

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

ดาวน์โหลดบทสรุปโซลูชันบนโซลูชัน SANless Cluster สำหรับสภาพแวดล้อมเซิร์ฟเวอร์เสมือน