今回からはLXCがコンテナイメージを置く領域に使えるいろいろなストレージバックエンドを利用し、LXCを便利に使う方法を紹介していきます。 LXCでいろいろなストレージバックエンドを利用する方法を紹介する前に、今後コンテナでの利用が増えそうな、3.18カーネルで新たに追加されたoverlayfsについて紹介しておきましょう。 タイトルは「Linuxカーネルのコンテナ機能」としていますが、これまでの機能と同様にoverlayfsもコンテナ専用として使う機能ではありません。名前空間やCgroup以上にコンテナ以外でさまざまなシーンで使えそうですね。 overlayfsとは overlayfsはunion filesystemの実装の1つで、ディレクトリを重ね合わせて1つのディレクトリツリーが構成できます。 話題のDockerが持つ特長として、よくコンテナイメージの差分管理ができることが挙げられま

2014年は非常にDockerが盛り上がった1年でしたね。 Dockerは2013年の夏ごろから注目を集めはじめました。その後バージョンが0.9となった2014年の春ごろからさらに注目を集めるようになり、それ以降はさまざまなサービスやベンダーがDockerをサポートしたり、Docker関連のプロダクトを出したりするニュースが駆け巡った気がします。 Dockerに関係する勉強会が数多く開催されるようになり、Docker Meetup Tokyoなどは募集が始まった途端に定員に達するという活況ぶりでした。 Dockerは「コンテナ技術」そのものではなく、Dockerがやりたいことを実現するための技術要素の1つとしてコンテナを使っています。このDockerの盛り上がりと共にそれまでどちらかというとマイナーな技術であった「コンテナ」も2014年には非常に注目される技術となりました。 実際、筆者が主

年末を迎えて今年もAdvent Calendarが多数作られていますね。この連載の今回の記事はLinuxカーネルの機能を紹介するので、Linux Advent Calendar 2014の16日目の記事としても書きました。興味深い記事が並んでいて勉強になりますね。 さて、第13回から3回、田向さんにPlamo LinuxでのLXCの利用に焦点を当てて記事を書いていただきました。テンプレート内部の詳しい解説から、Plamo Linuxでのコンテナの作成、ネットワーク構成の応用的な解説、コンテナでサウンドを扱う話まで、面白い記事が続きましたね。 ネットワークの話やサウンドの話はPlamo Linux以外でも十分に応用ができる話でしたし、サウンドの記事に関してはサウンド以外のデバイスをコンテナで使う場合にも非常に参考になる話だったと思います。 田向さん担当の記事のうち、第14回と第15回では一般

連載目次 連載第1回の「GitHub製フレームワークHubotの概要とインストール、チャットアプリと連携する基本的な使い方」では、GitHub社が開発しているBotフレームワーク「Hubot」の概要、Hubotとチャットとの連携方法、Hubotの基本的な使い方を紹介しました。 前回の「Redmine連携でチケットをチャットに通知＆開発を楽しくするHubotスクリプト6選」と同じく、今回も、サンプルアプリケーションに対して修正を行うシーンを例に、Hubotと各ツールがどう連携するかを解説します。 ソースコードはGitHubそっくりなUIと機能を提供している「GitBucket」（Scala製）で管理し、ビルドやデプロイはCI（継続的インテグレーション）ツール「Jenkins」で行います。 利用したソフトウェアとバージョンは以下の通りです。 Hubot 2.4.7 Kandan 1.2 Git

* About to connect() to redmine-server port 80 (#0) * Trying redmine-server... * Adding handle: conn: 0x21b3278 * Adding handle: send: 0 * Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x21b3278) send_pipe: 1, recv_pipe: 0 * Connected to redmine-server (xxx.xxx.xxx.xxx) port 80 (#0) > POST /issues.json HTTP/1.1 > User-Agent: curl/7.30.0 > Host: redmine-server > Accept: *

米Basho TechnologyesのNoSQLデータベース「Riak」は、スケーラブルに拡張可能な分散型データベースである。一方で共通のコアエンジンを用いたオブジェクトストレージである「Riak CS」も、日本進出の最初期段階から、国内ではIDCフロンティアなどのデータセンター／クラウドサービス事業者が注目し、クラウド向けストレージサービスのプラットフォームとしても注目されている。 同社のCEOであるAdam Wray氏の来日の機会にRiakの最新状況について聞いた。 NoSQLとしてのRiak 「Couchbase、MongoDB、DataStaxやApache Cassandraと並び、RiakはNoSQLデータベース市場でトップ5に入っている」（Wray氏） Bashoが提供するNoSQLデータベースRiakの市場でのポジショニングについての問いに、Wray氏はこのように回答した

Cephがスケールできる理由、単一障害点を排除する仕組み、負荷を減らす実装：Ceph/RADOS入門（4）（1/4 ページ） Ceph／RADOS が採用しているCRUSH、Paxosといった、分散したデータから正しく応答するための仕組みを支えるアルゴリズムの概要を学びながら、挙動を見ていきます。 連載バックナンバー 本連載では、オープンソースの分散オブジェクトストレージであるCeph/RADOSの技術詳細、実装について見ていきます。第1回ではCephの概要を、第2回ではCeph/RADOSを構成する要素を、第3回では実際にインストールして動作させるところまでを見てきました。 第4回である今回は、Ceph/RADOSの動作する仕組みについて、採用している分散アルゴリズムや単一障害点をなくす仕組み、メタデータ削減の方法などを見ていきます。 Ceph/RADOSのアーキテクチャ概要 Ceph/

連載バックナンバー IaaS構築・運用環境として注目を集める「OpenStack」でストレージを使用する場面としては、Compute service（Nova）が使用するファイルシステム、Image service（Glance）、Volume service（Cinder）、Object storage（Swift）などが挙げられます。 本連載では、OpenStackのストレージ環境として注目を集めているOSSの分散ストレージ「Ceph/RADOS」について見ていきます。同じくOSSストレージインフラの選択肢としてCeph/RADOSと並んで検討されることの多いGlusterとの比較にも言及する予定です。 はじめに：Cephとは？　RADOSとは？ Cephの名前は頭足類を意味するCephalopodsに由来しています。開発者のペットであるタコのニックネームとして使われているそうです（*

20年ほど前までは、ストレージ専用装置をサーバー間で共有するシステムは少なく、アプリケーションサーバーが内蔵しているディスクドライブにデータを保持するのが一般的だった。そもそも企業の扱うデータ容量が少なかったため、それで十分機能していたのだ。 その後、本格的なITの普及に伴ってデータ容量が増加。大容量のデータ格納領域が必要になってきた。また、アプリケーションはより高い性能が求められるようになり、低速なディスクドライブでは対処できなくなってきた。その結果、外部に高速なストレージ専用装置を配置して、データを集約するという構成が増えた。さらに、サーバー仮想化技術によるサーバー統合の流れも、共有ストレージという利用形態に拍車をかけたと言える。 しかし、最近、ストレージ専用装置ではなく、汎用サーバーをあたかもストレージ専用装置のようにストレージノードとして使う手法が注目を集めている（以下、サーバーベ