myAlteraアカウントへログイン

myAlteraユーザーネーム、パスワードを忘れた場合

myAlteraアカウントをお持ちでない方

データ・センター・イーサネット:パイプが太ければ十分か?

地中深くの計り知れない圧力と温度にさらされる鉱物は、人間に身近な環境では再現不可能な形を成します。それ故、炭素はダイヤモンドにもなれば、グラファイトになることもあります。

同様に、データ・センターの極めてダイナミックな環境では、通常のイーサネットが、Xerox 社パロアルト研究所 (PARC) の同発明者にとって想像もできない構成を持つようになりつつあります。炭素の場合と同様に、その結果は必ずしも類似性のないさまざまな形を成します。しかし、鉱物がある形を成し、その形を保つのとは異なり、データ・センターという厳しい試練の場の中で、各イーサネット・アダプタはアプリケーション環境の変化に対応できるように絶えず変化することを迫られます。もはやパイプを太くしさえすれば、それで十分という時代ではありません (図 1)。

1. パイプを太くするだけでは強烈な圧力への解決策にならない場合もある。

pipeline

強度

温度はさておき、まずは圧力の問題からです。データ・センターは、さまざまな外力により、「サーバーで満たされた大部屋」という単純な形をはるかに超えて形を変えつつあります。こうした力には、アプリケーションによるものもあれば、ビジネス・モデルによるものもあり、物理的理由もその 1 つです。

アプリケーションの中で、最も広く知られているのはビッグ・データ解析です。統計、分類、さらにはニューラル・ネットワーク解析を通じて大量のデータ・セットを渡すという考え方は、調査データを解析して解決策を得るツールから生まれました。ビッグ・データ・ツールは、例えば金融、証券、故障予測などの分野では、バックグラウンド・ジョブからリアルタイム・フィルタへの移行が進んでいます。こうした流れは、データ・センター・ネットワークに対して膨大な帯域幅要求を突きつけており、中には 400G 以上が要求される場所もあります。

C-RAN (Centralized Radio Access Network)、ネットワーク機能仮想化、フラッシュ・トレーディング、さらには IoT (モノのインターネット) の一部の概念など、さまざまな形の仮想化は、異なる方向に引き寄せられています。これらのアプリケーションでは、ゼロ・ネットワーク・レイテンシ、SLA (サービス・レベル・アグリーメント)、およびネットワーク間の正確なタイミングのような特殊な機能が要求されます。

しかし、データ・センター事業者は、ビジネス上の急務を踏まえて、別の方向に向かっています。事業者は、空いているサーバーやストレージ・チャネルを最大活用できるように再配置しながら、あらゆる種類のアプリケーションを自由に組み合わせるクラウド・センターを提供したいと考えています。クラウド事業者は、完全に均一なハードウェア、ソフトウェア・コンフィギュレーション可能なインフラストラクチャ、そして (認めるかどうかはともかく) ハードウェア・ベースの強力なセキュリティを必要としています。

その上、物理法則が立ちはだかります。スループットを高めるには、データ・センターをスケールアウトする、つまり 2 ~ 3 千台のサーバー・ラックを追加することです。しかし、スケールアウトはラックの消費電力増加、発熱の増加、電力網からの十分な電力の確保といった電力問題に直結します。加えて、経済面の問題もあります。データ・センターのライフサイクルが短ければ、電力コストが設備投資を上回ることになります。そのため、イーサネット・インタフェースを含め、あらゆる場所における消費電力を最小化することに熱が入っています。

帯域幅、レイテンシー、機能、セキュリティ、均一性、コンフィギュラビリティ、効率などは、いずれも合理的な要件です。問題は、これから見ていくように、それらがハードウェア・レベルではほとんど相互排反であることです。

クイック・ツアー

そのことを探るためには、10G (以上) イーサネット・インタフェースの内部をのぞいてみる必要があります。では、ブロックごとに見ていきましょう (図 2)。

2. 10G イーサネット・インタフェースのバックエンドには、ごくわずかなファンクション・ブロックしかない。

10g_ethernet_interface_diagram

アプリケーションからのメッセージがイーサネットのデータ長に対応したデータ・ブロックに分割するポイントから始めることにしましょう。分割されたデータ・ブロックは、宛先アドレスとおそらくは何らかの制御情報と共に、メディア・アクセス・コントローラ (MAC) と呼ばれる、イーサネット・インタフェースの機能に渡されます。この転送は、TCP/IP (Transmission Control Protocol and Internet Protocol) または UDP (User Datagram Protocol) によって、メッセージがそれぞれ固有の要件に合わせて形成された後、さらに Precision Time Protocol のような機能がそれぞれ固有の特殊なメッセージを作成した後に行われます。MAC は、データ・ブロックをその内容に関わらず受け取り、移動させるだけです。

具体的に言えば、MAC の仕事は各ブロックにプリアンブルを付加すること、イーサネット内の他のどこかにある別の MAC のアドレス (インターネット・プロトコルとは異なる固有のハードウェア識別子) を含むヘッダを追加すること、そして Type コードに組み込むことです。さらに、MAC は CRC (Cyclic Redundancy Check) コードを計算し、付加します。これは送信方向についての説明ですので、当然、受信側では逆の説明になります。

これはごく単純な話に聞こえますが、それも速度について考察を始めるまでのことです。実際、速度が問題でない場合、MAC 機能はすべてソフトウェアで実装可能ですが、10 Gbpsでは約 100 ns ごとに短いパケットが着信する可能性があります。このレートで処理できればよいのですが、さもなければバッファが必要になり、そのために追加のレイテンシや消費電力が発生します。レーンあたり 25G または 50G では、比例して時間が短くなります。さらに高速なイーサネット・リンクは、例えば100GE ならば 10本の 10G レーンというように、複数のレーンとして実装されます。そのため、MAC に対する負荷は上昇し続けます。

セキュリティの一側面により、MAC レイヤーはさらに複雑化します。MACsec は、プリアンブルを含めてパケット全体を暗号化する規格で、データ・センターのように、中間者攻撃が大きな脅威となる状況において特に役立ちます。このアルゴリズムは、多数の乗算および探索操作が必要であり、計算を極めて多用するため、ハードウェア・アクセラレーションが必須であり、レイテンシの追加につながります。

物理層

完全に形成されたイーサネット・パケットは、MAC から物理層 (PHY) に進みます。数ギガバイトの速度では、PHY はフィジカル・コーディング・サブレイヤ (PCS) とフィジカル・メディア・アタッチメント (PMA) という 2 つのブロックに分かれています。

PCS は、効率的に伝送できるようにフレームを準備します。インテル・プログラマブル・ソリューション・グループ・イーサネット・プロトコル担当リーダーの Nigel Gulstone は、「64b/66b エンコーダ/スクランブラを使用すれば、ビット・ストリームは多数の遷移、良好な DC バランス、そしていくつかの特殊文字のためのスペースを確保できることが期待されます。物理インタフェースが複数のレーンを使用する場合、PCS は最終的にエンコードされ、スクランブルされたブロックをレーン間で分割します」と説明します。

これらの機能に続いてギアボックスがあり、そこでまだパラレルのブロックが PCS の 66b 幅と PMA で使用される任意のデータ幅の間で再形成されます。MAC 回路の場合と同様に、受信側は基本的に送信側と逆のことを行います。

上述したように、PCS には複雑なアルゴリズムや不可解なアルゴリズムはありません。64b/66b エンコーダは単純であり、スクランブラは 1 + x39 + x58 などの多項式、比較的容易ながらレイテンシを誘発するわずかなハードウェアを使用します。ここでもやはり問題は速度です。100G の場合、64 ビット・ワードは約 670 ps ごとに 1 回の割合で PCS を通過します。

しかし、ここから難しくなっていきます。レーンあたりの速度が 10G から 25G に移行すると、PHY 内の次のステージである PMA は、入力波形から正しいデータ・ビットを回復する能力が徐々に低下します。多くのアプリケーションで許容されるビット・エラー・レートとして、10-15 以上を達成するには、順方向誤り訂正 (FEC) が必要です。しかも、FEC は 400G では PCS の一部として実装され、それより低速の規格では PCS と PMA の間に実装されます。

「ファイア・コードと 2 種類のリード・ソロモン・コードは、データ・センターで採用されているBAE-R 規格に代わることが考えられます」と Gulstone は言います。送信側の FEC エンコーダは多数の 66 ビット・ブロックをまとめ、誤り訂正ビットを埋め込んで全体を 1 つにまとめてエンコードします。受信側では、FEC デコーダが着信ビットのブロックをまとめてデコードし、紛れ込んでいる可能性のある個々の誤りをそのプロセスで訂正します。これらのコードは、PMA 内の何らかの回路に起因するものなど、集中的な不正ビットを 5280 ビット・ブロック内で最大 70 ビット訂正することが可能ですが、最終的にデータの損失の原因となる恐れがあります。

「FEC は、かなりの量の計算が必要な上、ブロック全体を保持するのに十分な大きさの高速バッファも必要です」と Gulstone は説明します。したがって、イーサネット・インタフェースのエネルギー消費とレイテンシを増加させます。しかし、現時点では、データ・センターに見られるインタコネクト・チャネル上のこうしたマルチギガビットの速度で適切なビット・エラー・レートを達成する唯一の方法です。

FEC を統合した PCS は MAC からイーサネット・フレームを受け取り、誤り保護され、スクランブルされ、エンコードされたビットの長いブロックをギアボックス経由で PMA に送ります。

シリアル化

PMA の送信側には基本的に 2 つの仕事があります。1 つは、マルチレーン接続のパラレル・データ・ストリーム (群) を、エンベデッド・クロックによってシリアル・データに変換することです。もう 1 つは、PC ボード・トレース、同軸ケーブル、銅配線バックプレーン、光ファイバーなど、伝送に使用するメディアに適したアナログ信号にシリアル・データを変換することです。PMA の受信側は、チャネルから出てくるアナログ信号を検出し、各レーンからシリアル・ビット・ストリームを回復し、シリアル・データをパラレル形式に変換し、PCS に渡さなければなりません。

10G の送信回路は、比較的低速なインタフェースの設計者にとって見覚えがあるものであるはずです。レーンごとに、周波数ソースが NRZ エンコーダをドライブします。エンコーダは、パルス・ストリームにプリディストーションを適用してチャネルの損失を補償するフィードフォワード・イコライザをドライブします。その後、アンプは物理媒体をドライブするか、光ケーブルをドライブするレーザーをドライブします。

それに対し、受信方向の方がやや複雑です。受信アンプは、連続時間フィルタ、クロック・データ・リカバリ (CDR) 回路、および DFE (Decision Feedback Equalizer) をドライブします。2 つのフィルタ間での仕事の分担は、大まかに言えば、リニア・フィルタがチャネルの周波数応答を訂正することで、DFE は ISI (Inter-Symbol Interference) と反射ノイズを低減することです。接続を確立する際、トランスミッタとレシーバは、FFE と DFE のタップ設定についてそれぞれ交渉して、チャネルの電子回路を調整します。

しかし、高速化と低消費電力化という二重の圧力を受けて、従来の方法は新しい方法に取って代わられようとしています。Gulstone は、「周波数が高いほど、従来の CDR から超高速アナログ-デジタル・コンバータ、さらには実質的な DSP プロセッサへの移行が進んでいます。DSP アルゴリズムは業界規格には含まれておらず、差別化の機会となっています」と言います。この新しいモデルでは、DSP ブロックが正しいデータの最良推定値を PCS に渡します。

50G への移行に当たっては、別の手法が検討されています。チャネルの損失は周波数と共に増加するため、物理接続で絶えず高周波数化を図ろうとするより、比較的低い周波数でクロックあたり複数のビットを送信した方が原理上、うまくいきます。NRZ は、基本的にクロックあたり 1 ビットを渡します。しかし、実質的に 2 ビット・デジタル-アナログ・コンバータで送信アンプをドライブするとすれば、各クロック周期に 2 ビットを詰め込むことができるため、基本周波数を 25G より高くせずに 50G の実現が可能です。これはパルス振幅変調と呼ばれますが、この場合は 1 つのクロック・サイクルで 4 つの離散電圧レベルが可能なため、PAM-4 と呼ばれます。

送信側では、アンプに対する直線性要件が高くなります。受信側でも、受信アンプの直線性要件がさらに厳しくなり、従来の CDR は付随する DSP ハードウェアにより、2 ビット・シグマ-デルタ・コンバータに置き換えられます。こうした追加作業が単に周波数を上げることに比べて利益になるのかどうかについては、まだ激しい議論が続いています。その答えはチャネルによって異なります。

新しい変調方式、メニー・タップ・イコライザ、DSP、および FEC を連携して働かせれば、少なくともいくつかの正常に動作するチャネルで、データ・センター・アーキテクトが求めるデータ・レートを確実に達成することが可能です。MAC より上のレイヤでアクティブ・セキュリティ・ハードウェアと連携して動作する MACsec ハードウェアは、セキュリティ・レベルをクラウド・ユーザの想定に近づけることができます。

しかし、これらの機能はいずれも、データ・センター事業者が嫌がる消費電力の増加に加え、アプリケーションが許容できないほど大幅なレイテンシの増加をもたらします。しかも、これらはハードウェア機能です。したがって、ホモジニアスなソフトウェア定義データ・センター・ファブリックの必要性は、これらの機能をすべてのネットワーク・インタフェースに配備しなければならないことを暗に示唆しています。

このジレンマに対する解決策となるのは、リコンフィギュラビリティと考えられます。つまり、すべて機能を実装した上で、各機能を選択的にバイパスし、直ちにパワー・ゲーティング可能な ASIC SoC か、あるいは現場でのリコンフィギュレーションが可能な FPGA です。いずれにしても、データ・センター管理システムは、ジョブを自由に再配置し、各ジョブに許容可能な最小限のレイテンシと、必要最小限のイーサネット帯域幅を与えることができなければなりません。それは、PMA ハードウェアから、データ・センター管理コードにまで及ぶ大きな課題です。


CATEGORIES : All, Data Center/ AUTHOR : Ron Wilson

Write a Reply or Comment

Your email address will not be published.