ในบทความนี้ ฉันต้องการแสดงให้เห็นว่าคุณสามารถสร้างรูปแบบการเฟลโอเวอร์สำหรับเว็บไซต์ (หรือบริการอินเทอร์เน็ตอื่น ๆ) ได้ง่ายและฟรีเพียงใดโดยใช้การตรวจสอบร่วมกัน
จะอยู่ร่วมกับการเฟลโอเวอร์หรือไม่มี?
จนเกิดปัญหาก็ไม่มีความแตกต่างกันมากนัก แต่เมื่อมันเกิดขึ้น หากไม่มีการเฟลโอเวอร์ สิ่งต่อไปนี้มักจะเกิดขึ้น: คุณพยายามค้นหาอย่างรวดเร็วว่าปัญหาคืออะไร มันไม่ทำงาน (การสำรองข้อมูลไม่ทำงาน ซอฟต์แวร์ด้วยเหตุผลบางอย่างไม่ทำงานอย่างที่ควรจะเป็นจากเอกสารประกอบ ฯลฯ ) แต่ไม่มีเวลาไม่มีเซิร์ฟเวอร์ - ไซต์วางอยู่ลูกค้ากำลังโทรหาทุกคนอยู่ในขอบคุณกำลังพยายามแก้ไขมันอย่างหยาบและสกปรก "ด้วยเทป" จากนั้นดูเหมือนว่าจะเริ่มทำงาน ด้วยไม้ค้ำยันและชีวิต คุณคิดว่าในเวลาว่างคุณจะต้องคิดให้ละเอียดมากขึ้นและทำทุกอย่างใหม่ให้สวยงาม แต่ไม่มีอะไรถาวรไปกว่าชั่วคราว
ตอนนี้สิ่งนี้จะเกิดขึ้นได้อย่างไรในเวอร์ชันที่สวยงามพร้อมไฟล์:
- มีข้อผิดพลาดเกิดขึ้น
- ตรวจพบข้อผิดพลาดโดยอัตโนมัติ
- การแจ้งเตือนถูกส่งออกไป
- การสลับไปยังเซิร์ฟเวอร์สำรองข้อมูลตัวใดตัวหนึ่งจะถูกถ่ายโอน
- ปัญหาได้รับการแก้ไขอย่างสงบและปราศจากความตื่นตระหนก และเซิร์ฟเวอร์ก็กลับมาใช้งานได้อีกครั้ง
แน่นอนว่าโครงร่างนี้อาจมีปัญหาของตัวเอง แต่ถึงกระนั้นโครงร่างก็เป็นเส้นตรง แต่ละขั้นตอนนั้นเรียบง่ายและสิ่งสำคัญคือสามารถแก้ไขจุดบกพร่องแยกกันได้ ดังนั้นโอกาสที่จะล้มเหลวของโครงร่างนี้จึงต่ำกว่ามาก และ การกระทำทั้งหมดสามารถเป็นอัตโนมัติและดำเนินการได้อย่างรวดเร็ว (ไม่เหมือนกับงานค้นหาและแก้ไขอึมหากาพย์ที่ไม่รู้จัก) เครื่องบินของคุณลงจอดในประเทศห่างไกล คุณเปิดโทรศัพท์ของคุณและดูการแจ้งเตือนในโทรเลขว่าเซิร์ฟเวอร์ขัดข้อง แต่ทุกอย่างเรียบร้อยดี เซิร์ฟเวอร์สำรองเปิดใช้งานแล้ว คุณสามารถเดินทางต่อได้ คุณไม่จำเป็นต้อง เพื่อบินกลับหรือซ่อมแซมผ่าน SSH จากร้านกาแฟที่ใกล้ที่สุดพร้อม WiFi คุณจะคิดออกเมื่อสะดวกมากขึ้น
อนาคตอยู่ที่นี่แล้ว!
ก่อนหน้านี้ ปัญหาหลักที่ทำให้เฟลโอเวอร์มักเป็นโซลูชันที่ยอมรับไม่ได้คือจำนวนต้นทุนที่ต้องจ่าย หรือจำเป็นต้องซื้อฮาร์ดแวร์ราคาแพง (และเชิญผู้เชี่ยวชาญที่มีราคาแพงกว่า) หรือฟาร์มรวมสิ่งที่ซับซ้อนตามคำแนะนำ (ฉันยังเจอตัวเลือกที่เซิร์ฟเวอร์สองตัวเชื่อมต่อเพิ่มเติมด้วยสายเคเบิลโมเด็มว่างและพวกเขาก็ส่งฮาร์ทบีทผ่านมันเพื่อที่ว่าในเวลาที่เหมาะสมเซิร์ฟเวอร์สำรองจะจดจำและเข้ายึดครองได้ในเวลาที่เหมาะสม ควบคุม). ขณะนี้มีวิธีที่ง่ายและฟรีมากขึ้น หากคุณมีเว็บไซต์ที่มีแมว ก็ไม่มีข้อแก้ตัวใด ๆ ที่คุณจะยังไม่ติดตั้งระบบเฟลโอเวอร์!
นอกจากนี้ สำหรับแผนเฟลโอเวอร์ คุณต้องมีเซิร์ฟเวอร์อื่น (และอาจมากกว่าหนึ่งเซิร์ฟเวอร์) และก่อนหน้านี้จะเป็นค่าใช้จ่ายจำนวนมาก ตอนนี้คุณสามารถรับ VDS ได้ในราคาประหยัด
เว็บไซต์ที่น่าเชื่อถือที่สุดเกี่ยวกับแมว
เพื่อแสดงให้เห็นวิธีแก้ปัญหาด้วย okrr + dynamic dns เราจึงเปิดตัวเว็บไซต์ที่มีแมว
ในข้อมูลทางเทคนิคจะมีบรรทัด “status=OK” บางครั้งเซิร์ฟเวอร์แสร้งทำเป็นเกิดปัญหาและเขียนสถานะ = ERR เซิร์ฟเวอร์หลัก “ดูเหมือนว่าจะล่ม” ทุกๆ 20 นาทีของทุกชั่วโมง (0:20, 1:20, 2:20, …) เซิร์ฟเวอร์สำรองใน 40 นาที เซิร์ฟเวอร์สุดท้าย (เซิร์ฟเวอร์ "ขออภัย") ทำงานอยู่เสมอ ทุกๆ 0 นาที เซิร์ฟเวอร์หลักและเซิร์ฟเวอร์สำรองจะถูก "กู้คืน"
หากคุณเปิดไซต์และปล่อยทิ้งไว้ในแท็บ คุณจะเห็นว่าไซต์ไม่เคยล่ม (แม้ว่าแต่ละเซิร์ฟเวอร์จะจำลองปัญหาเป็นระยะๆ ก็ตาม) และในกรณีที่เกิดปัญหากับเซิร์ฟเวอร์ ไซต์ก็จะ "ทำงาน" ระหว่างเซิร์ฟเวอร์ที่ใช้งานจริงเท่านั้น รูปภาพ ชื่อ และที่อยู่ของเซิร์ฟเวอร์และบทบาทของเซิร์ฟเวอร์จะเปลี่ยนไป บางครั้งคุณสามารถจับจังหวะได้เมื่อ status = ERR (ปัญหามีอยู่แล้ว แต่รูปแบบการเฟลโอเวอร์ทั้งหมดยังไม่ทำงาน) แต่การอัปเดตครั้งถัดไปจะแสดงเพจจากไซต์การทำงานให้คุณเห็น
เฟลโอเวอร์บน okrr + DNS ไดนามิก
เรามาดูกันว่ามันทำงานอย่างไรภายใต้ประทุน หน้าที่ของไฟล์คือตรวจสอบให้แน่ใจว่าที่อยู่ cat.okerr.com ชี้ไปยังที่อยู่ IP ของเซิร์ฟเวอร์ที่ทำงานเสมอ
ด้านหลังเซิร์ฟเวอร์แต่ละเซิร์ฟเวอร์ที่โฮสต์ไซต์ cat ของเราใน okerr จะมีตัวบ่งชี้ที่ตรวจสอบสถานะนาทีละครั้ง
ในภาพหน้าจอนี้ เราจะเห็นว่าไซต์ cat.okerr.com ได้รับการตรวจสอบจากเซิร์ฟเวอร์ alpha.okerr.com อย่างไร หน้านี้ควรมีสถานะ=ตกลง และดังที่เราเห็นด้านบน สถานะตัวบ่งชี้ของเราก็ใช้ได้แล้ว เมื่อเซิร์ฟเวอร์ “หยุดทำงาน” จะมีข้อผิดพลาดเกิดขึ้น (นี่เป็นเพียงตัวอย่างหนึ่งของตัวบ่งชี้ Okrr กำลังตรวจสอบ ดังนั้นคุณจึงสามารถแนบตัวบ่งชี้ประเภทใดก็ได้ เช่น ตรวจสอบพื้นที่ว่างบนดิสก์ จำนวนคำสั่งซื้อใหม่ในฐานข้อมูล และแม้แต่ตัวบ่งชี้เชิงตรรกะ เป็นต้น กลางคืนจะมีเกณฑ์ผิดพลาดบ้าง และช่วงกลางวันอื่นๆ )
ในการตั้งค่าโปรเจ็กต์ เราได้สร้างแผนเฟลโอเวอร์พร้อมตัวบ่งชี้เหล่านี้:
โครงการนี้มีตัวบ่งชี้สามตัว (สามเซิร์ฟเวอร์) ซึ่งมีลำดับความสำคัญต่างกัน เซิร์ฟเวอร์หลักสำหรับไซต์คือ charlie ถ้ามันใช้งานไม่ได้ (จะไม่มี "สถานะ=ตกลง" หรือใช้งานไม่ได้) ให้ไชโยและในกรณีหลัง - อัลฟ่า ทางด้านขวาของหน้าจะแสดงสถานะของบันทึก DNS บนเซิร์ฟเวอร์ต่างๆ
สำหรับผู้ที่สังเกตเห็นว่ามีการใช้ชื่อ cat.he.okerr.com: เราใช้รูปแบบที่ซับซ้อนกว่าเล็กน้อย แทนที่จะเปลี่ยนบันทึก DNS ของ cat.okerr.com เราจะเปลี่ยน cat.he.okerr.com (บนผู้ให้บริการ DNS แบบไดนามิก
จากล้มเป็นเพิ่มขึ้น
โครงการนี้ทำงานอย่างไรทีละขั้นตอน:
- เกิดปัญหา (จำลอง) บนเซิร์ฟเวอร์
- เซ็นเซอร์ Okrr จะตรวจสอบสถานะของแต่ละเซิร์ฟเวอร์นาทีละครั้ง และรายงานไปยังเซิร์ฟเวอร์โปรเจ็กต์หลักใน Okrr
- ตัวบ่งชี้เซิร์ฟเวอร์ที่เกี่ยวข้องเปลี่ยนจากตกลงเป็นข้อผิดพลาด
- เมื่อสถานะของตัวบ่งชี้เปลี่ยนแปลง จะมีการคำนวณการเฟลโอเวอร์อีกครั้ง และจะมีการคำนวณว่าต้องตั้งค่าที่อยู่ใด (หากจำเป็น ตัวอย่างเช่น หากเซิร์ฟเวอร์หลักทำงาน และในเวลาเดียวกันเซิร์ฟเวอร์สำรองหยุดทำงาน จะไม่มีการเปลี่ยนแปลงใด ๆ เกิดขึ้น ทำ)
- ที่อยู่นี้ถูกรายงานไปยังบริการ DNS แบบไดนามิก เมื่อเสร็จสิ้นขั้นตอนนี้ คุณจะเห็นสถานะ "ซิงค์" ทางด้านขวา
- เร็วๆ นี้ (วินาที) บันทึกจะไปถึงเซิร์ฟเวอร์ DNS ของโดเมนของคุณ (สำหรับไซต์ cat คือ ns1-ns5.he.net)
- จากนี้ไป ผู้ใช้บางส่วนจะอยู่ในเซิร์ฟเวอร์สดใหม่แล้ว แต่เซิร์ฟเวอร์ DNS บางแห่งในโลกยังไม่ได้อัปเดตบันทึก และบันทึกเก่าอาจยังถูกแคชไว้ที่ใดที่หนึ่ง คุณสามารถดูว่าข้อมูลบนเซิร์ฟเวอร์ DNS สาธารณะ “เต้น” ได้อย่างไร โดยแสดงค่าใหม่หรือค่าเก่า หากคุณอัปเดตหน้าการกำหนดค่าเฟลโอเวอร์ ตัวดำเนินการจะขอข้อมูลใหม่จากเซิร์ฟเวอร์ DNS
- หลังจากที่ข้อมูลมีความเสถียร บันทึกแคชเก่าจะเน่าทุกที่ - คำขอทั้งหมด 100% ไปที่เซิร์ฟเวอร์ใหม่
หากต้องการเร่งความเร็วขั้นที่ 7 (มักจะยาวที่สุด) ควรตั้งค่า TTL ของบันทึก DNS แบบไดนามิกให้ต่ำที่สุดเท่าที่จะเป็นไปได้ โดยทั่วไปบริการจะอนุญาตช่วงเวลา 90-120 วินาที นี่เป็นการประนีประนอมที่สมเหตุสมผลอย่างยิ่ง
นอกจากนี้
ทั้งหมดนี้สามารถกำหนดค่าได้ในช่วงเย็น (หากคุณมีเซิร์ฟเวอร์สำรองอยู่แล้ว) ทั้งบริการ okrr และ DNS แบบไดนามิกนั้นฟรี หากต้องการรับการตรวจสอบเพิ่มเติมใน okrr และระยะเวลาการตรวจสอบที่สั้นลง คุณต้องผ่านการฝึกอบรม (จากหน้าโปรไฟล์ของคุณ) เมื่อเสร็จสิ้น ระดับจะเพิ่มขึ้นทันที (20 ตัวชี้ต่อชั่วโมง + 1 ตัวชี้เร็ว 10 นาที) และหากมีน้อยก็เขียนถึง [ป้องกันอีเมล]มีแนวโน้มว่าจะเพิ่มขึ้นได้ (จนถึงตอนนี้มีโอกาสมาโดยตลอด ฉันไม่เคยปฏิเสธ ในทางกลับกัน ฉันเสนอให้ตัวเอง) แค่ในตอนแรกฉันไม่อยากสัญญากับทุกคนทุกเรื่อง ฉันไม่แน่ใจว่าตัวเองมีความสามารถเพียงพอที่จะรักษาคำพูดของฉันหรือไม่ แต่จนถึงขณะนี้มีผู้ใช้น้อย ดังนั้นจึงไม่มีปัญหาในการเพิ่มขีดจำกัด
โดยทั่วไปสิ่งที่ okrr สามารถทำได้ - ดูที่เว็บไซต์
เมื่อสถานะตัวบ่งชี้เปลี่ยนแปลง การแจ้งเตือนจะถูกส่งทางอีเมลหรือโทรเลข (เราตรวจสอบสิ่งที่เกิดขึ้นและพบว่าโทรเลขดูเหมือนจะเป็นผู้ส่งสารที่น่าเชื่อถือที่สุด ต้องขอบคุณ RKN สำหรับการทดสอบความเครียด!) เมื่อ okerr กำหนดค่าอย่างถูกต้อง การแจ้งเตือนใดๆ ก็เป็นสัญญาณว่า "ทิ้งทุกอย่าง เราต้องแก้ไขมัน!" หรือ “ไฟดับ!” ไม่ควรมีการแจ้งเตือนเพิ่มเติมจาก okerra (หากมี จำเป็นต้องกำหนดค่าให้แตกต่างออกไป) ตัวอย่างเช่น สำหรับไซต์ cat ของเรา เซิร์ฟเวอร์อัลฟ่าเป็นเซิร์ฟเวอร์สุดท้ายและไม่เคยปลอมแปลงข้อผิดพลาด ถ้าเขานอนเราต้องรู้ แต่เซิร์ฟเวอร์อื่น ๆ แสร้งทำเป็นข้อผิดพลาดอยู่ตลอดเวลา ดังนั้น เพื่อไม่ได้รับการแจ้งเตือนหลายครั้งต่อชั่วโมง ตัวบ่งชี้เหล่านั้นจึงมีสถานะ "เงียบ"
นอกจากนี้ยังสมเหตุสมผลที่จะสร้างเซิร์ฟเวอร์ขออภัย (บนโฮสติ้งที่ถูกที่สุด) ซึ่งจะมีหน้าคำขอโทษของคุณ (ในกรณีที่เซิร์ฟเวอร์หลักและเซิร์ฟเวอร์สำรองทั้งหมดล่ม) หรือจะนำคุณไปยังหน้าสถานะบน okerr (เช่น ของเรา
ที่มา: will.com