โปรโฮสต์ > บล็อก > การบริหาร > เคล็ดลับและคำแนะนำในการทำงานกับ Ceph ในโปรเจ็กต์ที่ยุ่งวุ่นวาย

เคล็ดลับและคำแนะนำในการทำงานกับ Ceph ในโปรเจ็กต์ที่ยุ่งวุ่นวาย

เคล็ดลับและคำแนะนำในการทำงานกับ Ceph ในโปรเจ็กต์ที่ยุ่งวุ่นวาย

การใช้ Ceph เป็นที่จัดเก็บข้อมูลเครือข่ายในโปรเจ็กต์ที่มีโหลดต่างกัน เราอาจเผชิญกับงานต่างๆ ที่เมื่อมองแวบแรกดูเหมือนจะไม่ง่ายหรือไม่สำคัญ ตัวอย่างเช่น:

  • การโยกย้ายข้อมูลจาก Ceph เก่าไปยังใหม่โดยใช้เซิร์ฟเวอร์ก่อนหน้าบางส่วนในคลัสเตอร์ใหม่
  • วิธีแก้ปัญหาการจัดสรรพื้นที่ดิสก์ใน Ceph

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

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

คำนำเกี่ยวกับ OSD

เนื่องจากสองในสามสูตรอาหารที่กล่าวถึงนั้นมีไว้สำหรับ OSD โดยเฉพาะ (ภูตหน่วยเก็บข้อมูลวัตถุ) ก่อนที่จะเจาะลึกถึงส่วนที่ใช้งานได้จริง - โดยสรุปเกี่ยวกับสิ่งที่อยู่ใน Ceph และเหตุใดจึงสำคัญมาก

ก่อนอื่น ควรกล่าวว่าคลัสเตอร์ Ceph ทั้งหมดประกอบด้วย OSD จำนวนมาก ยิ่งมีจำนวนข้อมูลว่างใน Ceph มากเท่าใด เข้าใจง่ายจากที่นี่ ฟังก์ชั่น OSD หลัก: จัดเก็บข้อมูลออบเจ็กต์ Ceph บนระบบไฟล์ของโหนดคลัสเตอร์ทั้งหมดและให้การเข้าถึงเครือข่าย (สำหรับการอ่าน การเขียน และคำขออื่นๆ)

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

คดีหมายเลข 1 ลบ OSD ออกจากคลัสเตอร์ Ceph อย่างปลอดภัยโดยไม่สูญเสียข้อมูล

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

เพื่อความสะดวกและเพื่อหลีกเลี่ยงสถานการณ์ที่ในขณะที่ดำเนินการคำสั่ง เราทำผิดพลาดในการระบุ OSD ที่ต้องการ เราจะตั้งค่าตัวแปรแยกต่างหาก โดยค่าจะเป็นตัวเลขของ OSD ที่จะลบ มาโทรหาเธอกันเถอะ ${ID} — ที่นี่และด้านล่าง ตัวแปรดังกล่าวจะแทนที่หมายเลข OSD ที่เรากำลังทำงานอยู่

มาดูสภาพก่อนเริ่มงานกัน:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

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

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

... และต่อ ๆ ไปจนเป็นศูนย์

ต้องการความสมดุลที่ราบรื่นเพื่อไม่ให้ข้อมูลสูญหาย โดยเฉพาะอย่างยิ่งหาก OSD มีข้อมูลจำนวนมาก เพื่อให้แน่ใจว่าหลังจากรันคำสั่งแล้ว reweight ทุกอย่างเป็นไปด้วยดี คุณทำมันให้สำเร็จได้ ceph -s หรือเรียกใช้ในหน้าต่างเทอร์มินัลแยกต่างหาก ceph -w เพื่อสังเกตการเปลี่ยนแปลงได้แบบเรียลไทม์

เมื่อ OSD “ว่างเปล่า” คุณสามารถดำเนินการตามขั้นตอนมาตรฐานเพื่อลบออกได้ เมื่อต้องการทำเช่นนี้ ให้โอน OSD ที่ต้องการไปยังสถานะ down:

ceph osd down osd.${ID}

ลอง “ดึง” OSD ออกจากคลัสเตอร์:

ceph osd out osd.${ID}

มาหยุดบริการ OSD และถอนติดตั้งพาร์ติชันใน FS:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

ลบ OSD ออกจาก บดขยี้แผนที่:

ceph osd crush remove osd.${ID}

มาลบผู้ใช้ OSD:

ceph auth del osd.${ID}

และสุดท้าย เรามาลบ OSD กัน:

ceph osd rm osd.${ID}

หมายเหตุ: หากคุณใช้เวอร์ชัน Ceph Luminous หรือสูงกว่า ขั้นตอนการลบ OSD ข้างต้นสามารถลดลงเหลือเพียงสองคำสั่ง:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

หากหลังจากทำตามขั้นตอนที่อธิบายไว้ข้างต้นแล้ว คุณรันคำสั่ง ceph osd treeดังนั้นควรชัดเจนว่าบนเซิร์ฟเวอร์ที่ดำเนินงานนั้นไม่มี OSD อีกต่อไปซึ่งดำเนินการข้างต้น:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

ระหว่างทางสังเกตว่าสถานะของคลัสเตอร์ Ceph จะไป HEALTH_WARNและเราจะเห็นจำนวน OSD และจำนวนพื้นที่ว่างในดิสก์ที่ลดลงด้วย

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

หากไม่มี OSD เหลืออยู่บนเซิร์ฟเวอร์นี้แล้ว หลังจากลบออกแล้ว คุณจะต้องแยกเซิร์ฟเวอร์ออกจากแมป OSD hv-2โดยรันคำสั่งต่อไปนี้:

ceph osd crush rm hv-2

ลบ mon จากเซิร์ฟเวอร์ hv-2โดยการรันคำสั่งด้านล่างบนเซิร์ฟเวอร์อื่น (เช่น ในกรณีนี้ เปิด hv-1):

ceph-deploy mon destroy hv-2

หลังจากนี้ คุณสามารถหยุดเซิร์ฟเวอร์และเริ่มดำเนินการตามมาได้ (ปรับใช้ใหม่ ฯลฯ)

คดีหมายเลข 2 การกระจายพื้นที่ดิสก์ในคลัสเตอร์ Ceph ที่สร้างไว้แล้ว

ฉันจะเริ่มเรื่องที่สองด้วยคำนำเกี่ยวกับ PG (กลุ่มตำแหน่ง). บทบาทหลักของ PG ใน Ceph คือการรวบรวมวัตถุ Ceph เป็นหลักและทำซ้ำเพิ่มเติมใน OSD มีสูตรที่คุณสามารถคำนวณจำนวน PG ที่ต้องการได้ ส่วนที่เกี่ยวข้อง เอกสารของเซฟ ปัญหานี้จะมีการกล่าวถึงพร้อมตัวอย่างเฉพาะเจาะจงด้วย

ดังนั้น: หนึ่งในปัญหาทั่วไปเมื่อใช้ Ceph คือจำนวน OSD และ PG ที่ไม่สมดุลระหว่างพูลใน Ceph

ประการแรก ด้วยเหตุนี้ สถานการณ์จึงอาจเกิดขึ้นเมื่อระบุ PG มากเกินไปในพูลขนาดเล็ก ซึ่งโดยพื้นฐานแล้วเป็นการใช้พื้นที่ดิสก์ในคลัสเตอร์อย่างไม่มีเหตุผล ประการที่สอง ในทางปฏิบัติมีปัญหาร้ายแรงกว่านั้น: ข้อมูลล้นใน OSD อันใดอันหนึ่ง สิ่งนี้ทำให้คลัสเตอร์เปลี่ยนไปเป็นสถานะก่อน HEALTH_WARNและจากนั้น HEALTH_ERR. เหตุผลก็คือ Ceph เมื่อคำนวณจำนวนข้อมูลที่มีอยู่ (คุณสามารถค้นหาได้โดย MAX AVAIL ในเอาต์พุตคำสั่ง ceph df สำหรับแต่ละพูลแยกกัน) ขึ้นอยู่กับจำนวนข้อมูลที่มีอยู่ใน OSD หากมีพื้นที่ไม่เพียงพอใน OSD อย่างน้อยหนึ่งรายการ จะไม่สามารถเขียนข้อมูลได้อีกจนกว่าข้อมูลจะถูกกระจายอย่างเหมาะสมไปยัง OSD ทั้งหมด

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

ลองจินตนาการถึงภาพต่อไปนี้: คลัสเตอร์มีสถานะ HEALTH_WARN เนื่องจาก OSD อันใดอันหนึ่งหมดพื้นที่ สิ่งนี้จะถูกระบุด้วยข้อผิดพลาด HEALTH_WARN: 1 near full osd. ด้านล่างนี้เป็นอัลกอริทึมสำหรับการออกจากสถานการณ์นี้

ก่อนอื่น คุณต้องกระจายข้อมูลที่มีอยู่ระหว่าง OSD ที่เหลือ เราได้ดำเนินการที่คล้ายกันแล้วในกรณีแรกเมื่อเรา "ระบาย" โหนด - มีความแตกต่างเพียงอย่างเดียวที่ตอนนี้เราจะต้องลดลงเล็กน้อย reweight. ตัวอย่างเช่น สูงถึง 0.95:

ceph osd reweight osd.${ID} 0.95

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

ในกรณีเฉพาะของเรา ทุกอย่างขึ้นอยู่กับ:

  • มูลค่าสูงเกินไป replication_count ในสระน้ำแห่งหนึ่ง
  • PG มากเกินไปในกลุ่มหนึ่ง และน้อยเกินไปในอีกกลุ่มหนึ่ง

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

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

คอลัมน์สุดท้ายช่วยคุณนำทาง - จำนวน PG ที่แนะนำ. ในกรณีของเรา อันที่สองก็มีประโยชน์เช่นกัน โดยมีการระบุพารามิเตอร์การจำลอง เนื่องจากเราตัดสินใจเปลี่ยนตัวคูณการจำลอง

ดังนั้นก่อนอื่นคุณต้องเปลี่ยนพารามิเตอร์การจำลอง - สิ่งนี้คุ้มค่าที่จะทำก่อนเนื่องจากเราจะเพิ่มพื้นที่ว่างในดิสก์ด้วยการลดตัวคูณ เมื่อคำสั่งทำงาน คุณจะสังเกตเห็นว่าพื้นที่ว่างในดิสก์จะเพิ่มขึ้น:

ceph osd pool $pool_name set $replication_size

และหลังจากเสร็จสิ้นเราจะเปลี่ยนค่าพารามิเตอร์ pg_num и pgp_num ดังต่อไปนี้:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

มันเป็นสิ่งสำคัญ: เราต้องเปลี่ยนจำนวน PG ตามลำดับในแต่ละพูลและไม่เปลี่ยนค่าในพูลอื่นจนกว่าคำเตือนจะหายไป “ลดความซ้ำซ้อนของข้อมูล” и "n-จำนวน pgs ลดลง".

คุณยังสามารถตรวจสอบได้ว่าทุกอย่างเป็นไปด้วยดีโดยใช้เอาต์พุตคำสั่ง ceph health detail и ceph -s.

คดีหมายเลข 3 การย้ายเครื่องเสมือนจาก LVM ไปยัง Ceph RBD

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

ปัญหาสามารถแก้ไขได้หลายวิธี - ตัวอย่างเช่นโดยการย้ายไปยังเซิร์ฟเวอร์อื่น (ถ้ามี) หรือเพิ่มดิสก์ใหม่ไปยังเซิร์ฟเวอร์ แต่ก็ไม่สามารถทำได้เสมอไป ดังนั้นการย้ายจาก LVM ไปยัง Ceph จึงเป็นวิธีแก้ปัญหาที่ยอดเยี่ยม ด้วยการเลือกตัวเลือกนี้ เรายังทำให้กระบวนการโยกย้ายระหว่างเซิร์ฟเวอร์เพิ่มเติมง่ายขึ้น เนื่องจากไม่จำเป็นต้องย้ายที่เก็บข้อมูลในเครื่องจากไฮเปอร์ไวเซอร์เครื่องหนึ่งไปยังอีกเครื่องหนึ่ง สิ่งเดียวที่จับได้คือคุณจะต้องหยุด VM ในขณะที่กำลังดำเนินการงาน

สูตรต่อไปนี้นำมาจาก บทความจากบล็อกนี้คำแนะนำที่ได้รับการทดสอบในทางปฏิบัติแล้ว อนึ่ง, มีการอธิบายวิธีการโยกย้ายที่ไม่ยุ่งยากอยู่ที่นั่นด้วยอย่างไรก็ตาม ในกรณีของเรา มันไม่จำเป็น ดังนั้นเราจึงไม่ได้ตรวจสอบมัน หากนี่เป็นสิ่งสำคัญสำหรับโครงการของคุณ เรายินดีที่จะทราบผลลัพธ์ในความคิดเห็น

เรามาดูส่วนที่ใช้งานได้จริงกันดีกว่า ในตัวอย่าง เราใช้ virsh และ libvirt ตามลำดับ ขั้นแรก ตรวจสอบให้แน่ใจว่าพูล Ceph ที่จะย้ายข้อมูลนั้นเชื่อมต่อกับ libvirt:

virsh pool-dumpxml $ceph_pool

คำอธิบายพูลต้องมีข้อมูลการเชื่อมต่อกับ Ceph พร้อมข้อมูลการอนุญาต

ขั้นตอนต่อไปคืออิมเมจ LVM จะถูกแปลงเป็น Ceph RBD เวลาในการดำเนินการขึ้นอยู่กับขนาดของภาพเป็นหลัก:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

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

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

... และแก้ไขต้นฉบับ (vm_name.xml). มาหาบล็อกที่มีคำอธิบายของดิสก์ (เริ่มต้นด้วยบรรทัด <disk type='file' device='disk'> และลงท้ายด้วย </disk>) และลดขนาดให้อยู่ในรูปแบบต่อไปนี้:

<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
  <secret type='ceph' uuid='sec-ret-uu-id'/>
 </auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
  <host name='10.0.0.1' port='6789'/>
  <host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/> 
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>

มาดูรายละเอียดกันดีกว่า:

  1. ไปที่โปรโตคอล source ระบุที่อยู่ไปยังที่เก็บข้อมูลใน Ceph RBD (นี่คือที่อยู่ที่ระบุชื่อพูล Ceph และอิมเมจ RBD ซึ่งถูกกำหนดในขั้นตอนแรก)
  2. ในบล็อค secret มีการระบุประเภท cephรวมถึง UUID ของข้อมูลลับที่จะเชื่อมต่อด้วย คุณสามารถค้นหา uuid ได้โดยใช้คำสั่ง virsh secret-list.
  3. ในบล็อค host ที่อยู่ไปยังจอภาพ Ceph จะถูกระบุ

หลังจากแก้ไขไฟล์การกำหนดค่าและแปลง LVM เป็น RBD เสร็จแล้ว คุณสามารถใช้ไฟล์การกำหนดค่าที่แก้ไขแล้วและเริ่มเครื่องเสมือนได้:

virsh define $vm_name.xml
virsh start $vm_name

ถึงเวลาตรวจสอบว่าเครื่องเสมือนเริ่มต้นอย่างถูกต้อง: คุณสามารถค้นหาได้โดยการเชื่อมต่อผ่าน SSH หรือทาง virsh.

หากเครื่องเสมือนทำงานอย่างถูกต้องและคุณไม่พบปัญหาอื่นใด คุณสามารถลบอิมเมจ LVM ที่ไม่ได้ใช้อีกต่อไปได้:

lvremove main/$vm_image_name

ข้อสรุป

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

PS

อ่านเพิ่มเติมในบล็อกของเรา:

ที่มา: will.com

เพิ่มความคิดเห็น