DRBD Network-RAID1 Mirroring Part II

การจัดการดิสก์

มาลองดูรายละเอียดเกี่ยวกับดิสก์ดูบ้าง หลักๆ แล้วให้ดูเรื่องขนาดครับ โดยดูขนาดของพาร์ติชั่นเป็นหลัก สำหรับกรณีที่ node ที่เราจะไปทำการ mirror นั้นทำการ production ไปแล้ว การจะไปปรับเปลี่ยนอะไรกับ production คงทำได้ยากหน่อย ให้มาปรับเปลี่ยนฝั่งที่เราจะทำเป็น destination จะสะดวกกว่า จากตัวอย่างการทำ DR-Ready Site จาก Part I ให้มองฝั่ง production คือ source และฝั่ง backup คือ destination

โดยทั่วไปเมื่อเราเพิ่มฮาร์ดดิสก์เข้าไปบนเซิร์ฟเวอร์และใช้ระบบปฏิบัติการลีนุกซ์ จะมองเห็นเป็น device เช่น /dev/sda, /dev/sdb, /dev/sdc, … หรือ /dev/hda,/dev/hdb,/dev/hdc,… แล้วแต่ชนิดดิสก์และคอนโทรลเลอร์ ในดิสก์แต่ละลูกเมื่อมีการแบ่งพาร์ติชั่นจะมองเ็ห็นเป็น device เช่น /dev/sdb1, /dev/sdb2,.. /dev/sdc1, /dev/sdc2,…

เมื่อเรานำ DRBD เข้ามาใช้งาน เราจะต้อง config ให้ device ของ DRBD ชี้ไปยัง device ของดิสก์ที่เราใช้งานและ mount disk ด้วย device ของ DRBD แทนของเก่า

ตัวอย่าง 1: source เป็น fixed disk ขนาด 1TB

• สมมุติว่าดิสก์ดังกล่าวถูกลีนุกซ์ assign เป็น device ชื่อ /dev/sdb
• ตรวจสอบก่อนว่าดิสก์ดังกล่าวแบ่งพาร์ติชั่นไว้อย่างไร ใช้คำสั่ง “fdisk -l /dev/sdb” ช่วยในการตรวจสอบ
• สมมุติว่าดิสก์ดังกล่าวแบ่งไว้สองพาร์ติชั่นคือ /dev/sdb1 และ /dev/sdb2 โดย /dev/sdb1 มีขนาด 50 GB และ /dev/sdb2 มีขนาด 650GB, และ /dev/sdb2 ถูกฟอร์แมตไว้ให้เป็นรูปแบบ ext3  สำหรับเก็บข้อมูลส่วนที่เป็น data
• การหาดิสก์มาทำ destination สำหรับการ replicate ให้หาขนาดขั้นต่ำ 650GB หากต้องการ data เฉพาะส่วนที่อยู่ใน /dev/sdb2, ให้เผื่อขนาด meta-data ในการจัดเก็บของ DRBD ด้วย ซึ่งโดยประมาณ 128MB รองรับ data จริงได้ 4TB
• การกำหนดพาร์ติชั่นฝั่ง destination ให้กำหนดจำนวน block ของดิสก์ให้เท่ากันกับจำนวน block ของ /dev/sdb2 ฝั่ง source, ลำดับไม่สำคัญ เช่น เราอาจจะ replicate จาก /dev/sdb2 มา /dev/sdb3 ก็ได้ เพียงแต่ดิสก์ต้องมีจำนวน block เท่ากัน
• สามารถ replicate ดิสก์ทั้งลูกเลยก็ได้ คือมองเป็น device แค่ในระดับ /dev/sdb ไม่แยกเป็น /dev/sdb1, /dev/sdb2 ก็ได้ ในกรณีนี้ควรหาดิสก์ฝั่ง destination ที่มีขนาดเท่ากันเป๊ะๆ ถ้าหาไม่ได้ให้หาขนาดที่ใหญ่กว่าแล้วแบ่งพาร์ติชั่นให้จำนวน block เท่ากับฝั่งต้นฉบับ

ตัวอย่าง 2: source เป็น extended file system ขนาด 1TB

• บน Linux มี LVM ช่วยในการจัดการ file system แบบที่ย่อขนาดหรือขยายขนาดได้
• LVM จะช่วยย่อหรือขยายในระดับพาร์ติชั่นใช้คู่กับคำสั่งขยายในระดับ file system ขึ้นกับรูปแบบ file system ที่ใช้
• หลักๆ LVM ให้เข้าใจ 3 เรื่อง 1) PV– Physical Volume; เป็นระดับล่างสุด คือระดับของดิสก์แต่ละลูกที่เราจะเพิ่มหรือเอาออก 2) VG-Volume Group; เป็นระดับที่สูงขึ้นมา เป็นตัวกำหนดกลุ่มของดิสก์ 3) LV-Logical Volume; เป็นระดับบนสุด เป็นตัวที่เราจะเอาไป mount ใช้งาน, การสร้าง LV จะกำหนดเข้า VG เพื่อให้เป็นหมวดเป็นหมู่
• การ config ใช้ร่วมกับ DRBD ให้เอาระดับ LV ไปกำหนดครับ
• ใช้คำสั่ง “lvscan” ช่วยในการตรวจสอบขนาด
• ใช้คำสั่ง “lvextend” ช่วยในการปรับขนาดฝั่ง destination ให้เท่ากับฝั่ง source

DRBD Network-RAID1 Mirroring Part I

Introduction

DRBD เป็น open source ที่เขียนให้ทำงานในระดับ Linux kernel ใช้ในการ replicate ข้อมูลในดิสก์สองที่ให้เหมือนกัน การ replicate ทำแบบออนไลน์ในขณะที่โปรแกรมรันและใช้ไฟล์นั้นๆ อยู่ได้โดย DRBD ทำงานในระดับ block device, DRBD สปอนเซอร์โดยบริษัท LINBIT (http://www.drbd.org)

ขอแทนคำว่า server ด้วยคำว่า node นะครับ เมื่อเรา replicate ข้อมูลทั้ง 2 node ให้เท่ากันแล้ว การที่จะใช้งานได้แบบ node เดียวหรือทั้ง 2 node พร้อมๆ กันส่วนหนึ่งขึ้นอยู่กับระบบไฟล์ที่ใช้  ระบบไฟล์โดยทั่วไปที่ไม่ได้ออกแบบมาให้ทำงานแบบคลัสเตอร์จะใช้ได้แบบ node เดียว ระบบไฟล์แบบนี้เช่น ext3, ext4, xfs ส่วนระบบไฟล์ที่ออกแบบมาเพื่อใช้สำหรับคลัสเตอร์ เช่น gfs, gfs2 ระบบไฟล์แบบคลัสเตอร์นี้มีสิ่งที่เพิ่มเติมเข้ามาคือ “กลไกในการ lock” ใช้ควบคุมตอน write ข้อมูล ถ้าไม่มีตัวควบคุม เป็นไปได้ว่า node หนึ่งยังไม่ทัน write เสร็จ อีก node ทำการ write เข้ามาทับ ก็จะเกิดความสับสนขึ้นได้

node ที่สามารถใช้งานได้ DRBD เรียกว่า Primary ส่วน node ที่เป็น backup เรียกว่า Secondary เมื่อเป็น Primary ดิสก์จะสามารถได้ทั้งอ่านและเขียน ส่วน Secondary อย่างมากทำได้แค่การอ่าน

ใน Linux kernel ใหม่ๆ ตั้งแต่เวอร์ชั่น 2.6.33 ขึ้นไปจะมี DRBD ฝังมาให้ในตัวเลย ส่วนเวอร์ชั่นที่เก่ากว่านั้น สามารถลงได้เช่นกัน โดยเพิ่ม package ในส่วนของ kmod เข้าไป

 หลังจาก synchronize ข้อมูลจนเท่ากันในการทำงานครั้งแรก ในครั้งต่อๆ ไป ข้อมูลจะ replicate เฉพาะข้อมูลที่ update และสนใจเฉพาะข้อมูลที่เป็นการ write จึงทำให้ข้อมูลที่ส่งระหว่างกันใช้ bandwidth ของ network อย่างคุ้มค่า นอกจากนั้นการ replicate ยังเป็นแบบ 2 ทาง เมื่อเราใช้งานที่ backup node ข้อมูลก็จะถูกส่งกลับไปยัง node หลักได้ด้วย ในบทต่อๆ ไปจะมีรายละเอียดลงลึกถึงโปรโตคอลที่ใช้ในการ replicate

ตัวอย่างการประยุกต์ใช้

ทำ backup site แบบ DR-Ready:

• Mail System: replicate โปรแกรมและ data ของ Zimbra
• Database System: replicate ส่วน data ของ PostgreSQL
• Application Server: replicate โปรแกรมและ user data session ของ Tomcat

ถ้าใช้แพลทฟอร์ม Linux ในการรัน Application อยู่แล้ว DRBD ถือเป็นตัวช่วยในการทำ DR Site หรือ Disaster Recovery Site ให้เป็นแบบพร้อมใช้หรือเรียกหรูๆ หน่อยว่า DR-Ready Site ได้ในระดับหนึ่งเลยครับ