ส่วนนี้สรุปแนวทางปฏิบัติที่ดีที่สุดและให้คำแนะนำในการใช้ OPDK กับระบบคลาวด์ AWS
Cassandra ใช้เป็นแบ็กเอนด์และพื้นที่เก็บข้อมูลสำหรับนโยบายเกือบทั้งหมด และเป็นส่วนสำคัญของสภาพแวดล้อมรันไทม์ Apigee Edge เอกสารนี้มุ่งเน้นการเพิ่มประสิทธิภาพ Casssandra สำหรับสภาพแวดล้อม AWS
ข้อกำหนดของพื้นที่เก็บข้อมูลและ I/O
Cassandra I/O ส่วนใหญ่เป็นแบบตามลำดับ แต่มีบางกรณีที่ต้องใช้ I/O แบบสุ่ม ตัวอย่างคือเมื่ออ่านตารางสตริงที่จัดเรียงในระหว่างการดำเนินการอ่าน SSD เป็นกลไกพื้นที่เก็บข้อมูลที่แนะนำสำหรับ Cassandra เนื่องจากให้เวลาการตอบสนองเวลาในการตอบสนองต่ำมากสำหรับการดำเนินการอ่านแบบสุ่ม ในขณะเดียวกันก็มอบประสิทธิภาพการเขียนตามลำดับที่เพียงพอสำหรับการดำเนินการบีบอัด การจำลองก็จะต้องพิจารณาในส่วนนี้ด้วย
อินสแตนซ์หลายรายการใน AWS EC2 มาพร้อมกับพื้นที่เก็บข้อมูลในเครื่อง ซึ่งฮาร์ดไดรฟ์จะต่ออยู่กับฮาร์ดแวร์ที่อินสแตนซ์ EC2 โฮสต์อยู่ Apigee ขอแนะนำให้คุณใช้ประโยชน์จากทั้งที่เก็บ SSD และอินสแตนซ์เมื่อเรียกใช้ Cassandra ในเวอร์ชันที่ใช้งานจริง เมื่อใช้ประเภทอินสแตนซ์ที่มี SSD มากกว่า 1 ตัว คุณสามารถใช้ RAID0 เพื่อรับอัตราการส่งข้อมูลและความจุของพื้นที่เก็บข้อมูลมากขึ้นได้
ข้อกำหนดเกี่ยวกับเครือข่าย
คาสซันดราใช้โปรโตคอล Gossip เพื่อแลกเปลี่ยนข้อมูลกับโหนดอื่นๆ เกี่ยวกับโทโพโลยีเครือข่าย การใช้ Gossip บวกกับลักษณะของ Cassandra ที่มีการเผยแพร่แบบกระจาย ซึ่งต้องอาศัยการบอกถึงโหนดหลายโหนดเพื่ออ่านและเขียน ทำให้มีการโอนข้อมูลผ่านเครือข่ายจำนวนมาก Apigee แนะนำให้ใช้ประเภทอินสแตนซ์ที่มีแบนด์วิดท์เครือข่ายอย่างน้อย 1 Gbps และมากกว่า 1 Gbps สำหรับระบบที่ใช้งานจริง
ใช้ VPC ที่มี CIDR เป็น /16 เนื่องจากซับเน็ตใน AWS ขยายไปยัง AZ ได้ไม่เกิน 1 AZ Apigee จึงแนะนำสิ่งต่อไปนี้
- สร้างซับเน็ต 1 รายการต่อโซนความพร้อมใช้งาน (AZ)
- ใช้ซับเน็ตส่วนตัว 3 รายการสำหรับการติดตั้ง Apigee ด้วยโหนด Cassandra 1 โหนดใน AZ แต่ละโหนด ซับเน็ต 3 รายการควรมีบล็อก CIDR เพียงพอเพื่อรองรับการขยายคลัสเตอร์ Cassandra ในแนวนอน
- กำหนดค่าซับเน็ตสาธารณะ 3 รายการด้วย NAT เฉพาะสำหรับ Cassandra เพื่อให้สื่อสารกับอินเทอร์เน็ตเพื่อดาวน์โหลดซอฟต์แวร์และอัปเดตความปลอดภัยได้
Cassandra มีสถาปัตยกรรมที่ไม่มีต้นแบบซึ่งต่างจากสถาปัตยกรรมต้นแบบดั้งเดิมที่โหนดทั้งหมดมีบทบาทเหมือนกัน ดังนั้นจึงไม่มีจุดความล้มเหลวเพียงจุดเดียว ลองกระจายโหนด Cassandra ไปยัง AZ หลายรายการเพื่อเปิดใช้ความพร้อมใช้งานสูง การกระจายโหนดไปยัง AZ ทำให้คุณยังคง พร้อมให้บริการและระยะเวลาทำงานในกรณีที่เกิดภัยพิบัติ
การเลือกกลุ่มอินสแตนซ์
เมื่อดูข้อกำหนดของ Cassandra CPU คุณควรทราบว่าภาระงานที่หนักหน่วงเป็น 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 |
| ที่เก็บอินสแตนซ์ | SSD (พื้นที่เก็บข้อมูลในเครื่อง) ที่มี RAID0 |
| ประเภทการเช่า | ค่าเริ่มต้น |
| ตำแหน่งโหนด | โหนด Cassandra 1 โหนดต่อ AZ |
| VPC และซับเน็ต | ซับเน็ต 1 รายการต่อ AZ และ VPC ต่อภูมิภาค |
ดูข้อมูลเพิ่มเติมได้ที่ประเภทอินสแตนซ์ของ Amazon