ブログトップ 記事一覧 ログイン 無料ブログ開設

Simple is Beautiful このページをアンテナに追加 RSSフィード

2005 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 04 | 05 | 07 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 12 |
2014 | 01 | 02 | 03 | 04 | 07 | 08 | 09 | 11 | 12 |
2015 | 01 | 02 | 04 | 05 | 06 | 12 |
2016 | 01 | 11 | 12 |
2017 | 03 | 04 | 05 | 06 |

2013/02/25 (月)

[]UCS Manager は Fabric Interconnect に入っている機能でござる

技術的に詳細な紹介は本家におまかせし、こちらでは今後も「そもそも」的な部分を小粒に書いていきたいと思います。別にOfficialなBlogでも仕事でもないですし!

Ciscoのサーバ製品 "Cisco UCS" には、ブレードサーバのBシリーズとラックマウントサーバのCシリーズがあります*1

以前、サーバ仮想化によってインフラは群体として扱われるモノとなっていく、と書きましたが、まさにこの言葉はUnifiedという言葉で、流行というか流れになってきていると思います。…そして、製品として冠にそのUnifiedという単語を含むUCSをUnifiedたらしめている存在が、UCS Managerです。

UCS ManagerはブレードサーバのBシリーズでは必須、ラックマウントサーバのCシリーズでは必須ではありませんが、あるとないとではだいぶ管理性が違ってきます。

f:id:takaochan:20130224000036p:image

ところで二つの側面があるので最初は分かりづらいかと思うのですが、UCS Managerは物理的にはFabric Interconnectと呼ばれる、見た目はNexus 5000シリーズと同じ様な見た目(色違い)の筐体内に搭載されているフラッシュデバイスに導入されている管理機能です。

Bシリーズサーバを納めるためのシャーシであるUCS 5108には、他社のブレードサーバシャーシに搭載されているような、いわゆる管理モジュールは搭載されていません。1/19に「Fabric Extender (FEX) って?」というエントリーを書きましたが、ブレードシャーシには電源やファンといったインフラモジュールを除けば、ブレードサーバ自体以外にはシャーシ搭載型のFEXが背面に搭載されているだけです。以前のエントリーでも書いたとおり、FEX自体は独立して管理するものではありませんので、徹底的にブレードシャーシの中で個別に管理しなければならないような要素が存在しないように作り込まれています。

また、インフラ管理機能がサーバとしてではなく、仮想アプライアンスのような形でもなく、Fabric Interconnectに搭載されるカタチで提供されているという点は考えてみると、なかなか理にかなっていると思います。管理対象となるサーバや、その上で動作する仮想アプライアンスのようなカタチであると、管理上入れ子状態となってしまうというか、やはり「管理する側と管理される側は切り離されているべき」でしょう(Fabric Interconnect自身も管理対象ではあるわけですが…設定を変化させる対象という意味ではFabric InterconnectとUCS Manager間の接続こそが最も失ってはいけない接続であるといえるわけで、であれば同居していることは最適な構成といえます)。

サーバからも、ブレードシャーシからも管理機能が切り離されているため、管理範囲はブレードシャーシ単位に制限されることもありませんし、Fabric Interconnectに接続していればラックマウント型のサーバであってもブレードサーバとまったく同じように管理することができます。ブレードシャーシを超えて統合された管理性が提供され、サーバ、Fabric Extender (FEX)、Virtual Interface Card (VIC)とVIC連携によるAdapter FEX / VM FEXなどがすべてまとめて管理できる*2ため、システム実行環境を組み替えたりする際に、サーバ、LAN、SANなどをバラバラに構成変更するような手間がない点はとても便利ですし実用的な仕組みといえます。

f:id:takaochan:20130224000037p:image

さらに、今後システムがよりUnifiedとなっていくためにはインフラのレイヤーとより上位のレイヤーが統合的に連携できる仕組みが必要となっていきますが、UCSの場合はすでにUCS Managerによってインフラ範囲が統合管理された状態となっているため、連携の仕組みも作りやすいといえるでしょう。

現在、UCS ManagerはJavaアプリケーションのカタチでインターフェイスが提供されていますが、これはあくまでもUCS Managerを管理操作するためのインターフェイス実装でしかありません。実体はAPIとなっていますし、このインターフェイスからも裏では単にUCS Managerに対してAPIによる制御が行われています。一元化された上でさらにAPI化されているため、アプリケーションやミドルウェア、オーケストレーターなどからの制御もよりシンプルに、明確なかたちで実装しやすくなっているかと思います。

前回も〆に書きましたが、こうしたちょっとした点の実装が、大きな違いとなっていくのではないでしょうか(^_^;)!

*1:あと、実はEシリーズとも呼ばれる、UCS Expressというブランチオフィス向けのISR統合ルータに搭載できてしまうService Ready Engine(SRE)型のモデルもありますが…

*2:構成的な制限を除けば、IntelBroadcomのNICや、QlogicなどのHBAも管理できます。

2013/02/16 (土)

[]ちょっとしたことが、大きな価値だったりする ー UCS ManagerにおけるProfile

仮想化環境のようなインフラ環境を構築する場合、同一モデル・同一構成のサーバを多数並べて使用する場合が多くあります。たとえばVMware vSphereを用いて仮想インフラ環境を構築する場合には、ESXiホストが仮想マシンの実行環境となりますが、基本的にはCPUモデルや搭載メモリ量、ネットワーク構成などが同一である方が様々な面で使い勝手がよいですし、多くの機能が「ESXiホスト間で構成に整合性があること」を前提としています。

単にESXiのHypervisorとしての構成における整合性だけであれば、vCenter Serverによって一元管理され、たとえばHost Profileなどの機能によって構成に差異がないことを確認することができます。しかし、最近のx86/64サーバでは多くの機能がハードウェアオフロードされたりハードウェア仕様に依存するようになってきており、特にCPU仮想化支援機能と呼ばれる、Intel VTやAMD-Vなどの機能、BIOSレベルにおける各種ブースト機能や、Power Managementなどのいわゆるキャッピング機能などの構成についても正しく構成されていたり、共通の設定となっていることが必要となります。

しかし多くのサーバベンダーの製品では、BIOSレベルの構成はBIOS自体で構成することが一般的です。また、OS上に導入するサーバ管理ソフトウェアや、OSに依存しないリモート管理アダプター側からはBIOSレベルの詳細な情報までは取得できないこともありますし、なによりもパラメータの確認はできても構成はできないことがよくあります。

後発サーバベンダーであるCiscoのサーバ "UCS" は、各社のサーバ製品を研究し、x86/64という汎用プラットフォームという共通性を持ちながらも、多くの差別化要素が盛り込まれています。そうした要素の1つとも言えるサーバの統合管理機能 UCS Manager では「サーバに対してProfileを割り当てることができる」という機能が備わっており、Profileの中にはBIOSに対する構成定義もポリシーとして含まれています。このため、BIOS構成を定義したProfileを適用したサーバにおいては、BIOS設定がProfileに含まれるBIOSポリシーに従って構成されていることが基本的に保証されています。

f:id:takaochan:20130216213927p:image

Profileの構成要素であるBIOSポリシーはサーバモデルを超えて共有することができますので、同じポリシーを含むProfileを適用した全サーバで同じ構成となっています。また、事前に構成しておくことができますので、サーバ導入作業のドタバタの中で設定を間違えたりすることもありません。これはちょっとした違いですし、サーバを導入する際にしか関係ないと思われるかもしれませんが、このちょっとした違いが大きな価値であるといえるのです。

BIOSレベルのちょっとした設定の違いによって「機能としては動作していてもパフォーマンスに影響を与える」項目もありますので、導入が完了し運用が開始された後に「なぜか特定のサーバだけパフォーマンスが出ない」などの問題が発生し、原因を切り分けていった結果としてBIOS設定がその1台だけ違っていた、なんてことがあり得るわけですが、UCSにおいては必要な構成が定義されたBIOS設定ポリシーを含めたProfileさえ適用されているかどうかを確認すれば、BIOS設定が正しく構成されているかどうか判断することができます。

こうした機能がなかった場合、たとえばESXiホストであればまだvMotionなどで待避した上でBIOSのチェックを行うことができるかもしれませんが、それであっても1台1台、人が確認していくとなれば作業負荷はかなりのものとなりますし、たとえサービスが停止しないとはいえども与えるインパクトは小さくはありません。さらにシングルサーバ構成のWindowsやLinuxが導入されたサーバであったとしたらサービスの停止に繋がってしまいます。

Profileは適用しておしまいではありません。構成情報がサーバ自体からは分離されて管理されている価値は、このBIOS構成に限らず、色々とあるかと思います。

2012/05/01 (火)

[]メモ書き:Windows Server 2012 - Storage

Networkに続いてStorage(ホワイトペーパーとしては、「記憶域」と「記憶域と可用性」がベース)。Windows Server 2012では大幅にストレージ関連の機能も強化されるが、Linuxにおいて実装が進んでいる機能の後追いといえる部分も多数ある。しかし、Windowsにおいてこれらの機能が実装されることには大きな意味があり、OSとして新しい次元に進んでいることがわかる。サーバ仮想化によってOSの存在は単なるアプリケーションの実行環境になってしまうかと思われたが、こうして進化した次世代OSはまだまだコンピューティングの中心に位置することになるのかもしれない。

  • ノード
    • メモリエラーの分離:特定ユーザモードアプリケーションのメモリエラーを分離することによるデータ整合性の維持
    • NICチーミング:SMB通信などにおける可用性の向上
  • 記憶域
    • 記憶域プールと記憶域スペースから構成される論理ストレージ機能

f:id:takaochan:20120501224709p:image

      • 記憶域プール:HDDやSSDなどの物理記憶域から構成される論理的なストレージ領域
        • AD統合セキュリティ、ミラーリングおよびパリティをサポート、クラスタ対応
      • 記憶域スペース:記憶域プール内に構成される要件レベル(復元性など)を定義された仮想ディスク
        • 必要に応じてNTFSなどによりフォーマットして使用する
        • SQLやファイルサーバなどに対する直接的な割り当てや、仮想環境への展開も可能
    • オフロードデータ転送(ODX)

f:id:takaochan:20120501224710p:image

      • ストレージ側でのオフロードデータ転送とサーバ側でのトークンコピーを連携させることによる低負荷・高速なデータ移動
      • ストレージ側での対応が必要
  • ファイルシステム
    • ReFS(Resilient File System)
      • 16KBクラスタサイズで2^78バイトのボリュームをサポート、2^64-1バイトのファイルサイズ、2^64個のファイル・フォルダのサポート
      • 可用性と信頼性の向上を目的としたNTFS/Win32APIと高い互換性のあるローカルファイルシステム
        • BitLockerドライブ暗号化、ACL、USNジャーナル、変更通知、ボリュームスナップショット、ファイルIDなど…
      • B+ツリーによるディスクパス表現
      • トランザクションモデルによる更新信頼性の向上
      • メタデータの書き込み時割り当てトランザクションとメタデータチェックサムによる破損検出と整合性確保
      • 記憶域スペースと組み合わせて使用することによる可用性
        • 記憶域スペースのミラーリングと組み合わせることが可能(自動的な破損データの修復)
      • データ破損部のみのオフライン化による、ボリューム全体に対する可用性低下の抑止
    • NTFS
      • 特定の書き込み順序に従う必要のある操作について、"Forced Unit Access"から"flush"コマンドのみを使用するよう拡張(メタデータ不整合に対する復元性の向上)
      • 修復性の向上
        • オンライン破損スキャン機能:Chkdsk必要性の減少
        • オンライン修復機能:自己修復機能の強化
        • 修復時間の短縮:数億ファイルで1箇所の破損があるボリュームにおけるChkdsk実行時間が8秒未満
    • データ重複除去

f:id:takaochan:20120501224711p:image

      • ファイルをメタデータとチャンクストアに分離して管理することによる重複排除
      • 可変サイズチャンキングおよび圧縮の使用(一般的ファイルサーバにおいて2:1、VHDライブラリにおいて20:1の最適化)
      • サーバワークロードへの影響を最小限に抑えたプライマリデータに対する重複除去処理の実行(実行タイミング・使用リソース割合・対象ファイルなどの管理も可能)
      • 整合性の維持:チェックサム、ID検証などと、メタデータを含むデータの冗長性確保
      • BranchCache統合:WAN帯域幅の消費削減
    • 仮想プロビジョニングおよびトリム
      • ストレージ側シンプロビジョニングと連携した必要時割り当てと解放(トリム)の実装
  • クラスタリング
    • CSV v2
      • Hyper-V以外のアプリケーションのサポート
      • 記憶域スペース・仮想プロビジョニングとの連携
      • 共有名前空間を通じたクラスタノード全体での構成共有(単一名前空間によるファイル名とパスの一貫性)
      • バックアップ関連機能強化:VSS完全サポート、スナップショット作成、クラスタレベルのポイントインタイムセマンティックス
  • ブロックアクセス
    • iSCSI Software Target

f:id:takaochan:20120501224712p:image

      • 標準の組み込みオプションとしての実装
      • iSCSIネットワークブートのサポート
        • 差分VHDファイルを使用することによる記憶域容量の最小化
        • ゴールデンイメージによる一元管理
      • 透過フェイルオーバー
  • ネットワークファイルシステム
    • NFS
      • NFS4.1対応
      • VMware仮想マシンのためのデータストアとしての使用をサポート(NFS v3)

f:id:takaochan:20120501224713p:image

      • PowerShellコマンドレットによる管理性
    • SMB
      • CVSによる単一名前空間機能を使用したActive/Activeクラスタ化(帯域幅の使用率向上、負荷分散)
      • サーバアプリケーションデータ配置のためのパフォーマンス向上と冗長パス
        • Hyper-VやSQLのためのデータ格納をサポート
          • Microsoft SQL Server over SMB:SQLトランザクションによる小規模ランダム読み書きへの最適化

f:id:takaochan:20120501224714p:image

          • Hyper-V over SMB:仮想マシン構成ファイルとVHDファイルのSMB共有フォルダへ格納

f:id:takaochan:20120501224715p:image

      • 透過的フェイルオーバーおよびFT:サーバクラスタとクライアントの連携による代替クラスタへの透過的なフェイルオーバー
      • 暗号化:暗号化機能の標準サポート
      • ディレクトリリース(クライアント側でのメタデータの長期的キャッシュ)によるWAN経由トラフィックの最適化
      • リモートSMBファイル共有のVSS:VSS連携バックアップなどによる整合性のあるバックアップおよび復元に対応

f:id:takaochan:20120501224716p:image

        • ファイル共有シャドウコピープロバイダ:リモート共有のための新VSSプロバイダ、UNCパスにおけるVSSをサポート
        • ファイル共有シャドウコピーエージェント:SMBファイル共有をホストするコンピュータ側
  • ネットワーク機能
    • SMBダイレクト
      • SMBにおけるRDMA(Remote Direct Memory Access)対応:カーネルをバイパスした高速なメモリ間書き込み/読み取り操作の直接実行
        • 要RDMA対応ネットワークアダプタ(iWARP, Infiniband, RDMA over Converged Ethernet (RoCE) )
    • SMBマルチチャネル
      • SMBセッションパスの自動フェイルオーバー
      • SMBセッションの複数同時接続による帯域の活用
      • SMBセッションの動的な負荷分散
      • パス追加時の自動認識と拡張
      • ※RDMA使用時にNICチーミングは使用できないがSMBマルチチャネルは使用可能
      • ※ワイヤレスインターフェイスではSMBマルチチャネルは使用不可
  • 仮想化
    • NPIVを用いたHyper-V仮想ファイバーチャネル
      • 仮想マシンからの直接ファイバーチャネル接続
        • ゲストOSにおけるファイバーチャネル経由でのクラスタ化が可能(Windowsフェイルオーバークラスタリングの実行など)
        • ゲストOSにおけるVSSなどにおけるハードウェアVSSプロバイダーの使用
      • ※要対応ドライバおよび対応HBA
      • 仮想SAN:複数のSANに対する仮想マシンにおける仮想SANを構成できる
      • ライブマイグレーションサポート
      • MPIOサポート
    • 仮想マシン記憶域の移動
      • ライブ記憶域マイグレーション(Storage vMotionに相当)

f:id:takaochan:20120501231632p:image

      • ライブマイグレーションとの組み合わせにより、同じ記憶域をシェアしていないクラスタホスト間での仮想マシン移行も可能
    • 仮想ハードディスクフォーマット
      • VMDX:最大16TBサポート、データ破損保護の強化、大容量セクタディスクでの動作性向上、容量可変ディスクと差分ディスクのブロックサイズ増加、4KB論理セクタ化、カスタムメタデータの格納、トリム対応

f:id:takaochan:20120501231631p:image

  • 管理
    • 包括的な記憶域管理

f:id:takaochan:20120501231633p:image

      • PowerShellベースでの自動化
      • 統合インターフェイス
        • 記憶域プールからSMB/NFS、iSCSI、3rd Party製サブシステムまでを一元的に管理

2012/04/21 (土)

[]メモ書き:Windows Server 2012 - Network

ブログのエントリー久しく書いていなかった…。色々と下書きは溜まっていくのだけれども…。

当面はまとまった文章書くというよりも、メモ書きのダダ漏れとして使います…m(_ _)m

Windows Server 2012のベータ版ホワイトペーパーについてのメモ書き。まずはNetwork編。

  • NICチーミング
    • アダプタとインターフェイスの間にネイティブなチーミング機能を提供
    • チーミングを構成するアダプタは同一速度である必要あり
    • 数種類のトラフィック分散アルゴリズム
    • もちろんVLANサポート
    • スイッチ非依存モード
    • スイッチ依存モード:対向スイッチは単一(もしくは、単一と認識されているスイッチ)
      • 汎用・静的チーミング(802.3ad Draft v1)
      • 動的チーミング(802.1ax / LACP)
    • チーミングと併用できない機能:SR-IOV, RDMA, TCP Chimney Offload
  • Hyper-Vレプリカ
    • ストレージなどに依存しないHyper-V環境(仮想マシン)のレプリケーション
    • HTTP/HTTPSベースのレプリケーション通信

f:id:takaochan:20120421171013p:image

  • SMB2.23.0
    • 透過フェイルオーバー:ノード間でのファイル共有の移動
    • マルチチャネル:SMBサーバ/クライアント間での複数パス使用

f:id:takaochan:20120421171014p:image

    • チーミング、別サブネットの複数NIC、Infinibandなどをサポート
      • RDMA (iWARP, Infiniband, RDMA over Converged Ethernet (RoCE) )

f:id:takaochan:20120421171015p:image

    • 仮想マシンのSMB共有フォルダ配置のサポート
    • 外部ファイル共有に対するVSSのサポート

f:id:takaochan:20120421171016p:image

  • SR-IOV (Single Root I/O Virtualization)

f:id:takaochan:20120421171017p:image

f:id:takaochan:20120421171018p:image

  • Accelerating Network I/O
  • DNSSEC
  • Hyper-Vネットワーク仮想化
    • GRE

f:id:takaochan:20120421171020p:image

    • IPアドレスの書き換え

f:id:takaochan:20120421171019p:image

  • Hyper-V拡張可能スイッチ

f:id:takaochan:20120421171021p:image

  • QoS

※2012/4/23 SMB2.2ではなく3.0とすることが正式に決定されたようなので表記修正。

2011/03/31 (木)

[][][]ServerSwitch 〜 Networkはシンプルに?柔軟に?

北京にあるMicrosoftリサーチアジアと精華大学が共同論文 ”ServerSwitch: A Programmable and High Performance Platform for Data Center Networks”を公開しています。わずか15ページの論文ですが、なかなか面白い内容です。

ハードウェアベースのネットワーク制御アプローチにおいては、専用ASICによる高パフォーマンスが可能でしたが柔軟性が制限されることや、ASIC開発に多大なコストがかかるために製品が高価となるなどの課題がありました。対して、ソフトウェアベースのネットワーク制御アプローチにおいては、プログラマブルとなることやコストが抑えられることなどのメリットがありますが、ソフトウェア処理によるオーバーヘッドや遅延などのデメリットが大きな課題でした。

ServerSwitchはこの問題に対する解決策の1つとして検討されている、標準化されたサーバアーキテクチャ(つまりはx86/64ってことでしょうね)と、PCIeインターフェイスに接続するモジュールである"Switching chip"を使用することにより、ある程度プログラム可能でありながらコストを抑え、ハイパフォーマンスかつ低遅延なネットワーク制御を両立させようということを目標とするデータセンター向け次世代スイッチ仕様です。

f:id:takaochan:20110327231114p:image

I/O性能として専用機に遜色のない処理性能を発揮できるPCIeインターフェイスにスイッチング処理を受け持つSwitching Chipを接続し、その制御に高い処理性能を持つx86/64アーキテクチャCPUを活用することがベースとなりますが、ServerSwitchはその名の通り、ハードウェアデバイスの制御を汎用Server OSが担う点が大きなポイントとなります。Kernelモードで動作するドライバ(Switching Chipドライバ、NICドライバ、ServerSwitchドライバ)とUserモードで動作するアプリケーションによってSwitching Chipを制御することが可能となるため、必要に応じてAPIやライブラリを拡張して制御をおこなうことができます。この柔軟性がASICとFirmwareによって動作するこれまでのモジュールスイッチに対するアドバンテージといえるかもしれません。

f:id:takaochan:20110330011430p:image

Microsoft Resarchが開発/試作したServerSwitch Card (PCIeカード)は、BroadcomIntelなどのコモデティ化されたパーツ群から構成されており、100枚製造してコストは$400/枚。大量生産(1万枚単位)されればよりハイエンドな仕様にしつつ1枚当たりのコストも$200/枚程度には下げることができると思われます。

コアとなるスイッチング制御はBroadcomのBCM56338チップ(※リンク先はBroadcomのBCM56330シリーズPDF1ページャ資料)で、ここでMACアドレス・IPアドレスに基づく制御やMPLS制御が実行されます。8ポートの1GbEポートと2ポートの10GbEポートを持ちます。8つの1GbEポートの内、4ポートはBCM5466 Ethernetトランシーバチップ(リンク先は同様にPDF1ページャ資料)を通じて外部接続ポートとなり、残り4ポートはPCIeカード基板上でデュアルGbEポートx2を制御するIntel 82576EBチップに接続され、ServerSwitch Card自体を搭載したサーバにとってのNICインターフェイスとして使用されます。2つの10GbEポートは複数のServerSwitch Cardを搭載した場合におけるモジュール間通信に使用することを想定しています。

この論文にはAPI例やServerSwitch Cardを搭載してテストするためのBCubeと呼ぶプロトコルを用いた簡易的なテスト結果などが記載されています。

ここで試作されたServerSwitchでは、プログラムできる制御範囲が制限されていたり、完全な低遅延通信の実現にまでは至っていない点、通信速度に限界があることなど、まだまだ実用化には多くの課題や開発が必要となるステータスではあります。しかしコモデティ化されたサーバハードウェアとチップと汎用OSを組み合わせてプログラマブルな通信制御の仕組みを作り出そうという試みはなかなか興味深いところがあります。ネットワークの管理においてはシンプル化しようという流れと柔軟性を持たせようという流れの両面があると思いますが、ServerSwitchは柔軟性を目指す1つのチャレンジとしては注目すべき取り組みといえるでしょう。現時点での状況でも、本番用途での使用は無理だとしても、DCN研究用のプラットフォームとしては十分価値がある実装レベルに到達しています。

仮想化などによりサーバ、そしてストレージが物理的な制約から解放されて様々な拡張機能・柔軟性を獲得しつつある現在、ネットワークについてもブレイクスルーが模索されています。ServerSwitchがそのままのかたちで製品化されることはないと思いますが、こうした試みがこれまでのネットワーク機器の構成を大きく変えるきっかけに繋がっていくことを期待したいですね。

2010/08/20 (金)

[][][]iSCSIはネットワーク?ストレージ?(3)

(1)(2)の続きです。

FC SANの場合、基本的にはソフトウェア制御をすることはないのでFC通信のための専用アダプタHBAを用います。FCプロトコル部分はすべてハードウェア制御されますので、サーバOS側はSCSIとしてのマルチパスを制御するドライバによってマルチパス制御を行うことになります。iSCSI SANの場合も、FCと同様に専用アダプタiSCSI HBAを用いる場合はFCの場合と動作はまったく同様です。しかしiSCSIの場合はWindows, Linux, Solaris, そしてVMware ESXなどの主流なOSがのきなみ標準でiSCSI Software Initiatorを搭載したため、iSCSIプロトコルをソフトウェア的に制御する構成が多く用いられるようになりました。Software Initiatorを用いることによるデメリットはデバイスドライバレベルでのソフトウェア制御であるためにFirmwareレベルで実装されているFCなどと比較してどうしてもOSがソフトウェア的に処理する=CPUリソースを消費すること、OSが起動した後にドライバとしてロードされるため、FC BootのようなOS起動前に対応が必要となる構成ができないことなどがありましたが、データ用のネットワークブロックストレージとして用いるには特に支障はなかったことと、CPUもマルチコア化によって多少のCPU負荷はまったく問題がない状況となったことなどによって、Software Initiatorを用いたiSCSIプロトコルの利用が普及したといえるかと思います。1GbEレベルであればハードウェア処理の場合と比較して、Software Initiatorを用いた場合であっても通信速度面での性能はまったく遜色がないレベルであったこともiSCSIのソフトウェア制御を普及させた要因の1つといえるかもしれません。

しかし今後は10GbEの普及、そしてiOE搭載NICの普及によって状況は変わっていくでしょう。iOE搭載NICの場合、IPアドレスの割り当てなどの管理はOS側に依存しますが、MACアドレスは通常の通信用とは別にiSCSI用が用意されているなど、ネットワークアダプタとしてはiSCSI制御部分はほとんどHBAに近いものとなっています。Firmwareを構成することによってiSCSI Bootも可能となっています。また、10GbEレベルの通信処理となるとCPU負荷もそれなりにはなるため、iSCSIのオフロード化を推し進める要素となるでしょう。

f:id:takaochan:20100820005501p:image

http://cloud.watch.impress.co.jp/epw/cda/parts/image_for_link/42627-13894-6-1.htmlよりパクリ(^_^;)

iSCSIの独自性ともいえる実装がリダイレクトをプロトコル仕様として実装していることでしょう。ここはネットワークとしてTCP/IPを用いていることをメリットを活用しているといえるかもしれません。WWNもしくはポートでZoningすることにより、形としてはネットワークでありながらも実際には1対1の紐付けを必要とするFC SANでは冒頭書いたようにマルチパスドライバによってマルチパスを制御するしかありませんが、iSCSIの場合はサーバ側からは隠匿したかたちで、サーバに対しては透過的にマルチパス制御やロードバランスを実装することができるわけです。

iSCSIリダイレクトをどのように実装するのかについてはiSCSIストレージ側次第ではありますが、使い方としては負荷分散とマルチパス制御がポイントとなるでしょう。負荷の低いポートへリダイレクトすることによって負荷を自動的にバランシングすることができますし、個別ポートのIPアドレスではなく仮想IPに対してiSCSIセッションを接続させるような仕様とすれば、サーバ側ではパスを一切制御することなくマルチパスを実現することができます。

概要の話ってどのレベル感で書くべきなのか、なかなか難しいですね。このシリーズ?はこれでひとまずおしまいです。

2010/08/16 (月)

[][]iSCSIはネットワーク?ストレージ?(2)

(1)の続きです。

iSCSIはSCSIプロトコルを完全にTCP/IPの上に載せていますので、実装は色々なパターンがあります。

f:id:takaochan:20100815204337p:image

最もハードウェア的な実装は、FCと同レベルのHBAを用いた実装です。FC SANではFCプロトコルを用いた実装部分は完全にハードウェアで実装されたため、OSからはFCデバイスがSCSIデバイスとして認識されます。マルチパスドライバをOSに導入することもありますが、そうしたドライバは複数パスから認識されるSCSIデバイスを仮想デバイスとしてOSに対して認識させることで、SCSIデバイスとしての経路障害をOSからは隔離します。

反対に、最もソフトウェア的な実装は、普通のNICを用いてL2レベルまではハードウェアを用いますがそこから上の、ストレージとしての実装においてすべてソフトウェアを用いる実装です。TCP/IPのネットワークスタックはほとんどのOSが持っていましたが、そのレイヤーとSCSIレイヤーを結びつけるためのiSCSIレイヤーを処理するためのソフトウェアスタック"iSCSI Software Initiator"をさらに実装することで、ソフトウェア的なiSCSIを実現しています。

最近はさらにその境目は複雑になってきています。NICがより上位のレイヤーについてもハードウェア的に処理できる機能を次第に広げつつあるからです。TCPセグメンテーションのオフロード、そしてさらにはiSCSIレイヤーそのものをオフロードするiSCSI Offload Engine (iOE)。これらはHBAとは異なりOS側の対応と構成が必要ですが、CPUに負荷をかけることなくiSCSI処理を実装しています。HBAのような高価な専用アダプタを用いることなくネットワークストレージへのブロックレベルでのアクセスを実現したことが、iSCSIの普及に拍車をかけているといえるでしょう。

VMware vSphere4もESX4.1からBroadcom NICに実装されたiOEをサポートしました。iOEが有効となっているBroadcom 5709 1GbEアダプタや57711 10GbEアダプタを、VMkernelはvmhbaデバイス、つまりハードウェアアダプタとして認識します。

ここまでで、iSCSIのネットワークレベルの部分と、ストレージレベルの部分について書いてきました。最後となる次回はそれを結びつける、iSCSIレベルそのものについて書いてみたいと思います。