読者です 読者をやめる 読者になる 読者になる

SSD情報

※本ブログの内容は個人的見解であり、所属組織及び企業の意見を代弁するものではありません。 / # The contents expressed here are only my personal opinions.

HFT (High Frequency Trading)動向

朝日新聞朝刊の連載記事が興味深かったので切り抜き。全4回(2016/3/17-20)。
光回線よりマイクロ波の方が速いし最短距離で飛ばせるので、HFTではネットワーク接続に電波を活用。
「ダークプール」って知ってますか?日本にもすでに十数箇所あるとのこと。

f:id:kz_tomo:20160320175440j:image
f:id:kz_tomo:20160320175452j:image
f:id:kz_tomo:20160320175507j:image
f:id:kz_tomo:20160320175516j:image
f:id:kz_tomo:20160320175604j:image


SSDとストレージインテリジェンス(Storage Intelligence)仕様

SDC(Storage Developer Conference)の取材記事として、Storage Intelligenceの話題が出ていました。日本語記事は初めて見ました。英語記事でもこの話題はかなり少ないと思いますが。

pc.watch.impress.co.jp

具体的には4つの技術をSSDおよびストレージシステムに導入することを説明した。(1)SSDのバックグラウンド動作をホストが制御する機能、(2)SSDに書き込むデータのストリーム化、(3)ストレージのオブジェクト化、(4)ストレージ内部でのコンピューティング、である。

記事にあるようにSamsungが発表していたようですが、SSDベンダー各社取り組みあり、SAS, SATA, PCIe(NVMe)それぞれで標準化が進んでいます(記事でも下記スライド紹介されています)。SCSI(SAS)では標準化済み、SATAでは今年12月までに標準化予定、PCIe(NVMe)では現在議論中で来年以降標準化の動き、とありますね。

http://pc.watch.impress.co.jp/img/pcw/docs/722/291/09.jpg


ご存知の方も多いと思いますが、SSD記憶媒体であるNANDフラッシュメモリの特徴として、

  • 1)データ書き込みがページサイズという大きな単位(※SCSI I/Oの単位であるセクタサイズ(通常512byte)よりも大きなサイズ)
  • 2)データの上書きが仕組み上できないので、上書きする場合は一度消してから新しく書く(※データ消去はページサイズよりも大きなブロックサイズ)

という点があります。上書きができないというのはHDDとは大きく異なる点で、そんなことをホストアプリケーションやOSから意識する必要がないよう、SSD内部で仮想的に上書きできるようになっています。

最近の(少なくとも一定以上のランクの)SSDではデータ管理を仮想化しているため、物理アドレス論理アドレスはマップ管理されており、大きなサイズでデータ上書きする場合は、新しいブロックに新しいデータを書いて、古いデータを無効化するだけなので簡単(余分な内部ライトは発生しない)ですが、細かい単位でデータを上書きする場合は、古いブロックの上書きされていないデータを新しいブロックにコピーする必要があり、この時に余分な内部ライト(古いブロックから新しいブロックへのコピーライト)が発生するため、ライトの増幅ということでWrite Amplificationと呼んでいます。ライトの増幅比率をWrite Amplification Factor(WAF「わふ」)と言っています。SSDの書き込み回数はNANDの仕様で決まっていますので、SSDの耐久性を向上させるというのは、いかにWAFを小さくするかというシンプルな話になります。

(余談ですが、SSDはOP(「おーぴー」)(Over Provisioning)という余剰容量を内部的に持っていて、OP比率でWAFは大きく変わります。OPを横軸、WAFを縦軸のグラフにすると、グラフの形は結構ダイナミックに右に上がっていくイメージです。。OPが大きいSSDは耐久性及び書き込み性能が相対的に高く、OPが小さいSSDは耐久性及び書き込み性能が相対的に低いです。OPと書き込み性能が連動するのは、OPが大きいと書き込みに伴う内部処理のワーキングエリアが大きいので、色々制御を工夫する余地が広がるためです。SSDのコストはNAND価格の割合が高いので、OPを大きくするとその分SSDが高価になります。また、SSDの性能と消費電力も相関関係があり、消費電力が大きくてOPも大きくてよければ性能はかなり上げられます。消費電力は仕様上レギュレーションがありますし、コストも抑える必要があるので、制約の中でいかにチューニングするかというF1みたいな地味な話になります。今回は出ませんがDWPDと合わせて、OP,WAF,DWPDくらいが説明できればSSDにかなり詳しい人かと思います。)

Storage Intelligence仕様でのStreamは、WAFを低減させるために、ホスト(アプリ)からのI/Oストリームに番号を付けて、例えば、「もしアプリが上書きしないアプリなら、データをそっとしておく」ということを実現することができます。ブロック内に上書きしないアプリ(A)(メディアファイル等)が書いたデータと、上書きしまくるアプリ(B)(データベース等)が書いたデータが混じってしまうと、(B)の上書きの影響で、(A)のデータも将来的にブロックを引っ越しする必要が発生し、WAF的にうれしくない状況になるので、(A)と(B)のブロックを分けるようなことを実現できます。(何を言っているのか分かりますでしょうか。。世の中に100万円単位でしか出金できない銀行口座しかない場合、生活費と長期預金の銀行口座は分けておいた方が銀行に行く回数が減らせて効率的というようなことです。あ、でもお金には色が付いてないのでデータとは違いますね、、下のスライドでは赤いのを隔離しておこうということです。)

 

http://pc.watch.impress.co.jp/img/pcw/docs/722/291/07.jpg

 

もう一つの(簡単な方の)仕様のBackground operationは、SSDの内部処理は色々あって、ホストのアクセス性能に影響を与える可能性がある(発表資料では実際に影響が出ているようです)ということで、ホストアクセスが少ないタイミングをホストからSSDに教えるという仕様です。

 

SSDの作りは各社、各モデル色々あると思いますので、Storage Intelligenceの効果は各SSDに依存することになりますが、ホストからの設定等を行うコマンド仕様を取り決めしているという状況です。

 

SAS(SCSI)では、SBC-4 (SCSI Block Commands)の中でStorage Intelligence仕様が書かれています。

SCSI Block Commands - 4 (SBC-4)

 

続きを読む

HDDのファームウェアにスパイウェアを仕込む話

下記日本語記事は、かなり記事のトーンがオリジナルと異なります。


HDDのファームウェアに感染するマルウェアが登場、逃れる術はないことが判明 - GIGAZINE

 

下記が英語元記事(ロイター)。通常のマルウェアのように感染する話とは全く異なります。HDDが感染する訳ではなく、HDDのファームウェアを書き換えることができた場合には、攻撃者は脆弱性を作り出したり、攻撃をしやすくなる、という話。


Russian researchers expose breakthrough U.S. spying program | Reuters

Raiu said the authors of the spying programs must have had access to the proprietary source code that directs the actions of the hard drives. 

ライウ氏(カスペルスキー社の研究者)によると、スパイプログラムの作者は、(各HDDベンダが開発する)独自のソースコードを入手し(ソースコード改造後にHDDのファームウェアを書き換えて)、HDDの動作を制御する必要がある。

※HDDファームウェアソースコードとHDDの仕様が必要なので普通はそんなこと出来ない。

"There is zero chance that someone could rewrite the [hard drive] operating system using public information," Raiu said.

「何者かが公開された情報を用いてHDDのオペレーティングシステムファームウェア)を書き換えられる可能性はゼロである」とライウ氏は述べた。

 

 

 

eSSD (enterprise SSD)

エンタープライズ用途(個人使用のPCではなく、データセンターや企業システム、インフラシステムで使うIT機器)で使うことのできる特性を持ったSSDエンタープライズSSD、略してeSSD(enterprise SSD)と呼ぶ場合も多いようです。

 

個人PCでのSSD使用はかなり一般的になってきましたが、エンタープライズ用途では、まだまだ特に性能が要求される場所に限定されて使われている状況です。

今後、容量単価($/GB)が安くなるとともに、SSD単体容量が増えることでHDDがSSDに置き換わっていくことが予想されています。必ずしも全てが置き換わる訳ではないですが、SSD比率は確実に上がっていくと思われます。

下記の記事では、2015年の今年が"Year of the eSSD"(eSSDの年)というありがちなタイトルで書かれています。結構、来年以降も引き続きYear of ...と書かれたりするかもですが(笑)。個人的には今年からeSSDの仕事に転職したので、私にとっては確実に「Year of the eSSD」です。

NAND flash-based memory has already come to dominate the personal storage market, be it in laptops, tablets, smartphones or cameras. In enterprise applications where storage capacities for a single server are in the terabyte to petabyte ranges, hard disk drives (HDDs) are still widely used due to their lower cost per gigabyte and the availability of higher capacities per drive. - See more at: 


Storage Trends 2015: The Year Of The eSSD | BCW

 

Conclusion

Sales of eSSDs will continue to grow through 2015 and beyond. As the cost per GB continues to fall, adoption will intensify and widen into new applications across the enterprise, while the adoption of new technologies and interfaces will further enhance the performance boost that eSSDs provide. To be successful in the competitive enterprise market, eSSD manufacturers will need full control of design and development of the next generation controllers and NAND flash memory cells. - See more at: 

Storage Trends 2015: The Year Of The eSSD | BCW

 

 

広告を非表示にする

ブログタイトル変更

某社でSSD(Solid State Drive)の商品企画を担当することになりました。

前職ではネットワーク系でしたが、元々長かったストレージ系の仕事に戻った形です。担当するのはエンタープライズ系の製品なので、エンタープライズIT分野という意味では一貫しています。

このブログはSSDエンタープライズ系中心)に関する最近の情報などを書いてみたいと思います。 

 

よろしくお願いいたします。

 

退職に伴うブログ名変更のお知らせ

私事ですが、今月一杯で現在の会社を退職し、2月より新たな活動を行うことになりました。転職に伴いまして、現職のテクノロジーとの関連が非常に強かった本ブログの名称(InfiniBand、RoCE等)も見直しを行いたいと思いますので、一旦ブログ名を削除し、仮の名称に変更しました。2月以降ブログを継続するかどうかは未定ですが、可能な限り継続したいと思っています。

お世話になった皆様へ

まだ来週1週間残っておりますので、若干早いですが、現職の2年7ヶ月の間、色々とお世話になりましてありがとうございました。

退職のご挨拶が行き届かない部分も多々あるかと思いますが、是非今後ともよろしくお願いできれば幸いです。

 

Twitter

 

以上、何卒よろしくお願いいたします。

 

RoCEv2アップデート

RoCEv2 IBTA標準化完了(2014年9月16日)

以前、当ブログでも紹介したRoCEv2(Ethernet上で動作するRDMA規格のIPルーティングできる新しい規格)が、先週2014年9月16日、InfiniBand関連規格団体であるIBTA(InfiniBand Trade Association)での標準化が完了した。

Press Release: IBTA - InfiniBand Trade Association

InfiniBand Trade Association Releases Updated Specification for Remote Direct Memory Access over Converged Ethernet (RoCE)
New specification enables RoCE routing capabilities for the evolving enterprise data center and hyperscale networking infrastructure

 

RoCEv2標準化完了 プレゼンテーション動画(英語)

 

従来のRoCE(RoCEv1)とRoCEv2の違い

下記比較表の通り、RoCEv1に比べ、RoCEv2はIPルーティングに対応し、サブネットを越えてRDMA通信ができるようになった。

f:id:kz_tomo:20140921005624j:plain

出典:Industry Ratifies RoCEv2 for Improved Hyperscale Computing 

パケットフレームとしては、下記のようにRoCE(RoCEv1)にはIPヘッダやUDPヘッダが無く、InfiniBandのL2ヘッダをEthernetヘッダ(MAC)に変えただけだったが、

f:id:kz_tomo:20140406165301j:plain

InfiniBandフレームとRoCEv1フレームとの対応

 

RoCEv2では、下図のようにIPヘッダ(L3ヘッダ)及びUDPヘッダ(L4ヘッダ)を備えている。中間にRoCE(IP Based)というものがあるが、これはRoCEv1.25なども呼ばれ(出典:Mellanox WinOF4.80 User Manual)、UDPヘッダがないものである。UDPヘッダは、L3でのルーティングにおいてマルチパス通信(ECMP: Equal Cost Multi Path等)を行う場合、L4のポート番号でのハッシュによるロードバランスが必要とされるため、UDPヘッダがある方が都合のよい場合がある。標準化されたのはUDPヘッダのあるRoCEv2である。

f:id:kz_tomo:20140921011428j:plain

出典:Mellanox MLNX OFED 2.3-1.0.1 User Manual(PDF)

RoCEv2パケットを見てみる

観察環境:

NIC:Mellanox ConnectX-3Pro (40GbE)

OS:RHEL 6.5

Driver : MLNX OFED 2.3-1.0.1

実行アプリケーション: ib_send_bw (MLNX OFEDインストールで一緒にインストールされるRDMA性能測定ツール。詳細は後述の性能測定例にて。)

RoCEv1 - 設定 特になし(ドライバデフォルトで動作)

RoCEv1パケットの構成:

  • Ethernet Type=0x8915(RoCE) : 後続のフィールドがIB GRH(Global Route Header)ヘッダであることを示している
  • IPヘッダはない(=IPルーティングはできない)

f:id:kz_tomo:20140921012509j:plain

RoCEv2 - 下記設定を実施

/etc/modprobe.d/mlx4.conf (無ければ作成)に、下記を追記する。

options mlx4_core roce_mode=2

追記後、ドライバのリスタートを実行する。

/etc/init.d/openibd restart

デフォルトでは、UDPポート番号は1021となる。変更する必要がある場合、/etc/modprobe.d/mlx4.confに、

options mlx4_core roce_mode=2 rr_proto=23456

などとする。

 

RoCEv2パケットの構成:

  • Ethernet Type=0x0800 : IPv4
  • IPヘッダがある(本例ではIPv4IPv6にも対応している)
  • UDPヘッダがある(本例ではDst portはデフォルトの1021、Src portは送信側アプリケーションによって様々に変わる=ECMPのマルチパス負荷分散が可能)

f:id:kz_tomo:20140921013307j:plain

 

RoCEv2性能測定例

測定環境(環境の都合により、上述のパケットキャプチャ時とは別環境):

NIC:Mellanox ConnectX-3Pro (40GbE)

OS:Ubuntu14.04LT

Driver : MLNX OFED 2.3-1.0.1

実行アプリケーション: ib_send_bw(使用方法は下図の実行例参照("ib_send_bw -h"でヘルプ表示))

接続構成: Mellanox 40GbEスイッチ経由接続(本例ではロスレス設定等は無し)

 

結果:約37Gbps程度の性能を確認(RoCEv1でも実施、ほぼ同等性能)

f:id:kz_tomo:20140921114027j:plain

RoCEv2ユーザー事例

当ブログでも以前紹介したが、Microsoft Azureのクラウドデータセンターで採用していると発表されている。


Microsoft Azureでの40GbE RoCE (RDMA over Converged Ethernet)活用 - Interconnect Your Future - InfiniBand and RoCE

 

下記のRoCEv2標準化完了に関するニュースでもMicrosoft Azureに関するコメントが記載されている。

 “RoCEv2 allows us to better scale our cloud deployment in a manner that is compatible with our evolving software defined networking infrastructure and growing virtualization demands, while achieving significant performance and efficiency benefits from RDMA,” said Albert Greenberg, partner development manager for Azure Networking at Microsoft. “Utilizing 40 Gigabit Ethernet solutions with RoCEv2 support is a key factor in enabling Microsoft Azure to efficiently, reliably and cost-effectively process the massive amounts of data required to support our customers’ wide range of workloads.”


Mellanox Announces Complete End-to-End Support for New RDMA over Converged Ethernet Version 2 (RoCEv2) Specification | Business Wire

 

 補足:RoCEv1/RoCEv2通信でのスイッチの要件

RoCEは、中間バッファを排除したアプリケーションメモリ間のダイレクトなRDMA通信を行うため、送信相手が確実に受け取れる前提で送信するプロトコルロスレス通信プロトコル)である。

一方、回線上のビットエラー等による一定レベルのパケットロスは、NICハードウェアで再送されるため、ここでの「ロスレス」とは、完全にパケットロスでなければならないという意味ではない。ロスレスとは、送信速度が受信速度を上回らない通信速度を自動的に保つ仕組みである。受信側が受信処理が間に合わない場合、送信側に「ちょっと待て」とか、「ちょっと送信速度を落として」と伝え、送信側は受信側からのフィードバックを踏まえて送信できればよい。

受信速度を上回る通信レートで送信する場合、受信が追いつかないことを意味し、追いつかない分は受信側で破棄(パケットロス)となる。送信性能と受信性能が釣り合っている環境の場合、ロスレスプロトコルが動いていなくても、結果的にロスレスとなることになる。

余談として、Ethernetスイッチのポートバッファが話題となることがある。スイッチのポートバッファは、受信側が間に合わない場合にもポートバッファ分だけ貯めておける仕組みだが、10Gbpsや40Gbpsといった高速な通信速度で通信する場合、ポートバッファで保留できる時間は非常に限定的であり、広帯域ネットワークでの本質的な解決策とはならないため、ロスレスプロトコルの導入が望ましい。

 

MellanoxコミュニティサイトでのRoCE関連まとめ記事紹介

(ポイントを補足を含めて日本語にて追記)

 RoCE v2 Considerations | Mellanox Interconnect Community

What are the network requirements for RoCE?
Both layer 2 and layer 3 RoCE share the requirement to configure the network for lossless operation. In fact, it does not mean that the network needs to be absolutely lossless. Some level of packet loss is acceptable. (for example as a result of bit errors that may occur at the physical layer). This is permissible as the transport protocol embedded within RoCE includes reliable services with built-in retransmission mechanisms. These reliability mechanisms are implemented in hardware and detect lost packets and retransmit without support required from software. An underlying lossless Ethernet network is required for RoCE traffic only in order to avoid systematic packet drops resulting from resource contention within network switches and adapters.

RoCEネットワークの要件とは?

  • RoCEの要件は、L2やL3(RoCEv2の場合)でのロスレス実現である
  • ビットエラー等による一定レベルのパケットロスはハードウェアで再送され、許容される
  • ネットワークスイッチやアダプタのリソース(処理能力やバッファサイズ)による構造的なパケットドロップは回避すべき(いわゆるロスレス

 

How do I achieve lossless Ethernet L2 network?
At the link level, it can be achieved by using flow control. Flow control is achieved by either enabling global pause across the network, or by the use of priority flow control (PFC). PFC is a link level protocol that allows a receiver to assert flow control telling the transmitter to pause sending traffic for a specified priority. PFC supports flow control on individual priorities as specified in the class of service field of the 802.1Q VLAN tag. Thus it is possible for a single link to carry both lossless traffic to support RoCE and other best effort traffic on a lower priority class of service.

ロスレスなL2 Ethernetネットワークはどのように実現するか?

  • リンク層では、フローコントロールによって実現可能
  • フローコントロールには2種類ある 
  • 1)Global puaseによる通信全体のPause(送信抑制)
  • 2)PFC(Priority Flow Control)による特定PriorityのフローのみのPause
  • PFCでは、802.1Q VLAN tagフィールドのCOSビットで指定されたPriority単位でPauseを実行し、同一リンクに複数の性質のフロー(ロスを許容するTCP/IP通信等)が混在する場合には有効

参考資料

HowTo Run RoCE over L2 Enabled with PFC | Mellanox Interconnect Community

 

 

If I run RoCE v2, should I use PFC or global pause for lossless L2 subnet?
In a converged environment lossy traffic share the same physical link with lossless RoCE traffic. Typically separate dedicated buffering and queue resources are allocated within switches and routers for the lossless and best-effort traffic classes that effectively isolates these flows from one another. Although global pause configuration is easier and might work nicely in a lab condition, it is recommended to use PFC in operational network in order to be able to differentiate between different flows. otherwise, In case of congestion, important lossy traffic, such as control protocols may be affected. Therefore, RoCE should run on a VLAN with priority enabled with PFC, while the control protocols (lossy) will run without flow control enabled on different priority.

RoCEv2を動作させる場合、PFCやGlobal pauseのどちらを使ったらよいか?

  • コンバージド環境(複数の用途の通信が広帯域ネットワークに統合された環境)では、Lossyなトラフィック(ロスを許容する通信)とLosslessなトラフィックロスレス通信)が混在
  • ロスレス通信のみをPauseさせ、Lossyなトラフィック(例えばハートビート等)は許容するPFCの使用が望ましい
  • (筆者注)ストレージ専用ネットワークのようにRoCEのみを使う場合はGlobal pauseでも問題ないと思われる

 

How do I preserve lossless characteristics on L3 network (between L2 subnets)?

Operating RoCE at layer 3 requires that the lossless characteristic of the network are preserved across L3 routers that connect layer 2 subnets. The intervening layer 3 routers should be configured to transport layer 2 PFC lossless priorities across the layer 3 router between Ethernet interfaces on the respective subnets. This can typically be accomplished through standard router configuration mechanisms mapping the received layer 2 class of service to the corresponding layer 3 Differentiated Serviced Code Point (DSCP) QoS setting.

L3ネットワークの場合、L2サブネット間でのロスレス性はどのように保持するか?

参考資料

HowTo configure RoCE v2 | Mellanox Interconnect Community

DSCP による QOS ポリシーの実装 - Cisco Systems

 

What happens when I use multi-path routing (ECMP) on L3 networks?
Rather than being constrained by layer 2 link-breaking protocols such as spanning tree algorithm, layer 3 networks can implement forwarding algorithms that take much better advantage of available network connectivity. Advanced data center networks can utilize multi-path routing mechanisms for load balancing and improved utilization. One commonly used protocol to achieve these goals is Equal Cost Multiple Path (ECMP). For each received packet the L3 Routers make a forwarding decision based on not just the destination IP address but also on other fields within the packet. In cases where there are many possible paths to a given endpoint ECMP allows different flows to select different paths and thus to leverage the available connectivity. The path selection for a given packet is based on the destination IP address and a hashed value of other packet fields. Note that while different flows can exploit different paths, the values used to select the output port for forwarding is deterministic such that packet ordering for a given flow is preserved.

 L3ネットワークでのECMPについては?

  • 先進的なデータセンタネットワークでは、L3でのECMPマルチパス活用でのネットワークが構成され、負荷分散と可用性を実現している
  • ECMPでは、L3ルーターでの送信先は、送信先IPアドレスだけでなく、パケットの他のフィールド値でのハッシュ計算で決定され
  • 1つのフローではパケット順序が保たれるようなフィールド値と計算方法が用いられる((筆者注)例えば、UDPポート番号)

 

広告を非表示にする