เราได้รับสวิตช์ 8Gb คู่ใหม่สำหรับผ้าแชนเนลไฟเบอร์ของเรา นี่คือสิ่งที่ดีเนื่องจากเราไม่มีพอร์ตในดาต้าเซ็นเตอร์หลักของเราและมันจะช่วยให้เรามี ISL 8Gb อย่างน้อยหนึ่งตัวที่ทำงานอยู่ระหว่างดาต้าเซ็นเตอร์สองตัวของเรา
ศูนย์ข้อมูลสองแห่งของเราห่างกันประมาณ 3.2 กม. ขณะที่เส้นใยวิ่ง เราได้รับบริการ 4Gb ที่มั่นคงเป็นเวลาสองสามปีแล้วและฉันหวังเป็นอย่างยิ่งว่าจะสามารถสนับสนุน 8Gb ได้เช่นกัน
ขณะนี้ฉันกำลังหาวิธีกำหนดค่าโครงสร้างของเราใหม่เพื่อยอมรับสวิตช์ใหม่เหล่านี้ เนื่องจากการตัดสินใจเรื่องค่าใช้จ่ายเมื่อสองสามปีก่อนเราไม่ได้ใช้ผ้าสองวงแยกกันอย่างสมบูรณ์ ค่าใช้จ่ายของความซ้ำซ้อนเต็มรูปแบบถูกมองว่ามีราคาแพงกว่าการหยุดทำงานที่ไม่น่าจะเกิดจากความล้มเหลวของสวิตช์ การตัดสินใจนั้นทำก่อนเวลาของฉันและตั้งแต่นั้นสิ่งต่าง ๆ ก็ไม่ได้ดีขึ้นมาก
ฉันต้องการใช้โอกาสนี้เพื่อทำให้เนื้อผ้าของเรามีความยืดหยุ่นมากขึ้นเมื่อเผชิญกับความล้มเหลวของสวิตช์ (หรือการอัพเกรด FabricOS)
นี่คือแผนภาพของสิ่งที่ฉันกำลังคิดสำหรับการจัดวาง รายการสีน้ำเงินเป็นรายการใหม่รายการสีแดงคือลิงค์ที่มีอยู่ซึ่งจะถูกย้าย (อีกครั้ง)
(ที่มา: sysadmin1138.net )
เส้นลูกศรสีแดงคือลิงค์ของสวิตช์ ISL ปัจจุบัน ISL ทั้งสองมาจากสวิตช์เดียวกัน ขณะนี้ EVA6100 เชื่อมต่อกับสวิตช์ 16/4 ทั้งสองที่มี ISL สวิตช์ใหม่จะช่วยให้เรามีสวิตช์สองตัวใน DC ระยะไกลหนึ่งใน ISL ระยะยาวกำลังเคลื่อนที่ไปยังสวิตช์ใหม่
ข้อดีของการทำเช่นนี้คือแต่ละสวิตช์ไม่เกิน 2 กระโดดจากสวิตช์อื่นและทั้งสองรุ่นของ EVA4400 ซึ่งจะอยู่ในความสัมพันธ์ของการจำลองแบบ EVA คือ 1 กระโดดจากกันและกัน EVA6100 ในแผนภูมิเป็นอุปกรณ์รุ่นเก่าที่จะถูกแทนที่ในที่สุดอาจเป็นรุ่น EVA4400 อีกเครื่อง
ครึ่งล่างของแผนภูมิเป็นจุดที่เซิร์ฟเวอร์ส่วนใหญ่ของเราอยู่และฉันมีความกังวลเกี่ยวกับตำแหน่งที่แน่นอน สิ่งที่ต้องเข้าไปที่นั่น:
- 10 โฮสต์ VMWare ESX4.1
- เข้าถึงทรัพยากรบน EVA6100
- 4 เซิร์ฟเวอร์ Windows Server 2008 ในหนึ่งคลัสเตอร์ล้มเหลว (คลัสเตอร์ไฟล์เซิร์ฟเวอร์)
- เข้าถึงทรัพยากรทั้ง EVA6100 และ EVA4400 ระยะไกล
- 2 เซิร์ฟเวอร์ Windows Server 2008 ในคลัสเตอร์ที่ล้มเหลวครั้งที่สอง (เนื้อหา Blackboard)
- เข้าถึงทรัพยากรบน EVA6100
- 2 เซิร์ฟเวอร์ฐานข้อมูล MS-SQL
- เข้าถึงทรัพยากรบน EVA6100 ด้วยการส่งออกฐานข้อมูลรายคืนไปยัง EVA4400
- 1 เทปไลบรารี LTO4 ที่มีเทปไดร์ฟ LTO4 2 ตัว แต่ละไดรฟ์จะได้รับพอร์ตไฟเบอร์ของตัวเอง
- เซิร์ฟเวอร์สำรอง (ไม่ใช่ในรายการนี้) สปูลให้พวกเขา
ในขณะที่คลัสเตอร์ ESX สามารถทนได้ถึง 3 หรือ 4 อาจโฮสต์จะลงก่อนที่เราจะต้องเริ่มต้นปิด VMs สำหรับพื้นที่ มีความสุขทุกอย่างที่เปิด MPIO
ลิงก์ 4GL ISL ปัจจุบันยังไม่ได้ใกล้เคียงกับความอิ่มตัวที่ฉันสังเกตเห็น นั่นอาจเปลี่ยนแปลงได้ด้วยการจำลองแบบสองแบบของ EVA4400 แต่อย่างน้อยหนึ่งใน ISL จะเป็น 8Gb ดูประสิทธิภาพที่ฉันได้รับจาก EVA4400-A ฉันมั่นใจมากว่าแม้จะมีการจำลองแบบทราฟฟิกเราก็จะมีช่วงเวลาที่ยากลำบากในการข้ามสาย 4Gb
คลัสเตอร์ที่ให้บริการไฟล์ 4 โหนดสามารถมีสองโหนดบน SAN1SW4 และสองบน SAN1SW1 เนื่องจากจะทำให้ทั้งสองอาร์เรย์เก็บข้อมูลหนึ่ง hop ออกไป
โหนด ESX ทั้ง 10 ตัวที่ฉันค่อนข้างหัวไม่ค่อยดี สามใน SAN1SW4 สามใน SAN1SW2 และสี่ใน SAN1SW1 เป็นตัวเลือกและฉันสนใจมากที่จะได้ยินความคิดเห็นอื่น ๆ ในรูปแบบ ส่วนใหญ่มีการ์ด FC แบบดูอัลพอร์ตดังนั้นฉันจึงสามารถรันสองสามโหนดได้ ไม่ใช่ของพวกเขาทั้งหมดแต่เพียงพอที่จะอนุญาตให้สวิตช์เดี่ยวล้มเหลวโดยไม่ฆ่าทุกสิ่ง
กล่อง MS-SQL สองกล่องจำเป็นต้องใช้กับ SAN1SW3 และ SAN1SW2 เนื่องจากต้องอยู่ใกล้กับที่เก็บข้อมูลหลักและประสิทธิภาพในการส่งออกของ db มีความสำคัญน้อยกว่า
ขณะนี้ไดรฟ์ LTO4 อยู่บน SW2 และ 2 hops จากลำแสงหลักของพวกเขาดังนั้นฉันจึงรู้แล้วว่ามันทำงานอย่างไร สิ่งเหล่านั้นสามารถอยู่บน SW2 และ SW3
ฉันไม่ต้องการให้ครึ่งล่างของแผนภูมิเป็นโทโพโลยีที่เชื่อมต่อเต็มที่ซึ่งจะช่วยลดจำนวนพอร์ตที่เราใช้งานได้จาก 66 เป็น 62 และ SAN1SW1 จะเป็น 25% ISL แต่ถ้าแนะนำอย่างยิ่งฉันสามารถไปเส้นทางนั้นได้
อัปเดต: หมายเลขประสิทธิภาพบางอย่างที่อาจมีประโยชน์ ฉันมีพวกเขาฉันแค่เว้นระยะที่พวกเขามีประโยชน์สำหรับปัญหาแบบนี้
EVA4400-A ในแผนภูมิด้านบนทำสิ่งต่อไปนี้:
- ระหว่างวันทำงาน:
- I / O มีค่าเฉลี่ยต่ำกว่า 1,000 ด้วย spikes ถึง 4500 ระหว่างสแนปชอตของเซิร์ฟเวอร์ไฟล์ ShadowCopy snapshots (ใช้เวลาประมาณ 15-30 วินาที)
- MB / s โดยทั่วไปอยู่ในช่วง 10-30MB โดยมี spikes สูงถึง 70MB และ 200MB ในระหว่าง ShadowCopies
- ในตอนกลางคืน (สำรอง) คือเมื่อมันเหยียบอย่างรวดเร็ว:
- I / O ใช้งานโดยเฉลี่ยประมาณ 1,500 ด้วย spikes สูงถึง 5500 ในระหว่างการสำรองฐานข้อมูล
- MB / s แตกต่างกันมาก แต่ทำงานประมาณ 100MB เป็นเวลาหลายชั่วโมงและปั๊ม 300MB / s ที่น่าประทับใจประมาณ 15 นาทีในระหว่างกระบวนการส่งออก SQL
EVA6100 มีงานยุ่งมากขึ้นเนื่องจากเป็นที่ตั้งของคลัสเตอร์ ESX, MSSQL และสภาพแวดล้อม Exchange 2007 ทั้งหมด
- ในระหว่างวันที่ I / O มีค่าเฉลี่ยประมาณ 2000 โดยมี spikes บ่อยมากถึงประมาณ 5000 (กระบวนการฐานข้อมูลเพิ่มเติม) และค่าเฉลี่ย MB / s ระหว่าง 20-50MB / s Peak MB / s เกิดขึ้นระหว่างสแน็ปช็อต ShadowCopy บนคลัสเตอร์ที่ให้บริการไฟล์ (~ 240MB / s) และอยู่ได้ไม่ถึงหนึ่งนาที
- ในช่วงกลางคืน Exchange Online Defrag ที่รันตั้งแต่ 1am ถึง 5am ปั๊ม I / O Ops ไปที่บรรทัดที่ 7800 (ใกล้กับความเร็วปีกสำหรับการเข้าถึงแบบสุ่มด้วยจำนวนสปินเดิลนี้) และ 70MB / s
ฉันขอขอบคุณคำแนะนำใด ๆ ที่คุณอาจมี
