บรรลุถึงความพร้อมใช้งานสูงอย่างคุ้มต้นทุน

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

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

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

ผู้เขียน: เบธ วินคอฟสกี้ ฝ่ายประชาสัมพันธ์

พิมพ์ซ้ำโดยได้รับอนุญาตจากSIOS

เหตุใดประวัติบริษัทจึงมีความสำคัญใน HA

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

เหตุใดประวัติบริษัทและผู้ให้บริการโซลูชันจึงมีความสำคัญในความพร้อมใช้งานสูง

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

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

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

ห้าวิธีที่ประวัติศาสตร์บริษัทกำหนดสถาปัตยกรรม HA

ต่อไปนี้เป็นห้า (5) วิธีที่ประวัติบริษัทควรส่งผลกระทบต่อสถาปัตยกรรม HA ของคุณ:

1. ขนาดของบริษัท (ใหญ่เกินไปหรือเล็กเกินไป)

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

2. วงจรชีวิตของบริษัท (ทุก ๆ ห้าปีหรือจนกว่าจะสิ้นสุด)

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

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

3. การจัดหาพนักงานของบริษัท (แบบประตูหมุนหรือแบบเรนเจอร์เดี่ยว)

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

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

4. ภัยพิบัติในอดีตของบริษัท

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

5. วัฒนธรรมองค์กร

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

อย่ามองข้ามบทบาทของประวัติบริษัทในการตัดสินใจด้าน HA

ใช่ ประวัติบริษัทของศูนย์ข้อมูลหรือผู้ให้บริการคลาวด์นั้นสำคัญ การทราบประวัติของ Lou’s Low Cost Cloud, LLC (ไม่ได้หมายความว่า Lou จะโกรธ) ซึ่งสูญเสียอุปกรณ์จำนวนมากในขณะที่ดำเนินงานในโรงรถที่บ้านพ่อแม่ของ Lou ซึ่งส่วนใหญ่ไม่มีเครื่องปรับอากาศ เป็นสิ่งสำคัญหากคุณกำลังพิจารณา Lou สำหรับศูนย์ข้อมูลของคุณ ใช่ ประวัติบริษัทของแอปพลิเคชันและผู้ให้บริการ HA ก็สำคัญเช่นกัน การทราบประวัติของผู้ให้บริการ ERP, ฐานข้อมูล และแอปพลิเคชันส่วนหน้าของคุณเป็นกุญแจสำคัญในการประเมินและลดความเสี่ยง ทำความเข้าใจรูปแบบและวิธีการปรับใช้ และสร้างความมั่นใจว่าการแก้ไข การอัปเดต ความปลอดภัย และการสนับสนุนที่ทันท่วงทีจะเป็นรากฐานสำคัญของสถาปัตยกรรมของคุณ แต่อย่าประเมินความสำคัญของการทราบประวัติบริษัทของคุณเองต่ำเกินไป และวิธีที่ความล้มเหลวที่สำคัญจะส่งผลต่อการตัดสินใจและโครงสร้างพื้นฐาน HA ใหม่และที่กำลังดำเนินอยู่ของคุณ

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

ผู้เขียน: Cassius Rhue, รองประธานฝ่ายประสบการณ์ลูกค้า

พิมพ์ซ้ำโดยได้รับอนุญาตจากSIOS

การจำลองข้อมูลที่เชื่อถือได้ด้วย SIOS DataKeeper: เหตุใดการสื่อสาร (และพอร์ต) จึงมีความสำคัญ

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

ไม่ว่าคุณจะเป็นการจำลองข้อมูลข้ามภูมิภาคหรือศูนย์ข้อมูล งานแรกของคุณคือการเปิดใช้งานการสื่อสารที่ปลอดภัยและเชื่อถือได้ระหว่างโหนดที่เข้าร่วมทั้งหมด หัวใจสำคัญของการสื่อสารนี้คือโปรโตคอล TCP/IP DataKeeper ใช้ชุดพอร์ต TCP ที่กำหนดไว้ล่วงหน้าเพื่อสร้างและรักษาการจำลองข้อมูล

พอร์ต TCP คืออะไร และเหตุใดจึงสำคัญสำหรับการจำลองข้อมูล?

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

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

SIOS DataKeeper ใช้พอร์ตใดบ้าง?

เพื่อสร้างการจำลองและรักษาการสื่อสารระหว่างโหนด DataKeeper จำเป็นต้องเปิดพอร์ต TCP ต่อไปนี้:

• 137, 138, 139, 445 – พอร์ตเหล่านี้เป็นพอร์ตเครือข่าย Windows ที่ใช้สำหรับการแชร์ไฟล์และเครื่องพิมพ์ (NetBIOS และ SMB)
• 9999 – นี่คือพอร์ตเริ่มต้นที่ใช้โดยบริการ DataKeeper สำหรับการควบคุมและการอัปเดตสถานะ
• 10000–10025 – พอร์ตเหล่านี้ใช้สำหรับการรับส่งข้อมูลการจำลองข้อมูลจริง แต่ละพอร์ตในช่วงนี้จะสอดคล้องกับอักษรระบุไดรฟ์:

10000 = เล่ม A

–

10025 = เล่ม Z

ตัวอย่างเช่น หากคุณกำลังจำลองโวลุ่ม F คุณจะต้องตรวจสอบให้แน่ใจว่าพอร์ต 10005 เปิดอยู่ระหว่างโหนด

สิ่งที่ต้องตรวจสอบเมื่อการจำลองข้อมูลไม่ทำงาน

หากการจำลองไม่เริ่มต้นหรือตัดการเชื่อมต่อซ้ำๆ โปรดพิจารณาสิ่งต่อไปนี้:

1. การกำหนดค่าไฟร์วอลล์
   1. ตรวจสอบว่า Windows Firewall ไม่ได้บล็อกพอร์ตที่จำเป็นใดๆ คุณสามารถสร้างกฎขาเข้าเพื่ออนุญาตการรับส่งข้อมูลบนพอร์ตที่จำเป็นได้:
      1. เปิดไฟร์วอลล์ Windows Defender พร้อมการรักษาความปลอดภัยขั้นสูง
      2. ไปที่กฎขาเข้า > กฎใหม่
      3. เลือกพอร์ต เลือก TCP และระบุ:

137, 138, 139, 445, 9999, 10000-10025

1. อนุญาตการเชื่อมต่อและใช้กฎกับโปรไฟล์ทั้งหมด (โดเมน ส่วนตัว สาธารณะ)

1. กลุ่มความปลอดภัยเครือข่าย / ไฟร์วอลล์บนคลาวด์

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

1. การทดสอบ Ping และการเชื่อมต่อ
   1. ใช้ ping หรือ Test-NetConnection ใน PowerShell เพื่อตรวจสอบความสามารถในการเข้าถึงเครือข่าย
   2. ใช้ telnet หรือ Test-NetConnection -Port เพื่อตรวจสอบว่าพอร์ตเฉพาะเปิดอยู่หรือไม่

แนวทางปฏิบัติที่ดีที่สุดสำหรับการปรับใช้ SIOS DataKeeper อย่างราบรื่น

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

รับรองการเชื่อมต่อพอร์ตสำหรับการจำลอง SIOS DataKeeper ที่เชื่อถือได้ในสรุป

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

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

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

ผู้เขียน: Tristan Allen วิศวกรซอฟต์แวร์ประสบการณ์ลูกค้าประจำที่ SIOS Technology Corp.

พิมพ์ซ้ำโดยได้รับอนุญาตจากSIOS

 

การรับประกัน HA สำหรับการดำเนินงานการผลิตทั่วโลก

SIOS มอบเวลาการทำงานและประสิทธิภาพการทำงาน

EGGER Group ผู้นำระดับโลกด้านการผลิตวัสดุจากไม้ บรรลุอัตราการทำงาน 99.99% สำหรับแอปพลิเคชันสำคัญขององค์กรด้วย SIOS LifeKeeper สำหรับ Linux SIOS ช่วยให้ EGGER มั่นใจได้ว่าการดำเนินงานในโรงงานผลิต 22 แห่งใน 11 ประเทศเป็นไปอย่างราบรื่น ปกป้องแอปพลิเคชัน SAP, Oracle และแอปพลิเคชันเฉพาะทางที่สำคัญไม่ให้หยุดทำงาน

อ่านกรณีศึกษาที่นี่

พิมพ์ซ้ำโดยได้รับอนุญาตจากSIOS