こんなん本当に使っていいの?って思っちゃったぐらい。今回試した経緯コレを試した理由としては、昨今のオブジェクトストレージの使い方の一つとして、FUSEと言う手法があることを知ったそれを応用したクラウドとの連携を試してみたかった事が挙げられます。いうのも、実は休職前にオブジェクトストレージと連携したストレージヘッドが提案の選択肢として浮上したことがあるんです。実際にどういう風にデータが解釈され、そして配置されるのか、暗号化に伴うオーバーヘッドや差分はどう扱われるのか?と言うところが当時は気になったものの、評価とかをする暇もなく、当時はお蔵入り案として選択肢から消したのですが、実際どういう代物なんだろう?と近似した仕組みでもいいから試したかったというのが一番の理由です。課金がちょいと怖いんですが、容量やファイル数から月額を試算した所、どうやらなんとか$10以内に収まりそうに見えたため、勇気を振り絞って踏み込んでみたのでした。大前提:S3へのバケット新規作成ここは大まかにしか説明しません。AWSコンソールへログインし、S3バケットを新規作成します。本記事ではバケット直下にs3qlデータを配置するようにしていますが、実際には1階層ディレクトリを作っておいたほうが良いです。理由としては以下の点です。同一バケット内にデータが保存され、統一ポリシーのもとでデータ運用ができるディレクトリに対して可用性レベルの設定が行えるバケット直下だと、全部Standard扱いになり、例えば今回のような可用性をそこまで求めない場合だとRRS(低可用性ストレージ)の選択が困難になります。AMコンソールを開き、グループとユーザを作成します。グループポリシーには、AWSS3FullAccess権限を付与すると良いようです。Keyを控えておきます。これは後の作業で必要になります。←任意のパスワードを入力します。passwordで入力したものをもう一度入力します。~/.s3ql/authinfo2以下の通り編集します。←ファイルシステムに適用したパスワードを入力します。/etc/init.d/s3ql以下の通り編集します。;;esac保存後、以下の通りコマンド実行し、実行属性を付与します。その後、サービスとして登録します。]マウント状態を確認する。/s3_storage一番下の行にS3のバケットがマウントされていることがわかると思います。容量について、初期値としては1.0TiBと言う扱いになるのですね。実際のバケット内にはチャンクされたデータファイルが入ってました。]マウント状態を確認する。/run/user/0S3バケットのマウントが解除されていることがわかると思います。onあとはサービス起動しとく。言うディレクトリに対してS3上のバケットと接続が行われ、ファイルシステムとしてアクセスができるようになります。S3上のバケットはどうなっているか?S3上のバケットでは、データは全てチャンク化されており、どれがどのデータかわからないようになっています。暗号化も加えられているため、ファイルを拾われてもまともに開けません。Averageもそれなりに高いです。現状、15:00頃から処理を開始して、16:45の時点で18GB程度のデータ転送が完了しています(総量は80GB弱ぐらい)。いうことで、およそ780MB/min(13MB/sec)ぐらいのスループットでデータコピーしているようです。考えると、かなりイッパイイッパイ帯域使ってデータコピーをしているように見えます。(実家のバックボーンは100Mbpsだから)その後、かな~りの時間をデータコピーに要しましたが、2:04に処理がやっとこさ完了しました。結果は以下のような感じ。1.56コピー終了までどえらく待たされた感じになりましたが、要所要所で見る限り、以下の傾向が見られました。それなりにあるようです。78GBの領域をバックアップしましたが、およそ58GBぐらいになってました。効果としては16%の容量削減ができてるようです。重複排除が聞いている場合の処理はかなり高速でした。ポインタ付処理のみで済んでしまうため、その間のIO処理能力が上がったんだと思われます。キャッシュ領域の使用量はピークで10GB程度、時々眺めましたが、それ以上の容量は使ってなさそうでした。root-vgは40GBで構成しているんですが、別領域を構成する必要は今のところなさそうです。動いてるとたいていメモリを結構食うはずなんですが、ピークでも10%前後で済んでました。処理実行したサーバはメモリ8GB搭載しているんで、およそ1GB弱程度がピークなんじゃないかなと思われます。重複排除の単位がブロックではなく、ファイル単位なんじゃないかな?とコピー処理の動きを見てると感じました。・・・と思ったら、どうやらブロック単位の重複排除みたいです。(s3qlの説明についてこちらが参考になるかと。17.3章を参照のこと。)キャッシュディレクトリの状況デフォルト設定だと、キャッシュはローカルディスクになります。ディレクトリ配下にキャッシュディレクトリが作られ、そこに格納されます。.rsync処理が進んでいくとこうなりました。.あらまぁ、立派に成長しちゃって・・・9GB近くキャッシュ領域を使用している状況を確認しました。コピー終了まで見続けた結果、これがピーク値だったようです。ジョブの仕込みコピーも無事終わったということで、これを定期実行ジョブにしました。hinemosのコマンドジョブにバックアップ処理を追加しています。隔地保管ジョブである「NFSBACKUP_CMD」が正常終了したら「S3BACKUP_CMD」を実行するようにしています。領域からコピーバックする感じになります。Mastodonインスタンスのスタートは別にこのS3バックアップ処理を待つ必要はないため、開始条件は変更していません。初期同期は11時間ぐらいかかりましたが、差分同期はどのぐらいかかるかな?ある意味見ものです。終わりに最近こうしたオブジェクトストレージと連携したストレージ製品が増えてきています。いうのも、最近のユーザの傾向として「資産を持ちたくない」と言うものが挙げられます。できるだけクラウドへシフトしたい、だけど、クラウドに接続する際の回線コストが・・・・あるいは拠点間のデータ整合性が・・・・と悩んだ際に、こうしたオブジェクトストレージは安価なので、だいぶ使い勝手が良いようです。そのことを狙い、各拠点にはストレージヘッドとして、いくぶんかのキャッシュ容量をSSDなどで積んでおき、使われないデータはオブジェクトストレージから取り出す、そんな製品がちらほら出てきました。表向きのデータ転送速度は向上させる事が可能(オンプレ並みのパフォーマンスに近似できる)大容量のデータ保管をオブジェクトストレージ設備の可用性に頼る確かに外部にデータは書き出してしまうが、オブジェクトストレージから直接データを取り出してもアプライアンスがないと読み出しできないことでセキュリティレベルも担保できるこうしたところなんかが、「資産を最低限にしたい」と言うニーズにマッチしているようです。実際には、「オブジェクトストレージの設備が倒れたらどーすんの?」と言うのがあったりします。そこを思考停止して、クラウドバンザイと言うのは少々違和感はあるのですが、データの多重化を考えたときの一つの方策として、その一つにこうした製品やサービスを連携させるのはありなのかもしれません。それにしても、クラウドとの連携の仕方の一つとして、これはかなり勉強になりました。久々のストレージネタになりましたね(笑)外にどんなものがあるのかこんなスライドを見つけたのでリンク張っておきます。バケットをそのままファイルシステムとしてみせるソフトウェアバケット上には、そのままファイルが置かれる。S3コンソールからファイルが普通に見れる。goofysファイルシステムのデータをバケット上に保存するソフトウェアバケット上には、ファイルシステムを構成するためのチャンクデータが置かれる。S3コンソールからは構成ファイルとしてしか見えない。ESXi今回、面白そうな製品を見つけた。製品名の通りフリーでございます。この製品、ホストOSやらVM上のゲストOSやらの管理ができるようで、なかなか見た目に面白いと。Agentが立ち上がらなくなりました。Summit400-24の電源を投入した。その際に基本的なコマンドとか打ち込んだりしたんで、備忘録として。IPMPを組むIPMPを組んでみた!と言うわけで記事にする。今回の構成はこんな感じです。他のサーバと同じように、1つのGigabitスイッチに2つのインタフェースを接続します。4LFFですが、その弱点はズバリ拡張性の低さです。PCI-eスロットはわずか2つ、HDDベイは4つしかありません。netmikoは抽象化の度合いこそ低いものの、対応デバイスの多さが特徴です。対応デバイス名の記載について言及があまりなく、実際どんなものがあるのかはGithubのソースを見ないとわかりません。StoreOnce-CatalystタイトルとURLをコピーしました。