サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
www.valinux.co.jp
クラウド 負荷分散 クラウドコンピューティングと負荷分散ソリューションLVS 第1回: LVSのアーキテクチャ 2012/07/25 技術本部 本部長 高橋 浩和 Linux Virtual Sever (LVS)は、Linuxオペレーションシステム上で実行されている負荷分散ソリューションの一種で、1998年5月、Wensong ZhangによってOSSプロジェクトとして開始されました。 LVSは、実サーバのクラスタ上に構築されたコンピュータ・クラスター技術を用いて高性能かつ高可用なLinuxサーバを構築し、スケーラビリティや信頼性、保守性を向上させます。また、LVSを利用することで、Webサービスや電子メールサービス、メルチメディア、VoIPサービスなどの高信頼ネットワークサービスの構築が可能となります。 VA LinuxはLVSに積極的な貢献をしており、新機能の実装や現バージョンへの移
オープンな汎用ハードウェアを仮想的に統合することで、大容量のストレージ環境を構築し、ストレージの利用効率の向上を実現します。スケールアウト型の構成により、スモールスタートから大規模環境まで、必要に応じた容量を低コストで導入することが可能です。 仮想化環境に最適なデータ保護、柔軟性、運用性を備えているため、仮想化ストレージとして活用できます。また、VA Storage全体をSANやNASストレージシステムとして活用することも可能です。
記事執筆時点ではkvm上でNetBSD/amd64はインストーラを起動することもできません。この組み合わせを例にとり、OSと仮想マシンの低レベルの処理の解説を兼ね、判明した問題点と修正方法を解説します。 仮想マシンは実在の標準的なハードウェアをエミュレートしているはずであり、一般の(任意の?)OSの実行に支障があるのは正しい姿ではありません。 一方、標準的な部品とBIOSを組みあわせて作られているわけではなく、仮想マシンの開発者は必ずしも十分な検証の手間はかけられないので、使われる頻度の低いOSの動作に支障のある特殊な存在となってしまうのは仕方がない面もあると言えます。また、OS側も仮想マシン上での動作を検証する人的資源を欠くこともあります。 記事執筆時点ではkvm上でNetBSD/amd64はインストーラを起動することもできません。この組み合わせを例にとり、OSと仮想マシンの低レベルの処
dm-iobandは、LinuxでディスクI/Oの帯域制御を行うdevice-mapperのデバイスドライバです。パーティション、ユーザ、プロセス、仮想マシン等、様々な単位で帯域を制御することができます。本文書では、このdm-iobandを使ってRed Hat Enterprise Linux 5(以下、RHEL5)および CentOS 5の論理ボリュームの帯域制御を行う方法を紹介します。 dm-iobandは既存のブロックデバイスの上にdevice-mapperのデバイスをスタックして利用します。このデバイスに対して出されたI/O要求は、dm-iobandで帯域制御されてから下位のデバイスに渡されます。 帯域制御の方式は三種類あり、それぞれ、weightポリシー、weight-iosizeポリシー、range-bwポリシーと呼びます。ユーザはこの中から任意のポリシーを撰択し
本書は、Linux KVMのshadow pagingの実装について解説します。読者の前提条件として、仮想化及びx86アーキテクチャにおけるアドレス変換機構(MMU)に関する基礎知識を有している方を対象としておりますので、あらかじめご了承ください。 KVMは米国Qumranet社により開発されている仮想マシンで、完全仮想化をサポートします。当初は仮想化拡張機能(Intel VT-x、 AMD SVM)をもつx86アーキテクチャを対象に開発されてきましたが、現在ではその他のCPUアーキテクチャにも移植されています。本書内では特に記載がある部分を除き、x86アーキテクチャのみを対象といたします。 実装の特徴としては次のようなものが挙げられます。
helpコマンドでは、各コマンドの詳細な説明や使用例を見ることができます。本講座で出てきたコマンドについても、適宜、helpコマンドで詳細を確認するようにしてください。 それでは、いよいよお待ちかねのダンプ解析に入ります。まず最初は、カーネルのデータの内容を確認する方法について見ていきます。 メモリの内容を見るには、rdコマンドを使用します。一例として、変数num_physpagesの値を確かめて見ましょう。変数のアドレスは、symコマンドで分かります。rdコマンドの引数には、仮想アドレスを指定します。-pオプションを使用して、物理アドレスの指定をすることも可能ですが、実際の解析において、物理アドレスの参照が必要なケースはあまり多くないと思います。rdコマンドの引数には、シンボル名を直接指定することもできます。 【 変数の値の参照例 】 crash> sym num_physpa
アプリケーションを独自MIBで監視させたいと思いながらも、「SNMPエージェントを作るのは少し難しい」と考えている方は、少なくないと思われます。日本語で解説しているWebサイト等も多くはありませんし。 そこで、本稿では、NET-SNMPをベースとしたSNMPサブエージェントの作成概要を紹介していきたいと思います。 NET-SNMPを使って独自MIBを実装する方式には、チュートリアル(※1)を見る限りは何種類かあるようですが、本稿では、NET-SNMPのエージェントsnmpd(マスタエージェント)にAgentX(※2)接続するサブエージェントという形で独自MIBを実装する例を中心に解説します。 本稿で作成するSNMPサブエージェントは【図1-1 イメージ】のように動作します。 SNMPサブエージェントがアプリケーションと情報を共有することで独自MIBを形成するようにしています。安
ダンプの解析をするためには実際のダンプがなければ話が始まりませんので、今回は、ダンプの取り方を簡単に説明します。 本講座では、プラットホームとして、Redhat Enterprise Linux 5(以下RHEL5)を例に取って、解説を進めていきます。RHEL5を使用するのは、ダンプを取るまでの設定が簡単であることと、ダンプの解析環境が整っていることが理由です。 RHEL5のカーネルは、2.6.18をベースにしています。2.6.13からサポートされたkdumpというダンプ採取機能が使えます。 ダンプを取るための設定から、実際にダンプを取るまでの手順は以下のとおりです。
「仮想マシン環境」の構成方法にはいくつかあり、またその手法により分類方法も複数存在しますが、ハードウェアをエミュレートするという基本的な考え方は同じです。 ホストOS型 あるOS(ホストOSと呼びます)上に、ハードウェアをエミュレートする環境を載せ、その上で別のOS(ゲストOSと呼びます)を動かす方法です。エミュレートはホストOSが持つ機能を利用して実現します。汎用機の仮想マシン環境等は、この方式を採用しています。 仮想マシンモニタ型 ハードウェア上に、直接ハードウェアをエミュレートする専用のプログラムを動作させる方法です。仮想マシン環境を実現する 為に必要最小限の機能を、OSとハードウェアの間に構成します。このプログラムを仮想マシンモニタと呼びます。この方式は、1つ目の方式よりも小さなオーバーヘッドで、仮想マシン環境を実装でき、Xenは、この方式を採用しています。 「仮想マ
HP オープンシステムセミナー 2008/10/7 OSS仮想マシン環境動向 XenとKVM VA Linux Systems Japan株式会社 小 田 逸郎 エンタープライズOS事業ユニット ユニット長 VA Quest隊長 valinux.co.jp Copyright © VA Linux Systems Japan. All rights reserved. 目次 ・仮想マシンのアーキテクチャ ・開発動向 ・関連企業の動向 ・まとめ valinux.co.jp 2 Copyright © VA Linux Systems Japan. All rights reserved. 仮想マシンのアーキテクチャ valinux.co.jp 3 Copyright © VA Linux Systems Japan. All rights reserved. さまざま
linux での代表的なプロファイル測定の実装を解説します。 関連して、マルチスレッドプログラムのプロファイル測定の注意点を述べます。 なお、gprof、oprofile の基本的な使い方は既知のものとし、本書では特に解説はいたしません。 linux では gprof は glibc に付属するツールです。ここでは glibc-2.3.6 を使って説明します。 gprof によるプロファイル測定を行うには、 -pg コンパイルオプションをつけてプログラムをコンパイルします。 このことにより、プログラムに以下の処理が追加されます。
この世の中には、ダンプを解析するためにcrashコマンドという大変便利なツールが存在しています。本講座では、ありがたくcrashコマンドを使用させてもらうことにします。 crashコマンドは、インストールCDにも入っています(crash-4.0-3.14.i386.rpm)が、最新版が下記のURLからダウンロードできるようになっています。 http://people.redhat.com/anderson/ crashコマンドは、後方互換を保ちながら開発が続けられていますので、常に最新版を使用して問題ありません。ここでは、この原稿執筆時点の最新版であるcrash-4.0-4.7を使用することにします。上記のURLには、src rpm パッケージとtarballが置いてありますので、お好きな方をダウンロードしてください。どちらもソースコードの状態ですので、展開後、コマンドを作る必
Linuxカーネルは、ブロックI/Oの処理効率を向上させるさせるための仕組みとして、I/Oスケジューラと呼ばれる機能を提供しています。I/OスケジューラはI/O要求の順序を入れ替えることにより、スループットを向上させたり、特定のI/O要求を優先して実行させたりします。 実際のブロックデバイスのセクタに対するアクセス(つまり読み書き)を、要求された順序ではなく、I/Oを最も効率よく行うためにその順序を並び替えるというアイデアは、初期のUNIXの実装から採用されていました。それは、セクタ番号順序に並び替えてI/Oを実行するという単純なものです。ディスク面上を移動するヘッドの動きがエレベータに似ているため、このアルゴリズムはエレベータアルゴリズムなどと呼ばれていました。 現在のLinuxカーネルでは、そのころのアルゴリズムより洗練されたスケジューリング方式を採用しており、目的に応じて4種類の
machine checkを有効にします。 P5はこれを指定しないとmachine checkは有効にな りません。
お知らせ サービス Xen Cloud Platformの最新版であるXen Cloud Platform (XCP) 1.0がリリース 2011/03/04 ヴィーエー・リナックス・システムズ・ジャパン株式会社 英国時間2011年3月3日に、Xen.orgよりXen Cloud Platformの最新版であるXen Cloud Platform (XCP) 1.0が発表されました。 本プレスリリースの中で、弊社 代表取締役社長 柿木 弾は以下のコメントを発表しています。 「Xen.orgのアドバイザリーボードメンバーとして、VA LinuxはXCP 1.0および新機能の発表を大変嬉しく思っております。XCPがクラウドプラットフォームにおいて重要な位置づけになることを期待し、弊社のお客様により素晴らしい機会を提供することができるでしょう。VA Linuxは引き続き、Xenを用いたクラウド技
dom0上で動作するxendデーモンは、Xenハイパーバイザとのやりとりを仲介するデーモンです。このxendデーモンの動作を設定ファイルで指定することができます。 xendの設定ファイルは /etc/xen/xend-config.sxp であり、S式(S-expression)(※1)で記述します。
これらの問題を検出する為の色々なツールも存在しますが、mallocライブラリ側でも簡単なチェック機能が備えられています。これは予めライブラリ内に組み込まれている為、簡単に使用することができ、アプリケーション側の修正も必要ありません。ただ簡単な仕組みの為、余り詳細なチェックは行えません。上記の(1)と(2)には対応が可能です。以下、この機能の仕組みについて説明します。 これは環境変数MALLOC_CHECK_に特定の値を設定する事により、ライブラリ側にデバッグ機能使用の通知を行いチェック機能を働かせるものです。この機能はmallocのmanにも書かれています。ここではライブラリでの内部的な処理についても述べて行きます。 MALLOC_CHECK_の値はpublic_mALLOc()コール時の最初の処理でcheck_actionという静的変数に設定されます。これは、public_mALLO
CD(イメージ)からブートすることができ、OSの通常のインストールを行うことができます。ただし、CDを入れ替える部分はコツが必要となります。ディスクイメージは、専用パーティションを用意するかファイルを用意しておく必要があります。
一般に、ILP32環境とLP64環境とでは、同一サイズの整数、実数であってもアライメントが異なります。IA-32とx86-64においても、【2.2 AMD64/Intel 64への対応】で示したように、32bitより大きな幅を持つスカラー型のアラインメントが変わっています。構造体や共用体では、そのメンバのうちもっともアラインメントの制約の強いものに合わせて大きさやアラインメントが決定されるため、メンバの順序などによってはサイズやアラインメントが大きく変化する可能性があります。 例えば、次の構造体の大きさは、bのアラインメントが異なるために、IA-32では12バイト、x86-64では16バイトとなります。
本Webサイト内に掲示された技術情報は、時間の経過や該当技術の進歩・変化等にともない、その記述内容に相違が発生する場合がございます。技術項目全てを保証するものではないことを事前にご了承いただき、参考情報としてご活用ください。
ダンプの解析を行なうためには、ダンプの構造を理解しておく必要があります。 前回、ダンプはメモリの内容を吐き出したものだと説明しましたが、実際の中身は、どのような形式になっているのでしょうか。ダンプの中身の形式は、ダンプ採取機能によって異なることがあります。kdumpでは、ELF形式で吐き出しています。 ELF形式なので、readelfコマンドで中の形式を覗くことができます。早速、覗いてみましょう。 タイプが「CORE」と言うことで、プロセスのコアファイルと同じ形式になっています。ただし、プロセスのコアファイルは、プロセスの仮想アドレス空間を吐き出したものですが、ダンプの場合は物理アドレス空間を吐き出したもので、意味が異なっているので注意してください。ダンプは、カーネルの仮想アドレス空間を吐き出したものではありません。ダンプのフォーマットにコアファイルのフォーマットを借用しているというのが正
LinuxカーネルはARPリクエストを受信した場合、デフォルトの状態では他の(カーネルにLinuxを使用していない)OSとは一部違った挙動を します。あるホストがARPリクエストを受信した場合に、リクエストの内容が受信したネットワークインタフェースに付けられたIPアドレス以外について解決する要求である場合には、非Linux系OSではリクエストを無視 します。一方、Linuxカーネルのデフォルトの状態では、ARPリクエストが受信したホストが保持するIPアドレスについての解決要求(※1)であった場合、受信したネットワークのアドレスであるかどうかに関係なく、受信したネットワークインタフェースのリンクレイヤアドレスで応答することにな ります。 右記のようなネットワーク環境で 、このことを確認してみましょう。host-xではLinux-2.6.21を用いたOSが動作して います。host
前回、mallocライブラリ内でメモリを管理する器であるアリーナ(arena)の存在について述べました。今回はこのarenaの詳細について説明します。 arenaの管理部分はmalloc_stateという構造体で定義されています。コード上ではmalloc_stateのtypedefであるmstateが良く使われます。他にも処理上で使用される値を格納する情報としてmalloc_par構造体があります。変数名はmp_です。以下に構造体定義を示します。 デフォルトで使用されるarenaの管理部はmain_arenaという変数名で静的に定義されています。プログラムが起動された時点ではarenaはこの一つが存在するだけです。通常はこの一つのarenaで十分です。 また、プログラムが起動時点ではmain_arenaが存在するだけで、メモリプールはまだありません。メモリプールは最初のmalloc()
hping(現在はhping3)はpingライクなパケット生成ツールです。ファイアウォールの動作検証等が一般的な用途になるでしょう。 本編では、ファイアウォールのフィルタリングルールを検証するためのhpingの使用法を解説します。 ※hping3は http://gd.tuwien.ac.at/www.hping.org/index.html から取得できます。
domUのカーネルイメージ及びinitrdイメージは、dom0からアクセスできる必要があります。それらがdomUのゲストOSのディスクイメージ上にある場合は、そのデータをdom0上へ持ってくる必要があります。pygrubは、その処理を行ってくれるツールです。ドメイン設定ファイルで、bootloaderに/usr/bin/pygrubを指定するとpygrubが呼び出されます。 カーネルイメージ等の指定は、domUディスクイメージ内にある 下記のgrubの設定ファイル にて行います。 /boot/grub/menu.lst /boot/grub/grub.conf /grub/menu.lst /grub/grub.conf pygrubがサポートしていないコマンドは無視されます。ドメイン設定ファイルでディスクを複数指定した場合は、先頭に指定したディスクにgrubの設定ファイ
malloc()といえばC言語ではお馴染みのライブラリで、最も良く使用されるライブラリの一つです。しかしその分だけ何らかの不具合を経験した人も多いのではないでしょうか。本書ではmalloc()、free()で確保、解放されるメモリリソースが内部的にどのように管理されているかを説明していきます。mallocライブラリの仕様を理解する事で、ライブラリ使用時に何らかの不具合が発生した際の手助けになればと思います。 ここではLinuxディストリビューションで標準的に使用されているglibcのmallocライブラリを扱います。今回の調査では次の環境を使用しています。 ディストリビューション :Debian sarge パッケージバージョン :glibc-2.3.2.ds1-22 OS : i386 Linux 本書では、上記の通りi386アーキテクチャの場合について記述しています。
本講座では、Linuxシステムを対象にダンプの解析方法について解説していきます。 "ダンプ解析"と言われてもピンとこない方もいらっしゃるかもしれません。先ずは、「ダンプの解析とは何なのか?」という観点で少し解説します。 そもそもダンプとは何かと言うと、マシンに搭載されているメモリの内容を(一般に)ディスクに出力したものです。(「出力する」という行為を、「吐き出す」とか「吐く」という表現もよく使われます。本講座内でも使用いたしますが、お客様向け資料等ではあまり好ましくない表現であることにご注意ください。) ダンプを吐く契機は、カーネルが自分自身の異常を検知したことです。カーネルは、これ以上動作を継続するのは危険と判断するとダンプを吐いてシステムをダウンさせます。(※1)つまり、ダンプが取られたということは、カーネルに障害が発生したということを意味します。察しのいい方はお気づきかと思いますが
64bitプロセサのためのプログラムを、C/C++で書く際に注意すべき点の1つが、整数データモデルの違いです。 32bit環境ではポインタは32bitであり、int型と同じ幅でした。64bitプロセサのプログラミング環境では、ポインタの幅が64bitとなります。Cの言語仕様(ISO/IEC 9899:1999 Programing Languages - C[5]、C99)においては、intは「実行環境のアーキテクチャの暗示する自然な大きさ」となっており、64bitプロセサにおいては64bitとなりそうではありますが、そうではない実装が主流となっています。主な整数データモデルを【表1.2】に示します。
本編では、主にIA-32版GNU/Linuxのアプリケーションを、64bitのx86-64に移行するにあたって有用と思われる基礎知識をまとめます。 まず第1章では一般的な64bitプロセサとx86-64アーキテクチャを概説し、第2章ではLinuxの64bitプロセサ対応に関して述べたのち、第3章で移植にあたっての具体的な注意点やヒントを列挙します。 本編では、64bitの整数を整数演算の基本とするプロセサを64bitプロセサと称します。 一般に、64bitプロセサの特徴として、 ・ 64bitの整数レジスタ ・ 64bitのメモリアドレス空間 などが挙げられます。メモリアドレスの計算も一種の整数演算と考えられることから、この2つの特徴は密接な関係にあります。メモリはバイト単位でアドレスが振られることから、64bitのアドレス空間で表現できるメモリは、264 バイト、すなわち16
次のページ
このページを最初にブックマークしてみませんか?
『VA LINUX SYSTEMS JAPAN VAリナックス』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く