คุณจะโน้มน้าวให้ฝ่ายบริหารจัดการว่า 3560/3750 เป็นความคิดที่ไม่ดีใน DC ของคุณได้อย่างไร?

3560 / 3750s มีบัฟเฟอร์ขนาดเล็กและสร้างสวิตช์สายไฟที่ดี อย่างไรก็ตามฉันมักจะเห็นสวิตช์เหล่านี้นั่งอยู่ใน DC คนจำนวนมากมักจะใช้พวกเขาเนื่องจากพวกเขาโดยทั่วไป 1Gb และ L3 สามารถ

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

FWIW ฉันมีประสบการณ์กับ 3750 (3750G และต่อมา 3750E / 3560E) ในระดับการตั้งค่า TOR; เริ่มแรกด้วย L2 พอร์ต - แชนเนล / GLBP (ตัวแปร 2x1G และ 2x2G และ 2x4G หายากสำหรับแร็ค db) จากนั้นด้วย L3 ถึง TOR (ไปด้วย 3750E / 3560E และ 10G ไปยังแกน) ฉันกำลังพูดถึงพวกเขาหลายพันคน เราเห็นปัญหากับบัฟเฟอร์สำหรับบริการที่ใช้แบนด์วิดท์มากที่สุดเท่านั้นและ ณ จุดนั้นเรากำลังมองหาโฮสต์ 10G ต่อไป (และกล่องพิซซ่าที่หนาแน่นด้วย 24-48 SFP +)

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

ฝ่ายบริหารต้องการเห็นข้อมูลและหากคุณไม่มีทรัพยากรในการทดสอบอย่างเต็มที่กล่อง (มาพร้อมกับแผนการทดสอบให้เชื่อมต่อกับฮาร์ดแวร์รุ่นการรับส่งข้อมูลบางส่วนขอบเขตอย่างเต็มที่และทดสอบความเครียดกับข้อมูลจำเพาะการออกแบบ ฯลฯ ) สิ่งนี้จะยากที่จะทำ พวกเขาจะไม่ประทับใจกับหลักฐานพอสมควรและการหาข้อมูลประเภทนี้อาจพิสูจน์ได้ยากเนื่องจากฉันแน่ใจว่าผู้เผยแพร่สิ่งนี้จะละเมิด NDA ทุกประเภท

ทุกคนที่โพสต์คำตอบนี้ได้สรุป "ปัญหาพื้นที่" ของแพลตฟอร์ม 3750: การซ้อนและโหมดความล้มเหลวแปลก ๆ โดยธรรมชาติขนาดบัฟเฟอร์ ฯลฯ นอกจากนี้ยังมีคำถามนี้ที่สรุปปัญหาเกี่ยวกับการรวบรวมสถิติ SNMP บนคิวเอาต์พุต - บัฟเฟอร์มีการแชร์ข้าม ASIC ดังนั้นสถิติใด ๆ ที่คุณได้รับผ่าน SNMP จะเหมือนกันสำหรับช่วงพอร์ตเฉพาะ (ซึ่งอาจเป็นจุดผสานที่คุณสามารถจัดการกับห่วงโซ่การจัดการของคุณ)

เพื่อสรุปฉันจะบอกว่า 3750/3560 จะ "ดี" สำหรับการใช้งานส่วนใหญ่แม้ในระดับที่ค่อนข้างใหญ่ หลีกเลี่ยงการเรียงซ้อนหากทำได้ แต่ฉันบอกว่ามันไม่น่ากลัวเกินไปที่จะทำในปริมาณที่น้อยมากและจัดการได้

มันขึ้นอยู่กับสถานการณ์การปรับใช้ของคุณ 3560 / 3750s เป็นสวิตช์ที่ยอดเยี่ยมมีบัฟเฟอร์ที่เหมาะสมและมักจะทำงานได้ดีสำหรับแอปพลิเคชันส่วนใหญ่ หากศูนย์ข้อมูลของคุณเห็นกระแสการจราจรที่ต้องการบัฟเฟอร์ที่ใหญ่กว่าคุณควรจะสามารถดึงสถิติจากสวิตช์เช่นการใช้บัฟเฟอร์และการปล่อยแพ็คเก็ต การโน้มน้าวใจฝ่ายบริหารให้วางสวิตช์ที่ทิ้งแพ็กเก็ตของพวกเขาไม่ควรท้าทายมากเกินไป ฉันคิด.

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

ในศูนย์ข้อมูลขนาดเล็ก 3750 stack แสดงถึงตัวเลือกที่มีราคาค่อนข้างต่ำเพื่อให้ได้ความหนาแน่นของพอร์ตโดยไม่ต้องเสียค่าใช้จ่ายของสวิตช์บนโครงเครื่อง ตัวฉันเองเพิ่งติดตั้งสำหรับลูกค้าขนาดเล็กกว่าโซลูชันศูนย์ข้อมูลที่เกี่ยวข้องกับเซิร์ฟเวอร์ Cisco UCS C220 M3 ไม่กี่ตัวที่มี Netapp FAS2240 และฉันใช้สแต็คของ 3750s เพื่อมอบความซ้ำซ้อน etherchannel แบบหลายแชสซีให้กับอุปกรณ์ใหม่แต่ละเครื่อง ระหว่างการเปลี่ยนแปลง มันใช้งานได้ดีจริงๆ

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

จริงๆแล้ววิธีที่พบมากที่สุดที่ฉันเคยเห็นในยุค 3750 คือตอนที่สวิตช์หลักถูกอัพเกรดเป็น Nexus 7k โดยปกติ (แต่ไม่เสมอไป) ส่วนหนึ่งของการรีเฟรชนั้นคือการย้าย TOR ไปยัง Nexus 2000 FEXs หรือ Nexus 5000

แม้ว่า 3750 นั้นไม่มีบัฟเฟอร์ที่ใหญ่ที่สุดในใจของคนส่วนใหญ่ แต่ก็ทำงานได้ดีพอในสภาพแวดล้อม DC ขององค์กรส่วนใหญ่

หากคุณไม่สามารถใส่ค่าเงินดอลลาร์สำหรับปัญหาที่เกิดจากการมี 3560/3750 ใน DC ฉันสงสัยว่าคุณจะสามารถโน้มน้าวให้ฝ่ายบริหารเปลี่ยนพวกเขานอกวงจรการฟื้นฟูผลิตภัณฑ์ปกติ

@mellowd ถูกต้องแน่นอนสวิตช์เหล่านี้ไม่ใช่สวิตช์ DC ที่ใช้งานได้ดีเนื่องจากบัฟเฟอร์ที่ จำกัด มากพวกเขาจะ microburst และลดทราฟฟิก

พิจารณาว่าคุณมีทางเข้า 2 * 1GE และทางออก 1 * 1GE สถานการณ์กรณีที่เลวร้ายที่สุดคือพอร์ต egress เริ่มลดลงหลังจากพอร์ต ingress ส่งไปพร้อมกันเป็นเวลา 2 มิลลิวินาที สถานการณ์กรณีที่ดีที่สุดคือคุณสามารถรับมือกับการระเบิด 8 มิลลิวินาที

คุณมีบัฟเฟอร์ egress 2MB ต่อ 4 พอร์ตดังนั้น 2MB / (1Gbps / 8) = สูงสุด 16ms และ 16/4 = 4ms ขั้นต่ำ หารจำนวนนั้นด้วยจำนวนพอร์ตทางเข้าที่ต้องการส่งและคุณจะได้รับจำนวนระยะเวลาที่คุณสามารถจัดการได้ นั่นคือยิ่งคุณเพิ่มพอร์ต (เซิร์ฟเวอร์) มากเท่าไหร่คุณก็สามารถจัดการ microbursting ที่น้อยลงได้

หากคุณต้องอยู่กับ 3750/3560 คุณควรอ่านเอกสารนี้เพื่อเพิ่มการใช้บัฟเฟอร์ให้สูงสุด และหากคุณยังคงใช้ LACP ในการออกไปข้างนอกถึงแม้ว่ากราฟของคุณจะแสดงว่าความต้องการการออกไปข้างนอกโดยเฉลี่ยนั้นต่ำมาก

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

ประสิทธิภาพเป็นปัญหาที่สำคัญอย่างยิ่งและได้รับการแก้ไขเป็นอย่างดี แต่ก็มีความแตกต่างมากมายตามคุณสมบัติและชุดคุณสมบัติ:

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

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

3. คุณสมบัติ DC (ISSU, DCB, ที่เก็บข้อมูล, องค์ประกอบการเขียนสคริปต์บางตัวในกล่อง) ไม่ใช่ - และจะไม่เป็นเช่นนั้นในอุปกรณ์ที่มุ่งเน้นไปที่วิทยาเขต กลไกในการจัดการและขยายขนาด L2 ด้วยวิธีที่มีสติ (เช่น FabricPath / TRILL, OTV, VXLAN และอื่น ๆ ) ก็มีแนวโน้มที่จะหายไปจากทั้งสถานะปัจจุบันและแผนการทำงานนอกผลิตภัณฑ์ DC รายการที่นี่จะเติบโต - virtualization on-box, การสนับสนุนกลไกการช่วยเหลือ HW และอื่น ๆ

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

โดยทั่วไปความแตกต่างระหว่าง DC และการเปลี่ยนตู้เสื้อผ้ากำลังเพิ่มขึ้น ในโลกของซิสโก้มีระบบปฏิบัติการที่แตกต่างกัน (NXOS กับ IOS) ด้วยเหตุผลที่ดีมาก - ความต้องการที่แตกต่างกันอย่างมากมายให้ผลลัพธ์ที่แตกต่างกัน ความเร็วคุณสมบัติสำหรับกลไกการตรวจสอบผู้ใช้ (802.1x) หรือการรวม AV แฟนซีไม่จำเป็นในศูนย์ข้อมูลในขณะที่ความสามารถในการยกเลิก 10GE ตันไม่จำเป็นในตู้สายไฟ เครื่องมือต่าง ๆ สำหรับงานต่าง ๆ กล่อง Nexus ที่เชื่อมต่อเดสก์ท็อปจะเป็นแผนที่ที่ไม่เหมาะ

ฉันจะชี้ให้คุณไปที่คำแนะนำการออกแบบต่างๆ (CVD's และอื่น ๆ ) ที่กำหนดเหตุผลสำหรับประเภทของสวิตช์ที่ใช้ในจุดต่างๆในเครือข่าย มีบางสิ่งที่จะกล่าวสำหรับโซลูชันที่โดยทั่วไปคล้ายคลึงกับวิธีปฏิบัติทั่วไปที่ดีที่สุดในอุตสาหกรรมและสวิตช์ที่คุณพูดถึงโดยทั่วไปไม่มีตำแหน่งใน DC นอกเหนือจากเครือข่ายการจัดการหรือสถานการณ์การเชื่อมต่อในกรณีพิเศษบางกรณี

ฉันมีลูกค้าที่ปรับใช้พวกเขาเป็นสวิทช์ SAN (โดยใช้ 3750X) ด้วยการเชื่อมต่อ SAN ที่ 10Gbit จากนั้นโฮสต์ ESX ของพวกเขาเชื่อมต่อที่ Gbit (หรือหลาย Gbit โดยใช้ LAG) และจำนวนหยดออกเป็นเรื่องทางดาราศาสตร์ คุณลองปรับจูนบัฟเฟอร์อย่างไร

ลูกค้ารายเดียวกันมีอีก 3750 สแต็คใน DC เดียวกันสำหรับเครือข่ายอื่นและทั้งหมดนี้สะอาด

TL; DR:มันขึ้นอยู่กับประเภทของการรับส่งข้อมูลที่คุณกำลังใส่ผ่านสแต็กและที่ที่คอขวดของคุณอยู่

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

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