ส่วนนี้จะสรุปแนวทางปฏิบัติแนะนำและให้คำแนะนำในการใช้ OPDK กับระบบคลาวด์ AWS
Cassandra ใช้เป็นแบ็กเอนด์และ Datastore สำหรับนโยบายเกือบทั้งหมด และเป็นส่วนสำคัญของสภาพแวดล้อมรันไทม์ของ Apigee Edge เอกสารนี้จะเน้นที่การเพิ่มประสิทธิภาพ Cassandra สำหรับสภาพแวดล้อม AWS
ข้อกำหนดด้านพื้นที่เก็บข้อมูลและ I/O
I/O ของ Cassandra ส่วนใหญ่เป็นแบบต่อเนื่อง แต่ก็มีบางกรณีที่คุณต้องใช้ I/O แบบสุ่ม ตัวอย่างเช่น เมื่ออ่านตารางสตริงที่จัดเรียงระหว่างการดำเนินการอ่าน SSD เป็นกลไกการจัดเก็บข้อมูลที่แนะนำสำหรับ Cassandra เนื่องจากมีเวลาในการตอบสนองที่มีเวลาในการตอบสนองต่ำมากสำหรับการดำเนินการอ่านแบบสุ่ม ขณะเดียวกันก็ให้ประสิทธิภาพการเขียนตามลำดับที่เพียงพอสำหรับการดำเนินการบีบอัด การจำลองแบบก็เป็นสิ่งที่ต้องพิจารณาในที่นี้ด้วย
อินสแตนซ์จำนวนมากใน AWS EC2 มาพร้อมกับพื้นที่เก็บข้อมูลในเครื่องซึ่งฮาร์ดไดรฟ์เชื่อมต่อกับฮาร์ดแวร์ที่โฮสต์อินสแตนซ์ EC2 อยู่ Apigee ขอแนะนำให้ใช้ทั้ง SSD และพื้นที่เก็บข้อมูลอินสแตนซ์เมื่อเรียกใช้ Cassandra ในเวอร์ชันที่ใช้งานจริง เมื่อใช้อินสแตนซ์ที่มี SSD มากกว่า 1 ตัว คุณสามารถใช้ RAID0 เพื่อให้ได้อัตราการส่งผ่านข้อมูลและความจุของพื้นที่เก็บข้อมูลมากขึ้น
ข้อกำหนดเกี่ยวกับเครือข่าย
Cassandra ใช้โปรโตคอล Gossip เพื่อแลกเปลี่ยนข้อมูลกับโหนดอื่นๆ เกี่ยวกับโทโพโลยีเครือข่าย การใช้ Gossip ร่วมกับลักษณะแบบกระจายของ Cassandra ซึ่งเกี่ยวข้องกับการสื่อสารกับหลายโหนดสำหรับการดำเนินการอ่านและเขียน ส่งผลให้มีการโอนข้อมูลจำนวนมากผ่านเครือข่าย Apigee ขอแนะนำให้ใช้อินสแตนซ์ที่มีแบนด์วิดท์เครือข่ายอย่างน้อย 1 Gbps และมากกว่า 1 Gbps สำหรับระบบเวอร์ชันที่ใช้งานจริง
ใช้ VPC ที่มี CIDR เป็น /16 เนื่องจากซับเน็ตใน AWS ไม่สามารถขยายข้าม AZ ได้มากกว่า 1 รายการ Apigee จึงขอแนะนำดังนี้
- สร้างซับเน็ต 1 รายการต่อ Availability Zone (AZ)
- ใช้ซับเน็ตส่วนตัว 3 รายการสำหรับการติดตั้ง Apigee โดยมีโหนด Cassandra 1 โหนดในแต่ละ AZ ซับเน็ตทั้ง 3 ควรมีบล็อก CIDR เพียงพอที่จะรองรับการขยายคลัสเตอร์ Cassandra ในแนวนอน
- กำหนดค่าซับเน็ตสาธารณะ 3 รายการที่มี NAT เฉพาะสำหรับ Cassandra เพื่อให้สามารถสื่อสารกับอินเทอร์เน็ตสำหรับการดาวน์โหลดซอฟต์แวร์และการอัปเดตความปลอดภัย
Cassandra มีสถาปัตยกรรมแบบไม่มีมาสเตอร์ซึ่งต่างจากสถาปัตยกรรมแบบมาสเตอร์-สเลฟเดิม โดยโหนดทั้งหมดมีบทบาทเหมือนกัน จึงไม่มีจุดเดียวของความล้มเหลว พิจารณากระจายโหนด Cassandra ไปยัง AZ หลายรายการเพื่อเปิดใช้ความพร้อมใช้งานสูง การกระจายโหนดไปยัง AZ ต่างๆ จะช่วยให้คุณยังคงรักษาความพร้อมใช้งานและระยะเวลาทำงานไว้ได้ในกรณีที่เกิดความเสียหาย
การเลือกตระกูลอินสแตนซ์
เมื่อพิจารณาข้อกำหนด CPU ของ Cassandra คุณควรทราบว่าเวิร์กโหลดที่ต้องใช้การแทรกจำนวนมากจะเชื่อมโยงกับ CPU ใน Cassandra ก่อนที่จะเชื่อมโยงกับ IO กล่าวคือ การดำเนินการเขียนทั้งหมดจะไปที่บันทึกการคอมมิต แต่ Cassandra มีประสิทธิภาพในการเขียนมากจน CPU กลายเป็นปัจจัยที่จำกัด Cassandra มีการทำงานพร้อมกันสูงและใช้แกน CPU มากเท่าที่มีอยู่
Apigee ขอแนะนำให้ใช้ตระกูลอินสแตนซ์ซึ่งมีทั้ง CPU และหน่วยความจำที่สมดุล โดยเฉพาะอย่างยิ่ง เราขอแนะนำให้ใช้อินสแตนซ์ตระกูล C5 หากมีในภูมิภาค AWS ของคุณ และใช้ C3 เป็นตัวเลือกสำรอง ในบางกรณี 4xlarge เป็นอินสแตนซ์ที่เหมาะสมที่สุดในทั้ง 2 ตระกูลซึ่งให้ราคา/ประสิทธิภาพที่ดีที่สุด
นอกจากนี้ Apigee ยังแนะนำให้ใช้กลุ่มผู้ใช้เริ่มต้นสำหรับอินสแตนซ์ Cassandra ด้วย เมื่อคุณปรับขนาดเป็นมากกว่า 1 อินสแตนซ์ต่อ AZ อินสแตนซ์ Cassandra ทั้งหมดของคุณน่าจะวางอยู่บนฮาร์ดแวร์พื้นฐานเดียวกันหากคุณตั้งค่าการเช่าเป็นแบบเฉพาะ ดังนั้นเมื่อฮาร์ดแวร์ขัดข้อง คุณก็อาจสูญเสียอินสแตนซ์ทั้งหมดใน AZ นั้น
ข้อมูลสรุปคำแนะนำ
ตารางต่อไปนี้สรุปคำแนะนำของ Apigee สำหรับการใช้ AWS กับ Apigee Edge สำหรับ Private Cloud
| ตระกูลอินสแตนซ์ | C5d (แนะนำ) หรือ C3 |
| ประเภทอินสแตนซ์ | C(x).4xlarge |
| Instance Store | SSD (พื้นที่เก็บข้อมูลในเครื่อง) พร้อม RAID0 |
| ประเภทการเช่า | ค่าเริ่มต้น |
| การวางโหนด | โหนด Cassandra 1 โหนดต่อ AZ |
| VPC และซับเน็ต | 1 ซับเน็ตต่อ AZ และ 1 VPC ต่อภูมิภาค |
ดูข้อมูลเพิ่มเติมได้ที่ประเภทอินสแตนซ์ของ Amazon