รากฐานที่ดีที่สุดสำหรับการปรับใช้ Mesos


9

ขณะนี้เรากำลังอยู่ในขั้นตอนของการออกแบบสถาปัตยกรรมของ Apache Mesos ระบบคลาวด์ใหม่ของเรา เป้าหมายคือการรวมระบบของเราด้วยการย้ายสแต็คที่แตกต่างกันไปยังสถาปัตยกรรมเดียวกัน ภาระงานหลักคือการวิเคราะห์ข้อมูลขนาดใหญ่โดยใช้ Apache Spark และโครงสร้างพื้นฐานขององค์กรของเรารวมถึงเว็บเซิร์ฟเวอร์เซิร์ฟเวอร์อีเมล ฯลฯ

แนวคิดคือการเรียกใช้บริการเว็บของเราในคอนเทนเนอร์ Docker ที่ทำงานบนหนึ่งในตัวกำหนดเวลาที่ใช้ได้สำหรับ Mesos (Marathon / Chronos, Aurora หรือ Singularity) นี่จะเป็นกลุ่มกรอบ Mesos แรก ถัดจากนั้นเราจะมี Apache Spark framework และเฟรมเวิร์กฐานข้อมูลต่าง ๆ สำหรับการจัดเก็บข้อมูล นี่จะเป็นเฟรมเวิร์กของ Mesos กลุ่มที่สอง เราจะเลือกเฉพาะหลังจากเรียกใช้พวกเขาทั้งหมดในแบบคู่ขนานสำหรับการทดสอบ

อย่างไรก็ตามเรามีปัญหาในการตัดสินใจซึ่งพื้นฐานในการเรียกใช้ Mesos เอง เป็นการดีที่เราต้องการเรียกใช้มันให้ใกล้เคียงกับโลหะมากที่สุด นอกจากนี้เรายังต้องการใช้วิธีการแก้ปัญหาแบบออเคสตร้าเพื่อให้แน่ใจว่า Mesos & framework daemons นั้นทำงาน / รีสตาร์ทเมื่อล้มเหลวเสมอ ตัวเลือกที่เรากำลังพิจารณามีดังนี้:

1) การเรียกใช้ Mesos & เฟรมเวิร์กเป็นคอนเทนเนอร์ docker ในระบบปฏิบัติการที่น้อยที่สุด ในส่วนนี้เรากำลังโน้มตัวไปสู่ ​​CoreOS และ Fleet

2) การเรียกใช้ Mesos & เฟรมเวิร์กโดยตรงบนเซิร์ฟเวอร์ Ubuntu / Debian สำหรับตัวเลือกนี้เรากำลังมุ่งหน้าไปยัง Foreman และ Puppet

สำหรับคำถามนี้เรากำลังมองหาวิธีการแก้ปัญหาซึ่งตามลำดับความสำคัญ:

  • มีความซับซ้อนน้อยที่สุดในการกำหนดค่า
  • เป็นวิธีที่ง่ายที่สุดในการรักษาและปรับปรุงให้ทันสมัยอยู่เสมอ
  • มีค่าใช้จ่ายน้อยที่สุด

เราไม่เคยทำงานกับ CoreOS มาก่อน แต่มันเป็นตัวเลือกที่เรามุ่งหวัง ปัญหาใหญ่ (อัตนัย) หนึ่งเรื่องที่ฉันมีคือเราเรียกใช้ Mesos บนคอนเทนเนอร์ Docker แล้วเราก็เรียกใช้คอนเทนเนอร์ Docker บน Mesos ดูเหมือนว่า "ไม่สะอาด" และผิดกับฉัน ข้อพิจารณานี้ปราศจากบุญหรือไม่?

ความคิดที่คล้ายกันเกี่ยวข้องกับความซ้ำซ้อนระหว่างเลเยอร์ เพื่ออธิบายว่าฉันมาจากที่ใดฉันจะเลือกว่า Mesos เป็นระบบปฏิบัติการจริงที่เพิ่งทำงานบนโลหะ ดูเหมือนว่าไม่ว่าคุณจะใช้พื้นฐานแบบใดคุณก็จบลงด้วยฟังก์ชั่นที่ตั้งใจไว้เหมือนกันในสถาปัตยกรรมมากกว่าหนึ่งเลเยอร์ (เช่น CoreOS & Fleet & SystemD == Mesos & Marathon & Chronos) สิ่งนี้หลีกเลี่ยงไม่ได้หรือไม่?

มีตัวเลือกที่ดีอื่น ๆ ในการเรียกใช้เลเยอร์ด้านล่าง Mesos ที่เราไม่ได้พิจารณาโดยคำนึงถึงเกณฑ์ของเราหรือไม่?


ฟังดูซับซ้อน สิ่งที่ดึงดูด Mesos ในบริบทนี้คืออะไร?
ewwhite

Mesos เติมเต็มข้อมูลขนาดใหญ่ / HPC ได้ดีเช่น Spark หรือแม้กระทั่ง Hadoop แต่ฉันไม่เห็นคุณค่าในการทำให้ทุกอย่างอยู่ภายใต้มันโดยเฉพาะเว็บหรือบริการอีเมล
Michael Hampton

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

@MichaelHampton เราเชื่อว่าสถาปัตยกรรม Mesos เป็นหนทางไปข้างหน้าสำหรับการประมวลผลแบบคลาวด์ แต่ฉันไม่ได้อ้างสิทธิ์ด้วยวิธีการใด ๆ ที่เป็นคำตอบเดียว มันควรจะชัดเจนว่ามันง่ายต่อการจัดการในคลัสเตอร์มากกว่าการจัดการคลัสเตอร์เดียวกันบวกบางสิ่งเพิ่มเติมที่ด้านข้าง
awishformore

1
นี่อาจเป็นสิ่งที่ควรค่าแก่การดู: mesosphere.com/product - รุ่นขององค์กรดูเหมือนว่าจะสามารถใช้งานได้กับโลหะเปลือย
Mary

คำตอบ:


2

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

ฉันเรียกใช้การตั้งค่า> เครื่องจักร 70 เครื่องและบริการที่หลากหลายภายใต้ HAProxy สำหรับการทำโหลดบาลานซ์ด้วย Mesos-DNS และ Marathon, Api gateway, Chronos, Jenkins, Docker, Collectd และ Graphite, ...

ตอนนี้เพื่อตอบคำถามโดยตรงของคุณ:

  • Mesos มีความซับซ้อนน้อยที่สุดในการกำหนดค่าโดยใช้การกระจาย Linux ที่ "โปรดปราน"ที่คุณคุ้นเคยมากที่สุด
  • ที่ง่ายที่สุดในการบำรุงรักษาคืออีกครั้ง distro ที่คุณคุ้นเคยมากที่สุด
  • เกี่ยวกับค่าใช้จ่าย Mesos เป็นระบบซอฟต์แวร์ที่ใช้ไลบรารี่ OS พื้นฐานและฟังก์ชั่นซอฟต์แวร์อื่น ๆ นอกเหนือจากนั้นและมี Mesos เป็นระบบปฏิบัติการ (ทำงานทั้งกับฮาร์ดแวร์และซอฟต์แวร์ ... ) เป็นภาพที่ผิดอย่างสมบูรณ์

ดังนั้นคำตอบที่ดีที่สุดของฉันสำหรับคุณคือการใช้ distro ลินุกซ์ที่คุณชื่นชอบและใส่ Mesos บนหรือถ้าคุณต้องการที่จะเรียนรู้สิ่งใหม่และอาจจะได้อย่างรวดเร็วและง่ายดายใช้(โอเพนซอร์ส) DCOSและCoreOS

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.