วิดีโอ: TechStrongTV: เสริมศักยภาพผู้ดูแลระบบคลัสเตอร์ HA ด้วย Aaron West จาก SIOS Technology

ในการสัมภาษณ์ผ่านวิดีโอนี้ Aaron West วิศวกรฝ่ายขายของ SIOS Technology กล่าวถึงการเปิดตัวของ SIOS Technologyคอนโซลการจัดการเว็บ LifeKeeper ใหม่– องค์กรต่างๆ ต้องพึ่งพาระบบที่สำคัญอย่าง SAP, HANA และ Oracle เป็นอย่างมาก ซึ่งทำให้มีความแข็งแกร่งความพร้อมใช้งานสูงและการกู้คืนระบบการแก้ปัญหา (HA/DR) จำเป็น ความซับซ้อนของสภาพแวดล้อมเหล่านี้มักจะเกินกว่าความเชี่ยวชาญของทีมไอทีภายในองค์กร ซึ่งนำไปสู่การหยุดทำงานและการสูญเสียทางการเงินที่อาจเกิดขึ้น Aaron แบ่งปันวิธีที่ SIOS เน้นย้ำถึงการเสริมศักยภาพให้กับผู้ดูแลระบบไอทีทั่วไป เพื่อให้มั่นใจว่าฟังก์ชันการทำงานจะไม่หยุดชะงักของระบบที่สำคัญ

ชมการสัมภาษณ์ที่นี่–

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

รักษา HA และ DR เมื่อแปลงคลัสเตอร์การจัดเก็บข้อมูลที่ใช้ร่วมกันเป็นคลัสเตอร์ SANless ด้วย DataKeeper

1. เตรียมสิ่งแวดล้อม

• สำรองข้อมูล: ตรวจสอบให้แน่ใจว่าคุณได้สำรองข้อมูลที่จัดเก็บข้อมูลที่ใช้ร่วมกันในปัจจุบันไว้อย่างสมบูรณ์
• ติดตั้ง DataKeeper: ดาวน์โหลดและติดตั้งโปรแกรมรักษาข้อมูล SIOSCluster Edition บนโหนดทั้งสองของคลัสเตอร์ของคุณ
• การเปิดใช้งานใบอนุญาต: เปิดใช้งานใบอนุญาต DataKeeper บนทั้งสองโหนด

2. ทำให้คลัสเตอร์การจัดเก็บข้อมูลที่ใช้ร่วมกันเข้าสู่โหมดการบำรุงรักษา

• โหมดการบำรุงรักษา: ทำให้คลัสเตอร์เข้าสู่โหมดการบำรุงรักษาเพื่อป้องกันการเปลี่ยนแปลงใดๆ ในระหว่างกระบวนการกำหนดค่า

3. ปรับการเข้าถึงดิสก์ที่ใช้ร่วมกัน

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

4. ลบทรัพยากรดิสก์คลัสเตอร์การจัดเก็บข้อมูลที่ใช้ร่วมกัน

• ลบทรัพยากร: ลบทรัพยากรดิสก์คลัสเตอร์ออกจากการกำหนดค่าคลัสเตอร์โดยสมบูรณ์ รวมถึงพื้นที่เก็บข้อมูลที่มีอยู่

5. เพิ่มดิสก์ในเครื่องบนโหนดรอง

• เพิ่มดิสก์ในเครื่อง: เพิ่มดิสก์ในเครื่องเพิ่มเติมให้กับโหนดรอง ดิสก์นี้ควรมีขนาดเท่ากันและมีอักษรระบุไดรฟ์เหมือนกับดิสก์ที่ใช้ร่วมกันดั้งเดิม
• ฟอร์แมตดิสก์ในเครื่อง: ฟอร์แมตดิสก์ในเครื่องใหม่และตรวจสอบให้แน่ใจว่าพร้อมใช้งาน

6. สร้างงานการจำลองแบบ SIOS DataKeeper

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

7. ลงทะเบียน SIOS DataKeeper Volume ในคลัสเตอร์

• ลงทะเบียนปริมาณ: ลงทะเบียนโวลุ่ม DataKeeper ในคลัสเตอร์ สิ่งนี้เกี่ยวข้องกับการเพิ่มโวลุ่ม DataKeeper เป็นทรัพยากรแบบคลัสเตอร์ใน WSFC

8. กำหนดค่าการพึ่งพาทรัพยากรคลัสเตอร์ใหม่

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

9. กำหนดค่าพยานใหม่

• ลบพยานดิสก์: หากคุณใช้ดิสก์พยาน ให้ลบดิสก์ใดๆ ที่ใช้เป็นดิสก์พยานออกจากคลัสเตอร์
• กำหนดค่า File Share Witness หรือ Cloud Witness–
  • พยานการแชร์ไฟล์: สร้างการแชร์ไฟล์บนเซิร์ฟเวอร์แยกต่างหาก และกำหนดค่าคลัสเตอร์เพื่อใช้การแชร์ไฟล์นี้เป็นพยาน
  • พยานเมฆ: กำหนดค่าพยานบนคลาวด์โดยการตั้งค่าบัญชีที่เก็บข้อมูลใน Azure และกำหนดค่าคลัสเตอร์เพื่อใช้บัญชีที่เก็บข้อมูลนี้เป็นพยาน

10. นำทรัพยากรใหม่มาสู่ออนไลน์

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

11. เสร็จสิ้นการกำหนดค่าสำหรับคลัสเตอร์ SANless

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

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

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

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

การสัมมนาออนไลน์: การเพิ่มประสิทธิภาพต้นทุนเซิร์ฟเวอร์ SQL ในการปรับใช้ Azure HA/DR

ลงทะเบียนเข้าร่วมสัมมนาออนไลน์ตามความต้องการ

หนึ่งในความท้าทายในการย้ายไปยัง Azure คือการควบคุมค่าใช้จ่ายรายเดือน มีบริการ Azure หลายอย่างสำหรับ SQL Server แต่คุณจำเป็นต้องทราบว่าบริการใดที่คุณต้องการจริงๆ และสิ่งเหล่านี้เหมาะสมกับกลยุทธ์ระบบคลาวด์ของ SQL Server ของคุณอย่างไร

ในการสัมมนาผ่านเว็บนี้ เราจะเจาะลึกเรื่อง High Availability (HA) และ Disaster Recovery (DR) สำหรับการปรับใช้ SQL Server ใน Azure โดยเน้นที่วิธีการที่คุ้มต้นทุน เซสชั่นนี้มีจุดมุ่งหมายเพื่อให้ความเข้าใจที่ครอบคลุมและการสาธิตเชิงปฏิบัติของเทคโนโลยีหลักสามประการ ได้แก่ Basic Availability Groups, SQL Server Failover Cluster Instances (FCI) พร้อม Azure Shared Disks และ Azure Site Recovery คุณจะได้รับข้อมูลเชิงลึกเกี่ยวกับสถาปัตยกรรม การตั้งค่า และความแตกต่างในการปฏิบัติงานของแต่ละวิธี

เราจะเน้นการเพิ่มประสิทธิภาพต้นทุนเป็นพิเศษโดยไม่กระทบต่อความน่าเชื่อถือและประสิทธิภาพ เซสชั่นนี้ได้รับการจัดโครงสร้างเพื่อเป็นประโยชน์ต่อทั้งผู้มาใหม่และมืออาชีพที่มีประสบการณ์ในด้านการใช้งาน SQL Server บนคลาวด์ เมื่อสิ้นสุดเซสชั่นนี้ ผู้เข้าร่วมจะได้รับความรู้ในการตัดสินใจอย่างมีข้อมูลเกี่ยวกับกลยุทธ์ HA/DR ใน Azure เพื่อให้มั่นใจทั้งประสิทธิภาพทางเศรษฐกิจและความแข็งแกร่งในสภาพแวดล้อม SQL Server

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

การสัมมนาออนไลน์: การบรรลุวัตถุประสงค์ HA/DR ในระบบคลาวด์

ลงทะเบียนเข้าร่วมสัมมนาออนไลน์ตามความต้องการ

ดูเหมือนว่าจะยังคงมีความสับสนเกี่ยวกับ Cloud SLA SLA ความพร้อมใช้งานของระบบคลาวด์ครอบคลุมความพร้อมใช้งานของโครงสร้างพื้นฐาน แต่แอปพลิเคชันเช่น SAP, SQL Server และ Oracle ล่ะ แอปพลิเคชันของคุณต้องการความพร้อมใช้งาน ความพร้อมใช้งานสูง หรือการป้องกันการกู้คืนระบบในระบบคลาวด์หรือไม่ เซสชั่น Actual Tech Media MegaCast นี้ครอบคลุมถึงวิธีการบรรลุวัตถุประสงค์ HA/DR สำหรับแอปพลิเคชันที่สำคัญต่อภารกิจของคุณในระบบคลาวด์

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

กลยุทธ์ในการเพิ่มประสิทธิภาพระบบไอทีเพื่อความพร้อมใช้งานสูง

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

ความท้าทายทั่วไปในการเพิ่มประสิทธิภาพระบบไอทีเพื่อความพร้อมใช้งานสูง

มีสองด้านที่แตกต่างกันซึ่งเริ่มสร้างความท้าทายให้กับระบบไอที สิ่งหนึ่งที่เกิดขึ้นบ่อยมากก็คือความเข้ากันได้กับโซลูชั่นป้องกันไวรัส (AV) บ่อยครั้งปัญหาเกิดจากการที่โปรแกรมป้องกันไวรัสมีการป้องกันระบบมากเกินไปและการกักกันไฟล์ที่มีความสำคัญต่อการทำงานของแอปพลิเคชันหรือโซลูชัน HA แน่นอนว่า การตรวจสอบความเข้ากันได้ระหว่างโซลูชันเป็นสิ่งสำคัญเสมอ เพื่อก้าวไปอีกขั้น เป็นเรื่องดีเสมอสำหรับทุกคนที่ดูแลระบบในการทำความคุ้นเคยกับวิธีการทำงานของโซลูชัน AV และเข้าใจขั้นตอนในการกำหนดค่า/ขอเปลี่ยนแปลง AV โซลูชันเพื่อให้แอปพลิเคชันที่สำคัญไม่หยุดชะงัก

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

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

บทบาทของกลยุทธ์การเฟลโอเวอร์และการกู้คืนความเสียหายในการประกันเวลาทำงานของระบบ

ความสามารถในการเฟลโอเวอร์และกลยุทธ์การกู้คืนระบบ (DR) ต่างก็ส่งผลกระทบอย่างมีนัยสำคัญต่อเวลาทำงานของระบบที่สำคัญ แน่นอนว่า HA สามารถจัดเตรียมความสามารถในการเฟลโอเวอร์เพื่อให้แน่ใจว่าปัญหาเซิร์ฟเวอร์เดี่ยวจะไม่ทำให้เกิดการหยุดทำงานสำหรับชุดแอปพลิเคชัน และเมื่อกำหนดค่าอย่างเหมาะสม เฟลโอเวอร์ก็เกือบจะราบรื่น ซึ่งช่วยให้สามารถกู้คืนระบบที่เสียหายต่อไปได้ ในขณะที่ระบบสแตนด์บายเข้ามามีบทบาทหลักในการรับโหลด แน่นอนว่าการกู้คืนความเสียหายสามารถเชื่อมโยงกับกลยุทธ์ HA ได้อย่างแนบแน่น หากมีการกำหนดค่าระบบสำรองไว้แล้ว ทำไมไม่ตรวจสอบให้แน่ใจว่าระบบสำรองนี้มีอยู่ใน Fault Domain หากสังเกตอย่างเหมาะสม แอปพลิเคชันจะมีความพร้อมใช้งานสูงและทนทานต่อข้อผิดพลาด เมื่อวิเคราะห์ผลลัพธ์เหล่านี้จากมุมมองของไอที ​​กลยุทธ์ HA และ DR ที่กำหนดค่าอย่างเหมาะสมสามารถรับประกันได้ว่าระบบจะถูกใช้งานอย่างเต็มศักยภาพโดยมีเวลาหยุดทำงานน้อยที่สุด ภัยพิบัติทางธรรมชาติหรือความล้มเหลวทางเทคโนโลยีในภูมิภาคที่แอปพลิเคชันโฮสต์อยู่มีโอกาสน้อยที่จะแพร่กระจายไปยังภูมิภาคอื่นๆ การใช้ประโยชน์จากความซ้ำซ้อนที่วางแผนไว้ควบคู่ไปกับแผนการกู้คืนความเสียหายอาจส่งผลให้ครอบคลุมข้อกำหนดด้านฟังก์ชันการทำงานมากขึ้นโดยใช้ทรัพยากรน้อยลง เนื่องจากการวางแผนอย่างรอบคอบสามารถรับประกันได้ว่าทั้งความซ้ำซ้อนและความทนทานต่อข้อผิดพลาดจะได้รับการจัดการโดยการปรับใช้ไซต์สแตนด์บาย

การสร้างสมดุลระหว่างความคุ้มค่าและความพร้อมใช้งานสูง: กลยุทธ์สำหรับองค์กร

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

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

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

การใช้ความพร้อมใช้งานสูง: แนวทางปฏิบัติที่ดีที่สุด

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

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

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