June 22, 2010

RAC on Oracle VM - iSCSIイニシエータを設定する - すこっと・たいがー!

udevの設定

udevを使用してiSCSIとして利用するデバイスを命名し固定化を行います。イニシエータがiSCSIターゲットにログインすると自動的にudevdデーモンが/dev/sdbのようにデバイスファイルを作成しますが、毎回同じデバイスファイル名を使用するとは限りません。また、/dev/sdbといったデバイスファイル名だとRAWデバイスとして使用する際に何の領域として利用しているのかわかりません。そこで、デバイスファイルの命名規則を作成すると同時に毎回同じファイル名が設定されるようにデバイスファイルの設定ルールを作成します。

まず、現状マッピングされているデバイスファイルの一覧は以下のコマンドで確認することができます。

[root@vmrac1 ~]# (cd /dev/disk/by-path; ls -l *openfiler* | awk '{FS=" "; print $9 " " $10 " " $11}') ip-172.16.1.13:3260-iscsi-iqn.2006-01.com.openfiler:vg01.dg01 -> ../../sdb ip-172.16.1.13:3260-iscsi-iqn.2006-01.com.openfiler:vg01.dg02 -> ../../sde ip-172.16.1.13:3260-iscsi-iqn.2006-01.com.openfiler:vg01.ocr01 -> ../../sdc ip-172.16.1.13:3260-iscsi-iqn.2006-01.com.openfiler:vg01.ocr02 -> ../../sdf ip-172.16.1.13:3260-iscsi-iqn.2006-01.com.openfiler:vg01.voting01 -> ../../sdg ip-172.16.1.13:3260-iscsi-iqn.2006-01.com.openfiler:vg01.voting02 -> ../../sda ip-172.16.1.13:3260-iscsi-iqn.2006-01.com.openfiler:vg01.voting03 -> ../../sdd

iSCSIターゲットのIQNでは「vg01.voting01」の文字列から何の領域かが判断つきますが、「/dev/sdg」といったデバイスファイル名だと何の領域なんだか判断がつきません。そこで、udevルールファイル「/etc/udev/rules.d/55-openiscsi.rules」を作成します。

[root@vmrac1 ~]# vi /etc/udev/rules.d/55-openiscsi.rules # /etc/udev/rules.d/55-openiscsi.rules KERNEL=="sd*", BUS=="scsi", PROGRAM="/etc/udev/scripts/iscsidev.sh %b",SYMLINK+="iscsi/%c/part%n", OWNER="oracle", MODE="0640", GROUP="oinstall"

上記の設定は、カーネルデバイス名が「sd*」でデバイスのバスの種類が「scsi」の場合、外部プログラム「/etc/udev/scripts/iscsidev.sh」を実行する。という意味で、さらにSYMLINKでデバイスファイル名の命名を行い、そのファイルの権限をOWNER、MODE、GROUPで設定しています。ちなみに、カーネルデバイス名(KERNEL)とデバイスバスのタイプ(BUS)はudevinfoコマンドを使用することで確認できます。たとえば、「/dev/sdb」で認識されているカーネルデバイス名とバスのタイプは以下のコマンドで調査します。

[root@vmrac1 ~]# udevinfo -a -p $(udevinfo -q path -n /dev/sdb) Udevinfo starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device.  looking at device '/block/sdb': KERNEL=="sdb" SUBSYSTEM=="block" : :

次に、ルールで設定した外部プログラム「/etc/udev/scripts/iscsidev.sh」を作成します。これは、IQNの最後の文字列(たとえば、dg01やocr01など)を取得するシェルスクリプトです。

[root@vmrac1 ~]# cat /etc/udev/scripts/iscsidev.sh #!/bin/sh # FILE: /etc/udev/scripts/iscsidev.sh  BUS=${1} HOST=${BUS%%:*}  [ -e /sys/class/iscsi_host ] || exit 1 file="/sys/class/iscsi_host/host${HOST}/device/session*/iscsi_session*/targetname" target_name=$(cat ${file})  # This is not an open-scsi drive if [ -z "${target_name}" ]; then exit 1 fi  echo "${target_name##*.}"

OS再起動

今までの設定を確認するためにOS再起動をしてみます。そして、デバイスファイルを確認してみると次のようにわかりやすい名前でデバイスが作成されていることがわかります。

[root@vmrac1 ~]# ls -l /dev/iscsi/*/* lrwxrwxrwx 1 root root 9  2月  1 21:18 /dev/iscsi/dg01/part -> ../../sdb lrwxrwxrwx 1 root root 9  2月  1 21:18 /dev/iscsi/dg02/part -> ../../sde lrwxrwxrwx 1 root root 9  2月  1 21:18 /dev/iscsi/ocr01/part -> ../../sdc lrwxrwxrwx 1 root root 9  2月  1 21:18 /dev/iscsi/ocr02/part -> ../../sdf lrwxrwxrwx 1 root root 9  2月  1 21:18 /dev/iscsi/voting01/part -> ../../sdg lrwxrwxrwx 1 root root 9  2月  1 21:18 /dev/iscsi/voting02/part -> ../../sda lrwxrwxrwx 1 root root 9  2月  1 21:18 /dev/iscsi/voting03/part -> ../../sdd

ちょっと難しかったので、ここまでとして次回はOCRと投票ディスク領域に、Oracle Cluster File System 2 を利用するための設定を行います。

Posted via web from アマノユウのポケットメモ | Comment »

June 21, 2010
June 16, 2010

Live Migration (System Administration Guide: Virtualization Using the Solaris Operating System) - Sun Microsystems

Live Migration

The following prerequisites apply:

  • Both the source machine and the target host must be on the same subnet.

  • The host and the target must each have the same CPU type (AMD or Intel).

  • Both systems must be running the same release of the xVM software.

  • There must be sufficient CPU and memory resources on the target to host the domain.

  • The target dom0 should have the same network interface as the source dom0 network interface used by the domU. For example, if the domU to be migrated has a VNIC that is bridged over the e1000g0 interface on the source dom0, then the target dom0 must also have the e1000g0 interface.

Enabling Live Migration on a Target Host

By default, xend listens only on the loopback address for requests from the localhost. The target host must be configured to accept the migration of a guest domain. The following example configures the xend SMF service on the target machine to accept guest migration from a system named host1. The caret (^) and dollar sign ($) are pattern-matching characters to ensure that the entire host name matches. The host1 name must match the name the target thinks the machine is called, which could be a host name, but could also be a fully qualified domain name (FQDN).


# svccfg -s svc:system/xvm/xend svc:/system/xvm/xend> setprop config/xend-relocation-address = "" svc:/system/xvm/xend> setprop config/xend-relocation-hosts-allow = "^host1\.?.*$ ^localhost$" svc:/system/xvm/xend> end # svcadm refresh svc:system/xvm/xend:default && \ svcadm restart svc:system/xvm/xend:default

You can test the connection by using:


host1# telnet target-host 8002

If connection fails, check the /var/log/xen/xend.log file on the target system.

Configuring the Guest Domain to Be Migrated

In addition to configuring the target system to accept migrations, you must also configure the domain that will be migrated so that the domain’s storage is accessible from both the source and the target systems. The domain’s accessible disks must reside on some form of shared storage, such as NFS files or iSCSI volumes. This document uses the NFS method available in the OpenSolaris 2009.06 release.

Prepare the NFS Storage on the NFS Server

On the NFS server, share the directory:


# sharectl set -p nfsmapid_domain=sun.com nfs # svcadm restart svc:/network/nfs/mapid:default # share -F nfs -o "sec=sys,root=host1:host2,rw" /vdisks

On both the host1 source system and the host2target system, also execute the sharectl to set the NFS mapid name to sun.com, and the svcadm command restart the xend service.

Create a PV Guest on the Source Machine (host1)


# virt-install -p --nographics -n domain -r 1024 -l /isos/os0906/os0906.iso -f /net/hostname_of_nfs_server/vdisks/testpv

The virt-install command then creates the virtual disk on the NFS server and starts the guest installation process.

iscsi Volume Method, Available in a Later Build


Note –

This method should be available in a build after the OpenSolaris 2009.06 release.


An iscsi-backed guest would be created with this base command:


# virt-install -n <name> -r <ram> -p --nographics -l /path/to/iso \ -m <mac address> \ --disk path=/static/<iscsi target ip address>/<lun>/<iqnnumber>,driver=phy,subdriver=iscsi

An example would be:


# virt-install -n ubuntu -r 1024 -p --nographics -l /net/xvm-4200m2-03/isos/ubuntu-7.04-32.iso \  --disk path=/static/172.20.26.10/0/iqn.1986-03.com.sun:02:52ac879e-788e-e0ea-bf5c-f86b2b63258a,driver=phy,subdriver=iscsi

In addition to setting up the xend relocation host allow field as described above in the section “Enabling Live Migration on a Target Host,” also issue the following command to enable static discovery on both dom0s:


# iscsiadm modify discovery -s enable

Migrating the Guest Domain

Use the following command to migrate the guest.


host1# virsh migrate domain --live xen:// xenmigr://target-host

Note –

While the use of the virsh command is preferred, you can try the following command if the virsh command appears to fail.


host1# xm migrate -l domain target-host

You can observe the migration while it occurs by monitoring the domain status on both machines using virsh list.

Note that the domain definition remains on the system on which it was created. You can start the domain on that system’s dom0 with the virsh start domain command.

Posted via web from アマノユウのポケットメモ | Comment »

CentOS&Xenサーバ導入メモ: Sparseファイルの取り扱い方法

Sparseファイルの取り扱い方法

XenのイメージファイルをSparseファイルにしておくと
未使用領域を圧縮した状態になる。

■メリット
・イメージファイルのディスクスペースの節約になる
・コピーが速い(イメージファイルを量産する時に有効)

■デメリット
・書き込み速度がとても遅い
http://www.atmarkit.co.jp/flinux/rensai/xen02/xen02b.html
・ファイルが膨張するとHDDから溢れて壊れる可能性がある。
・対応したコマンドで取り扱わないと、元に戻る。

■取り扱い方法
○コピー
# cp —sparse=auto [コピー元] [コピー先]
# rsync -avS [コピー元] [コピー先]

○GNU TARで圧縮/解凍
圧縮 # tar zcSvf [書庫ファイル] [格納するファイル]
解凍 # tar zxSvf [書庫ファイル]

○通常ファイルをSparseファイルにする
# cp —sparse=always [コピー元] [コピー先]

○Sparseファイルを通常ファイルに戻す
# cp [コピー元] [コピー先]

○実容量を表示する
# du -h [ファイル名] ※ワイルドカードOK
↑ls -lと比べてみよう。

Posted via web from アマノユウのポケットメモ | Comment »

June 11, 2010

レッドハット | オープンソース・カンパニー

GFS/iSCSI 対 NFS GFS/iSCSI NFS クライアントの拡張性 300以上 10-20もしくは高負荷時にはより少ない台数 サーバとクライアント間の帯域 無制限 NFSサーバの最大帯域によって制限 大規模拡張時の複雑性 同一のボリュームで単一の名前空間を保持することで複雑性を排除し、管理を簡素化する 大規模拡張では、NFSファイルシステムは個別のボリュームにまたがるように分割せざるを得ず、管理の複雑さを増大し、達成できる性能を制限してしまう POSIX互換 Yes。
最後に書き込まれたデータを常に読み出すことが可能で、アプリケーションを破壊しない No。
最後に書き込まれたデータを読み込めるかどうかは不確定 小規模拡張、低いパフォーマンスの環境 GFS/iSCSIはコスト効率を小規模拡張、低いパフォーマンスの環境にもスケールダウンできる NFSが得意とするのは小規模(5-10クライアント)で、低いパフォーマンスの環境のみ

Posted via web from アマノユウのポケットメモ | Comment »

June 9, 2010

うさぎドロップ映画化: ウニタ日記

うさぎドロップ映画化

2010fy7_l

フィールヤング7月号、本日発売です。
そして表紙画像を見ていただくとわかりますが、「うさぎドロップ」の映画化が決まりました。
今だに何かの間違いじゃないのかなあと思っているのですが、印刷物が出たので本当なのだと思います。
今後発売されるフィールヤングでいろいろと発表されていくはずです。
ご期待ください。

わたしにできるのは、今までどおり ちみちみまんがを描くことだけです。
映画化することに大喜びなのは言うまでもありませんが、うかれすぎずに気を引き締めてがんばります。
映画、まんが、ともによろしくお願いいたします。

Posted via web from アマノユウのポケットメモ | Comment »

June 4, 2010

私がiPadを買うべきでない理由:日経ビジネスオンライン

スタイル指南

  • 新世紀のカルティエ 新時代の試み
    カリブル ドゥ カルティエ

  • 真田広之インタビュー
    アメリカでの挑戦に込めた想い

記事を探す

“; colstr = colstr + “”; colstr = colstr + “”; colstr = colstr + “”; colstr = colstr + “”; colstr = colstr + “”; colstr = colstr + “”; colstr = colstr + “”; colstr = colstr + “”; colstr = colstr + “

”; for(i=0; i” + myWeekTbl[i] + “”; } colstr = colstr + “”; colstr = colstr + “”; for(i=0; i”; for(j=0; j”; }else{ colstr = colstr + myDat + “”; } }else{ colstr = colstr + myDat + “”; } } colstr = colstr + “”; } colstr = colstr + “”; colstr = colstr + “”; colstr = colstr + “”; document.getElementById(divname).innerHTML = colstr; myDate = new Date(iyear,imonth-2,idate); myYear = myDate.getYear(); myMonth = myDate.getMonth(); myToday = myDate.getDate(); myYear = (myYear

  • 記事ランキング

    注目のビジネストレンド

    • 連載:ブヘラを知る
      7つのキーワード vol.1

    • その脚の不快感は
      むずむず脚症候群!?

    • 納得の品質と価格 
      ファッションもWEBで!

    • 【ライトオン】
      強い企業体質を作る情報活用

    日経ビジネスからのご案内

  • Posted via web from アマノユウのポケットメモ | Comment »

    virtualization.info | Red Hat社のKVM採用でXenはどうなる? (20080620-1)

    Red Hat社のKVM採用でXenはどうなる? (20080620-1)

    Friday, June 20th, 2008   |   原文はこちら (English)

    正式版で何がうたわれていようと、Red Hat社の仮想化戦略は常に問題を抱えてきた。

    それは2004年12月にスタートした。同社はこのとき、自社のエンタープライズOSである「Red Hat Enterprise Linux(RHEL)4.0」の仮想化エンジンにオープンソースハイパーバイザーのXenを採用する計画を明らかにした。
    だが残念ながら、Red Hat社がようやくXenを搭載したRHEL 5.0をリリースした2007年3月までの2年間、このような計画が現実になることはなかった。

    そして2006年の半ば、同社は遅ればせながら興味深い作戦に出た。Xenは未成熟だと宣言し、自社のエンタープライズ版ディストリビューション(SUSE Linux)にXenを統合するのは無責任だとし、最大のライバルであるNovell社を非難してきた
    おそらくこの主張を裏付けるためと思われるが、Red Hat社はどのエンタープライズ標準で考えても最低限だと思われるGUIしかXenに用意せず、何とかRHEL 5を出荷してきた。それが「Virtual Machine Manager」だった。

    そこから一連の劇的な流れが続いた。
    まず、Microsoft社がXenSource社Novell社、そしてVirtual Iron社といったXenの重要なプロジェクト参加企業と次々に提携した。その後、2007年8月にはCitrix社がXenSource社を買収した

    つまり、同オープンソースプロジェクトに立ち上げ当初から参加していたにもかかわらず、Red Hat社はそれから1年も経たない間にXenの開発に対する影響力の大半を失ったのだ。
    同社がほかの選択肢の評価を早急に進めるであろうことは想像に難くなかった。そして、Red Hat社にとって唯一有益な選択肢が、開発期間わずか6カ月でLinuxカーネルに組み込まれた登場間もない仮想化プラットフォームのKVMだった。

    KVMはRed Hat社に多数の利点を提供する。
    たとえば、同製品は正式なカーネルモジュールとして出荷され、保守への膨大な投資が必要ない。
    またたとえば、Novell社はこれを採用しておらず、しばらくはその可能性も低い(今のところMicrosoft社とCitrix社で手一杯だ)。
    そしてたとえば、これにより、Xenへの本格的投資にこれ以上興味のないIBM社が新しく強力な味方につく。
    さらに、これがカーネルに組み込まれていることにより、Microsoft社、同社の同盟各社、あるいは厄介なベンダー各社が開発に影響を与えるのは相当困難になる。

    そこでRed Hat社は6月19日、KVM採用の発表という、十分に予想されていた行動に出た。

    同社はKVMを組み込んだ新しい軽量ディストリビューションを用意し、これをRed Hat社の仮想化プラットフォーム(「Embedded Linux Hypervisor」)として販売する。
    さらに同社は、標準化されたlibvirt APIを基盤にし、数千台の仮想マシンまで拡張できるよう開発された「oVirt」という新しい全社レベル対応の管理ソリューションも発売する。

    さて、これでXenはどうなるのだろうか?これに投じたRed Hat社の投資はどうなるのだろうか?
    正式なプレスリリースに明確な記述はないが、選ばれている言葉を見ると、Xenは過去のものでありKVMが未来である、との意味が読み取れる。
    Red Hat社がXenのサポートを継続するのかどうか、あるいはハイパーバイザーを利用するためにRHEL 5を選定した大企業の顧客が今後どうなるのかは分からない(これは、XenとKVMの両仮想マシン間に互換性がないためだ)。

    いずれにせよ、Red Hat社がXenを明日にでもサポートから外す可能性は低い。同社はXenの諮問委員会に参加しており、サポートポリシーにもすべてのディストリビューションは7年間サポートするとある。
    Red Hat社はこの期間を使い、KVMの方が仮想化エンジンとして優れていることを顧客に納得させたい考えなのかもしれない。たとえば、Virtual Machine Managerは既に、仮想マシン管理用のデスクトップユーザインターフェースへと分類し直されている。

    Embedded Linux HypervisorもoVirt管理コンソールも、既にベータ版がこちらからダウンロードできる。

    Red Hat社では、両製品の正式版の発売時期は明かしていない。

    Posted via web from アマノユウのポケットメモ | Comment »

    June 2, 2010

    @IT:Linux標準の仮想化技術「KVM」の仕組み(1/2)

    KVMは、ハードウェアのエミュレーションやゲストOSの管理用のフロントエンドとして「QEMU」を使い、Linuxの上でゲストOSを動かすので、一見前者のホストOS型に見えます。しかしLinux自体をハイパーバイザにしてしまうことを考慮すると、後者のハイパーバイザ型といえるでしょう。

    Posted via web from アマノユウのポケットメモ | Comment »

    Eucalyptus vs OpenNebula その1 « YLab

    Eucalyptus vs OpenNebula その1

    Eucalyptusを試用してみているが、EC2を模してよくできているクラウドプラットフォームとつくづく思う。

    日本国内でのクラウド啓蒙・認知の高まりと並行してUbuntuに取り込まれ(一部サービスが商用転化され)不特定多数に対して一定の訴求体制が出来上がりつつある。

    そこで、このようなオープンソース(もある)を利用してサービス構築を考えるものとして、クラウドプラットフォーム選定の際に検討したいのが、「オープンソース」でありつつ「いつまで利用者に対する透明性」が維持されるのか。Eucalyptusでは、すでに商用転化された機能範囲とコミュニティリリース版の機能範囲なものとでは、ユーザが利用できる機能に差が生じているように見受けられる。。。

    また、Eucalyptusが純粋・頑なにEC2を目指し模しているのに対して、OpenNebulaは対応するハイパーバイザ毎(KVM、Xen、そしてVMwareも)への柔軟(ハイパーバイザへの直接的なアプローチ)な連携を保ちつつクラウドプラットフォームの独自仕様があり、且つEC2の他のIaaSとの連携で「ハイブリッドクラウド」なるトレンドも取り入れている。

    はたして。。。

    より日本国内ユーザ向けを考えた際にはOpenNebulaに分があるか。。。

    機能面以外に政治的な要素もあるようです。

    Posted via web from アマノユウのポケットメモ | Comment »

    May 30, 2010
    tetris:


thezerohero:


melissa:

(via dersammler, via me, via dwam in the great circle of sex-memory-reblog-life)

    tetris:

    thezerohero:

    melissa:

    (via dersammler, via me, via dwam in the great circle of sex-memory-reblog-life)