เวลาใช้งาน 100% สำหรับเว็บแอปพลิเคชัน

เราได้รับ "ข้อกำหนด" ที่น่าสนใจจากลูกค้าวันนี้

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

อย่างไรก็ตามจากปัญหาเครือข่ายฉันก็ไม่สามารถคิดออกวิธีการทำงาน

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

ตอนนี้เรารู้แล้วว่าไม่มีวิธีแก้ไขสำหรับคนภายใน (ผู้ให้บริการนกพิราบ?) แต่พวกเขาต้องการให้ผู้ใช้ภายนอกไม่สังเกตเห็น

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

ไอเดีย?

UPDATE

ฉันได้พูดคุยกับลูกค้าในวันนี้และพวกเขาชี้แจงปัญหา

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

นี่คือแผนภูมิที่มีประโยชน์ของWikipediaเกี่ยวกับการแสวงหาเก้า:

ที่น่าสนใจมีเพียง3 ใน 20 อันดับแรกของเว็บไซต์เท่านั้นที่สามารถบรรลุ 5 ตำนานหรือ uptime 99.999% ในปี 2550 พวกเขาคือ Yahoo, AOL และ Comcast ในช่วง 4 เดือนแรกของปี 2551 เครือข่ายโซเชียลที่ได้รับความนิยมสูงสุดบางส่วนไม่ได้เข้าใกล้

จากแผนภูมิควรเห็นได้ชัดว่าการแสวงหา uptime 100% ไร้สาระเป็นอย่างไร ...

ขอให้พวกเขากำหนด 100% และวิธีการวัดในช่วงเวลาใด พวกเขาอาจหมายถึงใกล้ถึง 100% เท่าที่พวกเขาสามารถจ่ายได้ ให้ต้นทุนกับพวกเขา

ทำอย่างละเอียด. ฉันได้รับการพูดคุยกับลูกค้าในช่วงหลายปีที่ผ่านมาด้วยข้อกำหนดที่น่าหัวเราะ ในทุกกรณีพวกเขาใช้แค่ภาษาที่ไม่แม่นยำ

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

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

• ในเวลาที่ยุ่งที่สุดเป็นเวลา x ชั่วโมง
• อย่างน้อยก็ไม่ว่างชั่วโมง x ชั่วโมง

และวิธีที่พวกเขาจะวัดสิ่งนี้

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

ลูกค้าของคุณเป็นบ้า ความพร้อมในการทำงาน 100% เป็นไปไม่ได้ไม่ว่าคุณจะใช้เงินไปเท่าไหร่ ธรรมดาและเรียบง่าย - เป็นไปไม่ได้ ดูที่ Google, Amazon และอื่น ๆ พวกเขามีเงินเกือบจะไม่มีที่สิ้นสุดในการใช้โครงสร้างพื้นฐานของพวกเขา คุณต้องส่งข้อความนั้นไปยังพวกเขาและหากพวกเขายังคงยืนยันว่าพวกเขามีความต้องการที่สมเหตุสมผล หากพวกเขาไม่ยอมรับว่าบางส่วนจำนวนเงินของการหยุดทำงานเป็นสิ่งที่หลีกเลี่ยงแล้วทิ้ง 'em

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

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

นั่นเป็นสิ่งที่น่าสนใจอย่างแน่นอน ฉันไม่แน่ใจว่าฉันต้องการให้ตัวเองมีภาระผูกพันตามสัญญาเป็น uptime 100% แต่ถ้าฉันต้องฉันคิดว่ามันจะมีลักษณะเช่นนี้:

เริ่มต้นด้วย IP สาธารณะบน load balancer ออกจากเครือข่ายอย่างสมบูรณ์และสร้างอย่างน้อยสองตัวเพื่อให้สามารถล้มเหลวได้ โปรแกรมเช่น Heatbeart สามารถช่วยในการล้มเหลวอัตโนมัติของโปรแกรมเหล่านั้น

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

ฉันรัก Elastic IP ใน Amazon EC2 วันนี้ดังนั้นฉันอาจจะสร้าง load balancer ใน EC2 ในภูมิภาคต่าง ๆ หรืออย่างน้อยก็ในโซนความพร้อมใช้งานที่แตกต่างกันในภูมิภาคเดียวกัน นั่นจะทำให้คุณมีทางเลือกด้วยตนเอง (ห้ามไม่ให้ผู้อื่น) ปั่นบาลานเซอร์โหลดใหม่หากคุณต้องย้ายไอพีเรคคอร์ด A ที่มีอยู่ไปยังกล่องใหม่

วานิชไม่สามารถยกเลิก SSL ได้ดังนั้นหากเป็นเรื่องที่น่ากังวลคุณอาจต้องการดูบางอย่างเช่น Nginx แทน

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

นั่นคือสิ่งที่ฉันจะเริ่มต้นถ้าฉันมีงานนี้และปรับแต่งอย่างไม่ต้องสงสัยเมื่อฉันไปตาม

อย่างไรก็ตามตามที่ @ErikA ระบุว่าเป็นอินเทอร์เน็ตและมักจะเป็นส่วนหนึ่งของเครือข่ายที่อยู่นอกเหนือการควบคุมของคุณ คุณจะต้องแน่ใจว่ากฎหมายของคุณเชื่อมโยงคุณกับสิ่งที่อยู่ภายใต้การควบคุมของคุณ

ไม่มีปัญหา - ถ้อยคำสัญญาที่มีการแก้ไขเล็กน้อย:

... รับประกัน uptime 100% (ปัดเศษเป็นศูนย์ทศนิยม)

หาก Facebook และ Amazon ไม่สามารถทำได้คุณก็ทำไม่ได้ มันง่ายอย่างที่คิด

เพื่อเพิ่มคำตอบของ oconnoreจาก Hacker News

ฉันไม่เข้าใจว่าปัญหาคืออะไร ลูกค้าต้องการให้คุณวางแผนสำหรับภัยพิบัติและพวกเขาไม่ได้มุ่งเน้นทางคณิตศาสตร์ดังนั้นการขอความน่าจะเป็น 100% นั้นสมเหตุสมผล วิศวกรในฐานะวิศวกรมีแนวโน้มที่จะทำจำวันแรกของปัญหา & สถิติ 101 โดยไม่พิจารณาว่าลูกค้าอาจไม่ เมื่อพวกเขาพูดแบบนี้พวกเขาไม่ได้คิดเกี่ยวกับฤดูหนาวนิวเคลียร์พวกเขากำลังคิดเกี่ยวกับการทิ้งกาแฟของเขาบนเซิร์ฟเวอร์ในสำนักงานดิสก์หยุดทำงานหรือ ISP ล่ม นอกจากนี้คุณสามารถทำได้ ด้วยเซิร์ฟเวอร์การตรวจสอบตนเองที่แตกต่างกันทางภูมิศาสตร์คุณจะไม่มีเวลาหยุดทำงาน ด้วย 3 เซิร์ฟเวอร์ที่ทำงานด้วยอิสระ (1) สามความน่าเชื่อถือ 9 กับโหมดล้มเหลวที่ดีการหยุดทำงานที่คาดหวังของคุณอยู่ภายใต้วินาทีต่อปี (2) แม้ว่าสิ่งนี้จะเกิดขึ้นทั้งหมดในครั้งเดียว คุณยังอยู่ใน SLA ที่สมเหตุสมผลสำหรับการเชื่อมต่อเว็บดังนั้นจึงไม่มีการหยุดทำงานในทางปฏิบัติ ลูกค้ายังคงต้องรับมือกับสถานการณ์วันโลกาวินาศ แต่ก็อดซิลล่าได้รับการยกเว้นเขาจะมีบริการที่ "เสมอ" ขึ้น

(1) เซิร์ฟเวอร์ใน LA มีความเป็นอิสระจากเซิร์ฟเวอร์ในบอสตัน แต่ใช่ฉันเข้าใจว่ามีจุดตัดบางอย่างที่เกี่ยวข้องกับสงครามนิวเคลียร์แฮกเกอร์จีนชนแผงพลังงาน ฯลฯ ฉันไม่คิดว่าลูกค้าของคุณจะต้องเสียใจด้วย นี้.

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

คุณกำลังถูกถามถึงสิ่งที่เป็นไปไม่ได้

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

หากพวกเขายังคงยืนยันใน uptime 100% อย่างสุภาพแจ้งพวกเขาว่ามันไม่สามารถทำได้และปฏิเสธสัญญา คุณจะไม่ตอบสนองความต้องการของพวกเขาและหากสัญญาไม่ได้ดูดคุณจะได้รับการลงโทษ

ราคาตามนั้นและกำหนดในสัญญาว่าการหยุดทำงานที่ผ่านมาของ SLA จะได้รับคืนตามอัตราที่พวกเขาจ่าย

ISP ในงานสุดท้ายของฉันทำอย่างนั้น เรามีทางเลือกของสาย DSL "ปกติ" ที่ 99.9% อัพไทม์สำหรับ $ 40 / เดือนหรือสามทรีโอของ T1s ที่ 99.99% อัพไทม์สำหรับ $ 1100 / เดือน มีการหยุดทำงานบ่อยครั้งมากกว่า 10+ ชั่วโมงต่อเดือนซึ่งทำให้สถานะการออนไลน์ของพวกเขาต่ำกว่า DSL $ 40 / เดือน แต่เราได้รับเงินคืนแค่ประมาณ $ 15 หรือมากกว่านั้นเพราะนั่นคืออัตราต่อชั่วโมง * ชั่วโมงที่สิ้นสุด พวกเขาทำเหมือนโจรจากข้อตกลง

หากคุณเรียกเก็บเงิน $ 450,000 ต่อเดือนสำหรับช่วงเวลาการให้บริการ 100% และคุณมียอดถึง 99.999% คุณจะต้องคืนเงินให้ $ 324 ฉันยินดีที่จะเดิมพันค่าใช้จ่ายโครงสร้างพื้นฐานในการเข้าถึง 99.999% อยู่ในละแวกใกล้เคียง $ 45,000 ต่อเดือนสมมติว่า colos กระจายอย่างเต็มรูปแบบ, อัปลิงค์ชั้นที่ 1 หลาย, ฮาร์ดแวร์แฟนซี ฯลฯ

หากผู้เชี่ยวชาญถามว่าความพร้อมใช้งาน 99.999 เปอร์เซ็นต์ [เป็น] เป็นไปได้จริงหรือมีความเป็นไปได้ทางการเงินความพร้อมใช้งาน 99.9999% นั้นเป็นไปได้น้อยลงหรือใช้งานได้จริง นับประสา 100%

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

มีคนสองประเภทที่ขอความพร้อมในการทำงาน 100%:

1. ผู้ที่ไม่มีความรู้เกี่ยวกับคอมพิวเตอร์ระบบคอมพิวเตอร์หรืออินเทอร์เน็ต *
2. ผู้ที่ตั้งใจทำตัวเองอย่างจงใจเพื่อทดสอบความสามารถของคุณในการบอกว่าไม่ (Google "การทดสอบน้ำส้ม") หรือพยายามที่จะได้รับสัญญา SLA เพื่อใช้ประโยชน์จากการจ่ายเงินให้คุณในภายหลัง

คำแนะนำของฉันหลังจากที่ประสบกับลูกค้าทั้งสองประเภทนี้หลายต่อหลายครั้งคือไม่รับลูกค้ารายนี้ ปล่อยให้พวกเขาขับรถบ้าคนอื่น

* บุคคลเดียวกันนี้อาจไม่มีความลำบากใจในการสอบถามเกี่ยวกับการเดินทางที่เร็วกว่าแสงการเคลื่อนไหวแบบไม่หยุดยั้ง Cold Fusion ฯลฯ

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

ระยะเวลาทำงาน 100%

นี่คือสิ่งที่คุณต้องการ:

เซิร์ฟเวอร์ DNS หลายตัว (& ซ้ำซ้อน) ชี้ไปที่หลายไซต์ทั่วโลกพร้อม SLA ที่เหมาะสมกับ ISP แต่ละเครื่อง

ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ DNS ได้รับการตั้งค่าอย่างถูกต้องโดยรู้จัก TTL

มันง่ายมาก Amazon EC2 SLA ระบุไว้อย่างชัดเจนว่า:

“ เปอร์เซ็นต์สถานะการออนไลน์ต่อปี” คำนวณโดยลบออกจาก 100% เปอร์เซ็นต์ของระยะเวลา 5 นาทีในช่วงปีบริการที่ Amazon EC2 อยู่ในสถานะ“ ไม่พร้อมให้บริการในภูมิภาค”

http://aws.amazon.com/ec2-sla/

เพียงกำหนด 'uptime' เพื่อให้สัมพันธ์กับชุดบริการทั้งหมดที่คุณสามารถใช้งานได้จริง 100% และคุณไม่ควรมีปัญหาใด ๆ

นอกจากนี้ควรชี้ให้เห็นว่าจุดรวมทั้งหมดของ SLA คือการกำหนดว่าภาระผูกพันของคุณคืออะไรและจะเกิดอะไรขึ้นหากคุณไม่สามารถปฏิบัติตามข้อตกลงเหล่านั้นได้ ไม่สำคัญว่าลูกค้าจะขอ 3 เก้าหรือ 5 หรือ 10 ล้าน - คำถามคือสิ่งที่พวกเขาได้รับเมื่อ / ถ้าคุณไม่สามารถส่งมอบ คำตอบที่ชัดเจนคือให้รายการโฆษณาสำหรับช่วงเวลาการแสดงผล 100% ในราคาที่คุณต้องการคิดค่าบริการ 5 เท่าจากนั้นพวกเขาจะได้รับเงินคืน 4x หากคุณพลาดเป้าหมายนั้น คุณอาจให้คะแนน!

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

นี่เป็นวิธีที่ GTM ทำงานใน F5 Big IP โดยค่าเริ่มต้นของ DNS TTL คือ 30 วินาทีและหากสมาชิกคนหนึ่งของคลัสเตอร์ต้องการเข้าครอบครอง DNS จะได้รับการอัปเดตและ IP ใหม่จะถูกใช้งานเกือบจะทันที การหยุดทำงานสูงสุด 30 วินาที แต่นั่นคือกรณีขอบโดยเฉลี่ยจะเป็น 15 วินาที

คุณรู้ว่ามันเป็นไปไม่ได้

ไม่ต้องสงสัยเลยว่าลูกค้ามุ่งเน้นไปที่การเห็น "100%" ดังนั้นสิ่งที่ดีที่สุดที่คุณสามารถทำได้คือสัญญา 100% ยกเว้น [สาเหตุที่สมเหตุสมผลทั้งหมดที่ไม่ใช่ความผิดของคุณ]

ในขณะที่ฉันสงสัยว่าเป็นไปได้ 100% คุณอาจต้องการพิจารณา Azure (หรือบางสิ่งที่มี SLA ที่คล้ายกัน) เป็นไปได้ เกิดอะไรขึ้น:

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

ที่กล่าวว่าถึงแม้จะมีความล้มเหลวนี้ความแตกต่างระหว่าง 99.999 และ 100 ชายแดนกับความวิกลจริต

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

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

ฉันจะอยู่ในประโยคสำหรับกรณีเช่นนี้ (DDOS, การตัดกระดูกสันหลังทางอินเทอร์เน็ต, การโจมตีของผู้ก่อการร้ายสันทรายหรือสงครามครั้งใหญ่เป็นต้น)

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

ฉันแค่อยากจะเพิ่มเสียงอื่นให้กับพรรค "มันสามารถ (ในทางทฤษฎี) สามารถทำได้"

ฉันจะไม่ทำสัญญาที่ระบุสิ่งนี้ไม่ว่าพวกเขาจะจ่ายเงินให้ฉันแค่ไหน แต่เป็นปัญหาการวิจัยมันมีวิธีแก้ปัญหาที่น่าสนใจบ้าง ฉันไม่คุ้นเคยกับระบบเครือข่ายพอที่จะอธิบายขั้นตอนต่าง ๆ แต่ฉันคิดว่าการรวมกันของการกำหนดค่าที่เกี่ยวข้องกับเครือข่าย + การเดินสายไฟฟ้า / ฮาร์ดแวร์ล้มเหลว + การล้มเหลวของซอฟต์แวร์อาจเป็นไปได้ว่าในการกำหนดค่าบางอย่างหรืองานอื่น ๆ

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

อีกครั้งไม่ได้บอกว่ามันเป็นไปได้ .. ฉันไม่ชอบคำตอบเดียวที่ไม่ได้ตอบความจริงที่ว่ามันไม่ใช่ "วิธีไปที่นั่น" - มันไม่ใช่สิ่งที่พวกเขาต้องการจริงๆถ้าพวกเขาคิดผ่าน

Re: คิดว่าวิธีการของคุณในการวัดความพร้อมใช้งานแล้วทำงานร่วมกับลูกค้าของคุณในการตั้งค่าเป้าหมายที่มีความหมาย

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

บางครั้ง บริษัท เว็บขนาดใหญ่วัดความพร้อมใช้งานหรือความน่าเชื่อถือโดยใช้เมตริกต่อไปนี้:

1. เปอร์เซ็นต์ของการสืบค้นที่ตอบสำเร็จโดยไม่มีข้อผิดพลาดฝั่งเซิร์ฟเวอร์ (HTTP 500s)
2. เปอร์เซ็นต์ของข้อความค้นหาที่ตอบด้านล่างเวลาตอบสนองเป้าหมายที่แน่นอน
3. ข้อความค้นหาที่ลดลงควรนับรวมกับสถิติของคุณ (ดูด้านล่าง)

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

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

เปอร์เซ็นต์ของข้อความค้นหาที่ลดลงควรนับรวมกับสถิติของคุณด้วย มันสามารถถูกนำมาใช้ในที่ฝากข้อมูลเดียวกันกับข้อผิดพลาดฝั่งเซิร์ฟเวอร์ หากมีปัญหากับเครือข่ายหรือโครงสร้างพื้นฐานอื่น ๆ เช่น DNS หรือโหลด balancers คุณสามารถใช้คณิตศาสตร์ที่เรียบง่ายที่จะประเมินว่าหลายคำสั่งที่คุณหายไป หากคุณคาดหวังการสืบค้น X สำหรับวันดังกล่าวในสัปดาห์นั้น แต่คุณได้รับ X-1000 คุณอาจลดการค้นหา 1,000 ครั้ง พล็อตปริมาณการใช้งานของคุณลงในแบบสอบถามต่อนาที (หรือวินาที) กราฟ หากช่องว่างปรากฏขึ้นแสดงว่าคุณทำแบบสอบถามหาย ใช้รูปทรงเรขาคณิตพื้นฐานเพื่อวัดพื้นที่ของช่องว่างเหล่านั้นซึ่งจะให้จำนวนการสืบค้นที่ลดลงทั้งหมด

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

จากนั้นคุณสามารถเซ็นสัญญาตามการปรับปรุงพื้นฐาน สมมติว่าหากพวกเขาประสบความพร้อมใช้งาน 95% คุณสามารถสัญญาว่าจะปรับปรุงสถานการณ์สิบเท่าด้วยการไปถึง 98.5%

หมายเหตุ: มีข้อเสียสำหรับวิธีการวัดความพร้อมใช้งานนี้ ก่อนอื่นให้รวบรวมบันทึกประมวลผลและสร้างรายงานด้วยตัวคุณเองอาจไม่น่าสนใจเว้นแต่คุณจะใช้เครื่องมือที่มีอยู่แล้วทำ ประการที่สองข้อบกพร่องของแอปพลิเคชันอาจส่งผลต่อความพร้อมใช้งานของคุณ หากแอปพลิเคชันมีคุณภาพต่ำแอปจะแสดงข้อผิดพลาดเพิ่มเติม วิธีแก้ไขปัญหานี้คือพิจารณาเฉพาะ 500s ที่สร้างขึ้นโดย load-balancer แทนการมาจากแอ็พพลิเคชัน

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

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

มันง่ายกว่านั้นมาก มันเป็นไปไม่ได้ในทางคณิตศาสตร์

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

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

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

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

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

สิ่งเหล่านี้เป็นสิ่งที่ลูกค้าให้ความสำคัญ หากลูกค้าคิด SLA ที่แม่นยำจริง ๆ แล้วพวกเขาจะรู้พอที่จะแสดงเป็น 99.99 หรือ 99.999

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

สิ่งที่เป็นระเบียบเกี่ยวกับบริการของพวกเขาคือฉันไม่ต้องทำอะไรซับซ้อนมากนักเพื่อทำซ้ำเนื้อหาบนเซิร์ฟเวอร์ในดาต้าเซ็นเตอร์ของตัวเองไปยังดาต้าเซ็นเตอร์ นอกจากนี้ฉันรู้จากการทำงานกับพวกเขาพวกเขาใช้เซิร์ฟเวอร์ Apache HTTP อย่างหนัก

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

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

สำหรับไซต์ที่โฮสต์จากภายนอกคุณจะได้รับสถานะการออนไลน์สูงสุด 100% เมื่อโฮสต์ไซต์ของคุณบน App Engine ของ Google และใช้ที่เก็บข้อมูลการจำลองแบบสูง (HRD)ซึ่งทำซ้ำข้อมูลของคุณโดยอัตโนมัติในศูนย์ข้อมูลอย่างน้อยสามแห่ง เซิร์ฟเวอร์ Front Engine ของ App Engine จะถูกปรับขนาด / จำลองแบบอัตโนมัติสำหรับคุณเช่นเดียวกัน

อย่างไรก็ตามถึงแม้จะมีทรัพยากรทั้งหมดของ Google และแพลตฟอร์มที่ทันสมัยที่สุดในโลกการรับประกันความพร้อมใช้งานของApp Engine SLAนั้นมีเพียง "99.95% ของเวลาในทุกเดือนปฏิทิน"

ง่ายและตรงไปตรง: Anycast

http://en.wikipedia.org/wiki/Anycast

นี่คือสิ่งที่ cloudflare, google และ บริษัท ขนาดใหญ่อื่น ๆ ใช้ในการทำข้อมูลซ้ำซ้อน, ความหน่วงต่ำ, ความล้มเหลวข้ามทวีป / การปรับสมดุล

แต่โปรดจำไว้ว่าเป็นไปไม่ได้ที่จะมีเวลาใช้งาน 100% และค่าใช้จ่ายในการเปลี่ยนจาก 99.999% เป็น 99.9999% นั้นใหญ่กว่ามาก