Kyoto Tycoon と GreenBuckets を組み合わせて使う - blog.nomadscafe.jp
分散Object Storageの GreenBuckets ではストレージノードの実装を問わないので、こういうこともできると言う例 Kyoto Cabinet の Directry Hash DataBase を使うと、ファイルシステム上の1ファイルが1レコードとなるデータベースを作成することができます。通常のDBMでは数KBまでの小さいデータに性能が最適化されているのに対して、Directry Hash DataBaseでは数十KB〜のデータを扱いやすくなるということらしいです。 もちろん、Kyoto Tycoon からも使うことができるので、GreenBucketsのストレージノードとしても利用できます。 まず、ktserver でノードを立ち上げます。今回は試しに1つのktserverで複数のデータベースを担当させ、それぞれ1ノードとして扱います。 $ ktserver -li -
GreenBuckets ノード障害時の動作と復旧方法 - blog.nomadscafe.jp
/* カラム名を変更しています 20110524 */ @kamipo さんが正座して待っているのを思いだした。 GreenBucketsで、ノードがダウンした時の動作と復旧方法です。GreenBuckets自体の動作実績はないのであくまで想定です。ただ、mixiの画像クラスタの構成をまねているので復旧方法もほぼ同じかもです まず、障害が起きて、復旧するまでの間を次の3段階にわけて対応を考えます 障害が発生し、アラート検知、運用者が対応するまで 運用者が対応を行い、一時復旧 データの整合性がとれ、完全復旧 ■ 障害が発生し、アラート検知、運用者が対応するまで さて、HDDが破損するなどしてサーバがダウンした場合、運用者が対応を行うまで、GreenBucketsは障害の影響をなるべく表に出さないよう、動作します 上の2つの図はノード1がダウンした状態を示しています。オブジェクトを取得する際(
Amazon S3 に自動で定期的にDB のバックアップをとるようにしました
Amazon S3 は利用量の上限がないですし、費用も割と安いので、バックアップ用のオンラインストレージとしては結構便利だと思います。SCP などの今まで使い慣れていたデータ転送の仕組みを使えないのが少し面倒に感じるかもしれませんが、それもシェルスクリプトなどで一度自動化してしまえば問題ありません。S3 へのデータ転送にはRuby 製のs3sync を使っていますが、これに関しては他に詳しい記事がございますのでそちらを参照してください。 S3sync について S3Sync.net - S3Sync Wiki Amazon EC2/S3を使ってみた - 8.EC2とS3のデータを同期させる(S3Syncを使う) バックアップを自動化 基本的に直近2ヶ月間は毎時バックアップを残し、それ以前は月初のデータだけ永続的に残すというポリシーで運用しようと思いますので、今回は以下の作業を自動化しました
グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineering
はじめに はじめまして、グリー株式会社でエンジニアをしておりますkgwsと申します。今回は、グリー内で写真データの保存を行っている分散ストレージ(nanofs)を紹介させていただければと思います。 背景 弊社で運営させていただいている "GREE" ではユーザの写真や動画データを保存することができます。1億ユーザを目指すグリーは、ユーザの増加とともに写真や動画データは上限なしに増加していきます。またユーザの皆様の大切なデータを失うことは許されませんし、サービスを止めることも許されません。そんな状況の中、様々な技術や仕組みを使いサービスを運営してまいりました。 グリーのストレージの歴史は大きく分けて3世代がありました。 第一世代 第一世代ではアプリケーションサーバからNFSサーバをマウントし画像データを保存しておりました。簡単に導入できることと高価なサーバを使用すれば信頼性や安定性も保たれる
サーバ仮想化環境でのお薦めストレージ構成 at nkjmkzk.net
A Place to discuss Oracle VM, Linux and Other Great Software.サーバ仮想化環境では「リソースプール」という概念を実現するために共有ストレージ構成が多く採用されます。しかし、そもそも現在のCPU性能とDISK I/O性能を鑑みれば、そもそもDISK I/O性能はCPU性能の進化に追いついておらず、共有ストレージ構成とすれば追い打ちをかけるようにそこがボトルネックとなります。多くの環境ではサーバ仮想化環境では「共有ストレージ型前提。しかしこれまでの何倍ものI/O性能が必要」という要件に対応するため、ミドル〜ハイエンドのストレージ装置を採用するという選択を行っています。その結果初期導入費用が高価なのはもちろんですが、そのあとも莫大な保守費を支払うことになります。そして拡張できるものの、拡張するためのパーツがまた高価、というスパイラルに陥
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
