Yönetiminizi 3560 / 3750'lerin DC'nizde kötü bir fikir olduğuna nasıl ikna edersiniz?


12

3560 / 3750s küçük tamponlara sahiptir ve iyi kablolama dolap anahtarları yapar. Ancak bu anahtarların DC'lerde sık sık görüyorum. Birçok kişi genellikle 1Gb ve L3 yetenekli oldukları için bunları kullanma eğilimindedir.

DC dağıtımlarında ne kadar kötü olduklarını kanıtlamanın bir yolu var mı? İnsanların 3750'lerini mümkün olan en kısa sürede kaldırdıklarını söylediklerini duyuyorum, ancak henüz yönetimin onları çıkarmasını sağlamak için kullanılabilecek gerçek bir başarısızlık senaryosu duymadım.


8
İlk olarak, performans verilerini toplayarak kötü bir fikir olduklarını kanıtlayın .
Zoredache

1
Bu, yönetiminizin başlamak için yanınızda olduğunu varsayar ve performans verileri argümanlarını dinler. Birçok kötü ağ iletişimi ruhu, teknolojiyi anlamadığı ve düşündükleri ve gözle görünmeyen bazı ağ altyapısından daha yüksek oranda görünür projelere dolar harcamak yerine CTO'lar altında boyun eğmektedir. Kapak tarafında, akıl yürüten bir CTO'ya sahip olmak, daha yüksek performanslı anahtarların kullanılması anlamına gelmez , çünkü uygulamanın performans gereksinimlerinin mevcut ve beklenen büyümeyi desteklemek için anlaşılması ve kanıtlanması gerekir.
generalnetworkerror

3560'ın ötesinde yetenekler gerektiren bir çekirdek Nexus'unuz yoksa, 3560/3750 anahtarlarının harika olduğunu hissediyorum. Şunu kabul edelim ki, bu günlerde 1U anahtarına kim harcamak için 10 bin dolar var? Özel bir şey yapmadığınız sürece cevap hiç kimse değildir.
Brain2000

Yanıtlar:


13

FWIW Bir TOR kurulumunda 3750'ler (3750G ve daha sonra 3750E / 3560E) ile ilgili deneyim yaşadım; başlangıçta L2 port kanalları / GLBP (2x1G ve 2x2G varyantları ve db rafları için nadir bulunan 2x4G) ve daha sonra L3 ile TOR'a (3750E / 3560E ve 10G için çekirdeğe gitti). Onlardan bahsediyorum. Yalnızca en bant genişliği yoğun hizmetler için arabelleklerle ilgili sorunları gördük ve bu noktada ana bilgisayara 10G'ye baktık (ve 24-48 SFP + 'lı yoğun pizza kutuları).

Yönetime bir şey ispat edip edemeyeceğiniz gerçekten uygulamaya bağlıdır ve tasarımınızın ve uygulamanın gereksinimlerinin ne olduğu konusunda ödevinizi yapıyorsunuz ve uygulamanın spesifikasyonlarının tam olarak ne olduğunu biliyorsunuz yanı sıra beklenen büyüme hızı. Yönetim zincirinizle ve ağın birincil sahipleriyle / müşterileriyle bir tasarım incelemesi oluşturun.

Yönetim verileri görmek istiyor ve kutuyu tam olarak test etmek için kaynaklarınız yoksa (bir test planı hazırlayın, bazı trafik üretim donanımlarına bağlayın, tamamen kapsamlayın ve tasarım spesifikasyonuna stres testi yapın, vb.) bunu yapmak zor olacaktır. Anekdot kanıtlarından etkilenmeyecekler ve bu tür sert veriler bulmak zor olabilir, çünkü eminim ki bu tür bir şey yayınlayan insanlar her türlü NDA'ları ihlal edecektir.

En bir cevabı yayınladığını Herkes oldukça güzel 3750 platformun "sorunlu alanları" sıraladı: buna yığma ve garip başarısızlık modları doğasında, boyutları tampon, vb de var bu soru o çıktı kuyruğu damla SNMP istatistikleri toplamak ile hatlar sorunlar - arabellekler ASIC'ler arasında paylaşılır, bu nedenle SNMP aracılığıyla elde ettiğiniz tüm istatistikler belirli bağlantı noktası aralıkları için aynı olacaktır (bu, yönetim zincirinizle ortaya çıkarabileceğiniz bir bağlantı noktası olabilir).

Özetlemek gerekirse, 3750/3560'ın çoğu dağıtım için, biraz büyük ölçeklerde bile "iyi" olacağını söyleyebilirim. Mümkünse onları istiflemekten kaçının, ancak bunu çok küçük ve yönetilebilir miktarlarda yapmanın çok korkunç olmadığını söyleyebilirim .


10

Gerçekten dağıtım senaryosuna bağlıdır. 3560 / 3750'ler harika anahtarlardır, iyi arabelleklere sahiptir ve çoğu uygulama için genellikle iyi çalışırlar. Veri merkeziniz daha büyük arabellekler gerektiren trafik akışlarını görürse, arabellek kullanımı ve paket damlaları gibi anahtarlardan istatistik alabilmeniz gerekir. Yönetim paketlerini bırakan anahtarları bırakmaya ikna etmek çok zor olmamalı. Bence.


5
"paketleri bırakarak anahtarları bırakın" - harika!
Stefan

8

3750'nin ilk günlerinde, özellikle 2010'dan hemen önce piyasaya sürülen istifleme teknolojisinde, yığının çok zarif olmayan bir şekilde başarısız olmasına neden olan anahtar arızaları ile ilgili birçok sorun vardı. Bir yığını yükseltmenin en sezgisel süreç olmadığı gerçeğiyle birleştirin (o zamandan beri geliştirildi), 3750 gerçekten o zamandan beri sıkışmış kötü bir üne sahipti.

Küçük veri merkezlerinde, 3750 yığını, şasi tabanlı bir anahtar maliyeti olmadan bağlantı noktası yoğunluğunu elde etmek için nispeten düşük maliyetli bir seçeneği temsil eder. Kendimi daha küçük bir müşteriye, Netapp FAS2240 ile birkaç Cisco UCS C220 M3 sunucusunu içeren bir veri merkezi çözümü kurdum ve her yeni cihaza ve tüm eski sunucularına çoklu şasi eterchannel artıklığı sağlamak için 3750'lerlik bir yığın kullandım geçiş sırasında. Gerçekten, gerçekten iyi çalıştı.

Peki - 3750'nin sorunları var mı? Muhtemelen bu uzun zamandır var olan diğer anahtarlarla aynı. 6500'ün yaşam döngüsünde sorunları vardı ve şimdi yıllarca ve yıllarca dışarıda olduğu için o kadar da kötü değil. Ne atacağınıza bakmanızı öneririm ve performans metrikleri tutarsa, performanslarını dikkatle izlediğinizden emin olun.


3750'leri birçok kez başarılı bir şekilde kullandım. Daha sonra, DC dağıtımlarımın çoğu MPLS çekirdeğinde harcadığım için oldukça küçük. Ne kadar 'kötü' olduklarını duymaya devam ediyorum ve bazı şeyler için kötü olduklarından eminim, ancak bu ifadelerin asla sert verilerle desteklenmediğini gördüm
22'de mellowd

Yine, bunun çoğunlukla ürünle ilgili tarihsel sorunları olduğunu düşünüyorum. Bunları her yere dağıtmanız gerektiğini söylememek gerekirse, Şasi tabanlı, daha yüksek bağlantı noktası gereksinimleriyle çok daha uygun maliyetli hale geliyor - 3750 için aşağı yönde 10GbE özelliklerinin eksikliğinden bahsetmiyoruz. ürün bazı büyük kırışıklıkları ütülenmiştir.
Mierdin

6

Dürüst olmak gerekirse, 3750'lerin kaldırıma çarptığını gördüğüm en yaygın yol, çekirdek anahtarların Nexus 7k'ye yükseltildiği zamandı. Bu yenilemenin genellikle (ancak her zaman değil) bir kısmı, TOR'u Nexus 2000 FEX veya Nexus 5000'lere taşımaktır.

3750'ler en büyük arabelleklere sahip olmasa da, çoğu insanın zihninde, çoğu kurumsal DC ortamında "yeterince iyi" çalışırlar.

DC'de 3560'ların / 3750'lerin neden olduğu sorunlara bir dolar değeri koyamazsanız, yönetimi normal bir ürün yenileme döngüsünün dışında değiştirmeye ikna edebileceğinizden şüpheliyim.


Onlardan duyduğum en büyük sorun, gig arabirimlerine bağlı birkaç sunucunuz olduğunda ve WAN'a giden arayüzün 100Mb veya daha az olması. Ama yine de, bunu desteklemek için henüz sert veriler görmedim
22'de

2
Bu, 100Meg bağlantısına ulaşmayı bekleyen konser bağlantılarınızdan verileri yedeklediğiniz için küçük tamponlarla ilgili bir sorun olurdu, ancak bu bir tampon sorunu değil - Bu, "WAN'ımızın bant genişliğini boyutlandırmadık doğru "sorunu.
bigmstone

6

@mellowd kesinlikle doğru, bu anahtarlar çok kullanışlı DC anahtarları değil, çok sınırlı tamponlar nedeniyle mikro patlaması ve trafiği düşürecekler.

2 * 1GE giriş ve 1 * 1GE çıkışınız olduğunu düşünün. En kötü senaryo, giriş portları aynı anda 2 ms gönderildikten sonra çıkış portunun düşmeye başlamasıdır. En iyi senaryo, 8ms patlamasıyla başa çıkabilmenizdir.

Her 4 bağlantı noktası için 2MB çıkış tamponuna sahipsiniz, bu nedenle 2MB / (1Gbps / 8) = maksimum 16ms ve minimum 16/4 = 4ms. Bu sayıyı göndermek isteyen giriş portlarının miktarına bölün ve ne kadar süre ile başa çıkabileceğinizi öğrenin. Yani, ne kadar çok giriş bağlantı noktası (sunucu) eklerseniz, o kadar az mikro patlama gerçekleştirebilirsiniz.

3750/3560 ile yaşamak zorundaysanız, tampon kullanımını en üst düzeye çıkarmak için bu belgeyi okumalısınız . Grafikleriniz ortalama çıkış talebinin çok düşük olduğunu göstermesine rağmen, hala çıkışta LACP kullanın.

Yöneticilerinize tamponların yetersiz olduğunu kanıtlamak için mevcut ağlarınızın tüm aşağı bağlantılarını değiştirdiğini / dokunduğunu / kapsadığını kanıtlamak için zaman damgalarına ve paket boyutlarına ulaşacak ve anlık talebinizin ne kadar olduğunu ve ne kadar olduğunu hesaplayabilirsiniz. tampon ile başa çıkmak gerekir.


6

Performans kesinlikle önemli bir konudur ve yukarıda iyi bir şekilde ele alınmıştır, ancak özelliklere ve özellik setlerine göre çok fazla farklılaşma vardır:

  1. Harici RPS ünitelerine duyulan ihtiyaç birçok kurulumda büyük bir sorundur - 1U anahtarı başlangıç ​​maliyetleri, alan kaybı ve devam eden yönetim açısından daha pahalı hale gelir. Yedek güç, en küçük veri merkezi ortamları dışındaki tüm yerler için mutlak bir zorunluluk olarak düşünülmelidir.

  2. Son kullanıcı bağlantısı için çok sayıda ve gereksiz kod çalışıyor - hatalar, güvenlik sorunları ve kesinti için daha fazla fırsat.

  3. DC özellikleri (ISSU, DCB, depolama, bazı kutu üzerindeki komut dosyası öğeleri) kampüs odaklı cihazlarda yoktur ve olmayacaktır. L2 genişlemesini akılcı bir şekilde yönetme ve ölçekleme mekanizmaları da (örneğin FabricPath / TRILL, OTV, VXLAN, vb.) DC ürünlerinin dışındaki mevcut durum ve yol haritalarında eksik olma eğilimindedir. Buradaki liste sadece büyüyecek - kutuda sanallaştırma, HW destek mekanizmaları desteği, vb.

  4. Ölçeklenebilirlik - Altyapıyı nasıl büyütüyorsunuz? Çok sayıda anahtar (yönetilmesi pahalı)? İstifleme (operasyonel olarak zor, büyük kablolama sorunları) karışıklıktır. Ek olarak, arayüz tiplerinin (örneğin fiber ve bakır gibi) yoğunluktaki esnekliği zor olabilir.

Genel olarak DC ve dolap anahtarlama arasındaki farklar artmaktadır. Cisco dünyasında çok iyi nedenlerle farklı işletim sistemleri (NXOS vs IOS) vardır - büyük ölçüde farklı gereksinimler farklı çözümler sunar. Veri dolabında kullanıcı kimlik doğrulama mekanizmaları (802.1x) veya süslü AV entegrasyonu için özellik hızı gerekmezken, kablo dolabında tonlarca 10GE sonlandırma yeteneği gerekli değildir. Farklı işler için farklı araçlar. Masaüstü bilgisayarları bağlayan bir Nexus kutusu da ideal plandan daha az olacaktır.

Ayrıca sizi ağdaki çeşitli noktalarda kullanılan anahtar türleri için mantıklı olan çeşitli tasarım kılavuzlarına (CVD'ler, vb.) Yönlendireceğim. Genel olarak sektördeki en yaygın uygulamalara benzeyen çözümler için söylenecek bir şey vardır ve bahsettiğiniz anahtarların DC'de genellikle yönetim ağları veya belirli özel durum yerel bağlantı durumları dışında yeri yoktur.


4

SAN'ı 10Gbit'e bağlı olarak SAN anahtar yığını olarak (3750X'leri kullanarak) dağıtan bir müşterim var ve daha sonra ESX ana bilgisayarları Gbit'e (veya LAG kullanarak birden fazla Gbit'in) bağlı ve çıkış düşüşlerinin miktarı astronomik nasıl tamponları denemek ve ayarlamak.

Aynı müşterinin aynı DC'de diğer ağlar için iki 3750 yığını daha vardır ve bunların hepsi temizdir.

TL; DR: Bu gerçekten yığına koyacağınız trafik türüne ve darboğazlarınızın nerede olduğuna bağlıdır.


3

3560/3750 içerisindeki güç kaynakları / fanlar çalışırken değiştirilemez / anahtar takıldıktan ve bu cihazların kaçınılmaz hatası oluştuğunda, tüm sunucuların bağlantısı kesildiğinde ve RMA ile değiştirilirken 3560/3750'den çıkarılmalıdır.

Ayrıca 3560s / 3750s'deki fan yönü, sıcak koridor / soğuk koridor ve diğer soğutma kurulumlarında sorun haline gelir. Anahtarların sunucuların arkasına baktığı yerlere takılması, anahtar fanlarının yanlış yönde üflendiği bir durum yaratır. Bu, anahtarın aşırı ısınmasına neden olur, bu da arıza / değiştirme ihtiyacını artırır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.