ความพร้อมใช้งานเซิร์ฟเวอร์สูงสำหรับธุรกิจขนาดเล็ก

หลังจากตกใจเล็กน้อยกับเซิร์ฟเวอร์ที่จะไม่เกิดขึ้นในเช้าวันหนึ่งผู้ที่สูงขึ้นได้ตัดสินใจว่าธุรกิจต้องการความพร้อมใช้งานสูง / ล้มเหลวในการตั้งค่า

เรามีเซิร์ฟเวอร์หลัก 5 ตัว (4x Linux, 1x OpenBSD) ซึ่งทั้งหมดนี้จำเป็นต้องใช้เพื่อให้ บริษัท ดำเนินการได้ เซิร์ฟเวอร์สามตัวนั้นมีมาตรฐานพอสมควร (ไฟล์ / เว็บ / ฐานข้อมูล) เซิร์ฟเวอร์ตัวที่สี่จัดการกับการกำหนดเส้นทางเครือข่ายและผู้รับมอบฉันทะทางเว็บส่วนที่ห้ารองรับระบบโทรศัพท์ของเราและมีฮาร์ดแวร์ที่ไม่ได้มาตรฐาน

เจ้านายของฉันแจ้งว่าเวลาในการเปลี่ยนเซิร์ฟเวอร์ล้มเหลวควรต่ำกว่า 30 นาที

ประสบการณ์ของฉันในสาขานี้ไม่มีอยู่จริง (ฉันแค่เป็นโปรแกรมเมอร์ที่ได้รับการเลื่อนขั้น ') ดังนั้นฉันเดาว่าคำถามของฉันจะลดลงไปเป็น:

• นี่เป็นสิ่งที่ควรได้รับการพยายามจากผู้ที่มีทักษะการดูแลเซิร์ฟเวอร์โดยเฉลี่ยหรือไม่ ถ้าเป็นเช่นนั้นฉันควรอ่านอะไรและฉันควรจะพูดกับใคร

ขอบคุณ

ฉันคิดว่าคุณควรเริ่มด้วยการรวมตัวเลขเข้าด้วยกันเพื่ออธิบายค่าใช้จ่ายที่เกี่ยวข้องกับการปฏิบัติตาม "ข้อกำหนด" ที่ระบุไว้เพื่อดูว่ามันอยู่ในงบประมาณหรือไม่ หากคุณไม่พอใจกับวิธีการ "ปกติ" ทั้งหมดที่จะใช้ในการตอบสนองความต้องการ (การทำคลัสเตอร์ล้มเหลวไฮเปอร์ไวเซอร์ที่มีความสามารถ "การย้ายถิ่นร้อน" ฯลฯ ) คุณอาจทำได้ดีในการหาที่ปรึกษาที่สามารถ ช่วยออก.

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

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

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

อย่าลดการทำคลัสเตอร์ failover แบบ "ดั้งเดิม" มี "ชนะ" แน่นอนเช่นกันหากแอปพลิเคชันของคุณเหมาะสมกับการกำหนดค่าดังกล่าว

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

รับความช่วยเหลือจากใครบางคนที่สามารถเข้ามาและศึกษาธุรกิจของคุณและให้คำแนะนำ คุณจะไม่เสียใจ

"ถนนสายนี้นำไปสู่ความเจ็บปวดและความเจ็บปวดมากมาย ... "

ดังนั้นแผนความต่อเนื่องทางธุรกิจของคุณคืออะไร? คุณวางแผนการกู้คืนความเสียหายหรือไม่?

คุณเคยคุยกันไหม? เขียนลงไปไหม ทดสอบแล้วหรือ

คุณต้องมีการสนทนาที่เหมาะสมกับ "สูงขึ้น" และไปถึงด้านล่างของข้อกำหนดสำหรับความพร้อมใช้งานสูงเพราะแตกต่างกันสำหรับบริการที่แตกต่างกัน

ดังนั้น "จุดปวด" ที่พวกเขารู้สึกในเช้าวันนั้นคืออะไร?

คือมัน?

• โทรศัพท์หยุดทำงานเหรอ ปัญหา (และมองเห็นได้) ที่สำคัญพอสมควร และใช่ - สิ่งนี้จะต้องมี "วิธีแก้ปัญหา" แต่หวังว่านี่จะอยู่ภายใต้ข้อตกลงการสนับสนุนหรือไม่
• เว็บไซต์ล้มเหลว ตกลง - มองเห็นได้อย่างเป็นธรรม แต่ไม่คาดคิดและถ้าคุณไม่มีการแสดงตนทางเว็บจำนวนมากก็ไม่สำคัญ ตกลงเพื่อให้เซิร์ฟเวอร์นี้ทำงานไม่กี่ชั่วโมง
• เซิร์ฟเวอร์ฐานข้อมูลล่ม น่ากลัว ... หวังว่าคุณจะได้สำเนาสำรองที่ดี! อย่าสูญเสียข้อมูลมิฉะนั้นเขาจะทำธุรกิจล้มเหลว แต่ตราบใดที่ข้อมูลมีความปลอดภัยก็เป็นเซิร์ฟเวอร์ที่มีความสำคัญและควรมีแผนการกู้คืน
• ไฟล์และพิมพ์ (และแอพภายใน ฯลฯ ) นี่คือ PITA สำหรับคนส่วนใหญ่เนื่องจากพวกเขาจะนั่งเฉยๆและไม่ทำอะไรเลยในตอนเช้าตามที่คุณต้องการ

ฉันถือว่าคุณซื้อฮาร์ดแวร์คุณภาพสูงสำหรับระบบหลักของคุณหรือไม่ ดีเพราะราคาถูกในฮาร์ดแวร์เป็นเศรษฐกิจที่ผิดเนื่องจากเซิร์ฟเวอร์เหล่านี้มาพร้อมกับ "สอง" ทุกอย่างในกล่อง

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

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

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

Evan hit เป็นจุดที่ดี แต่นี่อาจเป็นวิธีที่คุ้มค่าในการใช้เวลากู้คืน 1 ชั่วโมงเมื่อเผชิญกับความล้มเหลว

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

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

หากเราเริ่มต้นด้วยคุณกำหนดเส้นทาง / เว็บพรอกซีเซิร์ฟเวอร์อาจเป็นวิธีที่ง่ายที่สุดเนื่องจากจะไม่อยู่ในสถานะจริงใด ๆ ที่จะต้องเก็บไว้ในกล่อง ดังนั้นเพียงแค่ได้รับซ้ำของกล่องเดียวกันและกำหนดค่าเดียวกัน ฉันจะเสียบปลั๊กทั้งคู่ในส่วนของ LAN และสมมติว่าคุณใช้อินเทอร์เน็ตอยู่ในอินเทอร์เฟซอื่นให้สลับสายเคเบิลหากเกิดความล้มเหลว จากเปอร์สเปคทีฟการกำหนดเส้นทางคุณตั้งค่าทั้งหมดที่คุณใช้กับไคลเอนต์ LAN เพื่อกำหนดเป้าหมายที่อยู่. 1 (VIP) สำหรับเส้นทางเริ่มต้นและพร็อกซีเซิร์ฟเวอร์ให้เซิร์ฟเวอร์ A .2 ที่อยู่และเซิร์ฟเวอร์ B ที่อยู่. 3 วิธีนี้พวกเขาทั้งสองสามารถจัดการเพื่ออัปเดตการกำหนดค่า (ใช้ได้กับทั้งคู่) และสิ่งที่คุณต้องทำเพื่อล้มเหลวคือลบการกำหนด IP .1 จาก .2 และย้ายไปที่. 3 และย้ายการเชื่อมต่ออินเทอร์เน็ตไปยังอินเทอร์เฟซอื่น มันไม่ซับซ้อนมากง่ายต่อการทำและเข้าใจ และต้นทุนฮาร์ดแวร์เพิ่มเติมของกล่องที่สอง หากคุณสามารถทำซ้ำซ้อนบนฝั่งอินเทอร์เน็ตคุณสามารถเพิ่มความซับซ้อนและรับ failover อัตโนมัติโดยใช้บางอย่างเช่น VRRP

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

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

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

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

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

ฉันทำงานด้านโทรคมนาคมและอุปกรณ์ของเราซ้ำซ้อนสูงมากรวมถึงในกรณีส่วนใหญ่ความซ้ำซ้อนทางภูมิศาสตร์กราฟิก จุดที่ล้มเหลวอันดับ 1 ของเราคือการซ้ำซ้อนไม่ได้รับการทดสอบหลังจากการเปลี่ยนแปลงและผู้ใช้ทำการเปลี่ยนแปลงที่ไม่ทราบว่ารูปแบบความซ้ำซ้อนทำงานอย่างไร อย่างไรก็ตามเรามีปัญหาเพิ่มเติมที่อุปกรณ์ทั้งหมดของเราต้องการรองรับการ failover อัตโนมัติในไม่เกินไม่กี่วินาที คุณสามารถทนต่อการขัดจังหวะด้วยมือในกรณีที่คุณล้มเหลวหากคุณจำเป็นต้องเปิดใช้งานและทำงานภายใน 30 - 60 นาที คุณแค่ต้องเตรียมพร้อม โชคดี.

คะแนนของคนอื่น ๆ นั้นยอดเยี่ยมมาก

ไม่สามารถรับประกัน 30 นาทีโดยเฉพาะอย่างยิ่งสำหรับทุกสิ่ง คุณสามารถพูดเป้าหมายได้ แต่ไม่มีวิธีใดที่จะรับประกันได้เพราะมีปัจจัย X อยู่เสมอ คุณอาจมีสาย ISP 2 เส้นและรถบรรทุกชนเข้ามาในอาคารและพาพวกเขาทั้งคู่ออกเพราะคุณไม่คิดว่าการที่พวกเขาส่งจากปลายด้านตรงข้ามของอาคารที่มีความสำคัญนั้นเป็นตัวอย่างหนึ่ง

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

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

สิ่งที่ฉันพบได้ดีกว่าสำหรับธุรกิจขนาดเล็กคือการออกแบบแผนการกู้คืนและจัดประเภททุกอย่าง

คิดว่าบริการใดบ้าง

สำคัญ (หยุดธุรกิจ)

สำคัญ (ธุรกิจช้าลง)

รูทีน (ธุรกิจสามารถทำโดยไม่ได้ทำในขณะที่)

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

นั่นยังทำให้คุณมีคำสั่งให้แก้ไขสิ่งต่าง ๆ ถ้า s ** t นิยมแฟนวันหนึ่ง :)

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

Failover เป็นไปได้ แต่โดยปกติจะต้องใช้ฮาร์ดแวร์ที่ซ้ำซ้อน SAN เพื่อแบ่งปันข้อมูลระหว่างเซิร์ฟเวอร์ ฯลฯ ... กล่าวอีกอย่างคือโชคดีที่ได้รับเงินทุนหากไม่ได้จ้างผู้ดูแลระบบเฉพาะเพื่อดูแล

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

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

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

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

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

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