DCで3560/3750が悪い考えだと経営者にどのように納得させますか?


12

3560 / 3750sには小さなバッファがあり、適切なワイヤリングクローゼットスイッチを作成します。ただし、これらのスイッチがDCに置かれていることはよくあります。多くの人は一般に1GbとL3に対応しているため、それらを使用する傾向があります。

DC展開でどれだけ悪いかを証明する方法はありますか?できるだけ早く3750を取り外したという人の声をよく耳にしますが、実際に障害シナリオを聞いて、経営者に知らせてそれらを取り出すことができます。


8
まずパフォーマンスデータを収集して、それらが悪いアイデアであることを証明します。
ゾレダチェ

1
これは、あなたの管理が最初からあなたの側にあり、パフォーマンスデータの引数をリッスンすることを前提としています。多くの貧しいネットワーキングソウルは、テクノロジーを理解していないCTOに支配されています。一方、理由に耳を傾けるCTOが存在することは、現在および予想される成長をサポートするためにアプリケーションのパフォーマンス要件を理解し、実証する必要があるため、高性能スイッチを使用することを意味しません。
generalnetworkerror

3560を超える機能を必要とするコアNexusがない限り、3560/3750スイッチは素晴らしいと感じます。最近、1Uのスイッチに1万ドルを費やす人がいますか?何か特別なことをしているのでなければ、答えは誰でもありません。
Brain2000

回答:


13

FWIW TORセットアップで大規模な3750(3750G、その後3750E / 3560E)の経験があります。最初はL2ポートチャネル/ GLBP(2x1Gと2x2Gのバリアント、dbラック用のまれな2x4G)、次にL3をTORに(3750E / 3560Eにこれを使用し、コアに10Gを使用)。私は数千人と話しています。最も帯域幅を集中的に使用するサービスのバッファに関する問題のみを確認し、その時点でホストに対して10Gを検討していました(および24-48 SFP +の高密度ピザボックス)。

経営陣に何かを証明できるかどうかは、実際にはアプリケーションと、設計とアプリケーションの要件が何であるか、そしてアプリケーションの仕様が何であるかを正確に把握して宿題をするかどうかにかかっています。、およびそれの予想される成長速度。ネットワークの主な所有者/顧客と同様に、管理チェーンで設計レビューをセットアップします。

管理者はデータを確認したいので、ボックスを完全にテストするためのリソースがない場合(テスト計画を立て、それをトラフィック生成ハードウェアに接続し、完全に範囲を絞り、設計仕様に合わせてストレステストを行い、など)これを行うのは難しいでしょう。彼らは逸話的な証拠に感動することはありませんし、この種のハードデータを見つけることは難しいかもしれません。なぜなら、この種のことを公開する人々はあらゆる種類のNDAに違反すると確信しているからです。

ありますなど、サイズをバッファリングし、それに固有の積み重ねと奇妙な故障モード:これはかなりうまく3750プラットフォームの「問題領域」を概説しているに答えを掲載することを誰もこの質問出力キュードロップでSNMP統計情報を収集して問題を概説-バッファはASIC全体で共有されるため、SNMPを使用してこれで得られる統計情報は、特定のポート範囲で同じになります(これは、管理チェーンで立ち上げられる可能性のある1つの固着点である可能性があります)。

要約すると、3750/3560は、いくぶん大規模であっても、ほとんどの展開で「素晴らしい」と言えるでしょう。できる限りそれらを積み重ねないようにしますが、非常に小さく管理しやすい量でこれを行うのはそれほど恐ろしいことではないと思います。


10

展開シナリオに大きく依存します。3560/3750は優れたスイッチであり、適切なバッファーを備えており、通常、ほとんどのアプリケーションで正常に機能します。より大きなバッファを必要とするトラフィックフローがデータセンターにある場合、バッファ使用量やパケットドロップなどの統計をスイッチから取得できるはずです。パケットをドロップしているスイッチをドロップするよう管理者に説得することは、それほど難しいことではありません。おもう。


5
「パケットをドロップしているスイッチをドロップ」-すばらしい!
ステファン

8

3750の初期には、特に2010年の直前にリリースされたスタッキングテクノロジーでは、スイッチの障害が原因でスタックがあまり優雅に失敗する原因となる多くの問題がありました。それに、スタックのアップグレードが最も直感的なプロセスではなかったという事実(それ以来改善されている)と組み合わせると、3750はそれ以来ずっと悪い評判を得ました。

小規模なデータセンターでは、3750スタックは、シャーシベースのスイッチのコストなしでポート密度を取得するための比較的低コストのオプションです。私自身は、Netapp FAS2240を備えたいくつかのCisco UCS C220 M3サーバーを含むデータセンターソリューションを小規模な顧客にインストールし、3750のスタックを使用して、新しい各デバイスとすべての古いサーバーにマルチシャーシイーサーチャネル冗長性を提供しました移行中。本当にうまくいきました。

それで-3750には問題がありますか?おそらく、この長い間使用されてきた他のスイッチと同じでしょう。6500にはライフサイクルの早い段階で問題がありましたが、今では何年も使用されていますが、それほど悪くはありません。私はあなたがそれに投げかけようとしているものを見ることをお勧めします。パフォーマンスメトリックが維持される場合は、警戒してパフォーマンスを監視するようにしてください。


私も3750を何度も使って成功しています。繰り返しになりますが、私のDCの展開は非常に小さく、ほとんどの時間はMPLSコアに費やされています。私は、彼らがどのように「悪い」聞いておくと、私は確信している彼らはいくつかのもののために悪いですが、これらの記述は、ハードデータをバックアップし見たことがない
mellowd

繰り返しますが、私はそれが製品の主な歴史的問題だと思います。あらゆる場所に展開する必要はありませんが、3750にはダウンストリームの10GbE機能がないことは言うまでもなく、シャーシベースではより高いポート要件でコスト効率が大幅に向上します。これは、サイジングのかなり標準的な問題です。製品には大きなしわがいくつかあります。
ミールディン

6

正直なところ、3750が縁石に当たった最も一般的な方法は、コアスイッチがNexus 7kにアップグレードされたときでした。通常(常にではないが)その更新の一部は、TORをNexus 2000 FEXまたはNexus 5000に移動することです。

3750には最大のバッファはありませんが、ほとんどの人の心では、ほとんどのエンタープライズDC環境で「十分に」動作します。

DCに3560's / 3750'sが存在することによって引き起こされる問題に価値を置くことができない限り、通常の製品更新サイクルの外でそれらを交換するよう経営陣に納得させることはできないと思います。


私が彼らから聞いた最大の問題は、ギグのインターフェイスに接続されたサーバーがいくつかあり、WANに接続するインターフェイスが100Mb以下である場合です。しかし、繰り返しますが、これを
裏付ける確か

2
100Megリンクに到達するのを待っているギグリンクからデータをバックアップするため、小さなバッファでは問題になりますが、これはバッファの問題ではありません-「WANの帯域幅をサイジングしませんでした」正しく」問題。
bigmstone

6

@mellowdは確かに正しいです。これらのスイッチは、マイクロバーストを使用してトラフィックをドロップするバッファーが非常に限られているため、あまり使用できないDCスイッチではありません。

2 * 1GEの入力と1 * 1GEの出力があるとします。最悪のシナリオは、入力ポートが同時に2ミリ秒間送信された後、出力ポートがドロップし始めることです。最良のシナリオは、8msバーストを処理できることです。

4ポートあたり2MBの出力バッファーがあるため、2MB /(1Gbps / 8)=最大16ms、最小16/4 = 4msです。送信したい入力ポートの量でその数を除算すると、処理できる時間の数がわかります。つまり、追加する入力ポート(サーバー)が多いほど、処理できるマイクロバーストが少なくなります。

3750/3560を使用する必要がある場合は、このドキュメントを読んでバッファーの使用を最大限にしてください。そして、あなたのグラフが平均的な出口需要が非常に低いことを示しているとしても、あなたがまだ出口でLACPを使用しているならば。

バッファーが不十分なモニター/タップ/スパンであることをマネージャーに証明するために、現在のネットワークがすべてのダウンリンクを切り替え、タイムスタンプとパケットサイズが出力され、瞬時の需要が1 Gbpsを超えているかどうかを計算できますバッファを処理する必要があります。


6

パフォーマンスは確かに重要な問題であり、上記で十分に対処されていますが、機能と機能セットに基づいて多くの差別化もあります。

  1. 外部RPSユニットの必要性は、多くのインストールで大きな問題です。1Uスイッチは、初期コスト、スペースの損失、継続的な管理の点でより高価になります。最小のデータセンター環境を除くすべての環境で、冗長電源を絶対的に必要と見なす必要があります。

  2. エンドユーザー接続のための多くの不必要なコードが実行されています-欠陥、セキュリティ問題、ダウンタイムの機会が増えています。

  3. DC機能(ISSU、DCB、ストレージ、特定のオンボックススクリプティング要素)は、キャンパス向けのデバイスにはありません-ありません。L2拡張を同じ方法で管理およびスケーリングするメカニズム(FabricPath / TRILL、OTV、VXLANなど)も、DC製品以外の現在の状態とロードマップの両方から欠落する傾向があります。ここでのリストは、オンボックスでの仮想化、HWアシストメカニズムのサポートなど、成長するだけです。

  4. スケーラビリティ-インフラストラクチャをどのように成長させますか?多くのスイッチ(管理に費用がかかる)?スタッキング(操作が難しく、主要なケーブル配線の問題)は混乱です。さらに、密度の高いインターフェイスタイプ(たとえば、ファイバと銅線)の柔軟性は困難な場合があります。

一般に、DCスイッチングとクローゼットスイッチングの違いは大きくなっています。シスコの世界では、非常に正当な理由により、異なるオペレーティングシステム(NXOSとIOS)があります。要件が大きく異なると、さまざまなソリューションが生まれます。ユーザー認証メカニズム(802.1x)や派手なAV統合の機能速度はデータセンターでは必要ありませんが、ワイヤリングクローゼットでは大量の10GEを終端する機能は必要ありません。さまざまな仕事のためのさまざまなツール。デスクトップを接続するNexusボックスも理想的な計画ではありません。

また、ネットワークのさまざまなポイントで使用されるスイッチの種類の理論的根拠を説明するさまざまな設計ガイド(CVDなど)を紹介します。業界の一般的なベストプラクティスに一般的に似たソリューションについては、言うべきことがあります。また、管理ネットワークや特定の特殊なケースのローカル接続状況を除き、言及しているスイッチは一般的にDCに置き場所がありません。


4

SANを10Gbitで接続したSANスイッチスタック(3750Xを使用)として展開し、Gbit(またはLAGを使用した複数のGbit)でESXホストを接続した顧客がいますが、出力ドロップの量は天文学的なものですバッファの試行および調整方法。

同じ顧客は、他のネットワーク用に同じDCに2つの他の3750スタックを持ち、これらはすべてクリーンです。

TL; DR:スタックを通過するトラフィックのタイプとボトルネックがどこにあるかによります。


3

3560/3750内の電源/ファンはホットスワップ可能ではありません/スイッチがマウントされ、これらのデバイスの避けられない障害が発生すると、すべてのサーバーは3560/3750をアンマウントし、RMAと交換する間、プラグを抜く必要があります。

また、3560s / 3750sのファンの方向は、ホットアイル/コールドアイルおよびその他の冷却セットアップで問題になります。スイッチポートがサーバーの背面を向くようにスイッチを取り付けると、スイッチファンが間違った方向に吹くという状況が発生します。これにより、スイッチが過熱し、故障する可能性が高くなり、交換が必要になります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.