技術情報

とよぢぃのねっとあっぷ四方山話　第12回

とよぢぃのねっとあっぷ四方山話

DISのとよぢぃと申します。
『ねっとあっぷ四方山話・ネットアップの技術紹介（4）』をお届けします。

これまでにADP（Advanced Drive Partitioning）とかARP（Autonomous Ransomware Protection）についてご紹介してきましたが、やはりネットアップのと言うか、ONTAPのテクノロジーの紹介で忘れてならないのはSnapshotとSnapshotをベースにしたSnapホニャララ系の機能ですよね。ということで、今回はSnapホニャララのベースになるSnapshotについてご紹介しておこうと思います。

ネットアップに限らず多くのストレージシステムが名前は違ってもスナップショット機能を持っています。機能の見た目的には別に目新しいものでもありませんし、難しいものではなくて、Point-in-Timeイメージやコピーをなんらかの方法でバックアップ的に保管するような仕組みです。また、このバックアップから復元する仕組みはPoint-in-TimeリストアとかPoint-in-Timeリカバリとか呼ばれます。「Point-in-Time」とは「ある時点」とか「ある瞬間」みたいな意味なので、ある時点（瞬間）のファイルシステムの状態をバックアップするのがスナップショットだと思っていただいてほぼほぼ間違いありません。機能の外見、見た目的にはある時点のイメージやコピーを保管したりその状態に復元するための仕組みということになります。
システム（OS）の内部を覗いてみると、スナップショットには大きく分けて2つの方式があります。一つはCopy-on-Write（CoW）、もう一つがRedirect-on-Write（RoW）です。ネットアップのSnapshotはRoWですが、どちらの仕組みにも一長一短あるので、まずはそれぞれの仕組みについて簡単にご紹介しておきます。
一般的にスナップショットと呼ばれる機能ではスナップショットによるPoint-in-Timeバックアップの取得時にファイル（データ）のコピーが行われたり、ストレージ容量を大きく消費したりすることはありません。これはCoW方式でもRoW方式でもほぼ同じです。CoWとRoWで動作が変わるのはスナップショット取得後にスナップショットによるバックアップの対象になったファイルの書換え（-on-Write）を行った場合です。書換え後（時）にファイルのコピーが発生するのがCoWであり、リダイレクトが発生するのがRoWです。このコピーかリダイレクトかの違いがCoWとRoWの一長一短の差になって表れることになります。で、コピーの場合は何が起こるのかなんとなく想像できますよね。コピーですから。しかし、リダイレクトって何が起こるのかよくわからなくないですか。これは後で説明するので、しばしお待ちを。

では、まずはCoWの場合。
CoWではスナップショットでバックアップ対象になったファイルが書換えられるとそのファイルが元々存在していたファイル領域（プライマリファイルシステム、アクティブファイルシステム）からバックアップ用の領域にコピーされます。ファイル全体がコピーされるものもありますし、ファイル内の書き換えられた部分（ブロック）だけをコピーするような仕組みもあります。いずれにしてもファイルやブロックのコピーを保存するための専用のバックアップ領域が必要になります。専用なので、この領域にユーザが直接データを書き込んだり、この領域にあるデータの削除や変更は通常はできません。この方式ではバックアップ領域の容量もそれなりに必要になりますからストレージ全体の規模が大きくなる傾向があります。


また、ファイル書き換え時に、ファイルやブロックのコピーが発生するということはストレージシステムのコンピュートリソース（CPUやメモリ、内部バス）などもそれなりに消費することになるので、ストレージシステムのパフォーマンスにも少なからず影響が出ることになります。多くのユーザがたくさんのファイルを書き換えたりすると、このコピーがずっと続くことになるので、ストレージのパフォーマンスに結構大きな影響を与えることになります。


ユーザが自由に使えないスナップショット専用のストレージ領域が追加で必要になるとか、性能に影響が出るとか言うあたりがCoWスナップショットの一長一短の『短』の部分になります。では、『長』は何かという、ファイルのコピーがもともとの領域とは別の専用の領域に保存されるわけですから、バックアップとしては有効な手段と言うことになります。まぁ、ファイル内の書き換えられた部分（ブロック）だけがコピーされるような仕組みの場合は、『長』とは言いにくいですね。ファイルの一部分しか別領域に保存されてないわけですから、バックアップとしての意味はかなり薄れちゃうので。

つぎに、ネットアップONTAPでも採用しているRoW方式について。
CoW方式のスナップショット方式ではその名の通りデータのコピーが発生しますが、RoW方式のスナップショットではコピーは行われません。RoW方式では書き換えられるデータはそのままにしておいて、書き換えるデータを同じファイルシステム内の別の場所に用意し、ファイルを構成するポインタを張り替えることでファイルを更新します。この「ポインタの張り替え」という動作をリダイレクト（Redirect）と呼んでいます。右側の一連の図を見ていただければわかると通り、リダイレクトではデータのコピーは行われません。CoW方式で短所として挙げたようなことは起こらないので、ストレージシステムのパフォーマンスに影響するようなことは仕組み的に発生しません。もちろん完全に0と言うわけではありませんが、データのコピーと比べたら格段に小さな負荷だということです。またコピーしないわけですから専用の領域が別に必要になることもありません。これがRoW方式の『長』になります。その代わりと言ってはなんですが、ポインタは一つのファイルシステム内でのみ有効な情報なのでリダイレクトした先も元も同じファイルシステム内にあることになりますから、バックアップとしての意味合いは薄れることになります。これがRoW方式の『短』の部分になります。
なお、データの変更量が非常に多い環境でRoWを使用するとプライマリファイルシステム内に変更差分のデータを保持しなければいけないので、それなりに大きなプライマリファイルシステムが必要になります。CoWのような別の専用領域ではありませんが、データの変更分を保持するという意味では同じなので。
ONTAPではこの差分データ（5. の[O]のブロック）用にファイルシステムの何％を割り当てるか（Snapshotリザーブ）と言うのを設定できるようになっています。デフォルトは5%ですが、5%を超えた場合は残りの95%のユーザデータ領域を侵食していきます。実はSnapshotはONTAPの内部的にも非常に重要な機能なのでこのような動きをします。

さて、ONTAPのSnapshotって仕組み的に結構イケてると思いませんか。ポインタ操作だけなのでSnapshotの取得は瞬時に完了します。さらに取得時だけでなく、その後のデータの書換えに際してもとても性能面でのオーバーヘッドが小さい（ほぼ皆無）うえ、余分なストレージ容量も必要ないわけですから…

でも、ここまでに紹介した図には実はちょっとしたウソがあるんです（すみません）。まぁ、ONTAPのSnapshotの動作をわかりやすくするためのウソではありますが…　例えば、図で使用したようなファイル（hello.txt）が1万個あったとしましょう。1ファイル当たり5個のポインタなので、全部で5万ポインタ。いっくら優れたOS（ファイルシステム）と超速いストレージを用意したって5万個ものポインタを一瞬で張れるわけがないですよね。実は、ONTAPではSnapshotの取得時にポインタを1つしか張らないんです。
ONTAPのボリュームには.snapshotと言う名前の特別なフォルダが用意されています。ここでsnap1と言う名前でSnapshotを取得すると.snapshotフォルダにsnap1というエントリが作られてもとのボリューム（/vol/vol1）へのポインタが張られます。Snapshotの取得はこれで終わりです。
その後、このボリューム内のデータに変更を加えると変更に関連するデータブロックが未使用領域に新たに配置されて/vol/vol1からのポインタが張り替えられて変更が完了します。元のデータへのポインタ（赤矢印）はsnap1からの参照のために使われることになります。

いかがですか？　正確な図にしようと思うと、フォルダもファイルなので、ちょっとした変更でも結構多くのデータが追記（変更）されることになり、図がグチャグチャになってしまうのでかなりはしょった絵になってますが、ネットアップのSnapshotのおおよそのところはお判りいただけたのではないかと。
ということで、次回以降、このSnapshotをベースにしたONTAPの機能についていくつか代表的なものをご紹介していこうと思っています。

とよぢぃ