TL;DR

ลูกค้าขอให้ฉันสร้างระบบที่แข็งแกร่งเพื่อเรียกใช้ไมโครเซอร์วิสที่มีคอนเทนเนอร์ภายใน LAN ของพวกเขา

ข้อจำกัด:พวกเขาให้ฉัน 2 เครื่องและ 6 ดิสก์ข้อมูล ไม่มีฮาร์ดแวร์อีกต่อไป ฉันต้องสร้าง "สิ่งที่ดีที่สุดที่ฉันสามารถทำได้" ที่นี่

ความกังวลของฉันคือการจัดเก็บและความพร้อมใช้งาน ความเร็ว/ประสิทธิภาพไม่ใช่ปัญหา

ฉันกำลังคิดถึง:

  • ในแต่ละเครื่อง ให้สร้าง RAID-5 โดยใช้ดิสก์ข้อมูล 3 ดิสก์ โดยให้ปริมาณข้อมูลหนึ่งรายการในแต่ละเครื่อง ตัวอย่างเช่น ZFS
  • ผูก 2 เครื่องกับระบบไฟล์แบบกระจาย ตัวอย่างเช่น GlusterF
  • จากนั้นใช้ Kubernetes เพื่อสร้างคลัสเตอร์ของ 2 โหนดที่ชี้ Persistent Volumes ไปยัง FS แบบกระจาย
  • ข้อเท็จจริงที่คลัสเตอร์ kubernetes ทำงานในฮาร์ดแวร์เดียวกันกับระบบไฟล์แบบกระจายนั้นเป็นเพียงอุบัติเหตุ

คำถามคือ มีวิธีแก้ปัญหาที่ดีกว่าเมื่อพิจารณาจากข้อจำกัดของลูกค้าหรือไม่

อ่านบริบทเพื่อทำความเข้าใจเพิ่มเติม

บริบท

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

สำหรับสถานการณ์ทั้งหมด ความเร็วไม่ใช่ปัญหา (ปริมาณการใช้งานต่ำ) ตัวขับเคลื่อนธุรกิจที่นี่คือ:

  • การคงอยู่ของข้อมูล (ลดความเสี่ยงของการสูญเสียข้อมูล)
  • ความพร้อมใช้งานสูง (ลดความเสี่ยงของการหยุดทำงาน)

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

สิ่งที่พวกเขากำลังวิ่งอยู่ (อย่าร้องไห้นะ ได้โปรด!!)

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

แน่นอนว่ามันไม่เป็นที่ยอมรับในสมัยนั้น (แม้จะไม่เป็นที่ยอมรับในปี 2018)

ฮาร์ดแวร์ที่พวกเขามีสำหรับโครงการนี้

เพื่อแก้ปัญหานี้ พวกเขาเพิ่งซื้อเซิร์ฟเวอร์ 2 เซิร์ฟเวอร์พร้อมดิสก์ระบบ 1 ตัว + ดิสก์ข้อมูล 3 ตัวในแต่ละเซิร์ฟเวอร์ (ทั้งหมด 6 ดิสก์ข้อมูล) แนวคิดเริ่มต้นที่พวกเขามีสำหรับดิสก์ข้อมูลคือการสร้างซอฟต์แวร์ท้องถิ่น RAID-5 ในดิสก์ข้อมูล 3 ตัวภายในแต่ละเซิร์ฟเวอร์

เรียกเซิร์ฟเวอร์alphaและbeta. ทั้งสองเครื่องเหมือนกันใน cpu, ram และ system-disk รวมถึง data-disk 3 ตัว ดังนั้นคอมพิวเตอร์จึงเป็นเครื่องโคลน พวกเขาทั้งคู่จะรัน Ubuntu linux

Master-slave (ความคิดของลูกค้า) กับคลัสเตอร์ (ข้อเสนอของฉัน)

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

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

คำขอของพวกเขา

สถานีวิทยุในขั้นต้นขอให้ฉันสร้าง RAID บนalphaผ่าน ZFS จากนั้นเปิด RAID อื่นbetaผ่าน ZFS ตั้งกลุ่มนักเทียบท่าalphaด้วย--restart=alwaysแล้วชี้ลูกค้าของบริการ (ทำงานในพีซีของนักข่าวตามลำดับ) ไปที่alpha(คิดว่าบริการต่างๆ เช่น การเขียนข่าว การอัปโหลดรูปภาพ การบันทึกเสียง การจัดตารางโปรแกรม การเผยแพร่เว็บ การแปลงรหัสสื่อ สตรีมสดในท้องถิ่น ฟีดไปยังระบบคลาวด์ ฯลฯ )

เกี่ยวกับการจัดเก็บ ค่าเริ่มต้นคือ:

  • สำหรับรูปภาพและไฟล์เสียง ให้สำรองข้อมูลปกติจากalphaเป็นbeta.
  • สำหรับ MySQL มีต้นแบบโทalpha- betaดังนั้นbetaส่วนใหญ่จะทำหน้าที่เป็นทาส แต่พร้อมที่จะนำมาใช้ในกรณีของการalphaตาย

จากนั้นหากอัลฟ่าแตก ให้เปลี่ยนไคลเอนต์ทั้งหมดเป็นbeta.

ฉันสนใจเฉพาะส่วนการจัดเก็บของเรื่อง

ฉันกำลังคิดอะไรอยู่

แทนที่จะ "เปลี่ยนไคลเอ็นต์ด้วยตนเอง" ฉันคิดว่าจะใช้kubernetesเพื่อสร้างคลัสเตอร์ของโหนดผู้ปฏิบัติงาน 2 โหนด เนื่องจากฉันไม่สามารถแยกฮาร์ดแวร์เพื่อทำหน้าที่เป็น "kubernetes master" ได้ ฉันจึงคิดที่จะทำเช่นกันalphaและbetaเป็นทั้งผู้เชี่ยวชาญ kubernetes ที่ซ้ำซากจำเจในฐานะคนงาน

ดังนั้นalphaจะเป็นต้นแบบของ kubernetes สำหรับalphaและbetaโหนดเช่นเดียวกับbetaจะเป็นต้นแบบที่ซ้ำซ้อนของ kubernetes สำหรับทั้งคู่alphaและbeta.

ถึงตรงนี้ไม่มีปัญหา

กว่าเราจะมาถึงโกดัง

ที่เก็บข้อมูล วอลุ่มถาวร GlusterF และ ZFS

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

นี่คือสิ่งที่ฉันกำลังคิด:

1. เลเยอร์ ZFS ในพื้นที่

  • ในระบบปฏิบัติการของalpha(ดั้งเดิมสำหรับระบบ ลืม kubernetes สักครู่) ใช้ ZFS เพื่อสร้าง RAID ในดิสก์ข้อมูล 3 ตัว (ขนาดเท่ากัน) ดังนั้นหากแต่ละดิสก์มีขนาด 1TB มี 3TB โดยที่ 2TB จะพร้อมใช้งานในโวลุ่มข้อมูลและ 1TB อยู่ภายใต้ประทุนเพื่อความซ้ำซ้อน เรียกดิสก์ A1, A2 และ A3 มาเรียก ZFS วอลุ่ม A กันเถอะ

  • ในbetaทำซ้ำโครงสร้าง ดิสก์ B1, B2, B3 มาเรียก ZFS วอลุ่ม B กันเถอะ

จนถึงตอนนี้ ฉันมีเซิร์ฟเวอร์อิสระ 2 เซิร์ฟเวอร์ ซึ่งแต่ละเซิร์ฟเวอร์ป้องกันความล้มเหลวของดิสก์เดียว ไม่มีการป้องกันความล้มเหลว 2 ดิสก์พร้อมกัน ไม่มีการป้องกันโหนดเต็มลง

2. เลเยอร์ GlusterFs แบบกระจาย

  • จากนั้นสร้าง GlusterF ข้ามalphaและbetaด้านบนของวอลุ่ม ZFS ฉันเข้าใจว่า GlusterF ต้องให้การmirroringกำหนดค่าบางอย่างแก่ฉันดังนั้น ZFS โวลุ่ม A และ B จึงเป็นมิเรอร์ของอีกอันหนึ่ง ดังนั้น ถ้า A คือ 2TB และ B คือ 2TB "พื้นที่เก็บข้อมูลทั้งหมดที่มี" จะเป็น 2TB สำหรับการใช้งานเช่นกัน

  • ดังนั้นการเพิ่ม GlusterF และ ZFS ในขณะนี้ จากความจุของฮาร์ดแวร์ทั้งหมด 6TB ผู้ใช้จะมีความจุ 2TB ดังนั้น 4TB จึงทำหน้าที่เป็นระบบสำรอง

จนถึงตอนนี้ ฉันควรมี "ดิสก์แบบกระจาย" ที่มีความซ้ำซ้อนมากกว่ามาก และอนุญาตให้มีดิสก์ 2 ตัวล้มเหลวและเกิดความล้มเหลวของโหนดด้วย

ฉันเห็นการป้องกันดิสก์ 2 แผ่นที่ล้มเหลวในลักษณะต่อไปนี้:

  1. หากดิสก์ทั้งสองเกี่ยวข้องกับโวลุ่มต่างกัน (เช่น A2 และ B3) ล้มเหลว ดังนั้น NFS แต่ละรายการจะป้องกันแยกจากกัน และทั้งโวลุ่ม ZFS A และ B จะไม่หยุดชะงัก (GlusterF ไม่เห็นการเปลี่ยนแปลง)
  2. หากดิสก์ 2 แผ่นที่ล้มเหลวเป็นของโหนดเดียวกัน แสดงว่าวอลุ่มเต็มจะล้มเหลว ตัวอย่างเช่น ความล้มเหลวใน A2 และ A1 ทำให้ A เสีย แต่ GlusterF ควรจะสามารถปรับสมดุลเพื่อใช้ "เพียง 1 โหนด" จนกว่าอีกโหนดจะพร้อมใช้งาน (ในกรณีนี้ "ใช้เฉพาะ B จนกว่า A จะกลับมาอีกครั้ง")

3. รันไทม์คอนเทนเนอร์ Kubernetes สำหรับคลัสเตอร์บริการ + Kubernetes Persistent Volumes

  • สุดท้าย ใช้ Kubernetes Persistent Volumesจะชี้ไปที่วอลุ่ม GlusterFs

  • ถ้าฉันมี 4 เครื่อง บางทีฉันอาจจะใช้ 2 เป็นโหนด kubernetes และ 2 สำหรับการจัดเก็บที่ทำหน้าที่เป็นที่เก็บข้อมูลเครือข่ายไปยังคลัสเตอร์

  • แต่เรามีเพียง 2 เครื่องจริง ดังนั้น kubernetes จะชี้ "ไดรฟ์ข้อมูลแบบถาวร" ไปที่ "GlusterFs" เหมือนกับว่า "อยู่ในเครื่องระยะไกลอื่น" ทำให้ไม่เชื่อว่าไดรฟ์ข้อมูลอยู่ในโหนดเดียวกัน

คำถาม

ฉันไม่เคยสร้างสิ่งก่อสร้างแบบนี้มาก่อน บนกระดาษมันใช้งานได้ ฉันสงสัยว่าความเป็นจริงแตกต่างกันหรือไม่

จากข้อจำกัด (2 เครื่อง 6 ดิสก์ข้อมูล) คำถามคือ:

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

เมื่อคุณทำคลัสเตอร์คุณต้องคิดถึงการแบ่งสมอง สำหรับสิ่งนี้คุณต้องมี 3 โหนด

ฉันต้องการ RAID10 แทน RAID5 (RAIDZ) ในกรณีของ ZFS ส่วนใหญ่เพื่อประสิทธิภาพ

สำหรับ MySQL/MariaDB ฉันจะใช้ปลั๊กอินGaleraสำหรับการจำลองแบบ

คุณจะต้องมีซอฟต์แวร์การจัดการการจัดกลุ่มเช่นClusterLabs ผู้นำ

สำหรับการจัดเก็บฉันจะพิจารณาCephด้วย

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

คุณวางแผนที่จะใช้ตัวโหลดบาลานซ์ (เช่นHAProxy ) หรือไม่?

ความซ้ำซ้อนของเครือข่าย? LACP, Spanning tree, OSPF/BGP...

เซิร์ฟเวอร์โหลดอย่างไร? บางทีคุณอาจติดตั้งการตั้งค่าทั้งหมดใน VM ได้ คุณยังคงต้องการโฮสต์จริง 3 ตัว แต่คุณจะมีความยืดหยุ่นมากขึ้น

และคุณต้องจดเอกสารและสคริปต์สำหรับสถานการณ์ความล้มเหลวต่างๆ รวมถึงที่เกิดจากความผิดพลาดของมนุษย์

ด้วยเครื่องเพียง 2 เครื่อง สำหรับข้อมูลที่เป็นลายลักษณ์อักษร (ที่เก็บข้อมูล ฐานข้อมูล) ควรทำการกำหนดค่า master-slave โดยที่คุณเขียนเฉพาะบนเครื่องหลักเท่านั้น และมี salave เป็นข้อมูลสำรอง สำหรับบริการไร้สัญชาติ คุณสามารถกำหนดค่าได้ในโหมดแอ็คทีฟ-แอ็คทีฟ