[sfstudy] 発表のまとめ #sfstudy 02 [ストレージ友の会]

Pocket

Tweet

今更ですけれども、9月3日(土) に開催したストレージ友の会 #02 グループディスカッションを実施しました。その各グループの発表についてまとめました。
当グループディスカッションに関する所感につきましては、ニフティさんのblog へ寄稿させていただきましたので、@nifty ENGINEER BLOG中のストレージ友の会 #02 ～これからのバックアップを考える～をご覧ください。

今回は次の要求事項について、各グループにてディスカッションを実施していただきました。要求事項に含まないものは、好きに前提をおいてどのように対処しても構わないので、奇抜な発想を期待しています、と発破をかけました。
残念ながら私の期待するほどの奇抜なアイディアは出てきませんでしたが、面白い結果になったと感じています。面白い結果については「ストレージ友の会 #02 ～これからのバックアップを考える～」の所感をご覧ください。

要求事項

• 24/365 連続稼働予定のデータベースサーバー
• 3TB 以上のデータ蓄積があり、年率 20% 程度の伸張率でデータが増えていきます。
• ディスクは専用装置
• 0時を静止点とするデータがバックアップには必要です
• 毎日、テープへのバックアップが必要です
• 常にオンライン業務で利用しており、バックアップ取得時に極限まで I/O への負荷がかからないようにデザインする必要があります

各グループの発表まとめ

^[I]発表順ではありません

グループ#1

このチームの特徴は、スナップショットを Cloud ストレージへとって、テープを使わずに Amazon EBS へデータを転送する、と言う部分です。他にも重複排除などのキーワードもあります。キーワードとしては現在先端のテクノロジーを利用することで、できる限り要求に応えようとしているところが見て取れます。
ただ、「テープへの」という要求がクリアされていないことと、フルバックアップを最初に取得するだけで、その後はアーカイブログを保管していくという流れでは、リストアの時に最初のフルバックアップからその時点までの全てのアーカイブログを適用する必要があり、現実的ではありませんでした。

sfstudy02_team01

View more presentations from lc23twr

グループ#2

VTS ^[II]Vitrual Tape Server と Solaris ZFS を組み合わせ、それらを Xen 上で稼働させて Xen の Snapshot を取得するバックアップ方法です。ストレージは iSCSI 接続として安価に済ませている辺りは小ネタが効いています。
最後に、「一番実用的なのはどれか」アンケートを採ったときに、最も多い得票数を稼いでいた内容で、バックアップ手法的には筋が通っていて一般的です。また、スナップショットを Xen から取得することで、システムの復旧も可能ということまで見込んでいました。
欠点は一般的だったことですね。とは言え、現時点で実用的なバックアップ手順の組み合わせを安価で示そうとすると、この方法に行き着くのかも知れません。奇抜さはありませんでしたが、堅実でした。VTS からテープへの落とし込みについては記述なかったと記憶していますが、そこまで押さえられれば十分です。

グループ#3

DBサーバを MySQL として、Master/Slave 構成にし、Slave 側からバックアップを取得して、それを案かな HP Tape Loader へデータを書き込む流れとしました。I/O に負荷の発生しないように Slave 側から取得するようにしたのが工夫点でしょう。
これも RDBMS が MySQL だった場合、というコトで着目した場合には良い方法です。これも奇抜なアイディアではありませんけどね。あとは、大容量データを Slave とはいえそこまで日々バックアップ取得していくことが現実かどうかの担保について検討が必要そうです。

グループ#4

このチームも Master/Slave 型の DBサーバ配置ですが、ストレージ内にも Master/Slave 及び「SQL保管領域」を保持しました。バックアップの静止点を取った後、SQL の実行内容については SQL 保管領域に退避することで、静止点をアプリケーションで作ってやってしまおうという内容です。
スナップショットの取り方をディスク上のデータの静止点ではなく、SQL の静止点に着目した部分については、新しいアイディアだと感じました。ただし、LTO5 が高いのとアプリケーションでの作り込みの影響度合いが分からず、安定+実運用上の懸念はありそうですね。

ストレージ友の会#02 チーム#4発表資料

View more presentations from Chikahiro Yamamoto

グループ#5

奇抜さでは群を抜いていたのではないかと、今頃になってジワジワ来ています。
運用をインドで実施することで、オペコストを抑えます。NetAPP とバックアップサーバを組み合わせて、DDS で組み合わせ、日々の更新データを Gmail で送りつけるという内容です。運用自体を海外の安価なグローバルリソースにおくことで、安価に押さえようとする努力、考え方は良いことだと感じました。また、Gmail へデータを保管するというアイディアは新しいです。奇抜さでいけばこれが一番でしょう。Gmail へ保管しておくことによって DR ^[III]Disaster Recovery 対策とする思考の柔軟性は見習いたい部分です。
とはいえ、リカバリーの手順や実運用を考慮した場合の懸案事項と、Gmailの Annuity など逆にコストのかかる部分が出てきているところが若干残念でした。

Sfstudy#2チーム5

View more presentations from Yasuhiro Arai

グループ#6

ここは視点が最初からずれていて、アーキテクチャではなく、観点が奇抜でした。アーキテクチャー自体は普通です。
DBサーバは Master/Slave/Backup サーバを準備し、ストレージ内で 2つ領域を持ち、レプリケーションをする方法です。奇抜な観点は、ハードウェアは NTT-Xやオークションで安価に調達し、ソフトウェアはもちろんオープンソースで無料、保守は自宅SAN友の会で運用する、と言う「安価」にするための方策を提示する形で奇抜さを表現してきました。挙げ句の果て、ストレージもVTSも自作するといった手の込みようです。スライドもうまいですね。
問題は価格コストのメリットが全て、島崎さんのところへ追いやってごまかしているとこでしょうか。障害が出ないといいですね。

Sfstudy #2

View more presentations from (^-^) togakushi

グループ #受付

オチ専門グループ集団、グループ#受付です。メンバーは流動的なのに、やることも結論もあまり変わらない素敵なブレインを持った人たちで構成されています。
奇抜という点では HDD を毎日 AWS から送ってもらうとか、AWS で全運用するとか、ニフティでの開催にもかかわらず、全て Amazon に頼った作りになっていてこわい物知らずです。オチとしてはいいデキですね。
実運用としては多分運用不可だと考えられますし、HDD 送付を毎日やっていると、結構お金がかかる気がします。残念ながらネタとしては秀逸ですが、アーキテクチャーとしては悲惨でしたw
考え方としては、悪くないと思いますけどね。

Sfstudy02 team UKETSUKE

View more presentations from mamoru tateoka

最後に、縦軸に「奇抜さ」横軸に「コスト」を評価軸とした四象限マップを当時作って貼り付けていたものを公開します。
上に行くほど奇抜、下へ行くほどレガシー、左へ行くほどコストが高く、右へ行くほど安価、と言う構成です。

コスト評価的には、おおむね安価により、ばらばらな傾向になりましたが、奇抜さがあまり突飛に上に出るものがありませんでした。そのあたりは残念です。
実のところ、要求事項自体には穴が多かったので、いろいろな前提を置くともっと奇抜な構成が可能だっただろうと予測していましたが、誰もその「穴」をついてこなかったのは、行儀が良いことと、バックアップとはこうするべき、こうあるべき、という考えがあったんだろうと考えています。
たとえば、このDBサーバは更新系ではなく、データ蓄積型だったら・・・、データのレプリケーション先を常にテープにするとか・・・また新しい発想が出てきたのではないかと感じています。

ですが、勉強会での短い時間でのグループディスカッションの主目的は、答えを出すこと、よりも皆が知恵を絞って考え出す、と言う過程にあると考えています。ですから、この短時間の間にこれだけのアイディアが出てきたこと、まとめられたことは私も含めて勉強になったことと感じています。これからも、「考える」と言うことを忘れずに新しいものへの挑戦を忘れず、エンジニアとしての階段を上っていきましょう。

では、また次回。