VMware VMFS5 และ LUN sizing - หลายดาต้าสโตร์ที่เล็กกว่าหรือ 1 ดาต้าสโตร์ใหญ่?


10

ด้วย VMFS5 ไม่มีขีด จำกัด 2TB สำหรับปริมาตร VMFS อีกต่อไปฉันกำลังพิจารณาสถานการณ์ที่จะเป็นประโยชน์โดยรวมมากขึ้น: -

  • LUN ที่น้อยกว่าที่มีขนาดใหญ่กว่าหรือ
  • LUN เพิ่มเติมที่มีขนาดเล็กกว่านี้

ในกรณีของฉันฉันมีอาร์เรย์หน่วยเก็บข้อมูล 24- ดิสก์ใหม่ที่มีดิสก์ 600GB ฉันจะใช้ RAID10 ขนาด 7.2TB คร่าวๆและพยายามตัดสินใจว่าจะใช้ดาต้าสโตร์ขนาดใหญ่ 1TB หรือ 1 ร้านค้าจำนวนมากที่ 1TB แต่ละแห่ง

ข้อดีและข้อเสียของแต่ละวิธีคืออะไร

อัปเดต : แน่นอนฉันไม่สนใจที่จะรวมอะไหล่ที่ร้อนแรงในการคำนวณของฉันดังนั้นมันจึงต่ำกว่า 7.2TB แต่แนวคิดทั่วไปก็เหมือนกัน :-)

อัปเดต 2 : มี 60 VMs และ 3 โฮสต์ ไม่มี VMs ของเราโดยเฉพาะอย่างยิ่ง I / O ที่เข้มข้น ส่วนใหญ่เป็นเว็บเซิร์ฟเวอร์ / แอปและยังมีสิ่งต่าง ๆ เช่นการตรวจสอบ (munin / nagios), Windows DC 2 เครื่องที่มีโหลดน้อยที่สุดและอื่น ๆ เซิร์ฟเวอร์ DB นั้นแทบจะไม่ได้อยู่ในสภาพเสมือนจริงเว้นแต่ว่าพวกเขาจะมีความต้องการ I / O ต่ำมาก ตอนนี้ฉันคิดว่าเซิร์ฟเวอร์ฐานข้อมูลเสมือนเดียวที่เรามีคือกล่อง MSSQL และฐานข้อมูลในกล่องนั้นคือ <1GB

อัปเดต 3 : ข้อมูลเพิ่มเติมเกี่ยวกับการเชื่อมต่ออาร์เรย์และ FC อาร์เรย์เป็นตัวควบคุม IBM DS3524, 2 ตัวพร้อมแคช 2GB พอร์ต FC 8Gbit 4x ต่อตัวควบคุม โฮสต์ ESXi แต่ละแห่งมี HBA แบบ 4G 4G 2 เท่า


1
คุณได้รับอนุญาตให้ใช้ StorageDRS หรือไม่
Chopper3

@ Chopper3: ขณะนี้เรามีใบอนุญาตองค์กรทั่วไปไม่ใช่ Plus ดังนั้นจึงไม่มี StorageDRS ในขณะนี้
ThatGraemeGuy

@ThatGraemeGuy การแก้ไขนี้คืออะไร?
ewwhite

@ ขาว: เศร้าฉันจำไม่ได้ เมื่อไม่นานมานี้และฉันได้ออกจากงานไปหนึ่งปีแล้ว :-( ฉันจำได้ไม่ชัดเจนว่าการสร้างที่เก็บข้อมูล VMFS ขนาดเท่า ๆ กัน 4 ตัวต่ออาร์เรย์ 24 ดิสก์และฉันรู้ว่าเราไม่มีปัญหา I / O เลยหลังจากย้ายไปยังอาร์เรย์ใหม่ FWIW
ThatGraemeGuy

คำตอบ:


4

คุณไม่ได้ระบุจำนวน VM ที่คุณมีหรือสิ่งที่พวกเขากำลังจะทำ แม้จะไม่มีข้อมูลนั้นฉันก็หลีกเลี่ยงที่จะสร้าง LUN อันยิ่งใหญ่เพื่อเหตุผลในการบล็อกขนาด / ประสิทธิภาพการแข่งขันและความยืดหยุ่น


2

ฉันจะสมมติว่าคุณกำลังจะทำเวอร์ชวลเซิร์ฟเวอร์ไม่ใช่เดสก์ท็อปใช่ไหม? ต่อไปฉันจะสมมติว่าคุณกำลังจะใช้เซิร์ฟเวอร์ ESX / ESXi หลายเครื่องเพื่อเข้าถึงที่เก็บข้อมูลของคุณและให้พวกเขาจัดการโดย vCenter Server

เมื่อตัดสินใจเลือกขนาด LUN และจำนวนของ VMFS คุณจะต้องปรับสมดุลหลายปัจจัย: ประสิทธิภาพความยืดหยุ่นในการกำหนดค่าและการใช้ทรัพยากร

คุณสามารถรับประสิทธิภาพที่ดีที่สุดด้วยการจับคู่ 1 VM ถึง 1 LUN / VMFS ไม่มีการแข่งขันระหว่างเครื่องจักรบน VMFS เดียวกันไม่มีการช่วงชิงล็อกการโหลดแต่ละครั้งจะถูกแยกและทั้งหมดคือ goood ปัญหาคือว่าคุณจะจัดการ LUNs ในปริมาณที่ไม่ดีอาจได้รับการสนับสนุนขีด จำกัด สูงสุดปวดหัวกับการปรับขนาดและการโยกย้าย VMFS มีการใช้ทรัพยากรน้อยกว่าขีด จำกัด (พื้นที่ว่างในจุดเดียวบน VMFS เพิ่มขึ้น) จัดการไม่ดี

อีกอย่างหนึ่งคือ VMFS ขนาดใหญ่ตัวหนึ่งที่ได้รับมอบหมายให้โฮสต์ทุกอย่าง คุณจะได้รับการใช้ทรัพยากรที่ดีที่สุดด้วยวิธีนี้จะไม่มีปัญหาในการตัดสินใจว่าจะปรับใช้ตำแหน่งใดและปัญหาใดกับ VMFS X ซึ่งเป็นจุดที่น่าสนใจในขณะที่ VMFS Y กำลังทำงานอยู่ ต้นทุนจะเป็นประสิทธิภาพโดยรวม ทำไม? เพราะการล็อค เมื่อ ESX หนึ่งเขียนไปยัง VMFS ที่กำหนดไว้อื่น ๆ จะถูกล็อคออกไปตามเวลาที่ใช้ในการทำให้ IO สมบูรณ์และต้องลองใหม่ ค่าใช้จ่ายนี้มีประสิทธิภาพ นอกสนามเด็กเล่น / ทดสอบและพัฒนาสภาพแวดล้อมมันเป็นวิธีการที่ไม่ถูกต้องในการกำหนดค่าการจัดเก็บ

วิธีปฏิบัติที่ได้รับการยอมรับคือการสร้างดาต้าสโตร์ขนาดใหญ่พอที่จะโฮสต์ VMs จำนวนหนึ่งและแบ่งพื้นที่เก็บข้อมูลที่มีอยู่ให้เป็นชิ้นขนาดที่เหมาะสม จำนวน VMs นั้นขึ้นอยู่กับ VMs คุณอาจต้องการฐานข้อมูลการผลิตที่สำคัญเพียงหนึ่งหรือสองอย่างบน VMFS แต่อนุญาตให้มีเครื่องทดสอบและพัฒนาสามหรือสี่โหลลงในที่เก็บข้อมูลเดียวกัน จำนวน VMs ต่อ datastore ยังขึ้นอยู่กับฮาร์ดแวร์ของคุณ (ขนาดดิสก์, rpm, แคชของคอนโทรลเลอร์, ฯลฯ ) และรูปแบบการเข้าถึง (สำหรับระดับประสิทธิภาพที่กำหนดคุณสามารถโฮสต์เว็บเซิร์ฟเวอร์บน VMFS เดียวกันได้มากกว่าเซิร์ฟเวอร์เมล)

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

อีกอย่างหนึ่ง: เมื่อสร้างดาต้าสโตร์เหล่านั้นให้เป็นมาตรฐานในขนาดบล็อกเดียว มันลดความซับซ้อนของหลายสิ่งในภายหลังเมื่อคุณต้องการทำบางสิ่งระหว่างดาต้าสโตร์และดูข้อผิดพลาด "ไม่เข้ากัน" ที่น่าเกลียด

อัปเดต : DS3k จะมีตัวควบคุมแอคทีฟ / พาสซีฟ (เช่น LUN ใดก็ตามที่สามารถให้บริการได้โดยคอนโทรลเลอร์ A หรือ B การเข้าถึง LUN ผ่านการควบคุมที่ไม่ใช่เจ้าของจะได้รับการลงโทษ) ดังนั้นมันจะจ่ายเป็นจำนวน LUNs อย่างสม่ำเสมอระหว่างตัวควบคุม

ฉันสามารถจินตนาการเริ่มต้นด้วย 15 VMs / LUN ด้วยพื้นที่ที่จะเติบโตถึง 20 หรือดังนั้น


มีความขัดแย้งกันมากน้อยกว่ากับ VMFS5 มากกว่า แต่ก่อน
Chopper3

เพิ่มข้อมูลเพิ่มเติมเกี่ยวกับ VMs และระบบจัดเก็บข้อมูล
ThatGraemeGuy

1

คำตอบสั้น ๆ สำหรับคำถามของคุณคือทุกอย่างขึ้นอยู่กับรูปแบบ IO ของคุณและสิ่งนี้จะไม่ซ้ำกับสภาพแวดล้อมของคุณ

ฉันขอแนะนำให้คุณดูที่นี่http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/เนื่องจากอาจช่วยให้คุณพิจารณา IOPS ที่คาดการณ์ไว้และจำนวน LUNS ที่เหมาะสม ที่กล่าวว่าหากคุณทำผิดด้านความระมัดระวังบางคนจะแนะนำให้มี LUNS จำนวนมาก (หากการแก้ไขของฉันสำหรับคำตอบก่อนหน้านี้ได้รับการอนุมัติให้ดูความคิดเห็นของฉันอีกครั้ง LUN IO เข้าแถวด้านอาร์เรย์) ฉันมักจะเห็นด้วย แต่จะไปไกลกว่านั้นรวมเข้าด้วยกันเป็นโวลุ่ม VMFS เดียว / ไม่กี่ (ไม่เชื่อ FUD เกี่ยวกับขอบเขตและข้อ จำกัด VMFS อื่น ๆhttp://virtualgeek.typepad.com/virtual_geek/2009/03 /vmfs-best-practices-and-counter-fud.html) สิ่งนี้จะมีประโยชน์ในการจัดการดาต้าสโตร์เดี่ยว / ไม่กี่ภายใน vSphere และเนื่องจาก vSphere จะทำการปรับยอด VM ให้โดยอัตโนมัติผ่านส่วนขยายที่มีให้โดยเริ่มต้นด้วยบล็อกแรกของแต่ละขอบเขตประสิทธิภาพการทำงานจะกระจาย IO ของคุณผ่าน LUN หลายตัว

อย่างอื่นที่ต้องพิจารณา ... คุณบอกว่าไม่มี VM ใดที่ใช้ IO อย่างเข้มข้น เมื่อพิจารณาสิ่งนี้คุณอาจต้องการพิจารณาการรวมกันของ RAID5 และ RAID10 เพื่อให้ได้ประโยชน์สูงสุดจากทั้งสองโลก (พื้นที่และความเร็ว)

นอกจากนี้หากคุณกำหนดค่า VM ของคุณด้วยหลาย VMDK ด้วยรูปแบบ OS และแอปพลิเคชั่น IO แผ่กระจายไปทั่วดิสก์เสมือนเหล่านั้น (เช่น OS, เว็บ, ฐานข้อมูล, บันทึก ฯลฯ ในแต่ละ VMDK แยกต่างหาก) คุณสามารถค้นหาแต่ละ VMDK บน ที่เก็บข้อมูลอื่นเพื่อจับคู่ความสามารถ IO ของ LUN ทางกายภาพนั้น (เช่น OS บน RAID5, บันทึกบน RAID10) ทั้งหมดนี้เกี่ยวกับการรักษารูปแบบ IO ที่คล้ายกันเพื่อใช้ประโยชน์จากพฤติกรรมเชิงกลของดิสก์ต้นแบบเพื่อให้ตัวอย่างเช่นการเขียนบันทึกใน VM หนึ่งจะไม่ส่งผลกระทบต่ออัตราการอ่านเว็บของคุณใน VM อื่น

FYI ... คุณสามารถจำลองเซิร์ฟเวอร์ฐานข้อมูลได้สำเร็จคุณเพียงแค่ต้องวิเคราะห์รูปแบบ IO และอัตรา IOPS และกำหนดเป้าหมายที่ IO ให้เป็น LUN ที่เหมาะสม ทั้งหมดในขณะที่ตระหนักถึงรูปแบบ IO และ IOPS ที่ LUN กำลังทำอยู่ นี่คือเหตุผลที่ผู้ดูแลระบบหลายคนกล่าวโทษ virtualiseation สำหรับประสิทธิภาพของฐานข้อมูลที่แย่ ... เพราะพวกเขาไม่ได้คำนวณ IO / IOPS อย่างรอบคอบว่าเซิร์ฟเวอร์หลายเครื่องจะสร้างเมื่อพวกเขาวางไว้บน LUN ที่ใช้ร่วมกัน (นั่นคือความผิดของผู้ดูแลระบบ )


0

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


0

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

ตัวอย่างเช่นหากคุณมี LUN เพียงรายการเดียวคุณจะใช้คอนโทรลเลอร์ที่ใช้งานได้ครั้งละหนึ่งตัวเท่านั้น คนอื่น ๆ จะนั่งเฉยๆเหมือนไม่มีอะไรทำ

หากคุณมี LUN สองตัว แต่ตัวหนึ่งมีธุระยุ่งกว่าตัวอื่น ๆ คุณจะใช้ตัวควบคุมทั้งสอง แต่ไม่เท่ากัน เมื่อคุณเพิ่ม LUN เพิ่มเติมตัวควบคุมจะแบ่งใช้ปริมาณงานที่เท่ากัน

คำแนะนำเฉพาะสำหรับคุณ:

VMs ของคุณนั้นค่อนข้างเหมือนกันในแง่ของข้อกำหนดด้านประสิทธิภาพ ฉันจะสร้าง LUN สองอันต่อหนึ่งตัวควบคุม เริ่มต้นวาง VM บน LUN แรกและวัดเวลาแฝง I / O และความลึกของคิวเมื่อเวลาผ่านไปตามที่ VM กำหนดไว้อย่าใช้ LUN ตัวที่สอง เติม LUN ต่อไป 1. คุณจะไปถึงจุดที่คุณเริ่มเห็นตัวบ่งชี้ประสิทธิภาพว่า LUN เต็มหรือคุณจะย้ายครึ่งหนึ่งของ VM ไปยัง LUN นั้นและยังคงรักษาประสิทธิภาพไว้

หากคุณเห็นปัญหาเกี่ยวกับประสิทธิภาพการทำงานฉันจะลบ 30% ของ VM ออกจาก LUN 1 และย้ายไปที่ LUN 2 จากนั้นเริ่มเติม LUN 2 ในลักษณะเดียวกัน ไปที่ LUN 3 หากจำเป็น ... นั่นสมเหตุสมผลไหม แนวคิดคือเพื่อให้ได้ความหนาแน่น VM สูงสุดบน LUN ที่กำหนดพร้อมกับค่าใช้จ่ายประมาณ 30% สำหรับห้องเหลวไหล

ฉันจะสร้าง LUN "ประสิทธิภาพสูง" คู่หนึ่งสำหรับ VM ที่มีการกดปุ่มสูง อีกครั้งหนึ่งต่อตัวควบคุมเพื่อแบ่งปันภาระงาน


-1

จากคำอธิบายของคุณข้างต้นคุณควรใช้ได้ 1 datastore 60 vm มากกว่า 3 ไพร่พลนั้นไม่เลวเลย (20: 1) อย่างไรก็ตามฉันขอแนะนำให้คุณอัปเกรด HBA เป็น 8Gb หากเป็นไปได้ทางการเงินในโฮสต์อย่างน้อยหนึ่งโฮสต์หากสวิตช์ไฟเบอร์ของคุณเป็นสวิตช์ 8Gb อย่างน้อยที่สุด

ที่ถูกกล่าวว่าฉันจะทำอย่างน้อย 2 ถ้าไม่ใช่ 3 datastores ในอาร์เรย์ 1 ที่เก็บข้อมูลต่อโฮสต์โดยที่เซิร์ฟเวอร์ทั้งหมดเข้าถึงผู้อื่นสำหรับ vMotion ฉันไม่รู้เกี่ยวกับอาเรย์ของ IBM มากนัก ด้วย EMC ฉันจะสร้าง RAID10 กลุ่มเดียวที่มี 3 LUNs สำหรับแต่ละที่เก็บข้อมูล ด้วยการตั้งค่านี้โฮสต์ที่มี HBA 8Gb จะยอดเยี่ยมสำหรับระบบ I / O ที่สูงขึ้นของคุณ

คุณสามารถทำได้ 1 ดาต้าสโตร์ / เซิร์ฟเวอร์และมีบางกรณีที่ฉันทำด้วยตัวเอง แต่ฉันทำได้เฉพาะกับการจำลองแบบ SAN บนเซิร์ฟเวอร์พิเศษ การจัดการ 87 ดาต้าสโตร์ที่แตกต่างกันมากกว่า 9 เซิร์ฟเวอร์สำหรับ vMotion ทำให้สับสนเมื่อคุณตั้งค่า! vm ของฉันส่วนใหญ่อยู่ใน datastores ที่ใช้ร่วมกันกับเซิร์ฟเวอร์ 5-10 ตัวขึ้นอยู่กับว่าพวกเขาต้องการพื้นที่เท่าใด

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


2
ฉันมีเวลายากที่เชื่อว่า OP จะต้องการแบนด์วิดท์มากกว่า 2x4Gb หรือแม้แต่ 1x 4Gb คุณช่วยอธิบายได้ไหมว่าเพราะเหตุใดการอัพเกรดนี้จึงคุ้มค่านอกเหนือจาก "มากกว่าจะดีกว่าเสมอ" นอกจากนี้การสร้างดาต้าสโตร์ 3 ชุดจะให้ความรู้สึกที่ดี แต่การพูดว่า "หนึ่งต่อโฮสต์" นั้นสร้างความสับสน มิฉะนั้นคุณจะไม่สามารถใช้การจัดเก็บ vMotion, vMotion หรือ HA ...
เจเรมี

ฉันไม่ได้พูดเพิ่ม 8Gb ทั่วกระดานอย่างที่ฉันบอกว่ามันเป็นคำแนะนำที่ไม่จำเป็น 2x4Gb นั้นยอดเยี่ยมและฉันจะไม่ทำ 1x4Gb เพียงเพราะคุณต้องการเส้นทางที่ซ้ำซ้อน การมีไว้ในที่เดียวช่วยให้สามารถขยายไปสู่ระบบ I / O ที่สูงขึ้นได้ Heck ฉันกำลังเรียกใช้ระบบแลกเปลี่ยนของเราด้วย 2x4Gb HBA's แต่พวกเขามีเพียง 3-4 VM ต่อโฮสต์
ARivera3483
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.