Cloister → การจัดการคลัสเตอร์ OTP อย่างง่าย

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

มันกลับกลายเป็นว่าโชคดีมาก Erlangซึ่งเราเลือกเพราะไวยากรณ์ที่น่าพึงพอใจและโฆษณาเกินจริง มีระดับเฟิร์สคลาส รองรับระบบแบบกระจาย. ตามทฤษฎีแล้ว สิ่งนี้ฟังดูเล็กน้อยโดยสิ้นเชิง:

ข้อความที่ส่งผ่านระหว่างกระบวนการบนโหนดที่แตกต่างกัน รวมถึงระหว่างลิงก์และจอภาพ มีความโปร่งใส […]

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

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

หมายเหตุ: ฉันรู้ว่ามี libcluster. เจ๋งจริง มีดาวพันกว่าคน นักเขียนดังในชุมชน และอื่นๆ อีกมากมาย หากวิธีการที่นำเสนอโดยแพ็คเกจนี้สำหรับการสร้างและบำรุงรักษาคลัสเตอร์นั้นเพียงพอสำหรับคุณ ฉันยินดีสำหรับคุณ น่าเสียดายที่ฉันต้องการมากกว่านี้มาก ฉันต้องการควบคุมการตั้งค่าอย่างละเอียด และไม่ใช่ผู้ชมภายนอกในการปรับโครงสร้างคลัสเตอร์

ความต้องการ

สิ่งที่ฉันต้องการเป็นการส่วนตัวคือไลบรารีที่จะเข้ามาควบคุมคลัสเตอร์และจะมีคุณสมบัติดังต่อไปนี้:

• การทำงานที่โปร่งใสด้วยทั้งรายการโหนดแบบฮาร์ดโค้ดและการค้นพบแบบไดนามิกผ่านบริการ Erlang;
• การโทรกลับที่ทำงานได้อย่างสมบูรณ์สำหรับการเปลี่ยนแปลงโทโพโลยีทุกครั้ง (โหนดตรงนั้น, โหนดที่นี่, ความไม่เสถียรของเครือข่าย, การแยก)
• อินเทอร์เฟซที่โปร่งใสสำหรับการเปิดตัวคลัสเตอร์ที่มีชื่อยาวและสั้นเช่นเดียวกับ :nonode@nohost;
• รองรับ Docker ทันทีโดยไม่ต้องเขียนโค้ดโครงสร้างพื้นฐาน

อย่างหลังหมายความว่าหลังจากที่ฉันทดสอบแอปพลิเคชันในเครื่องแล้ว :nonode@nohostหรือในสภาพแวดล้อมที่มีการกระจายแบบเทียมโดยใช้ test_cluster_task, ฉันแค่อยากจะวิ่ง docker-compose up --scale my_app=3 และดูว่ามันรันสามอินสแตนซ์ใน docker ได้อย่างไรโดยไม่ต้องเปลี่ยนโค้ดใดๆ ฉันยังต้องการแอปพลิเคชันที่ต้องพึ่งพาเช่น mnesia - เมื่อโทโพโลยีเปลี่ยนแปลง เบื้องหลังจะสร้างคลัสเตอร์ขึ้นมาใหม่โดยไม่ต้องอาศัยแอปพลิเคชันเพิ่มเติม

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

แนวทางที่เลือก

กุฏิ มีวัตถุประสงค์เพื่อให้ทำงานเป็นแอปพลิเคชัน แม้ว่าผู้ใช้ขั้นสูงจะสามารถทำงานกับการประกอบและการบำรุงรักษาคลัสเตอร์ด้วยตนเองโดยการรันโดยตรง Cloister.Manager ในแผนผังหัวหน้างานของแอปพลิเคชันเป้าหมาย

เมื่อรันเป็นแอปพลิเคชันไลบรารีจะอาศัย configซึ่งอ่านค่าพื้นฐานต่อไปนี้:

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # or ~w|n1@foo n2@bar|a
  consensus: 3,              # number of nodes to consider
                             #    the cluster is up
  listener: MyApp.Listener   # listener to be called when
                             #    the ring has changed

พารามิเตอร์ข้างต้นหมายถึงสิ่งต่อไปนี้อย่างแท้จริง: กุฏิ ใช้สำหรับการสมัคร OTP :my_app, ใช้ การค้นพบบริการ erlang เพื่อเชื่อมต่อโหนดอย่างน้อยสามและ MyApp.Listener โมดูล (การนำไปใช้งาน @behaviour Cloister.Listener) ได้รับการกำหนดค่าให้รับการแจ้งเตือนเกี่ยวกับการเปลี่ยนแปลงโทโพโลยี สามารถดูคำอธิบายโดยละเอียดของการกำหนดค่าทั้งหมดได้ใน เอกสาร.

ด้วยการกำหนดค่านี้แอปพลิเคชัน กุฏิ จะ เปิดตัวเป็นระยะซึ่งทำให้กระบวนการเริ่มต้นแอปพลิเคชันหลักล่าช้าออกไปจนกว่าจะถึงความเห็นพ้องต้องกัน (มีการเชื่อมต่อและเชื่อมต่อสามโหนดดังตัวอย่างด้านบน) สิ่งนี้ทำให้แอปพลิเคชันหลักมีโอกาสที่จะสันนิษฐานว่าเมื่อเริ่มต้น คลัสเตอร์จะพร้อมใช้งานอยู่แล้ว เมื่อใดก็ตามที่โทโพโลยีเปลี่ยนแปลง (จะมีหลายอย่างเนื่องจากโหนดไม่เริ่มทำงานพร้อมกันอย่างสมบูรณ์) ตัวจัดการจะถูกเรียก MyApp.Listener.on_state_change/2. โดยส่วนใหญ่แล้วเราดำเนินการเมื่อได้รับข้อความสถานะ %Cloister.Monitor{status: :up}ซึ่งหมายความว่า: “สวัสดี คลัสเตอร์พร้อมแล้ว”

ในกรณีส่วนใหญ่การติดตั้ง consensus: 3 เหมาะสมที่สุดเพราะแม้ว่าเราจะคาดหวังว่าจะมีโหนดเชื่อมต่อมากขึ้น แต่การโทรกลับก็จะผ่านไปได้ status: :rehashing → status: :up บนโหนดที่เพิ่งเพิ่มหรือลบออก

เมื่อเริ่มต้นในโหมดการพัฒนา คุณเพียงแค่ต้องตั้งค่า consensus: 1 и กุฏิ จะยินดีข้ามการรอคอยการชุมนุมคลัสเตอร์เมื่อเห็น :nonode@nohostหรือ :node@hostหรือ :[email protected] - ขึ้นอยู่กับวิธีการกำหนดค่าโหนด (:none | :shortnames | :longnames).

การจัดการแอปพลิเคชันแบบกระจาย

แอปพลิเคชันแบบกระจายที่ไม่อยู่ในสุญญากาศมักจะรวมถึงการพึ่งพาแบบกระจาย เช่น mnesia. เป็นเรื่องง่ายสำหรับเราในการจัดการการกำหนดค่าใหม่จากการโทรกลับเดียวกัน on_state_change/2. ตัวอย่างเช่น นี่คือคำอธิบายโดยละเอียดเกี่ยวกับวิธีการกำหนดค่าใหม่ mnesia ได้ทันที เอกสาร กุฏิ.

ข้อได้เปรียบหลักของการใช้ กุฏิ คือการดำเนินการที่จำเป็นทั้งหมดเพื่อสร้างคลัสเตอร์ใหม่หลังจากการเปลี่ยนแปลงโทโพโลยี ใต้ฝากระโปรง. แอปพลิเคชันทำงานในสภาพแวดล้อมแบบกระจายที่เตรียมไว้แล้ว โดยเชื่อมต่อโหนดทั้งหมด โดยไม่คำนึงว่าเราจะทราบที่อยู่ IP และชื่อโหนดล่วงหน้าหรือไม่ หรือถูกกำหนด/เปลี่ยนแปลงแบบไดนามิก สิ่งนี้ไม่ต้องการการตั้งค่าการกำหนดค่านักเทียบท่าพิเศษอย่างแน่นอน และจากมุมมองของนักพัฒนาแอปพลิเคชัน ไม่มีความแตกต่างระหว่างการทำงานในสภาพแวดล้อมแบบกระจายหรือการทำงานในสภาพแวดล้อมแบบท้องถิ่น :nonode@nohost. คุณสามารถอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ใน เอกสาร.

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

หมายเหตุ: ณ จุดนี้ในต้นฉบับมีวลี "Happy Clustering!" และ Yandex ที่ฉันแปลด้วย (ฉันไม่ต้องอ่านพจนานุกรมด้วยตัวเอง) เสนอตัวเลือก "Happy Clustering!" ให้ฉัน อาจเป็นไปไม่ได้เลยที่จะจินตนาการถึงการแปลที่ดีกว่านี้ โดยเฉพาะอย่างยิ่งเมื่อพิจารณาจากสถานการณ์ทางภูมิรัฐศาสตร์ในปัจจุบัน

ที่มา: will.com