Uma.Tech พัฒนาโครงสร้างพื้นฐานอย่างไร

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

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

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

เราพูดคุยเกี่ยวกับวิธีที่เราพัฒนาฮาร์ดแวร์ของโครงสร้างพื้นฐานของเรา ("Rutube 2009-2015: ประวัติความเป็นมาของฮาร์ดแวร์ของเรา") และพัฒนาระบบที่รับผิดชอบในการอัพโหลดวิดีโอ (“จากศูนย์ถึง 700 กิกะบิตต่อวินาที - หนึ่งในเว็บไซต์โฮสต์วิดีโอที่ใหญ่ที่สุดในรัสเซียอัปโหลดวิดีโอได้อย่างไร”) แต่เวลาผ่านไปนานมากนับตั้งแต่เขียนข้อความเหล่านี้ มีการสร้างและดำเนินการโซลูชันอื่น ๆ อีกมากมายซึ่งผลลัพธ์ช่วยให้เราสามารถตอบสนองความต้องการที่ทันสมัยและยืดหยุ่นเพียงพอที่จะปรับให้เข้ากับงานใหม่

Uma.Tech พัฒนาโครงสร้างพื้นฐานอย่างไร

แกนเครือข่าย เรากำลังพัฒนาอย่างต่อเนื่อง เราเปลี่ยนมาใช้อุปกรณ์ Cisco ในปี 2015 ซึ่งเราได้กล่าวถึงในบทความก่อนหน้านี้ สมัยนั้นยังคงเป็น 10/40G เหมือนเดิม แต่ด้วยเหตุผลที่ชัดเจน หลังจากนั้นไม่กี่ปีพวกเขาก็อัปเกรดแชสซีที่มีอยู่ และตอนนี้เราใช้ 25/100G อย่างจริงจัง

Uma.Tech พัฒนาโครงสร้างพื้นฐานอย่างไร

ลิงก์ 100G ไม่ได้เป็นสิ่งที่หรูหรามานานแล้ว (แต่นี่เป็นข้อกำหนดเร่งด่วนในส่วนของเวลาในกลุ่มของเรา) หรือเป็นสิ่งที่หายาก (ผู้ให้บริการจำนวนมากขึ้นเรื่อยๆ ให้การเชื่อมต่อด้วยความเร็วดังกล่าว) อย่างไรก็ตาม 10/40G ยังคงมีความเกี่ยวข้อง: ผ่านลิงก์เหล่านี้ เราจะยังคงเชื่อมต่อผู้ให้บริการที่มีการรับส่งข้อมูลจำนวนเล็กน้อย ซึ่งในปัจจุบันไม่เหมาะสมที่จะใช้พอร์ตที่มีความจุมากขึ้น

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

เซิร์ฟเวอร์เอาท์พุตวิดีโอ พัฒนาอย่างรวดเร็ว ซึ่งเราทุ่มเทความพยายามอย่างมาก หากก่อนหน้านี้เราใช้เซิร์ฟเวอร์ 2U เป็นหลักโดยมีการ์ดเครือข่าย 4-5 ใบพร้อมพอร์ต 10G สองพอร์ตต่อพอร์ต ตอนนี้การรับส่งข้อมูลส่วนใหญ่จะถูกส่งจากเซิร์ฟเวอร์ 1U ซึ่งมีการ์ด 2-3 ใบพร้อมพอร์ต 25G สองพอร์ตต่อพอร์ต การ์ดที่มี 10G และ 25G มีราคาเกือบเท่ากัน และโซลูชันที่เร็วกว่าช่วยให้คุณสามารถส่งผ่านทั้ง 10G และ 25G ผลลัพธ์ที่ได้คือการประหยัดอย่างเห็นได้ชัด: ส่วนประกอบเซิร์ฟเวอร์และสายเคเบิลสำหรับการเชื่อมต่อน้อยลง - ต้นทุนลดลง (และความน่าเชื่อถือที่สูงขึ้น) ส่วนประกอบใช้พื้นที่ในแร็คน้อยลง - เป็นไปได้ที่จะวางเซิร์ฟเวอร์มากขึ้นต่อหนึ่งพื้นที่ และทำให้ค่าเช่าลดลง

แต่ที่สำคัญกว่านั้นคือการได้รับความเร็ว! ตอนนี้เราสามารถส่งมากกว่า 1G ด้วย 100U! และสิ่งนี้ขัดกับฉากหลังของสถานการณ์ที่โครงการขนาดใหญ่ในรัสเซียบางโครงการเรียกเอาต์พุต 40G จาก 2U ว่าเป็น "ความสำเร็จ" เราต้องการปัญหาของพวกเขา!

Uma.Tech พัฒนาโครงสร้างพื้นฐานอย่างไร

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

ระบบจัดเก็บข้อมูล กำลังเติบโตเช่นกัน ในช่วงห้าปีที่ผ่านมา พวกเขาเปลี่ยนจากดิสก์สิบสองดิสก์ (12x HDD 2U) เป็นสามสิบหกดิสก์ (36x HDD 4U) บางคนกลัวที่จะใช้ “ซาก” ที่กว้างขวางเช่นนี้ เนื่องจากหากแชสซีตัวใดตัวหนึ่งทำงานล้มเหลว อาจมีภัยคุกคามต่อประสิทธิภาพการทำงาน – หรือแม้แต่ความสามารถในการทำงาน! – สำหรับทั้งระบบ แต่สิ่งนี้จะไม่เกิดขึ้นกับเรา: เราได้จัดเตรียมการสำรองข้อมูลในระดับสำเนาข้อมูลที่กระจายตามภูมิศาสตร์ เราได้กระจายแชสซีไปยังศูนย์ข้อมูลต่างๆ - เราใช้ทั้งหมดสามแห่ง - และวิธีนี้จะช่วยขจัดปัญหาที่เกิดขึ้นทั้งในกรณีที่แชสซีทำงานล้มเหลวและเมื่อไซต์ล่ม

Uma.Tech พัฒนาโครงสร้างพื้นฐานอย่างไร

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

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

สองปีที่แล้ว เราย้ายภายใน MMTS-9 โดยย้ายไปยังไซต์ที่มีการซ่อมคุณภาพสูง ระบบระบายความร้อนที่ดี แหล่งจ่ายไฟที่เสถียร และไม่มีฝุ่น ซึ่งก่อนหน้านี้วางเป็นชั้นหนาในทุกพื้นผิว และยังอุดตันด้านในของอุปกรณ์ของเราอีกด้วย . เลือกบริการที่มีคุณภาพ และไม่มีฝุ่น! – กลายเป็นเหตุผลในการย้ายของเรา

Uma.Tech พัฒนาโครงสร้างพื้นฐานอย่างไร

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

การย้ายครั้งที่สองเกิดขึ้นเมื่อปีที่แล้ว ในปี 2019 เราย้ายจากศูนย์ข้อมูลที่ไม่ดีนักไปยัง O2xygen เหตุผลของการย้ายนั้นคล้ายคลึงกับที่กล่าวไว้ข้างต้น แต่เสริมด้วยปัญหาความไม่น่าดึงดูดของศูนย์ข้อมูลเดิมสำหรับผู้ให้บริการโทรคมนาคม - ผู้ให้บริการหลายรายต้อง "ตามทัน" ถึงจุดนี้ด้วยตัวเอง

Uma.Tech พัฒนาโครงสร้างพื้นฐานอย่างไร

การย้ายชั้นวาง 13 ตู้ไปยังไซต์คุณภาพสูงใน MMTS-9 ทำให้สามารถพัฒนาตำแหน่งนี้ไม่เพียงแต่เป็นที่ตั้งของผู้ปฏิบัติงาน (ชั้นวางสองสามชั้นวางและ "ไปข้างหน้า" ของผู้ปฏิบัติงาน) แต่ยังใช้เป็นหนึ่งใน คนหลัก สิ่งนี้ทำให้การย้ายจากศูนย์ข้อมูลที่ไม่ค่อยดีนักค่อนข้างง่ายขึ้น - เราขนส่งอุปกรณ์ส่วนใหญ่จากศูนย์นั้นไปยังไซต์อื่นและ O2xygen ได้รับบทบาทเป็นศูนย์ที่กำลังพัฒนาโดยส่งชั้นวาง 5 อันพร้อมอุปกรณ์ไปที่นั่น

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

เราดำเนินการขั้นตอนหลักของการย้ายในคืนเดียวเสมอ และเมื่อย้ายภายใน MMTS-9 และไปยัง O2xygen เราก็ปฏิบัติตามกฎนี้ เราเน้นย้ำว่าเราปฏิบัติตามกฎ "ย้ายข้ามคืน" อย่างเคร่งครัด โดยไม่คำนึงถึงจำนวนชั้นวาง! เคยมีแบบอย่างเมื่อเราย้ายชั้นวาง 20 ตู้และทำสิ่งนี้ให้เสร็จสิ้นในคืนเดียวด้วย การย้ายข้อมูลเป็นกระบวนการที่ค่อนข้างง่ายซึ่งต้องการความแม่นยำและสม่ำเสมอ แต่มีเคล็ดลับบางประการ ทั้งในขั้นตอนการเตรียมการ และเมื่อย้าย และเมื่อปรับใช้ไปยังตำแหน่งใหม่ เราพร้อมพูดคุยเกี่ยวกับการย้ายถิ่นอย่างละเอียดหากคุณสนใจ

ผลการวิจัย เราชอบแผนพัฒนาห้าปี เราได้เสร็จสิ้นการก่อสร้างโครงสร้างพื้นฐานที่ทนทานต่อข้อผิดพลาดใหม่ที่กระจายอยู่ในศูนย์ข้อมูลสามแห่ง เราได้เพิ่มความหนาแน่นของการรับส่งข้อมูลอย่างรวดเร็ว - หากเมื่อเร็ว ๆ นี้เราพอใจกับ 40-80G กับ 2U ตอนนี้บรรทัดฐานสำหรับเราคือ 100G กับ 1U ตอนนี้แม้แต่การจราจรไม่กี่เทราบิตก็ถูกมองว่าเป็นเรื่องธรรมดา เราพร้อมที่จะพัฒนาโครงสร้างพื้นฐานของเราเพิ่มเติม ซึ่งกลายเป็นเรื่องยืดหยุ่นและปรับขนาดได้

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

ผู้แต่ง: Petr Vinogradov - ผู้อำนวยการฝ่ายเทคนิคของ Uma.Tech แฮมสเตอร์

ที่มา: will.com

เพิ่มความคิดเห็น