ด้วยระบบเสมือนจริงมันยังคงสมเหตุสมผลที่จะใช้จุดเชื่อมต่อหลายจุดหรือไม่


15

ในปี 2013 มันสมเหตุสมผลหรือไม่ที่ยังคงมีจุดเชื่อมต่อหลายจุดบนอิมเมจ Linux ใหม่หรือจัดสรรพื้นที่ทั้งหมดเพื่อให้เหมาะสม

ฉันต้องการหลีกเลี่ยงการเริ่มระบบใหม่เพื่อเพิ่มขนาดของจุดเชื่อมต่อ ฉันต้องการตรวจสอบพื้นที่ของเมาท์เดียว ฉันอยากจะรู้ว่าเซิร์ฟเวอร์ทั้งหมดมีการใช้พื้นที่ไดรฟ์มากกว่า 70% เทียบกับการเชื่อมต่อกับจุดเชื่อมต่อแต่ละจุด


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

คำตอบ:


17

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

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

ดังนั้นในระยะสั้นใช่ยังคงมีเหตุผลที่ดีสำหรับการทำเช่นนี้ในปี 2013


เครื่องจะยังคงพังหรือไม่แม้ว่า / var (หรือ / tmp) จะเต็มหรือไม่
onionjake

2
@onionjake ไม่ไม่จำเป็น แต่พวกเขาจะพังถ้า/เติมให้เต็ม
ewwhite

ขอขอบคุณที่ทราบเกี่ยวกับบันทึกที่ไม่สามารถควบคุมได้ VMs เฉพาะเหล่านี้ใช้ SAN ดังนั้นฉันเชื่อว่า IO ได้รับการเผยแพร่ไปแล้วและไม่ได้เป็นข้อกังวลสำหรับฉันในสถานการณ์เฉพาะนี้
Jeremy Mullin

นอกเหนือจากจุดนี้หากคุณต้องการให้ VM เดียวขยายหลายพูล VMFS ใน ESXi คุณจะต้องใช้ดิสก์เสมือนหลายตัว (ซึ่งปรากฏเป็นดิสก์ทางกายภาพกับ VM) คุณยังคงสามารถรวมสิ่งเหล่านี้ไว้ในจุดเมานท์เดียวกับ LVM ได้หากคุณต้องการจริงๆ
พอลเกียร์

5

ทุกวันนี้ฉันจะไม่ใช้เมานต์แยกกันมากเกินไป แต่อาจมีกุญแจสำคัญสองสามอันที่จะเป็นประโยชน์ในการบริหารระบบ

เพียง 2 หรือ 3 โดยเฉพาะ ด้วยขนาดที่แตกต่างกัน ขึ้นอยู่กับสิ่งที่คุณใช้ ฉันจะบอกแค่ / (ค่อนข้างคงที่) และ / var (เปลี่ยน) ขึ้นอยู่กับระบบปฏิบัติการและรูปทรงของดิสก์อาจจำเป็นต้องใช้ / boot / tmp มีแนวโน้มที่จะติดตั้ง tmpfs โดยตัวติดตั้ง

การเปลี่ยนแปลง (/ var ส่วนใหญ่ แต่อาจเป็นเพียง / var / log และ / var / lib / mysql ฯลฯ ) ปริมาณมักเป็นสิ่งที่คุณต้องกังวลเกี่ยวกับและวางแผนสำหรับการขยายตัว ดังนั้นถ้าเป็นไปได้ใช้ lvm เป็นต้นเพื่อทำให้การปรับขนาดง่ายขึ้น


1
ฉันใช้ LVM เป็นการส่วนตัวและการบู๊ตจะต้องอยู่ในพาร์ติชันของตัวเองไม่ใช่ส่วนหนึ่งของกลุ่มวอลุ่มที่ฉันเชื่อ (ถ้าคุณใช้ด้วงแบบดั้งเดิม)

4

ใช่ฉันยังคงใช้หลายพาร์ติชันบนเครื่องเสมือนและจุดยึดสำหรับตรวจสอบความปลอดภัยและความต้องการการบำรุงรักษา

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

(BTW ฉันไม่ชอบ LVM บนเครื่องเสมือน ... วางแผนได้ดีกว่า !! )

ในระบบของฉันฉันพยายามทำสิ่งต่อไปนี้:

  • / โดยทั่วไปจะมีขนาดเล็กและไม่เติบโตมาก
  • /boot สามารถคาดการณ์ได้ในขนาดและการเจริญเติบโตจะถูกควบคุมโดยความถี่ของการปรับปรุงเคอร์เนล
  • /tmpขึ้นอยู่กับแอปพลิเคชันและสภาพแวดล้อม แต่สามารถปรับขนาดได้อย่างเหมาะสม การตรวจสอบแยกต่างหากช่วยวัดพฤติกรรมที่ผิดปกติและปกป้องส่วนที่เหลือของระบบ
  • /usr ควรคาดเดาได้ประกอบด้วยไฟล์ปฏิบัติการ ฯลฯ
  • /varเพิ่มขึ้น แต่ปริมาณของข้อมูลปั่นป่วนอาจมีขนาดเล็กลง ยินดีที่ได้ทำการวัดแยกต่างหาก
  • และพาร์ทิชันการเจริญเติบโต ในกรณีนี้ก็/dataแต่ถ้าครั้งนี้มีระบบฐานข้อมูลก็อาจจะมี/var/lib/mysqlหรือ/var/lib/pgsql... /dev/sdbโปรดทราบว่ามันเป็นอุปกรณ์ป้องกันที่แตกต่างกัน นี่เป็นเพียง VMDK อื่นในเครื่องเสมือนนี้ดังนั้นจึงสามารถปรับขนาดได้อย่างอิสระจาก VMDK ที่มีพาร์ติชันระบบปฏิบัติการจริง

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              12G  2.5G  8.8G  23% /
tmpfs                 7.8G     0  7.8G   0% /dev/shm
/dev/sda1             291M  131M  145M  48% /boot
/dev/sda7             2.0G   68M  1.9G   4% /tmp
/dev/sda3             9.9G  3.5G  5.9G  38% /usr
/dev/sda6             6.0G  892M  4.8G  16% /var
/dev/sdb1             360G  271G   90G  76% /data

การแบ่งแยกบางส่วนของพาร์ติชั่นเหล่านี้ทำให้ง่ายต่อการระบุแนวโน้มและตรวจจับพฤติกรรมที่ผิดปกติ เช่น 4GB ทิ้งหลักใน/varกระบวนการที่หลักสี่/tmp,

ปกติ ป้อนคำอธิบายรูปภาพที่นี่

ผิดปกติ การเพิ่มขึ้นอย่างฉับพลันใน/varนั้นจะไม่ง่ายต่อการตรวจสอบหาก/มีการใช้พาร์ติชันขนาดใหญ่ ป้อนคำอธิบายรูปภาพที่นี่


เมื่อเร็ว ๆ นี้ฉันต้องใช้ค็อกเทลและพารามิเตอร์เมาท์ระบบแฟ้ม (nodev, nosuid, noexec, noatime, nobarrier) สำหรับเทมเพลต VM ที่เสริมความปลอดภัย การแบ่งพาร์ติชันเป็นข้อกำหนดที่แน่นอนสำหรับสิ่งนี้เนื่องจากพาร์ติชันบางตัวต้องการการตั้งค่าเฉพาะที่ไม่สามารถใช้ร่วมกันได้ จุดข้อมูลอื่น


2

แน่นอนว่าจุดเชื่อมต่อหลายจุดยังคงมีข้อได้เปรียบคือเซิร์ฟเวอร์เสมือนจริงหรือไม่

แต่ด้วยการจำลองเสมือนคุณอาจใช้เทมเพลตเครื่องเสมือนใช่ไหม และระบบตรวจสอบของคุณเช่น Nagios (พร้อม NConf?) ก็รองรับเทมเพลตด้วยหรือไม่ ถ้าเป็นเช่นนั้นคุณต้องผ่านการต่อสู้ในจุดที่จิตนี้เพียงครั้งเดียว

กลับไปที่หัวข้อ

ผมใช้ในการแยกระบบของฉันด้วยวิธีนี้: /, /home, /usr, /var, /tmp(และอาจจะบางจุดอื่น ๆ สำหรับข้อมูลการติด) แต่นั่นก็เป็น overkill และยุ่งยาก ทุกวันนี้อิมเมจระบบปฏิบัติการที่เรียบง่ายมีเพียงอย่างเดียว/บางทีอาจจะมีวิธีแยก/varสำหรับฉัน ถ้าเซิร์ฟเวอร์เสมือนต้องการพื้นที่เก็บข้อมูลเพิ่มเติมฉันก็จะให้อิมเมจดิสก์อีกอันสำหรับมันแล้วติดตั้งทุกที่ที่ต้องการ


คุณจะตรวจสอบปัญหาในการพูด/optหรือ/tmpภายใต้การตั้งค่าพาร์ทิชันเดียวได้อย่างไร
ewwhite

หากเซิร์ฟเวอร์เริ่มกินเนื้อที่ดิสก์อย่างรวดเร็วสิ่งที่คล้ายกันdu -m --max-depth=4 / | sort -nr | head -n 30 | lessนั้นมีประสิทธิภาพอย่างน่าประหลาดใจ และในการควบคุม สภาพแวดล้อมที่ถูกตรวจสอบคุณมีสถานที่ที่เป็นไปได้จำนวนเท่าใดสำหรับสิ่งประเภทนี้ /var/log, /tmp, /opt/*/logบางทีสิ่งอื่นใด ไม่ยากเกินไป
Janne Pikkarainen

1

สำหรับไฟล์เซิร์ฟเวอร์ฉันก็มักจะเมานต์วอล/homeลุ่มบนพาร์ติชั่น / ดิสก์ของตัวเองและใช้noexecตัวเลือกเมื่อทำการติดตั้ง ความหวาดระแวง แต่ป้องกันไม่ให้ผู้ใช้เรียกใช้ไฟล์จากภายในโฮมโฟลเดอร์

เช่นกันฉันมักจะวาง/bootโวลุ่มบนกระจกเงา RAID 1 ในไดรฟ์ทั้งหมด แต่อีกครั้งฉันควรปฏิบัติตามแบบเก่าที่ฉันไม่เห็นข้อเสีย


1
คำถามเกี่ยวกับเซิร์ฟเวอร์เสมือนดังนั้นบิตเกี่ยวกับ / boot บน RAID 1 จึงไม่สามารถใช้งานได้ แต่เป็นความคิดที่ดีสำหรับเซิร์ฟเวอร์จริง
พอลเกียร์
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.