プロフィール
ウルトラ同時ユーザー、大規模なコンピューティング、ストレージ、クラスタのパフォーマンスが良くなっ、ストレージ・ハードウェア技術の継続的な発展を促進する必要があり、全体的なIOパスのより多くの低レイテンシ性能要件も増加しています。クラウドシーンでハードディスク、ストレージクラスタの後端からIO要求を生成して、IO複合体との間のパスを返すために、すべてのIOは、仮想マシン内の次にそれを送信する必要があるため、仮想IO特定のパスは、パフォーマンスのボトルネックになることがありバックエンド・ストレージ・システム。私たちは、仮想化SPDK IOパスを最適化するために使用、最大120万のRSSDクラウドハードドライブをオープンソース未解決SDPKホットアップグレードおよびオンライン移行シナリオを提案し、成功した高性能なクラウドディスクのシナリオに適用され、良い結果を達成しましたIOPS。本稿では、この分野での経験の一部を共有しています。
2つのSPDKのバーチャルホストの基本原理
SPDK（ストレージパフォーマンス開発キット）ユーザーモードに分け本質的になる、高パフォーマンスのために準備セット、ライブラリとツールに保存されたスケーラブルな、ユーザーモードアプリケーションを提供することで、ポーリング、非同期、全くロックのNVMeドライブがから提供されていません直接SSDゼロコピーにアクセスするためのユーザー・スペース・アプリケーション、高度な並列アクセス。
IO仮想パスで、より一般的に半仮想化ソリューションのvirtio使用され、底部があるのvirtio VRINGを介して通信する、第一のvirtio VRINGを導入の基本原理以下、それぞれのvirtio VRINGは、主に以下のセクションが含まれ：
DESCテーブルアレイは、アレイは、デバイスキューの深さのサイズ、典型的には128に等しいです。配列の各要素は、IO要求を表し、エレメントを指すポインタは、長さ等の保存用データメモリIOアドレス、IO基本情報に含まれます。一般DESC配列要素に対応するIO要求は、当然のことながら、IOメモリの複数のページに関連し、それは使用されるリンクされたリストDESCを複数接続する必要がある、未使用desc要素は、それ自体で次のポインタをfree_headに接続し、形成されています。その後の使用のためのリスト。
IO要求を処理するときに円形アレイで利用可能な配列は、それぞれ配列DESCインデックスaを表し、IO要求に対応するDESC配列を見つけるために内側からなり、配列のインデックスを取得します。
これは、アレイ、アレイを使用し、同様の役に立つが、IO要求の完了を示すために使用されます。IO要求の処理が完了すると、要求DESC配列インデックスが配列に格納され、スキャンのフロントエンドは、完全な回復はDESCが要求に対応する場合のvirtioドライバは、要求されたデータが終了したか否かを判断する通知されます次の配列エントリIO要求へ。
SPDKは、処理、原理はSPDKアレイをVRING上記のvirtioに情報を送信するために第1のQEMUのバーチャルホストドライブの初期化によって、単純であり、その後IO要求が停止ホイールによって使用可能SPDK配列を見つけるためにかどうかを決定する、処理する要求があったバーチャルホストインデックスは、各フロントエンドのvirtioのeventfd通知することにより、使用される配列に追加した後。
SPDK IO要求は、要求へのポインタのみを受信した場合、処理する際に、直接、このメモリにアクセスできるようにする必要があり、アドレスポインタはアドレス空間のQEMUで、明らかに直接使用するので、いくつかの変換を行うために必要性が存在することはできません。
仮想SPDK機密使用ラージ・ページ・メモリーを使用する場合は、SPDK初期に送信された情報の中の仮想マシンは、大きなページメモリになり、SPDKので、mmapの独自のアドレス空間に同じ大きなページメモリによる情報とマッピングを解析し、実装する共有メモリ、オフセット簡単にアドレス空間SPDKへのポインタに変換することができますを計算することで、ポインタSPDKのQEMUのアドレス空間を取得します。
私たちは、プロセスの迅速な移動が完全に大幅にパフォーマンスIOパスを改善し、送信された2つのポインタのメモリをコピーする必要がないことな方法かもしれIO要求で共有上記の原理SPDKのバーチャルホスト大規模ページのメモリーから見ることができます。
私たちは、単に仮想化IOパスの性能を比較するために、我々は直接IOを受けた後に返すために使用する方法を以前にした後SPDKのバーチャルホストを使用して遅延と遅延を使用し、クラウドQEMUのディスク・ドライブを比較しました：
1.シングルキュー（1 iodepth、1 NUMJOB）
QEMUネットワークディスク・ドライブ・遅延：
SPDKのバーチャルホストの遅延：
単一キューが非常に明白な遅延、7.3usにダウンオリジナル130usから平均遅延立ち下がり見場合。
2.マルチ・キュー（128 iodepth、1 NUMJOB）
QEMUネットワークディスク・ドライブ・遅延：
SPDKのバーチャルホストの遅延：
単一のキューよりもマルチキューIO待ち時間は、一般に、大きなマルチシーン平均遅延は、元の1/3に落とし、1090usに3341usから減少に、キューを見ることができます。
三のSPDKホットアップグレード
在我们刚开始使用SPDK时，发现SPDK缺少一重要功能——热升级。我们使用SPDK 并基于SPDK开发自定义的bdev设备肯定会涉及到版本升级，并且也不能100%保证SPDK进程不会crash掉，因此一旦后端SPDK重启或者crash，前端qemu里IO就会卡住，即使SPDK重启后也无法恢复。
我们仔细研究了SPDK的初始化过程发现，在SPDK vhost启动初期，qemu会下发一些配置信息，而SPDK重启后这些配置信息都丢失了，那么这是否意味着只要SPDK重启后重新下发这些配置信息就能使SPDK正常工作呢？我们尝试在qemu中添加了自动重连的机制，并且一旦自动重连完成，就会按照初始化的顺序再次下发这些配置信息。开发完成后，初步测试发现确实能够自动恢复，但随着更严格的压测发现只有在SPDK正常退出时才能恢复，而SPDK crash退出后IO还是会卡住无法恢复。从现象上看应该是部分IO没有被处理，所以qemu端虚机一直在等待这些IO返回导致的。
通过深入研究virtio vring的机制我们发现在SPDK正常退出时，会保证所有的IO都已经处理完成并返回了才退出，也就是所在的virtio vring中是干净的。而在意外crash时是不能做这个保证的，意外crash时virtio vring中还有部分IO是没有被处理的，所以在SPDK恢复后需要扫描virtio vring将未处理的请求下发下去。这个问题的复杂之处在于，virtio vring中的请求是按顺序下发处理的，但实际完成的时候并不是按照下发的顺序的。
假设在virtio vring的available ring中有6个IO，索引号为1，2，3，4，5，6，SPDK按顺序的依次得到这个几个IO，并同时下发给设备处理，但实际可能请求1和4已经完成，并返回了成功了，如下图所示，而2，3，5，6都还没有完成。这个时候如果crash，重启后需要将2，3，5，6这个四个IO重新下发处理，而1和4是不能再次处理的，因为已经处理完成返回了，对应的内存也可能已经被释放。也就是说我们无法通过简单的扫描available ring来判断哪些IO需要重新下发，我们需要有一块内存来记录virtio vring中各个请求的状态，当重启后能够按照该内存中记录的状态来决定哪些IO是需要重新下发处理的，而且这块内存不能因SPDK重启而丢失，那么显然使用qemu进程的内存是最合适的。所以我们在qemu中针对每个virtio vring申请一块共享内存，在初始化时发送给SPDK，SPDK在处理IO时会在该内存中记录每个virtio vring请求的状态，并在意外crash恢复后能利用该信息找出需要重新下发的请求。
四 SPDK在线迁移
SPDK vhost所提供的虚拟化IO路径性能非常好，那么我们有没有可能使用该IO路径来代替原有的虚拟化IO路径呢？我们做了一些调研，SPDK在部分功能上并没有现有的qemu IO路径完善，其中尤为重要的是在线迁移功能，该功能的缺失是我们使用SPDK vhost代替原有IO路径的最大障碍。
SPDK在设计时更多是为网络存储准备的，所以支持设备状态的迁移，但并不支持设备上数据的在线迁移。而qemu本身是支持在线迁移的，包括设备状态和设备上的数据的在线迁移，但在使用vhost模式时是不支持在线迁移的。主要原因是使用了vhost之后qemu只控制了设备的控制链路，而设备的数据链路已经托管给了后端的SPDK，也就是说qemu没有设备的数据流IO路径所以并不知道一个设备那些部分被写入了。
在考察了现有的qemu在线迁移功能后，我们觉着这个技术难点并不是不能解决的，因此我们决定在qemu里开发一套针对vhost存储设备的在线迁移功能。
块设备的在线迁移的原理比较简单，可以分为两个步骤，第一个步骤将全盘数据从头到尾拷贝到目标虚机，因为拷贝过程时间较长，肯定会发生已经拷贝的数据又被再次写入的情况，这个步骤中那些再次被写脏的数据块会在bitmap中被置位，留给第二个步骤来处理，步骤二中通过bitmap来找到那些剩余的脏数据块，将这些脏数据块发送到目标端，最后会block住所有的IO，然后将剩余的一点脏数据块同步到目标端迁移就完成了。
SPDK的在线迁移原理上于上面是相同的，复杂之处在于qemu没有数据的流IO路径，所以我们在qemu中开发了一套驱动可以用来实现迁移专用的数据流IO路径，并且通过共享内存加进程间互斥的方式在qemu和SPDK之间创建了一块bitmap用来保存块设备的脏页数量。考虑到SPDK是独立的进程可能会出现意外crash的情况，因此我们给使用的pthread mutex加上了PTHREAD_MUTEX_ROBUST特性来防止意外crash后死锁的情况发生，整体架构如下图所示：
五 SPDK IO uring体验
IO uring是内核中比较新的技术，在上游内核5.1以上才合入，该技术主要是通过用户态和内核态共享内存的方式来优化现有的aio系列系统调用，使得提交IO不需要每次都进行系统调用，这样减少了系统调用的开销，从而提供了更高的性能。
SPDK在最新发布的19.04版本已经包含了支持uring的bdev，但该功能只是添加了代码，并没有开放出来，当然我们可以通过修改SPDK代码来体验该功能。
首先新版本SPDK中只是包含了io uring的代码甚至默认都没有开放编译，我们需要做些修改：
1.安装最新的liburing库，同时修改spdk的config文件打开io uring的编译；
2.他のBDEVのリファレンス実装はuring機器IO RPC呼び出しのために加え、私たちはBDEVのような他の装置を作成するようにIO uringデバイスを作成することができます。
3.最新liburingはio_uring_get_completionをコンパイルするときio_uring_get_completion機能を見つけることができませんio_uring_peek_cqeに呼び出し、io_uring_cqe_seen使用を満たすために必要なので、我々は、エラーを回避するために、実装の下IO uringコード調整にSPDKする必要があります。
4.私たちのデータははfdatasync呼び出すよりもリターンの床、および高効率に書かれていることを確認するために、ファイルを開いて、私たちは、BDEVは、同じ変更をしたAIO O_SYNCモードを使用し、オープン呼び出しを変更し、読み書きモードを追加します。
これらの変更は、IO uringデバイスが正常に出て作成することができますspdk、我々は次の性能比較を行った後：
AIOのBDEV時間を使用します。
IO uringのBDEV時間を使用します。
uring IO最高のパフォーマンスとレイテンシで見えるが良いという利点があり、約10％遅れ、約20％向上IOPS。この結果は、基礎となるハードウェアの最大の性能によって制限され、実際に、それはまだuring IO上限に達していないされています。
六の概要
SPDKアプリケーションの仮想化技術は、パフォーマンスIOはアップグレードパスがもはやボトルネックになって、またUCloud高性能クラウドディスク製品に貢献することは、バックエンド・ストレージのより良いパフォーマンスを再生することはできませんになります。もちろん、技術のアプリケーションはそれほど滑らかではない、我々はまた、上述の共有に加えて、使用SPDK中に我々はまた、SPDKコミュニティに提出されたいくつかのバグフィックスなどの多くの問題に遭遇し、高速な反復型開発などSPDKプロジェクト、私たちの驚きの各バージョンは、私たちが発見し、さらにディスクや他の製品の性能にクラウドを強化するために使用するのを待っている多くの興味深い機能もあります。