เว็บสมัยใหม่แทบจะคิดไม่ถึงเลยหากไม่มีเนื้อหาสื่อ คุณยายเกือบทุกคนมีสมาร์ทโฟน ทุกคนใช้โซเชียลเน็ตเวิร์ก และการหยุดทำงานของการบำรุงรักษาถือเป็นค่าใช้จ่ายสำหรับบริษัทต่างๆ นี่คือสำเนาเรื่องราวของบริษัท เกี่ยวกับวิธีที่เธอจัดระเบียบการจัดส่งภาพถ่ายโดยใช้โซลูชันฮาร์ดแวร์ ปัญหาด้านประสิทธิภาพที่เธอพบในกระบวนการ สาเหตุที่เกิดขึ้น และวิธีแก้ปัญหาเหล่านี้โดยใช้โซลูชันซอฟต์แวร์ที่ใช้ Nginx ในขณะเดียวกันก็รับประกันความทนทานต่อข้อผิดพลาดในทุกระดับ (). เราขอขอบคุณผู้เขียนเรื่องราวของ Oleg Efimova และ Alexandra Dymova ผู้ร่วมแบ่งปันประสบการณ์ในการประชุม .
— เรามาเริ่มกันด้วยการแนะนำเล็กน้อยเกี่ยวกับวิธีที่เราจัดเก็บและแคชรูปภาพ เรามีเลเยอร์สำหรับจัดเก็บ และเลเยอร์สำหรับแคชรูปภาพ ในเวลาเดียวกัน หากเราต้องการบรรลุอัตรากลอุบายที่สูงและลดภาระในพื้นที่จัดเก็บข้อมูล สิ่งสำคัญสำหรับเราที่ภาพถ่ายแต่ละภาพของผู้ใช้แต่ละรายจะต้องอยู่บนเซิร์ฟเวอร์แคชเซิร์ฟเวอร์เดียว มิฉะนั้น เราจะต้องติดตั้งดิสก์เพิ่มขึ้นหลายเท่าเนื่องจากเรามีเซิร์ฟเวอร์มากขึ้น อัตรากลอุบายของเราอยู่ที่ประมาณ 99% นั่นคือเรากำลังลดภาระบนพื้นที่จัดเก็บข้อมูลของเราลง 100 เท่า และเพื่อที่จะทำเช่นนี้ เมื่อ 10 ปีที่แล้ว เรามีเซิร์ฟเวอร์ 50 เครื่อง เมื่อทั้งหมดนี้ถูกสร้างขึ้น ดังนั้น เพื่อที่จะให้บริการรูปภาพเหล่านี้ เราจำเป็นต้องมีโดเมนภายนอก 50 โดเมนที่เซิร์ฟเวอร์เหล่านี้ให้บริการ
โดยปกติแล้ว คำถามก็เกิดขึ้นทันที: หากเซิร์ฟเวอร์ตัวใดตัวหนึ่งของเราล่มและไม่สามารถใช้งานได้ เราจะสูญเสียการรับส่งข้อมูลส่วนใดไป เราพิจารณาสิ่งที่อยู่ในตลาดและตัดสินใจซื้อฮาร์ดแวร์ชิ้นหนึ่งเพื่อที่จะแก้ไขปัญหาทั้งหมดของเรา ทางเลือกตกอยู่ที่โซลูชันของบริษัทเครือข่าย F5 (ซึ่งเพิ่งซื้อ NGINX, Inc.): BIG-IP Local Traffic Manager
สิ่งที่ฮาร์ดแวร์ชิ้นนี้ (LTM) ทำ: เป็นเราเตอร์เหล็กที่ทำให้พอร์ตภายนอกมีความซ้ำซ้อนและช่วยให้คุณสามารถกำหนดเส้นทางการรับส่งข้อมูลตามโทโพโลยีเครือข่าย ในการตั้งค่าบางอย่าง และทำการตรวจสุขภาพ สิ่งสำคัญสำหรับเราคือสามารถตั้งโปรแกรมฮาร์ดแวร์ชิ้นนี้ได้ ดังนั้นเราจึงสามารถอธิบายตรรกะของวิธีการแสดงภาพถ่ายของผู้ใช้รายใดรายหนึ่งจากแคชเฉพาะได้ มันดูเหมือนอะไร? มีฮาร์ดแวร์ชิ้นหนึ่งที่ดูอินเทอร์เน็ตบนโดเมนเดียว หนึ่ง IP ทำการถ่ายโอน SSL แยกวิเคราะห์คำขอ http เลือกหมายเลขแคชจาก IRule ตำแหน่งที่จะไป และปล่อยให้การรับส่งข้อมูลไปที่นั่น ในเวลาเดียวกัน จะทำการตรวจสอบสภาพ และในกรณีที่เครื่องบางเครื่องไม่พร้อมใช้งาน ในขณะนั้นเราได้ดำเนินการเพื่อให้การรับส่งข้อมูลไปยังเซิร์ฟเวอร์สำรองเดียว จากมุมมองของการกำหนดค่าแน่นอนว่ามีความแตกต่างบางอย่าง แต่โดยทั่วไปแล้วทุกอย่างค่อนข้างง่าย: เราลงทะเบียนการ์ดการโต้ตอบของหมายเลขที่แน่นอนกับ IP ของเราบนเครือข่ายเราบอกว่าเราจะฟังบนพอร์ต 80 และ 443 เราบอกว่าหากเซิร์ฟเวอร์ไม่พร้อมใช้งาน คุณจะต้องส่งทราฟฟิกไปยังเซิร์ฟเวอร์สำรอง ซึ่งในกรณีนี้คือเซิร์ฟเวอร์ที่ 35 และเราจะอธิบายตรรกะหลายประการเกี่ยวกับวิธีการแยกประกอบสถาปัตยกรรมนี้ ปัญหาเดียวคือภาษาที่ใช้ตั้งโปรแกรมฮาร์ดแวร์คือ Tcl หากใครจำสิ่งนี้ได้เลย... ภาษานี้เขียนได้อย่างเดียวมากกว่าภาษาที่สะดวกสำหรับการเขียนโปรแกรม:
เราได้อะไร? เราได้รับฮาร์ดแวร์ชิ้นหนึ่งที่รับประกันความพร้อมใช้งานสูงของโครงสร้างพื้นฐานของเรา กำหนดเส้นทางการรับส่งข้อมูลทั้งหมดของเรา ให้ประโยชน์ต่อสุขภาพ และใช้งานได้จริง ยิ่งกว่านั้นมันใช้งานได้ค่อนข้างนานในช่วง 10 ปีที่ผ่านมาไม่มีการร้องเรียนเกี่ยวกับเรื่องนี้ ภายในต้นปี 2018 เราได้ส่งรูปภาพไปแล้วประมาณ 80 ภาพต่อวินาที นี่คือปริมาณการรับส่งข้อมูลประมาณ 80 กิกะบิตจากศูนย์ข้อมูลทั้งสองของเรา
แต่…
เมื่อต้นปี 2018 เราเห็นภาพที่น่าเกลียดบนแผนภูมิ: เวลาในการส่งรูปภาพเพิ่มขึ้นอย่างเห็นได้ชัด และมันก็เลิกเหมาะกับเราแล้ว ปัญหาคือพฤติกรรมนี้จะมองเห็นได้เฉพาะในช่วงที่มีการจราจรหนาแน่นเท่านั้น สำหรับบริษัทของเรา นี่คือคืนตั้งแต่วันอาทิตย์ถึงวันจันทร์ แต่เวลาที่เหลือระบบก็ทำงานตามปกติไม่มีสัญญาณขัดข้อง
อย่างไรก็ตามปัญหาก็ต้องได้รับการแก้ไข เราระบุปัญหาคอขวดที่อาจเกิดขึ้นได้และเริ่มกำจัดมัน ก่อนอื่นเลย เราได้ขยายอัปลิงก์ภายนอก ดำเนินการตรวจสอบอัปลิงก์ภายในอย่างสมบูรณ์ และพบปัญหาคอขวดที่เป็นไปได้ทั้งหมด แต่ทั้งหมดนี้ไม่ได้ให้ผลลัพธ์ที่ชัดเจนปัญหาก็ไม่หายไป
ปัญหาคอขวดที่เป็นไปได้อีกประการหนึ่งคือประสิทธิภาพของแคชภาพถ่ายเอง และเราตัดสินใจว่าบางทีปัญหาก็ขึ้นอยู่กับพวกเขา เราได้ขยายประสิทธิภาพ - ส่วนใหญ่เป็นพอร์ตเครือข่ายบนแคชรูปภาพ แต่ก็ไม่เห็นการปรับปรุงที่ชัดเจนอีกครั้ง ในท้ายที่สุด เราให้ความสนใจอย่างใกล้ชิดกับประสิทธิภาพของ LTM และในภาพนี้เราเห็นภาพที่น่าเศร้าบนกราฟ: โหลดบน CPU ทั้งหมดเริ่มดำเนินไปอย่างราบรื่น แต่ทันใดนั้นก็มาถึงที่ราบสูง ในเวลาเดียวกัน LTM จะหยุดตอบสนองอย่างเพียงพอต่อการตรวจสอบสภาพและอัปลิงก์ และเริ่มปิดการทำงานแบบสุ่ม ซึ่งส่งผลให้ประสิทธิภาพลดลงอย่างร้ายแรง
นั่นคือเราได้ระบุสาเหตุของปัญหา ระบุคอขวด ยังคงต้องตัดสินใจว่าเราจะทำอะไร
สิ่งแรกที่ชัดเจนที่สุดที่เราสามารถทำได้คือปรับปรุง LTM ให้ทันสมัยขึ้น แต่มีความแตกต่างบางประการเนื่องจากฮาร์ดแวร์นี้มีเอกลักษณ์เฉพาะคุณจะไม่ไปซุปเปอร์มาร์เก็ตที่ใกล้ที่สุดแล้วซื้อมัน นี่เป็นสัญญาแยกต่างหาก สัญญาสิทธิ์การใช้งานแยกต่างหาก และจะใช้เวลานานมาก ตัวเลือกที่สองคือเริ่มคิดเอง คิดวิธีแก้ปัญหาของคุณเองโดยใช้ส่วนประกอบของคุณเอง ควรใช้โปรแกรมการเข้าถึงแบบเปิด สิ่งที่เหลืออยู่คือตัดสินใจว่าเราจะเลือกอะไรกันแน่และเราจะใช้เวลาในการแก้ปัญหานี้นานเท่าใด เนื่องจากผู้ใช้ได้รับภาพถ่ายไม่เพียงพอ ดังนั้นเราจึงจำเป็นต้องทำทั้งหมดนี้อย่างรวดเร็วมากใครๆก็พูดเมื่อวานนี้
เนื่องจากงานดูเหมือน “ทำอะไรบางอย่างให้เร็วที่สุดเท่าที่จะเป็นไปได้และใช้ฮาร์ดแวร์ที่เรามี” สิ่งแรกที่เราคิดก็คือการนำเครื่องจักรที่ไม่ทรงพลังบางตัวออกจากด้านหน้า วาง Nginx ไว้ตรงนั้น ซึ่งเรารู้วิธีที่จะ ทำงานและพยายามใช้ตรรกะเดียวกันกับที่ฮาร์ดแวร์เคยทำ นั่นคือในความเป็นจริง เราออกจากฮาร์ดแวร์ของเรา ติดตั้งเซิร์ฟเวอร์อีก 4 เครื่องที่เราต้องกำหนดค่า สร้างโดเมนภายนอกสำหรับพวกเขา คล้ายกับเมื่อ 10 ปีที่แล้ว... เราสูญเสียความพร้อมใช้งานเล็กน้อยหากเครื่องเหล่านี้ล่ม แต่ มันยังช่วยแก้ไขปัญหาของผู้ใช้ของเราในพื้นที่ได้อีกด้วย
ดังนั้น ตรรกะยังคงเหมือนเดิม: เราติดตั้ง Nginx มันสามารถทำ SSL-offload ได้ เราสามารถตั้งโปรแกรมลอจิกการกำหนดเส้นทาง การตรวจสอบสภาพในการกำหนดค่า และเพียงแค่ทำซ้ำตรรกะที่เรามีก่อนหน้านี้
มานั่งเขียน config กัน ในตอนแรกดูเหมือนว่าทุกอย่างจะเรียบง่ายมาก แต่น่าเสียดายที่การค้นหาคู่มือสำหรับทุกงานนั้นยากมาก ดังนั้นเราไม่แนะนำให้เพียงแค่ googling "วิธีกำหนดค่า Nginx สำหรับรูปภาพ": เป็นการดีกว่าถ้าอ้างอิงถึงเอกสารอย่างเป็นทางการซึ่งจะแสดงว่าควรสัมผัสการตั้งค่าใด แต่ควรเลือกพารามิเตอร์เฉพาะด้วยตัวเองจะดีกว่า ถ้าอย่างนั้น ทุกอย่างก็เรียบง่าย: เราอธิบายเซิร์ฟเวอร์ที่เรามี เราอธิบายใบรับรอง... แต่สิ่งที่น่าสนใจที่สุดคือ จริงๆ แล้ว ลอจิกการกำหนดเส้นทางนั้นเอง
ในตอนแรกดูเหมือนว่าเราเพียงแค่อธิบายตำแหน่งของเรา โดยจับคู่จำนวนแคชรูปภาพของเราในนั้น โดยใช้มือหรือเครื่องกำเนิดไฟฟ้าเพื่ออธิบายจำนวนอัปสตรีมที่เราต้องการ ในแต่ละอัปสตรีม เราระบุเซิร์ฟเวอร์ที่การรับส่งข้อมูลควรได้รับ ไปและเซิร์ฟเวอร์สำรอง - หากเซิร์ฟเวอร์หลักไม่พร้อมใช้งาน:
แต่บางทีถ้าทุกอย่างเรียบง่าย เราก็จะกลับบ้านและไม่พูดอะไรเลย น่าเสียดายที่การตั้งค่าเริ่มต้นของ Nginx ซึ่งโดยทั่วไปแล้วใช้เวลาหลายปีของการพัฒนาและไม่เหมาะกับกรณีนี้โดยสิ้นเชิง... การกำหนดค่าจะมีลักษณะดังนี้: หากเซิร์ฟเวอร์อัปสตรีมบางตัวมีข้อผิดพลาดคำขอหรือหมดเวลา Nginx เสมอ สลับการรับส่งข้อมูลไปยังรายการถัดไป ยิ่งไปกว่านั้น หลังจากความล้มเหลวครั้งแรก ภายใน 10 วินาที เซิร์ฟเวอร์จะถูกปิดทั้งโดยไม่ได้ตั้งใจและหมดเวลา - ซึ่งไม่สามารถกำหนดค่าได้ในทางใดทางหนึ่งด้วยซ้ำ นั่นคือถ้าเราลบหรือรีเซ็ตตัวเลือกการหมดเวลาในคำสั่งอัปสตรีม แม้ว่า Nginx จะไม่ประมวลผลคำขอนี้และจะตอบกลับด้วยข้อผิดพลาดที่ไม่ค่อยดีนัก แต่เซิร์ฟเวอร์ก็จะปิดตัวลง
เพื่อหลีกเลี่ยงปัญหานี้ เราได้ทำสองสิ่ง:
ก) พวกเขาห้ามไม่ให้ Nginx ทำสิ่งนี้ด้วยตนเอง - และน่าเสียดายที่วิธีเดียวที่จะทำได้คือเพียงตั้งค่าการตั้งค่าสูงสุดที่ล้มเหลว
b) เราจำได้ว่าในโครงการอื่น ๆ เราใช้โมดูลที่ช่วยให้เราสามารถตรวจสุขภาพพื้นหลังได้ ดังนั้น เราจึงทำการตรวจสุขภาพค่อนข้างบ่อยเพื่อให้การหยุดทำงานในกรณีที่เกิดอุบัติเหตุมีน้อยที่สุด
น่าเสียดายที่นี่ไม่ใช่ทั้งหมดเพราะแท้จริงแล้วสองสัปดาห์แรกของการดำเนินการของโครงการนี้แสดงให้เห็นว่าการตรวจสอบสุขภาพ TCP ก็เป็นสิ่งที่ไม่น่าเชื่อถือเช่นกัน: บนเซิร์ฟเวอร์อัปสตรีมอาจไม่ใช่ Nginx หรือ Nginx ใน D-state และใน ในกรณีนี้เคอร์เนลจะยอมรับการเชื่อมต่อ การตรวจสุขภาพจะผ่าน แต่จะไม่ทำงาน ดังนั้นเราจึงแทนที่สิ่งนี้ด้วย http ตรวจสุขภาพทันทีโดยสร้างอันเฉพาะซึ่งหากส่งคืน 200 แสดงว่าทุกอย่างใช้งานได้ในสคริปต์นี้ คุณสามารถดำเนินการตรรกะเพิ่มเติมได้ ตัวอย่างเช่น ในกรณีของแคชเซิร์ฟเวอร์ ให้ตรวจสอบว่าระบบไฟล์ติดตั้งอย่างถูกต้อง:
และนี่จะเหมาะกับเรา ยกเว้นว่าในขณะนี้วงจรทำซ้ำสิ่งที่ฮาร์ดแวร์ทำโดยสิ้นเชิง แต่เราอยากจะทำให้ดีขึ้น ก่อนหน้านี้ เรามีเซิร์ฟเวอร์สำรองหนึ่งเซิร์ฟเวอร์ และนี่อาจไม่ดีนัก เพราะหากคุณมีเซิร์ฟเวอร์นับร้อยเซิร์ฟเวอร์ เมื่อหลายเซิร์ฟเวอร์ล้มเหลวในคราวเดียว เซิร์ฟเวอร์สำรองหนึ่งเซิร์ฟเวอร์ก็ไม่น่าจะรับมือกับโหลดได้ ดังนั้นเราจึงตัดสินใจกระจายการจองไปยังเซิร์ฟเวอร์ทั้งหมด: เราเพียงสร้างอัปสตรีมแยกกันอีกเซิร์ฟเวอร์หนึ่ง เขียนเซิร์ฟเวอร์ทั้งหมดที่นั่นด้วยพารามิเตอร์บางอย่างตามโหลดที่เซิร์ฟเวอร์สามารถรองรับได้ เพิ่มการตรวจสุขภาพแบบเดียวกับที่เรามีก่อนหน้านี้ :
เนื่องจากเป็นไปไม่ได้ที่จะไปยังอัปสตรีมอื่นภายในอัปสตรีมเดียว จึงจำเป็นต้องตรวจสอบให้แน่ใจว่าหากอัปสตรีมหลักซึ่งเราบันทึกแคชรูปภาพที่จำเป็นและถูกต้องไม่พร้อมใช้งาน เราก็เพียงแค่ไปที่ error_page เพื่อสำรอง จาก ที่เราไปที่ต้นน้ำสำรอง:
และโดยการเพิ่มเซิร์ฟเวอร์สี่ตัวอย่างแท้จริง นี่คือสิ่งที่เราได้รับ: เราแทนที่ส่วนหนึ่งของโหลด - เราลบมันออกจาก LTM ไปยังเซิร์ฟเวอร์เหล่านี้ ใช้ตรรกะเดียวกันที่นั่น โดยใช้ฮาร์ดแวร์และซอฟต์แวร์มาตรฐาน และได้รับโบนัสทันทีที่เซิร์ฟเวอร์เหล่านี้สามารถทำได้ สามารถปรับขนาดได้เนื่องจากสามารถจัดหาได้มากเท่าที่ต้องการ ข้อเสียอย่างเดียวคือเราสูญเสียความพร้อมใช้งานสูงสำหรับผู้ใช้ภายนอก แต่ในขณะนั้นเราก็ต้องเสียสละสิ่งนี้เพราะจำเป็นต้องแก้ไขปัญหาทันที ดังนั้นเราจึงลบภาระงานบางส่วนออก ตอนนั้นประมาณ 40% LTM รู้สึกดี และแท้จริงแล้วสองสัปดาห์หลังจากปัญหาเริ่มต้นขึ้น เราเริ่มส่งคำขอไม่ใช่ 45 ต่อวินาที แต่ 55 คำขอ ในความเป็นจริง เราเพิ่มขึ้น 20% - นี่คือปริมาณการเข้าชมที่เราไม่ได้มอบให้กับผู้ใช้อย่างชัดเจน และหลังจากนั้นพวกเขาก็เริ่มคิดถึงวิธีแก้ปัญหาที่เหลืออยู่เพื่อให้มั่นใจว่ามีการเข้าถึงจากภายนอกสูง
เราหยุดพักชั่วคราวในระหว่างนั้นเราพูดคุยกันว่าจะใช้วิธีแก้ไขปัญหาใดในเรื่องนี้ มีข้อเสนอเพื่อให้มั่นใจในความน่าเชื่อถือโดยใช้ DNS โดยใช้สคริปต์ที่เขียนเองที่บ้าน โปรโตคอลการกำหนดเส้นทางแบบไดนามิก... มีตัวเลือกมากมาย แต่ก็ชัดเจนแล้วว่าสำหรับการส่งภาพถ่ายที่เชื่อถือได้อย่างแท้จริงคุณต้องแนะนำอีกเลเยอร์หนึ่งที่จะตรวจสอบสิ่งนี้ . เราเรียกช่างภาพเครื่องจักรเหล่านี้ว่า ซอฟต์แวร์ที่เราใช้งานคือ Keepalived:
เริ่มต้นด้วย Keepalived ประกอบด้วยอะไรบ้าง? ประการแรกคือโปรโตคอล VRRP ซึ่งเป็นที่รู้จักกันอย่างแพร่หลายในหมู่นักเครือข่าย ซึ่งตั้งอยู่บนอุปกรณ์เครือข่ายที่ให้ความทนทานต่อข้อผิดพลาดกับที่อยู่ IP ภายนอกที่ไคลเอนต์เชื่อมต่ออยู่ ส่วนที่สองคือ IPVS ซึ่งเป็นเซิร์ฟเวอร์เสมือน IP สำหรับการปรับสมดุลระหว่างเราเตอร์รูปภาพและการรับรองความทนทานต่อข้อผิดพลาดในระดับนี้ และประการที่สาม - การตรวจสุขภาพ
เริ่มจากส่วนแรกกันก่อน: VRRP - มีหน้าตาเป็นอย่างไร? มี IP เสมือนบางตัวซึ่งมีรายการอยู่ใน dns badoocdn.com ที่ซึ่งไคลเอนต์เชื่อมต่อ ในช่วงเวลาหนึ่ง เรามีที่อยู่ IP บนเซิร์ฟเวอร์เดียว แพ็กเก็ต Keepalive ทำงานระหว่างเซิร์ฟเวอร์โดยใช้โปรโตคอล VRRP และหากต้นแบบหายไปจากเรดาร์ - เซิร์ฟเวอร์รีบูตหรืออย่างอื่น เซิร์ฟเวอร์สำรองจะรับที่อยู่ IP นี้โดยอัตโนมัติ - ไม่ต้องดำเนินการด้วยตนเอง ความแตกต่างระหว่างข้อมูลหลักและข้อมูลสำรองส่วนใหญ่จะมีความสำคัญเป็นอันดับแรก ยิ่งมีค่าสูงเท่าไร โอกาสที่เครื่องจะกลายเป็นข้อมูลหลักก็จะยิ่งมากขึ้นเท่านั้น ข้อได้เปรียบที่สำคัญมากคือคุณไม่จำเป็นต้องกำหนดค่าที่อยู่ IP บนเซิร์ฟเวอร์ การอธิบายที่อยู่ IP ในการกำหนดค่าก็เพียงพอแล้ว และหากที่อยู่ IP จำเป็นต้องมีกฎการกำหนดเส้นทางที่กำหนดเอง จะมีการอธิบายโดยตรงในการกำหนดค่าโดยใช้ ไวยากรณ์เดียวกับที่อธิบายไว้ในแพ็คเกจ VRRP คุณจะไม่พบสิ่งที่ไม่คุ้นเคย
สิ่งนี้มีลักษณะอย่างไรในทางปฏิบัติ? จะเกิดอะไรขึ้นหากหนึ่งในเซิร์ฟเวอร์ล้มเหลว? ทันทีที่ต้นแบบหายไป การสำรองข้อมูลของเราจะหยุดรับโฆษณาและกลายเป็นต้นแบบโดยอัตโนมัติ หลังจากนั้นไม่นาน เราได้ซ่อมแซมต้นแบบ รีบูท ยกระดับ Keepalived - โฆษณามาถึงโดยมีลำดับความสำคัญสูงกว่าการสำรองข้อมูล และการสำรองข้อมูลจะย้อนกลับโดยอัตโนมัติ ลบที่อยู่ IP ไม่จำเป็นต้องดำเนินการด้วยตนเอง
ดังนั้นเราจึงรับประกันความทนทานต่อความผิดพลาดของที่อยู่ IP ภายนอก ส่วนถัดไปคือการสร้างสมดุลการรับส่งข้อมูลจากที่อยู่ IP ภายนอกไปยังเราเตอร์รูปภาพที่กำลังยุติการใช้งานอยู่แล้ว ทุกอย่างค่อนข้างชัดเจนด้วยโปรโตคอลการปรับสมดุล นี่เป็นทั้งการปัดเศษแบบธรรมดาหรือสิ่งที่ซับซ้อนกว่าเล็กน้อย wrr การเชื่อมต่อรายการ และอื่นๆ โดยทั่วไปจะอธิบายไว้ในเอกสารประกอบ ไม่มีอะไรพิเศษ แต่วิธีการจัดส่ง... เราจะมาดูว่าทำไมเราถึงเลือกวิธีใดวิธีหนึ่งให้ละเอียดยิ่งขึ้น เหล่านี้คือ NAT, Direct Routing และ TUN ความจริงก็คือเราวางแผนที่จะส่งมอบการรับส่งข้อมูล 100 กิกะบิตจากไซต์ทันที ถ้าประมาณว่าต้องมีการ์ด 10 กิกะบิตใช่ไหม? การ์ด 10 กิกะบิตในเซิร์ฟเวอร์เดียวนั้นอยู่นอกเหนือขอบเขตของแนวคิด "อุปกรณ์มาตรฐาน" ของเราเป็นอย่างน้อย แล้วเราก็จำได้ว่าเราไม่เพียงแค่ให้การเข้าชม แต่เราแจกรูปถ่ายด้วย
มีอะไรพิเศษ? — ความแตกต่างอย่างมากระหว่างการรับส่งข้อมูลขาเข้าและขาออก การรับส่งข้อมูลขาเข้ามีขนาดเล็กมาก การรับส่งข้อมูลขาออกมีขนาดใหญ่มาก:
หากดูกราฟเหล่านี้ คุณจะเห็นว่าขณะนี้ผู้กำกับได้รับข้อมูลประมาณ 200 MB ต่อวินาที ซึ่งถือเป็นวันธรรมดามาก เราให้คืน 4,500 MB ต่อวินาที อัตราส่วนของเราอยู่ที่ประมาณ 1/22 เป็นที่ชัดเจนแล้วว่าเพื่อให้การรับส่งข้อมูลขาออกไปยังเซิร์ฟเวอร์ผู้ปฏิบัติงาน 22 คนอย่างสมบูรณ์ เราต้องการเพียงเซิร์ฟเวอร์เดียวที่ยอมรับการเชื่อมต่อนี้ นี่คือจุดที่อัลกอริธึมการกำหนดเส้นทางโดยตรงเข้ามาช่วยเหลือเรา
มันดูเหมือนอะไร? ผู้กำกับภาพถ่ายของเราส่งสัญญาณการเชื่อมต่อไปยังเราเตอร์ภาพถ่ายตามตารางของเขา แต่เราเตอร์ภาพถ่ายจะส่งทราฟฟิกย้อนกลับไปยังอินเทอร์เน็ตโดยตรง ส่งไปยังไคลเอนต์ แต่จะไม่ย้อนกลับผ่านโฟโต้ไดเร็กเตอร์ ดังนั้นด้วยจำนวนเครื่องจักรขั้นต่ำ เราจึงรับประกันความทนทานต่อข้อผิดพลาดอย่างสมบูรณ์และการสูบฉีดของการรับส่งข้อมูลทั้งหมด ในการกำหนดค่าจะมีลักษณะดังนี้: เราระบุอัลกอริทึม ในกรณีของเราคือ rr ธรรมดา จัดเตรียมวิธีการกำหนดเส้นทางโดยตรง จากนั้นเริ่มแสดงรายการเซิร์ฟเวอร์จริงทั้งหมด จำนวนเซิร์ฟเวอร์ที่เรามี ซึ่งจะเป็นตัวกำหนดปริมาณการเข้าชมนี้ หากเรามีเซิร์ฟเวอร์มากกว่าหนึ่งหรือสองเครื่องที่นั่น หรือหลายเซิร์ฟเวอร์ ความจำเป็นดังกล่าวก็เกิดขึ้น เราเพียงเพิ่มส่วนนี้ในการกำหนดค่าและไม่ต้องกังวลมากเกินไป จากด้านข้างของเซิร์ฟเวอร์จริง จากด้านข้างของเราเตอร์รูปภาพ วิธีนี้ต้องการการกำหนดค่าขั้นต่ำที่สุด โดยมีการอธิบายไว้อย่างสมบูรณ์ในเอกสารประกอบ และไม่มีข้อผิดพลาดใดๆ
สิ่งที่ดีเป็นพิเศษคือโซลูชันดังกล่าวไม่ได้หมายความถึงการออกแบบเครือข่ายท้องถิ่นใหม่อย่างสิ้นเชิง นี่เป็นสิ่งสำคัญสำหรับเรา เราต้องแก้ไขปัญหานี้ด้วยต้นทุนที่น้อยที่สุด หากมองดู แล้วเราจะมาดูกันว่ามีลักษณะอย่างไร ที่นี่เรามีเซิร์ฟเวอร์เสมือนบางตัว บนพอร์ต 443 ฟัง ยอมรับการเชื่อมต่อ เซิร์ฟเวอร์ที่ทำงานทั้งหมดแสดงอยู่ในรายการ และคุณจะเห็นได้ว่าการเชื่อมต่อนั้น ให้หรือรับ เหมือนกัน หากเราดูสถิติบนเซิร์ฟเวอร์เสมือนเดียวกัน เรามีแพ็กเก็ตขาเข้า การเชื่อมต่อขาเข้า แต่ไม่มีแพ็กเก็ตขาออกอย่างแน่นอน การเชื่อมต่อขาออกจะส่งตรงไปยังไคลเอนต์ โอเค เราสามารถทำให้มันไม่สมดุลได้ ทีนี้ จะเกิดอะไรขึ้นหากเราเตอร์รูปภาพตัวใดตัวหนึ่งของเราทำงานล้มเหลว ท้ายที่สุดแล้วเหล็กก็คือเหล็ก เคอร์เนลอาจตื่นตระหนก อาจพัง ไฟอาจไหม้ได้ อะไรก็ตาม. นี่คือเหตุผลว่าทำไมจึงต้องตรวจสุขภาพ ซึ่งอาจทำได้ง่ายเพียงแค่ตรวจสอบวิธีการเปิดพอร์ต หรือสิ่งที่ซับซ้อนกว่านั้น ไปจนถึงสคริปต์ที่เขียนขึ้นเองซึ่งจะตรวจสอบตรรกะทางธุรกิจด้วยซ้ำ
เราหยุดที่ไหนสักแห่งตรงกลาง: เรามีคำขอ https ไปยังตำแหน่งเฉพาะ สคริปต์จะถูกเรียก หากตอบกลับด้วยการตอบกลับครั้งที่ 200 เราเชื่อว่าเซิร์ฟเวอร์นี้ทุกอย่างเรียบร้อยดี เซิร์ฟเวอร์นี้ยังมีชีวิตอยู่และสามารถเปิดใช้งานได้ค่อนข้างดี อย่างง่ายดาย.
สิ่งนี้ดูเป็นอย่างไรในทางปฏิบัติ? มาปิดเซิร์ฟเวอร์เพื่อการบำรุงรักษา - ทำการแฟลช BIOS เป็นต้น ในบันทึก เราจะมีการหมดเวลาทันที เราเห็นบรรทัดแรก จากนั้นหลังจากพยายามสามครั้ง บรรทัดนั้นจะถูกทำเครื่องหมายว่า "ล้มเหลว" และเพียงลบออกจากรายการ
ตัวเลือกลักษณะการทำงานที่สองก็เป็นไปได้เช่นกัน เมื่อ VS ถูกตั้งค่าเป็นศูนย์ แต่ถ้าภาพถ่ายถูกส่งคืน วิธีนี้จะทำงานได้ไม่ดี เซิร์ฟเวอร์ปรากฏขึ้น Nginx เริ่มต้นที่นั่น การตรวจสอบสภาพจะเข้าใจทันทีว่าการเชื่อมต่อใช้งานได้ ทุกอย่างเรียบร้อยดี และเซิร์ฟเวอร์ปรากฏในรายการของเรา และโหลดจะเริ่มนำไปใช้กับเซิร์ฟเวอร์ทันที ไม่ต้องดำเนินการด้วยตนเองจากผู้ดูแลหน้าที่ เซิร์ฟเวอร์รีบูตในเวลากลางคืน - แผนกตรวจสอบไม่ได้โทรหาเราเกี่ยวกับเรื่องนี้ในเวลากลางคืน พวกเขาแจ้งให้คุณทราบว่าสิ่งนี้เกิดขึ้นทุกอย่างเรียบร้อยดี
ดังนั้นด้วยวิธีที่ค่อนข้างง่าย ด้วยความช่วยเหลือของเซิร์ฟเวอร์จำนวนไม่มากนัก เราจึงสามารถแก้ไขปัญหาความทนทานต่อข้อผิดพลาดภายนอกได้
สิ่งเดียวที่ต้องบอกคือเรื่องทั้งหมดนี้จำเป็นต้องได้รับการตรวจสอบ ควรสังเกตว่า Keepalivede ซึ่งเป็นซอฟต์แวร์ที่เขียนขึ้นเมื่อนานมาแล้วมีวิธีตรวจสอบมากมาย ทั้งโดยใช้การตรวจสอบผ่าน DBus, SMTP, SNMP และ Zabbix มาตรฐาน นอกจากนี้ตัวเขาเองยังรู้วิธีเขียนจดหมายสำหรับการจามเกือบทุกครั้งและพูดตามตรงว่า ณ จุดหนึ่งเราก็คิดที่จะปิดมันด้วยซ้ำ เพราะเขาเขียนจดหมายจำนวนมากสำหรับการสลับการรับส่งข้อมูลการเปิดสวิตช์สำหรับการเชื่อมต่อ IP ทุกครั้ง และอื่น ๆ แน่นอนว่าหากมีเซิร์ฟเวอร์จำนวนมาก คุณก็สามารถล้นหลามตัวเองด้วยจดหมายเหล่านี้ได้ เราตรวจสอบ nginx บนเราเตอร์ภาพถ่ายโดยใช้วิธีการมาตรฐาน และการตรวจสอบฮาร์ดแวร์ยังไม่หายไป แน่นอนว่าเราจะแนะนำอีกสองสิ่ง: ประการแรก การตรวจสุขภาพและความพร้อมใช้งานจากภายนอก เพราะแม้ว่าทุกอย่างจะใช้งานได้ ในความเป็นจริงแล้ว ผู้ใช้อาจไม่ได้รับรูปภาพเนื่องจากปัญหากับผู้ให้บริการภายนอกหรือสิ่งที่ซับซ้อนกว่านั้น ควรเก็บไว้ที่ใดที่หนึ่งบนเครือข่ายอื่นใน Amazon หรือที่อื่น เครื่องแยกต่างหากที่สามารถ ping เซิร์ฟเวอร์ของคุณจากภายนอกได้ และมันก็คุ้มค่าที่จะใช้การตรวจจับความผิดปกติ สำหรับผู้ที่รู้วิธีการเรียนรู้ของเครื่องที่ยุ่งยากหรือการตรวจสอบแบบง่ายๆ อย่างน้อยก็เพื่อติดตามว่าคำขอลดลงอย่างรวดเร็วหรือเพิ่มขึ้นในทางกลับกัน นอกจากนี้ยังสามารถเป็นประโยชน์ได้
สรุป: ในความเป็นจริงเราได้เปลี่ยนโซลูชันหุ้มเหล็กซึ่งในบางจุดไม่เหมาะกับเราด้วยระบบที่ค่อนข้างเรียบง่ายซึ่งทำทุกอย่างเหมือนกันนั่นคือให้การยุติการรับส่งข้อมูล HTTPS และการกำหนดเส้นทางอัจฉริยะเพิ่มเติมด้วย การตรวจสุขภาพที่จำเป็น เราได้เพิ่มความเสถียรของระบบนี้ กล่าวคือ เรายังคงมีความพร้อมใช้งานสูงในแต่ละเลเยอร์ แถมยังมีโบนัสที่มันค่อนข้างง่ายที่จะปรับขนาดทั้งหมดในแต่ละเลเยอร์ เพราะเป็นฮาร์ดแวร์มาตรฐานที่มีซอฟต์แวร์มาตรฐานนั่นคือ เราได้ทำให้การวินิจฉัยปัญหาที่เป็นไปได้ง่ายขึ้น
เราลงเอยด้วยอะไร? เราประสบปัญหาในช่วงวันหยุดเดือนมกราคมปี 2018 ในช่วงหกเดือนแรกขณะที่เรานำแผนนี้ไปปฏิบัติ เราได้ขยายไปยังการรับส่งข้อมูลทั้งหมดเพื่อลบการรับส่งข้อมูลทั้งหมดออกจาก LTM เราขยายเฉพาะการรับส่งข้อมูลในศูนย์ข้อมูลเดียวจาก 40 กิกะบิตเป็น 60 กิกะบิต และในเวลาเดียวกันสำหรับ ตลอดทั้งปี 2018 สามารถส่งภาพถ่ายได้มากกว่าเกือบสามเท่าต่อวินาที
ที่มา: will.com