วิธีเรียกใช้ Cassandra และ Kubernetes ร่วมกัน

คอนเทนเนอร์ได้รับความนิยมมากขึ้นสำหรับนักพัฒนาที่ต้องการปรับใช้แอปพลิเคชันในระบบคลาวด์ ในการจัดการแอปพลิเคชันใหม่เหล่านี้ Kubernetes ได้กลายเป็นมาตรฐานโดยพฤตินัยสำหรับการจัดระเบียบคอนเทนเนอร์ Kubernetes ช่วยให้นักพัฒนาสามารถสร้างแอปพลิเคชันแบบกระจายที่ปรับขนาดได้โดยอัตโนมัติตามความต้องการ

Kubernetes ได้รับการพัฒนาเพื่อปรับใช้ปรับขนาดและจัดการปริมาณงานแอปพลิเคชันแบบไร้สัญชาติในการผลิตได้อย่างง่ายดาย เมื่อพูดถึงข้อมูลที่มีสถานะเป็นระบบคลาวด์จำเป็นต้องมีความสะดวกในการปรับใช้และขนาดเดียวกัน

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

เชื่อมต่อ Cassandra กับ Kubernetes

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

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

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

มีตัวดำเนินการหลายตัวสำหรับ Cassandra ที่ได้รับการพัฒนาโดยชุมชน Cassandra สำหรับตัวอย่างนี้เราจะใช้ Cass-operator ซึ่ง DataStax รวบรวมและโอเพ่นซอร์ส รองรับ Kubernetes แบบโอเพนซอร์ส, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) และ Pivotal Container Service (PKS) ดังนั้นคุณจึงสามารถใช้บริการ Kubernetes ที่เหมาะสมกับสภาพแวดล้อมของคุณได้มากที่สุด

การติดตั้งตัวดำเนินการ Cass บนคลัสเตอร์ Kubernetes ของคุณเองเป็นกระบวนการง่ายๆหากคุณมีความรู้พื้นฐานในการเรียกใช้คลัสเตอร์ Kubernetes เมื่อตรวจสอบสิทธิ์คลัสเตอร์ Kubernetes แล้วโดยใช้ kubectl เครื่องมือบรรทัดคำสั่งคลัสเตอร์ Kubernetes และอินสแตนซ์ระบบคลาวด์ Kubernetes (ไม่ว่าจะเป็น Kubernetes แบบโอเพนซอร์ส GKE EKS หรือ PKS) เชื่อมต่อกับเครื่องในพื้นที่ของคุณคุณสามารถเริ่มใช้ Cass- การกำหนดค่าตัวดำเนินการไฟล์ YAML ไปยังคลัสเตอร์ของคุณ

การตั้งค่านิยามตัวดำเนินการคาสของคุณ

ขั้นตอนต่อไปคือการใช้คำจำกัดความสำหรับรายการตัวดำเนินการคาสคลาสพื้นที่จัดเก็บและศูนย์ข้อมูลกับคลัสเตอร์ Kubernetes

หมายเหตุสั้น ๆ เกี่ยวกับคำจำกัดความของศูนย์ข้อมูล สิ่งนี้เป็นไปตามคำจำกัดความที่ใช้ใน Cassandra มากกว่าการอ้างอิงถึงศูนย์ข้อมูลทางกายภาพ

ลำดับชั้นสำหรับสิ่งนี้มีดังนี้:

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

ตอนนี้เราได้ยืนยันหลักการตั้งชื่อของเราแล้วก็ถึงเวลาตั้งค่าคำจำกัดความ ตัวอย่างของเราใช้ GKE แต่กระบวนการนี้คล้ายกับกลไก Kubernetes อื่น ๆ มีสามขั้นตอน 

ขั้นตอนที่ 1

ขั้นแรกเราต้องเรียกใช้คำสั่ง kubectl ซึ่งอ้างอิงไฟล์กำหนดค่า YAML สิ่งนี้ใช้คำจำกัดความของรายการตัวดำเนินการคาสกับคลัสเตอร์ Kubernetes ที่เชื่อมต่อ Manifests คือคำอธิบายอ็อบเจ็กต์ API ซึ่งอธิบายสถานะที่ต้องการของอ็อบเจ็กต์ในกรณีนี้คือตัวดำเนินการ Cassandra ของคุณ สำหรับรายการ Manifest เฉพาะเวอร์ชันทั้งหมดโปรดดูหน้า GitHub นี้

นี่คือตัวอย่างคำสั่ง kubectl สำหรับ GKE cloud ที่ใช้ Kubernetes 1.16:

kubectl สร้าง -f //raw.githubusercontent.com/datastax/cass-operator/v1.3.0/docs/user/cass-operator-manifests-v1.16.yaml

ขั้นตอนที่ 2

คำสั่ง kubectl ถัดไปใช้การกำหนดค่า YAML ที่กำหนดการตั้งค่าหน่วยเก็บข้อมูลที่จะใช้สำหรับโหนด Cassandra ในคลัสเตอร์ Kubernetes ใช้ทรัพยากร StorageClass เป็นเลเยอร์นามธรรมระหว่างพ็อดที่ต้องการพื้นที่จัดเก็บถาวรและทรัพยากรพื้นที่เก็บข้อมูลทางกายภาพที่คลัสเตอร์ Kubernetes ระบุได้ ตัวอย่างใช้ SSD เป็นประเภทการจัดเก็บ สำหรับตัวเลือกเพิ่มเติมโปรดดูหน้า GitHub นี้ นี่คือลิงก์โดยตรงไปยัง YAML ที่ใช้ในการกำหนดค่าพื้นที่เก็บข้อมูลด้านล่าง:

apiVersion: storage.k8s.io/v1

ชนิด: StorageClass

ข้อมูลเมตา:

  ชื่อ: เซิร์ฟเวอร์ที่เก็บข้อมูล

ผู้จัดเตรียม: kubernetes.io/gce-pd

พารามิเตอร์:

  ชนิด: pd-ssd

  ประเภทการจำลองแบบ: ไม่มี

volumeBindingMode: WaitForFirstConsumer

reclaimPolicy: ลบ

ขั้นตอนที่ 3

สุดท้ายใช้ kubectl อีกครั้งเราใช้ YAML ที่กำหนด Cassandra Datacenter ของเรา

# ปรับขนาดให้ทำงานกับโหนดคนงาน 3 k8s พร้อม 1 core / 4 GB RAM

# ดูตัวอย่างที่อยู่ใกล้เคียง -cassdc-full.yaml สำหรับเอกสารสำหรับแต่ละพารามิเตอร์

apiVersion: cassandra.datastax.com/v1beta1

ชนิด: CassandraDatacenter

ข้อมูลเมตา:

  ชื่อ: dc1

ข้อมูลจำเพาะ:

  clusterName: คลัสเตอร์ 1

  serverType: คาสซานดรา

  เวอร์ชันเซิร์ฟเวอร์: "3.11.6"

  managementApiAuth:

    ไม่ปลอดภัย: {}

  ขนาด: 3

  ที่เก็บข้อมูลConfig:

    CassandraDataVolumeClaimSpec:

      storageClassName: เซิร์ฟเวอร์ที่เก็บข้อมูล

      accessModes:

        - ReadWriteOnce

      ทรัพยากร:

        คำขอ:

          การจัดเก็บ: 5Gi

  config:   

    คาสแซนดรา - ยำล:

      ตัวพิสูจน์ตัวตน: org.apache.cassandra.auth.PasswordAuthenticator

      Authorizer: org.apache.cassandra.auth.CassandraAuthorizer

      role_manager: org.apache.cassandra.auth.CassandraRoleManager

    jvm- ตัวเลือก:

      initial_heap_size: "800M"

      max_heap_size: "800M"

YAML ตัวอย่างนี้ใช้สำหรับอิมเมจ Apache Cassandra 3.11.6 แบบโอเพนซอร์สที่มีสามโหนดบนแร็คเดียวในคลัสเตอร์ Kubernetes นี่คือลิงค์โดยตรง มีชุดการกำหนดค่าดาต้าเซ็นเตอร์เฉพาะฐานข้อมูลทั้งหมดในหน้า GitHub นี้

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

ในการเชื่อมต่อกับฐานข้อมูล Cassandra ที่ปรับใช้เองคุณสามารถใช้ cqlsh เชลล์บรรทัดคำสั่งและค้นหา Cassandra โดยใช้ CQL จากภายในคลัสเตอร์ Kubernetes ของคุณ เมื่อตรวจสอบสิทธิ์แล้วคุณจะสามารถส่งคำสั่ง DDL เพื่อสร้างหรือแก้ไขตาราง ฯลฯ และจัดการข้อมูลด้วยคำสั่ง DML เช่นแทรกและอัปเดตใน CQL

อะไรต่อไปสำหรับ Cassandra และ Kubernetes?

แม้ว่าจะมีตัวดำเนินการหลายตัวสำหรับ Apache Cassandra แต่ก็มีความต้องการตัวดำเนินการทั่วไป บริษัท ที่เกี่ยวข้องในชุมชน Cassandra เช่น Sky, Orange, DataStax และ Instaclustr กำลังร่วมมือกันเพื่อจัดตั้งตัวดำเนินการทั่วไปสำหรับ Apache Cassandra บน Kubernetes ความพยายามในการทำงานร่วมกันนี้ดำเนินไปควบคู่ไปกับโอเปอเรเตอร์โอเพนซอร์สที่มีอยู่และจุดมุ่งหมายคือเพื่อให้องค์กรและผู้ใช้มีสแต็กที่มีการขยายขนาดที่สอดคล้องกันสำหรับการคำนวณและข้อมูล

เมื่อเวลาผ่านไปการย้ายไปยังแอปพลิเคชันบนระบบคลาวด์จะต้องได้รับการสนับสนุนด้วยข้อมูลบนระบบคลาวด์เช่นกัน สิ่งนี้จะอาศัยระบบอัตโนมัติมากขึ้นซึ่งขับเคลื่อนโดยเครื่องมือเช่น Kubernetes ด้วยการใช้ Kubernetes และ Cassandra ร่วมกันคุณจะสามารถเข้าถึงข้อมูลในระบบคลาวด์ได้

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ Cassandra และ Kubernetes โปรดไปที่ //www.datastax.com/dev/kubernetes สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการเรียกใช้ Cassandra ในระบบคลาวด์โปรดดู DataStax Astra 

Patrick McFadin เป็นรองประธานฝ่ายพัฒนาสัมพันธ์ที่ DataStax ซึ่งเขาเป็นผู้นำทีมที่อุทิศตนเพื่อทำให้ผู้ใช้ Apache Cassandra ประสบความสำเร็จ เขายังทำงานเป็นหัวหน้าผู้เผยแพร่ศาสนาของ Apache Cassandra และที่ปรึกษาของ DataStax ซึ่งเขาช่วยสร้างการปรับใช้ที่ใหญ่ที่สุดและน่าตื่นเต้นในการผลิต ก่อนหน้า DataStax เขาเป็นหัวหน้าสถาปนิกที่ Hobsons และ Oracle DBA / ผู้พัฒนามากว่า 15 ปี

-

New Tech Forum เป็นสถานที่สำหรับสำรวจและพูดคุยเกี่ยวกับเทคโนโลยีสำหรับองค์กรที่เกิดขึ้นใหม่ในเชิงลึกและเชิงกว้างที่ไม่เคยมีมาก่อน การเลือกเป็นเรื่องส่วนตัวขึ้นอยู่กับการเลือกใช้เทคโนโลยีที่เราเชื่อว่ามีความสำคัญและเป็นที่สนใจของผู้อ่านมากที่สุด ไม่ยอมรับหลักประกันทางการตลาดสำหรับการตีพิมพ์และขอสงวนสิทธิ์ในการแก้ไขเนื้อหาที่มีส่วนร่วมทั้งหมด ส่งคำถามทั้งหมดไปที่ [email protected]