/ccmp/tech

SuperMicro社が提供している有償ツールのSuperMicro Update Manager(SUM)を試してみました。このツールを利用するとIPMIと同じ感覚でBIOS設定の確認や変更、BIOSファームウエアの更新が可能です。 SuperMicro Update Manager SUM紹介ベージ https://www.supermicro.com/solutions/SMS_SUM.cfm Linux起動中にBIOSの設定を確認したくなることありませんか。Windows環境のマシンであればそのようなツールもあるよう気もしますが、Linux上となるとあまり聞かないと思います。以前、Linux上でEFI変数を利用する方法を試してみたのですが、設定らしきものはバイナリデータになっていて詳細不明で、設定の変更はブートデバイスの優先順位くらいしか変更できませんでした。SuperMicro社が提供しているSuperMicro Update Managerを利用すると簡単に(同社のMB限定ですが)OS起動中にBIOSの設定を確認したり変更したりすることが可能になります。 SUMの機能などの詳細な説明は上記のWebページに詳しく紹介されていますのでそちらを参照ください。今回はBIOS周りの機能を試してみました。 SUMではツールを利用して以下のことが可能です。 BIOS設定の取得 現在の設定やデフォルトの設定などをテキストファイルベースで確認できます。 BIOS設定の変更 テキストファイルベースで設定の変更ができます。ただし変更を反映するには再起動が必要です。 BIOSファームウェアのアップデート BIOSをアップデートをそのままの環境で実行できます(DOS環境はいりません)。ただしアップデートを反映するには再起動が必要です。 また対象のサーバにアクセスする方法として二つの方法あります。 リモート(Out-band)でアクセスする。 別のマシンでSUMを実行してネットワーク経由で対象サーバにアクセスする ローカル(In-band)でアクセスする。 対象サーバ上で起動しているOS(Llnux)上でSUMを実行して自分自身にアクセスする。 IPMIと同様に実際にBIOSの設定を取得したり変更したりする

非集中型のクラスタ管理ツールのSerfを触ってみました。クラスタ管理というと何かいろいろ大変そうなイメージですが、Serfを利用すると簡単にサーバの死活監視や情報の収集が可能になります。 Serfについて Serfの本家サイト: https://www.serfdom.io/ Serf is a decentralized solution for cluster membership, failure detection,and orchestration. Lightweght and highly available. 本家のサイトのトップページに書かれているようにserfは軽量で高可用性の非集中型のクラスタ管理ツールです。 インストールは簡単。  serfの静的バイナリを各サーバにコピーするだけOK。 マスターサーバのような全体を管理しているノードはない 全てのノードで実行されているserfは平等。 ゴシッププロトコルを利用したノード間のメッセージングツール ノード間でお互いに通信して情報を全体に伝播させる。 各ノードで実行されているserf agent が情報のやりとりをする。 クラスタ内のノードの増減についてのイベント クラスタ内のノードの生死についてのイベント ユーザ独自のイベントを通知することも可能 イベントをトリガにして任意の処理(スクリプト)を実行できる。 これによっていろいろ応用が効くようになる。 例えば、クラスタ内のノードの死活監視やノードが追加/停止したときに自動でロードバランサの設定(バランス先)を変更するなどの使い方が考えられます。 また複数のアプリケーションを組み合わせて利用する場合に全体の統制をとるのに利用できます。元々そのような管理の仕組みのないアプリケーションの組み合わせでも全体を統制するような仕組みを構築できます。 インストール 公式サイトに(静的)バイナリで配布されているのでそれをダウンロードしてきて展開し適当なパスにコピーすればOKです。今回は/usr/local/binに置く事にしました。 # wget https://releases.hashicorp.com/serf/0

従来の仮想マシンと比較して軽量な仮想環境としてコンテナが注目されている。コンテナによる仮想環境での特徴としてコンテナで同じカーネルを共有している点があげられる。 また、コンテナで実際のサービスを提供する場合、アプリケーションがほかにカーネルの提供する機能も必要となる。そこで今回はコンテナ環境下でのカーネルの機能の利用について実際に試してみた。 コンテナ上でのカーネルの機能の利用 コンテナではapacheやmysqlといったプロセスはそれぞれの名前空間で実行されている カーネルはすべてのコンテナでホストのカーネルを利用している。 ipvsやiptablesはカーネル側の機能 コンテナではホストのカーネルを共有しそれぞれのコンテナごとに独立した名前空間を作成して、その上でユーザプロセスを実行することによって仮想環境を実現している。 しかし、実際のサービスなどにおいてはhttpサーバやデータベースなどのユーザプロセスだけではなくカーネルの機能も合わせて利用される。例えば、ロードバランスやパケットのフィルタリングを行う場合などはipvsやiptablesといったカーネルの機能が必要になる。 コンテナ上でカーネルの機能を利用する場合、そのカーネルについてはすべてのコンテナで共有されている点において通常とは事情が異なる。 今回はipvsおよびiptablesについて実際にコンテナ上での利用を試してみた。 システム構成 コンテナ構成図 検証としてWebサーバへのアクセスをLVSを利用してロードバランスするシステムをコンテナを利用して構成することを考える(上図) ホストマシン2台からなる構成で、それぞれのホストにipvsを利用してWebコンテナへのロードバランスを実行するLVSコンテナ、 iptablesとapacheを使ってLVSからロードバランスされてきたアクセスを受けるWebコンテナを作成する。 以下の説明ではそれぞれのホスト及びコンテナの構成方法についての詳細は割愛して、それぞれのコンテナ上でのipvsおよびiptablesの動作および設定についてのみ述べる LVSコンテナ LVSコンテナは2つのネットワークインターフェースeth0、eth1を持ちそれぞれが仮想ブリッジを介して仮想イーサネット(veth)によって

Linuxコンテナ 従来の仮想マシンと比較して軽量な仮想環境としてコンテナが注目されています。仮想マシンのようにまるごと物理マシンをエミュレーションした環境を用意するのでなく、ネットワークやプロセスIDなどのみが独立した環境(コンテナ)を用意してその中でプロセスを実行するタイプのOSレベル仮想環境です。今回はそのコンテナについてもっともベースとなる部分を試してみました。 LXCのインストール 最近はコンテナの利用する環境を整えるのにも各ディストリビューションに対応したパッケージをインストールするだけで大丈夫です。 コンテナを利用するための実装にはいくつのかの種類がありますが今回はLXCを利用します。他にはDockerなどが有名です。ただLinuxコンテナの核となる部分はカーネル側の機能なので、実装が違っていてもベースとなる考え方は一緒です。　 　今回はDebian/Jessieを利用しますが、LXCはほとんどのディストリビューションでパッケージ化されていると思います。またカーネルが必要な機能を有効にしてコンパイルされていないとダメなのですが、ディストリビューションの標準カーネルであればまず問題ないはずです。 　DebianのJessieではapt-getでインストールするだけです。 # apt-get install lxc コンテナの作成　 　ではコンテナを作りましょう。一連の作業はrootで実行する必要があります。コンテナの作成においては、コンテナ用のファイルシステムを作成することがメインです。あとはコンテナを実行するためのLXCの設定ファイルも必要です。 コンテナ用のファイルシステム コンテナ内のプロセスからはこのファイルシステムがルートファイルシステム(/)として見え、基本的にここにしかアクセスできません。コンテナ内のプロセスはこのルートファイルシステム上で実行されます。 　コンテナを作成するには先ほどインストールしたLXCのユーティリティに含まれるlxc-createコマンドを利用するのが簡単です。 lxc-create -n <コンテナ名> -t <テンプレート名> -- <テンプレートオプション> 例:test1という名前で64bit Debian/Jessieのル