มิถุนายน 3, 2022 |
ประโยชน์ของ SIOS Protection Suite/LifeKeeper สำหรับ Linuxประโยชน์ของ SIOS Protection Suite/LifeKeeper สำหรับ Linux
ทำซ้ำโดยได้รับอนุญาตจาก SIOS |
|||||||||||||||||||||
พฤษภาคม 29, 2022 |
SIOS Protection Suite/LifeKeeper for Linux – ส่วนประกอบแบบบูรณาการSIOS Protection Suite/LifeKeeper for Linux – ส่วนประกอบแบบบูรณาการSIOS Protection Suite ประกอบด้วยส่วนประกอบซอฟต์แวร์ต่อไปนี้เพื่อปกป้องระบบภารกิจสำคัญขององค์กร SIOS ผู้ช่วยชีวิตSIOS LifeKeeper ให้บริการ a เสร็จสิ้น ซอฟต์แวร์แก้ไขข้อบกพร่อง ที่ช่วยให้มีความพร้อมใช้งานสูงสำหรับเซิร์ฟเวอร์ ระบบไฟล์ แอปพลิเคชัน และกระบวนการ LifeKeeper ไม่ต้องการฮาร์ดแวร์ที่ปรับแต่งเองได้และทนต่อข้อผิดพลาด LifeKeeper ต้องการเพียงสองระบบขึ้นไปเพื่อจัดกลุ่มในเครือข่าย จากนั้นข้อมูลการกำหนดค่าเฉพาะไซต์จะถูกสร้างขึ้นเพื่อให้ การตรวจจับและกู้คืนข้อผิดพลาดอัตโนมัติ . ในกรณีที่เกิดความล้มเหลว LifeKeeper จะย้ายทรัพยากรที่ได้รับการปกป้องจากเซิร์ฟเวอร์ที่ล้มเหลวไปยังเซิร์ฟเวอร์สแตนด์บายที่กำหนด ผู้ใช้พบการหยุดชะงักชั่วครู่ระหว่างการเปลี่ยนผ่านจริง อย่างไรก็ตาม LifeKeeper จะกู้คืนการทำงานบนเซิร์ฟเวอร์สำรองโดยไม่ต้องให้เจ้าหน้าที่ดำเนินการใดๆ SIOS DataKeeperSIOS DataKeeper ให้ความสามารถในการจำลองข้อมูลแบบบูรณาการสำหรับสภาพแวดล้อม LifeKeeper ฟีเจอร์นี้ช่วยให้ทรัพยากร LifeKeeper ทำงานได้ใน สภาพแวดล้อมการจัดเก็บข้อมูลแบบใช้ร่วมกันและไม่แบ่งใช้ . ชุดกู้คืนแอปพลิเคชัน ( อาร์ค ส)ชุดกู้คืนแอปพลิเคชัน ( อาร์ค s) รวมเครื่องมือและยูทิลิตี้ที่อนุญาตให้ LifeKeeper จัดการและควบคุมแอปพลิเคชันหรือบริการเฉพาะ เมื่อ อาร์ค ได้รับการติดตั้งสำหรับแอปพลิเคชันเฉพาะ LifeKeeper สามารถตรวจสอบความสมบูรณ์ของแอปพลิเคชันและกู้คืนแอปพลิเคชันโดยอัตโนมัติหากล้มเหลว ชุดการกู้คืนเหล่านี้ไม่ล่วงล้ำและไม่ต้องทำการเปลี่ยนแปลงภายในแอปพลิเคชันเพื่อให้ LifeKeeper ปกป้อง มีคลังชุดกู้คืนแอปพลิเคชัน 'นอกชั้นวาง' ที่ครอบคลุมซึ่งเป็นส่วนหนึ่งของ SIOS ผลงานชุดป้องกัน ชนิดและปริมาณของ อาร์ค s ที่ให้มาแตกต่างกันไปตามรุ่นของ SIOS ซื้อชุดป้องกันแล้ว ทำซ้ำโดยได้รับอนุญาตจาก SIOS |
|||||||||||||||||||||
พฤษภาคม 25, 2022 |
ความพร้อมใช้งานสูง RTO และ RPOความพร้อมใช้งานสูง RTO และ RPOความพร้อมใช้งานสูง (HA) เป็นคำศัพท์ด้านเทคโนโลยีสารสนเทศที่อ้างถึงซอฟต์แวร์คอมพิวเตอร์หรือส่วนประกอบที่ใช้งานได้และพร้อมใช้งานมากกว่า 99.99% ของเวลาทั้งหมด ผู้ใช้ปลายทางของแอปพลิเคชันหรือระบบ มีประสบการณ์การหยุดชะงักของบริการน้อยกว่า 52.5 นาทีต่อปี ความพร้อมใช้งานในระดับนี้โดยทั่วไปทำได้โดยใช้คลัสเตอร์ที่มีความพร้อมใช้งานสูง การกำหนดค่าที่ช่วยลดเวลาหยุดทำงานของแอปพลิเคชันโดยกำจัดจุดล้มเหลวเพียงจุดเดียวผ่านการใช้เซิร์ฟเวอร์สำรอง เครือข่าย ที่เก็บข้อมูล และซอฟต์แวร์ วัตถุประสงค์ของเวลาพักฟื้นคืออะไร ( RTO ) และวัตถุประสงค์ของจุดพักฟื้น ( RPO )?นอกเหนือจากเวลาพร้อมใช้งาน 99.99% แล้ว สภาพแวดล้อมที่มีความพร้อมใช้งานสูง ยังตรงตามเป้าหมายเวลาพักฟื้นและจุดพักฟื้นที่เข้มงวด วัตถุประสงค์เวลาพักฟื้น ( RTO ) เป็นการวัดเวลาที่ผ่านไปตั้งแต่ความล้มเหลวของแอปพลิเคชันไปจนถึงการกู้คืนการทำงานและความพร้อมใช้งานของแอปพลิเคชัน เป็นการวัดระยะเวลาที่บริษัทสามารถรับใบสมัครนั้นได้ วัตถุประสงค์ของจุดพักฟื้น ( RPO ) เป็นการวัดว่าข้อมูลเป็นปัจจุบันเพียงใดเมื่อมีการกู้คืนความพร้อมใช้งานของแอปพลิเคชันหลังจากปัญหาการหยุดทำงาน มักถูกอธิบายว่าเป็นปริมาณการสูญเสียข้อมูลสูงสุดที่สามารถยอมรับได้เมื่อเกิดความล้มเหลวขึ้นSIOS คลัสเตอร์ที่มีความพร้อมใช้งานสูงส่งมอบ an RPO ของศูนย์และ an RTO นาที. คลัสเตอร์ที่มีความพร้อมใช้งานสูงคืออะไรในคลัสเตอร์ที่มีความพร้อมใช้งานสูง แอปพลิเคชันที่สำคัญจะทำงานบนโหนดเซิร์ฟเวอร์หลัก ซึ่งเชื่อมต่อกับโหนดรองอย่างน้อยหนึ่งโหนดเพื่อความซ้ำซ้อน ซอฟต์แวร์คลัสเตอร์ เช่น SIOS LifeKeeper ตรวจสอบแอปพลิเคชันแบบคลัสเตอร์และทรัพยากรที่เกี่ยวข้องเพื่อให้แน่ใจว่าทำงานบนโหนดที่ใช้งานอยู่ การตรวจสอบระดับระบบทำได้โดยใช้ฮาร์ตบีตแบบช่วงเวลาระหว่างโหนดคลัสเตอร์ ถ้าเซิร์ฟเวอร์หลักล้มเหลว เซิร์ฟเวอร์รองจะเริ่มการกู้คืนหลังจากเกินช่วงหมดเวลาของฮาร์ทบีต สำหรับความล้มเหลวในระดับแอปพลิเคชัน ซอฟต์แวร์การทำคลัสเตอร์จะตรวจพบว่าแอปพลิเคชันไม่พร้อมใช้งานบนโหนดที่ทำงานอยู่ จากนั้นจะย้ายแอปพลิเคชันและทรัพยากรที่ขึ้นต่อกันไปยังโหนดรองในกระบวนการที่เรียกว่าเฟลโอเวอร์ โดยที่การดำเนินการจะดำเนินต่อไปและเป็นไปตามข้อกำหนดที่เข้มงวด RTO ส. ในคลัสเตอร์ failover แบบดั้งเดิม โหนดทั้งหมดในคลัสเตอร์จะเชื่อมต่อกับที่เก็บข้อมูลที่ใช้ร่วมกันเดียวกัน โดยทั่วไปจะเป็นเครือข่ายพื้นที่เก็บข้อมูล ( ซาน ). หลังจากเฟลโอเวอร์ โหนดรองจะได้รับสิทธิ์เข้าถึงที่เก็บข้อมูลที่ใช้ร่วมกัน ทำให้สามารถปฏิบัติตามข้อกำหนดที่เข้มงวด RPO ส. ทำซ้ำโดยได้รับอนุญาตจาก SIOS
|
|||||||||||||||||||||
พฤษภาคม 21, 2022 |
คู่มือการประเมิน SIOS Protection Suite สำหรับ Linux สำหรับสภาพแวดล้อม AWS Cloudคู่มือการประเมิน SIOS Protection Suite สำหรับ Linux สำหรับสภาพแวดล้อม AWS Cloudเริ่มต้นการประเมิน SIOS Protection Suite สำหรับ Linux ใน AWSใช้คำแนะนำทีละขั้นตอนนี้เพื่อกำหนดค่าและทดสอบคลัสเตอร์สองโหนดใน AWS เพื่อปกป้องทรัพยากร เช่น Oracle, SQL Server, PostgreSQL, NFS, SAP และ SAP HANA ก่อนที่คุณจะเริ่มการประเมินของคุณตรวจสอบลิงก์เหล่านี้เพื่อทำความเข้าใจแนวคิดหลักที่คุณต้องการก่อนเริ่มโครงการคลัสเตอร์เมื่อเกิดข้อผิดพลาดใน AWS
การกำหนดค่าส่วนประกอบเครือข่ายส่วนนี้สรุปทรัพยากรการคำนวณที่จำเป็นสำหรับแต่ละโหนด โครงสร้างเครือข่าย และกระบวนการที่จำเป็นในการกำหนดค่าส่วนประกอบเหล่านี้
การสร้างอินสแตนซ์บน AWS EC2 จาก Scratch
กำหนดค่า Linux Nodes เพื่อเรียกใช้ SIOS Protection Suite สำหรับ Linuxติดตั้ง SIOS Protection Suite สำหรับ Linuxเข้าสู่ระบบและการกำหนดค่าพื้นฐานการปกป้องทรัพยากรที่สำคัญเมื่อทรัพยากร IP ได้รับการป้องกันแล้ว ให้เริ่มต้นสวิตช์ (โดยที่โหนด "สแตนด์บาย" จะกลายเป็นโหนด "ใช้งานอยู่") เพื่อทดสอบการทำงาน |
|||||||||||||||||||||
พฤษภาคม 16, 2022 |
ประสิทธิภาพของ Azure Shared Disk พร้อม Zone Redundant Storage (ZRS)ประสิทธิภาพของ Azure Shared Disk พร้อม Zone Redundant Storage (ZRS)เมื่อวันที่ 9 กันยายน 2564 Microsoft ประกาศ ความพร้อมใช้งานทั่วไปของ Zone-Redundant Storage (ZRS) สำหรับ Azure Disk Storage รวมถึง Azure Shared Disk สิ่งที่ทำให้สิ่งนี้น่าสนใจคือตอนนี้คุณสามารถสร้างอินสแตนซ์คลัสเตอร์ล้มเหลวที่จัดเก็บข้อมูลที่ใช้ร่วมกันซึ่งครอบคลุม Availability Zone (AZ)ด้วยโหนดคลัสเตอร์ที่อยู่ใน AZ ต่างๆ ผู้ใช้จึงมีสิทธิ์ได้รับ SLA ความพร้อมใช้งาน 99.99% ก่อนที่จะรองรับ Zone Redundant Storage นั้น Azure Shared Disks รองรับ Locally Redundant Storage (LRS) เท่านั้น ซึ่งจำกัดการปรับใช้คลัสเตอร์เป็น AZ เดียว ทำให้ผู้ใช้เสี่ยงต่อไฟดับหาก AZ ออฟไลน์ อย่างไรก็ตาม มีข้อจำกัดบางประการที่ต้องระวังเมื่อปรับใช้ Azure Shared Disk กับ ZRS
ฉันยังพบบันทึกที่น่าสนใจใน เอกสาร . “ยกเว้นเวลาแฝงในการเขียนที่มากขึ้น ดิสก์ที่ใช้ ZRS จะเหมือนกับดิสก์ที่ใช้ LRS โดยมีเป้าหมายขนาดเดียวกัน เปรียบเทียบดิสก์ของคุณเพื่อจำลองปริมาณงานของแอปพลิเคชันของคุณและเปรียบเทียบเวลาแฝงระหว่างดิสก์ LRS และ ZRS” แม้ว่าเอกสารประกอบจะระบุว่า ZRS จะทำให้เกิดเวลาในการตอบสนองในการเขียนเพิ่มเติม แต่ก็ขึ้นอยู่กับผู้ใช้ที่จะกำหนดว่าพวกเขาสามารถคาดหวังเวลาในการตอบสนองเพิ่มเติมได้มากเพียงใด ลิงก์ไปยัง มาตรฐานดิสก์ เอกสารนี้จัดทำขึ้นเพื่อช่วยแนะนำคุณในการทดสอบประสิทธิภาพของคุณ ตามคำแนะนำในเอกสาร ฉันใช้ DiskSpd เพื่อวัดเวลาแฝงในการเขียนเพิ่มเติมที่คุณอาจพบ แน่นอนว่าผลลัพธ์จะแตกต่างกันไปตามปริมาณงาน ประเภทดิสก์ ขนาดอินสแตนซ์ ฯลฯ แต่นี่คือผลลัพธ์ของฉัน
การทดสอบ DiskSpd ที่ฉันเรียกใช้ใช้พารามิเตอร์ต่อไปนี้ diskspd -c200G -w100 -b8K -F8 -r -o5 -W30 -d10 -Sh -L testfile.dat ฉันเขียนไปยังดิสก์ P30 ที่มี ZRS และ P30 พร้อม LRS ที่ต่อกับ Standard DS3 v2 (4 vcpus, หน่วยความจำ 14 GiB ) ประเภทอินสแตนซ์ นอกจากนี้ ZRS P30 ที่แชร์ยังแนบกับอินสแตนซ์ที่เหมือนกันใน AZ อื่น และเพิ่มเป็นที่จัดเก็บข้อมูลที่ใช้ร่วมกันในแอปพลิเคชันคลัสเตอร์ที่ว่างเปล่า ค่าใช้จ่าย 2% ดูเหมือนจะเป็นราคาที่สมเหตุสมผลที่จะจ่ายเพื่อให้ข้อมูลของคุณกระจายพร้อมกันใน AZ สองแห่ง อย่างไรก็ตาม ฉันสงสัยว่าจะเกิดอะไรขึ้นหากคุณย้ายแอปพลิเคชันแบบคลัสเตอร์ไปยังโหนดระยะไกล โดยทำให้ดิสก์ของคุณอยู่ใน AZ เดียวและอินสแตนซ์ของคุณใน AZ อื่น นี่คือผลลัพธ์
ในสถานการณ์นั้น ฉันวัดเวลาแฝงในการเขียนที่เพิ่มขึ้น 25% หากคุณพบความล้มเหลวโดยสมบูรณ์ของ AZ ทั้งพื้นที่จัดเก็บและอินสแตนซ์จะเฟลโอเวอร์ไปยัง AZ สำรอง และคุณไม่ควรพบกับเวลาแฝงที่เพิ่มขึ้นนี้เลย อย่างไรก็ตาม สถานการณ์ความล้มเหลวอื่นๆ ที่ไม่ได้ครอบคลุม AZ อาจทำให้แอปพลิเคชันแบบคลัสเตอร์ของคุณทำงานใน AZ เดียวโดยมี Azure Shared Disk ทำงานใน AZ อื่น ในสถานการณ์เหล่านี้ คุณจะต้องย้ายเวิร์กโหลดแบบคลัสเตอร์ของคุณกลับไปยังโหนดที่อยู่ใน AZ เดียวกันกับที่เก็บข้อมูลของคุณโดยเร็วที่สุดเพื่อหลีกเลี่ยงโอเวอร์เฮดเพิ่มเติม Microsoft เอกสารวิธีการ เริ่มต้นความล้มเหลวของบัญชีการจัดเก็บ ไปยังภูมิภาคอื่นเมื่อใช้ GRS แต่ไม่มีวิธีเริ่มต้นการเฟลโอเวอร์ของบัญชีพื้นที่จัดเก็บด้วยตนเองไปยัง AZ อื่นเมื่อใช้ Zone Redundant Storage คุณควรตรวจสอบอินสแตนซ์ของคลัสเตอร์ที่ล้มเหลวเพื่อให้แน่ใจว่าคุณได้รับการแจ้งเตือนทุกครั้งที่ปริมาณงานของคลัสเตอร์ย้ายไปที่เซิร์ฟเวอร์อื่น และวางแผนที่จะย้ายกลับทันทีที่ปลอดภัย คุณสามารถพบว่าตัวเองอยู่ในสถานการณ์นี้โดยไม่คาดคิด แต่จะเกิดขึ้นอย่างแน่นอนในระหว่างการบำรุงรักษาที่วางแผนไว้ของแอปพลิเคชันเซิร์ฟเวอร์แบบคลัสเตอร์เมื่อคุณทำการอัปเดตทีละน้อย การรับรู้เป็นกุญแจสำคัญที่จะช่วยให้คุณลดระยะเวลาที่จัดเก็บข้อมูลของคุณในสถานะที่เสื่อมโทรมลง ฉันหวังว่าในอนาคต Microsoft จะอนุญาตให้ผู้ใช้เริ่มต้นการเฟลโอเวอร์ด้วยตนเองของดิสก์ ZRS เช่นเดียวกับที่ทำกับ GRS เหตุผลที่พวกเขาเพิ่มคุณลักษณะนี้ให้กับ GRS ก็คือการให้อำนาจแก่ผู้ใช้ในกรณีที่เกิดข้อผิดพลาดโดยอัตโนมัติไม่เกิดขึ้นตามที่คาดไว้ ในกรณีของ Zone Redundant Storage ฉันเห็นว่าผู้คนต้องการลองเชื่อมโยงพื้นที่จัดเก็บและแอปพลิเคชันเข้าด้วยกัน เพื่อให้มั่นใจว่าพวกเขาจะทำงานใน AZ เดียวกันเสมอ คล้ายกับวิธีที่โซลูชันการจำลองแบบอิงโฮสต์ เช่น SIOS DataKeeper ทำ |