検閲Tech: Cluster

ESXiは、無償・無料で利用できるライセンスがあるが、PowerCLIでこのライセンスを導入したESXiに接続すると、システムの動作を変更する操作(write operation、write操作)を実行することができない。例えば、仮想ホストをメンテナンスモードに移行しようとすると、エラーになる。

実際に実行して試してみる。まず、仮想ホストesxi01に接続する。

PowerCLI vis:¥> Connect-VIServer -Server esxi01 -User 管理者ユーザ名 -Password '管理者パスワード'

Name                           Port  User
----                           ----  ----
esxi01                         443   管理者ユーザ名


PowerCLI vis:¥>

現在の状態をGet-VMHostコマンドレットを使って確認する。

PowerCLI vis:¥> Get-VMHost

Name                 ConnectionState PowerState NumCpu CpuUsageMhz CpuTotalMhz   MemoryUsageGB   MemoryTotalGB Version
----                 --------------- ---------- ------ ----------- -----------   -------------   ------------- -------
esxi01               Connected       PoweredOn       2          78        4266           1.293          11.999   5.5.0


PowerCLI vis:¥>

「ConnectionState」が「Connected」即ち、接続中であることが判る。

状態の変更には、Set-VMHostコマンドレットを使う。

PowerCLI vis:¥> Set-VMHost -State Maintenance
Set-VMHost : 2014/05/20 17:41:52    Set-VMHost        Current license or ESXi version prohibits execution of the requested operation.
発生場所 行:1 文字:1
+ Set-VMHost -State Maintenance
+ ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
    + CategoryInfo          : NotSpecified: (:) [Set-VMHost], RestrictedVersion
    + FullyQualifiedErrorId : Client20_ComputeResourceServiceImpl_VmHostEnterMaintenaceMode_ViError,VMware.VimAutomation.ViCore.
   Cmdlets.Commands.SetVMHost

PowerCLI vis:¥>

ライセンスの問題で、要求した操作を実行できない。

PowerCLI: 接続時の証明書に関する警告を抑制

ESXiインストール直後の状態では、PowerCLI上でConnect-VIServerコマンドレットなどを使って当該ESXiに接続すると、X.509証明書に関する警告が表示される。

PowerCLI vis:¥> Connect-VIServer -Server esxi01 -User 管理者ユーザ名 -Password '管理者パスワード'
警告: There were one or more problems with the server certificate for the server esxi01:443:

* The X509 chain could not be built up to the root certificate.

* The certificate's CN name does not match the passed value.

Certificate: [Subject]
  OID.1.2.840.113549.1.9.2="1333622464,564d7761726520496e632e", CN=localhost.localdomain, E=ssl-certificates@vmware.com,
OU=VMware ESX Server Default Certificate, O="VMware, Inc", L=Palo Alto, S=California, C=US

[Issuer]
  O=VMware Installer

[Serial Number]
  4A6C787339575678

[Not Before]
  2012/04/05 19:41:05

[Not After]
  2023/10/05 19:41:05

[Thumbprint]
  CAFD0D77AB938E6B5A70D01262BA4C7FC79121FA



The server certificate is not valid.

警告: THE DEFAULT BEHAVIOR UPON INVALID SERVER CERTIFICATE WILL CHANGE IN A FUTURE RELEASE. To ensure scripts are not affected by
 the change, use Set-PowerCLIConfiguration to set a value for the InvalidCertificateAction option.


Name                           Port  User
----                           ----  ----
esxi01                         443   管理者ユーザ名


PowerCLI vis:¥>

実用上、問題は無いが、この警告を抑制する方法を紹介する。

2014/05/19

PowerCLI: VMware ESXiにライセンスをインストールする。

VMware vSphere PowerCLIは、PowerShellを使ってvShpereやvCloudを管理するコマンドレット群(cmdlets)。ESXi/ESXやvCenter Serverに接続して、対話的な管理作業が可能で、スクリプトによる管理作業の自動化することもできる。

今回は、これを使って、ライセンス導入作業を実施する。

2012/12/19

PowerShellでGoogle Apps Email Migration APIを呼び出す

※PowerShell Advent Calendar 2012参加企画。

この記事では、PowerShellでGoogle Apps Email Migration APIを呼び出すC#サンプルスクリプトをPowerShellに移植したものを紹介する。

PowerShellの利点はいくつもあるが、特筆すべきは以下の点だろう。

対話的コマンドラインインターフェース(CLI)を備えている
プログラミング言語として現代的な文法を備えている
.NET Frameworkを扱うことができる

最初と二番目は、PowerShellは、CMD.exeでできたことを網羅しつつ、現代的な文法を備えたスクリプト言語、と言うことだ。Windows標準環境では、CMD.exeを使うことができたが、文法が貧弱でプログラミングが困難だった。同じくWindows標準環境では、VBScriptやJScriptなどの現代的なスクリプト言語が使えたが、対話的CLIが無かった。
三番目だが、Windows標準環境では、.NET Frameworkの重要度が上がっているが、CMD.exeではこれを直接扱う方法が無かった。PowerShellでは可能になった。

そこで、この記事では、PowerShellから.NET Frameworkへアクセスするスクリプトを紹介する。ただ、PowerShellから標準的な.NET Frameworkのライブラリにアクセスする方法は、他にもいい記事があるので、改めて紹介する意味は薄い。ここでは少し趣向を変え、PowerShellからGoogle Apps Email Migration APIを使う例を紹介する。Google Apps Email Migration APIのクライアントライブラリは、Java版・Python版の他に.NET版も提供されている。このサンプルスクリプトmigrationsample.csをPowerShellに移植した。コードmigrationsample.ps1(ダウンロード)は以下の通り。

<#
.SYNOPSIS
Sample script to demonstrate the use of the Google Apps Domain Migration API client library.

.DESCRIPTION
Sample script to demonstrate the use of the Google Apps Domain Migration API client library.
The original C# version is from https://developers.google.com/google-apps/email-migration/.

.INPUTS
Nothing.

.OUTPUTS
Nothing.
#>

[CmdletBinding()param(
    # The hosted domain (e.g. example.com) in which the migration will occur.
    [String]
    [parameter(Mandatory=$true)]
    $domain,

    # The username of the administrator or user migrating mail.
    [String]
    [parameter(Mandatory=$true)]
    $adminUsername,

    # The password of the administrator or user migrating mail.
    [String]
    [parameter(Mandatory=$true)]
    $adminPassword,

    # The username to which emails should be migrated.
    # End users can only transfer mail to their own mailboxes.
    # If unspecified, will default to login_email.
    [String]
    [parameter(Mandatory=$true)]
    $destinationUser = ''
)

#####
$REDIST_PATH = "$Env:ProgramFiles\Google\Google Data API SDK\Redist"
Add-Type -Path "$REDIST_PATH\Google.GData.Apps.dll"
Add-Type -Path "$REDIST_PATH\Google.GData.Client.dll"
Add-Type -Path "$REDIST_PATH\Google.GData.Extensions.dll"

$LabelFriend = New-Object Google.GData.Extensions.Apps.LabelElement("Friends")
$LabelEventInvitations = New-Object Google.GData.Extensions.Apps.LabelElement("Event Invitations")

$PropertyElementINBOX = [Google.GData.Extensions.Apps.MailItemPropertyElement]::INBOX
$PropertyElementSTARRED = [Google.GData.Extensions.Apps.MailItemPropertyElement]::STARRED
$PropertyElementUNREAD = [Google.GData.Extensions.Apps.MailItemPropertyElement]::UNREAD


[String]$rfcTxt = @"
Received: by 10.143.160.15 with HTTP; Mon, 16 Jul 2007 10:12:26 -0700 (PDT)
Message-ID: <_message_id_ mail.gmail.com="mail.gmail.com">
Date: Mon, 16 Jul 2007 10:12:26 -0700
From: "Mr. Serious" <serious adomain.com="adomain.com">
To: "Mr. Admin" <testadmin apps-provisioning-test.com="apps-provisioning-test.com">
Subject: Random Subject
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Delivered-To: testadmin@apps-provisioning-test.com

This is a message delivered via DMAPI
"@

$random = New-Object Random


if($destinationUser -eq '') {
    $destinationUser = $adminUsername
}


$mailItemService = New-Object Google.GData.Apps.Migration.MailItemService($domain, "Sample Migration Application")
$mailItemService.setUserCredentials("$adminUsername@$domain", $adminPassword)


<#
.DESCRIPTION
Generates a random RFC822 message based on the template in rfcTxt.
We have to randomly modify the subject and message ID to prevent duplicate
supression by the Gmail server.

.INPUTS
Nothing.

.OUTPUTS
The randomly-modified RFC822 message.
#>
Function GenerateRandomRfcText
{
    ($rfcTxt -replace "Random Subject", "Random Subject $($random.Next())") `
        -replace "_message_id_", "$($random.Next())"
}


<#
.DESCRIPTION
Helper method to set up a new MailItemEntry.

.INPUTS
Nothing.

.OUTPUTS
The newly created MailItemEntry.
#>
Function SetupMailItemEntry
{
    param(
        # The batch ID for this entry.
        [String]$batchId
    )

    $entry = New-Object Google.GData.Apps.Migration.MailItemEntry

    [void]$entry.Labels.Add($LabelFriend)
    [void]$entry.Labels.Add($LabelEventInvitations)

    [void]$entry.MailItemProperties.Add($PropertyElementINBOX)
    [void]$entry.MailItemProperties.Add($PropertyElementSTARRED)
    [void]$entry.MailItemProperties.Add($PropertyElementUNREAD)

    $entry.Rfc822Msg = New-Object Google.GData.Extensions.Apps.Rfc822MsgElement(GenerateRandomRfcText)

    $entry.BatchData = New-Object Google.GData.Client.GDataBatchEntryData
    $entry.BatchData.Id = $batchId

    $entry
}


<#
.DESCRIPTION
Demonstrates inserting several mail items in a batch.

.INPUTS
Nothing.

.OUTPUTS
A MailItemFeed with the results of the insertions.
#>
Function BatchInsertMailItems
{
    param(
        # The number of entries to insert.
        [Int]$numToInsert
    )

    [Google.GData.Apps.Migration.MailItemEntry[]]$entries = @()

    # Set up the mail item entries to insert.
    foreach($index in 0..($numToInsert-1)) {
        $entries += SetupMailItemEntry([String]$index)
    }

    # Execute the batch request and print the results.
    [Google.GData.Apps.Migration.MailItemFeed]$batchResult = $mailItemService.Batch($domain, $destinationUser, $entries)
    [Google.GData.Client.AtomEntry]$entry = $Null
    foreach($entry in $batchResult.Entries) {
        [Google.GData.Client.GDataBatchEntryData]$batchData = $entry.BatchData

        Write-Host "Mail message $($batchData.Id): $($batchData.Status.Code) $($batchData.Status.Reason)"
    }

    $batchResult
}

try {
    # Insert several emails in a batch.
    [Google.GData.Apps.Migration.MailItemFeed]$batchResults = BatchInsertMailItems(10)
} catch [Google.GData.Client.GDataRequestException] {
    Write-Host ("Operation failed ({0}): {1}" -f $Error[0].Message, $Error[0].ResponseString)
}

使い方は次の通り。

migrationsample.ps1 domain userEmail password [destinationEmail]

ここで、domainは、Google Appsのドメイン名、userEmailとpasswordは、対象となるユーザの資格情報。もしdestinationEmailを与えると、対象となるユーザを指定したことになり、その場合、userEmailとpasswordは、Google Appsのドメイン管理者の資格情報を与える必要がある。

以下はその実行例。

PS C:\Users\user01> .\migrationsample.ps1 example.co.jp appsmaster 'password' appsuser
Mail message : 201 Created
Mail message : 201 Created
Mail message : 201 Created
Mail message : 201 Created
Mail message : 201 Created
Mail message : 201 Created
Mail message : 201 Created
Mail message : 201 Created
Mail message : 201 Created
Mail message : 201 Created
PS C:\Users\user01>

この例では、10通すべてのメールデータの処理結果が状態コード201で、Google Apps上に移行されたことが判る。

なお、このコードを実行するためには、事前に次の作業を実行しておく必要がある。

Google Data APIクライアントライブラリのダウンロードおよびインストール
PowerShell実行ポリシの変更

実際のメールデータ移行作業での注意点については、こちらを参照して欲しい。

2008/04/02

RHCS: iSCSI, DM-MP, CLVM and GFS・その9・考察

これまで、iSCSIを用いて二本の経路で共有されたブロックデバイスをCLVMで論理ボリュームとして扱い、その論理ボリュームをGFS2でフォーマットし、マウントする手順について述べた。この構成では、iSCSIターゲット=イニシエータ間のパスが複数存在するので、この間の接続が信頼性の急所(single point of failure)にならない。ここまでは、『その1・概要』および『その5・Device-Mapper Multipathの設定』で述べた通り。

ただし、今回の構成には、問題点がある。

クラスタcDomUsのメンバ、dc[123]が仮想マシンフェンス(XVMフェンス)された場合、システム起動されても、iSCSIの接続は復旧しない。この場合、VGcDomUs00やLVGFS00は認識されず、GFS2ファイルシステムはマウントされない。
iSCSIターゲット=イニシエータ間のパスが何らかの不具合で一時的に切断された場合、その後障害が復旧しても、当該パスは自動的に復旧しない。

iSCSIターゲット用RPMパッケージscsi-target-utilsの不具合によるものだ。この不具合は、『その4・iSCSIイニシエータの設定』で以下の通り述べた。

ターゲット側で使用するscsi-target-utilsで提供されるサービスtgtdは、同一パス・同一イニシエータ名でのセッションでの多重接続を拒否する。従って、イニシエータ側では、ユニークなイニシエータ名を使用する必要がある。
また、tgtdは、イニシエータが正常なログアウト処理を行わずに停止した場合、そのイニシエータに対するセッションを保持し続ける。このイニシエータが再起動され、ターゲットにログインしようとすると、ターゲット側には同一パス・同一イニシエータ名のセッションが残っているため、ターゲットはこのログインを拒否する。このため、このイニシエータはストレージにアクセスできなくなってしまう。

従って、少なくとも現時点では、CentOS 5をiSCSIターゲットとしたシステムでは、Device-Mapper Multipathの利点を活かしきれない。

『その1・概要』
『その2・インストールとクラスタの構成』
『その3・iSCSIターゲットの設定』
『その4・iSCSIイニシエータの設定』
『その5・Device-Mapper Multipathの設定』
『その6・CLVMの設定』
『その7・GFS2の設定』
『その8・Congaでの設定』
『その9・考察』

2008/03/31

RHCS: iSCSI, DM-MP, CLVM and GFS・その8・Congaでの設定

今までの設定を、できるだけConga (Luci & Ricci)を使って行う方法を紹介する。
Congaは、Device-Mapper Multipath (DM-MP)を理解しないことに注意。これは、GNBDを理解しないのと似ている(『Red Hat Cluster: GNBD, CLVM and GFS・その8・Congaからの設定』参照)。つまり、CongaからDM-MPを設定できないし、Congaは/etc/mapper/mpath0等のDM-MPデバイスをディスクとして認識しない。従って、CongaでDM-MPデバイスをGFS2としてフォーマットするのに先立って、論理ボリュームマネージャ(logical volume manager, LVM)で物理ボリューム(physical volume, PV)およびボリュームグループ(volume group, VG)を設定しなければならない。
実際、『その6・CLVMの設定』の『PVの作成』までを実行した状態で、Luciの設定画面から[strage]タブ→ [System List]からcDomUsのメンバ(この場合はdc1.xencluster)を選ぶと、

の様に、iSCSIで作成されたデバイス/dev/sd[ab]はディスクとして認識されるが、DM-MPデバイス/dev/mapper/mpath0やPVは認識されない。
この状態から、『その6・CLVMの設定』の『VGの作成』を実行し、再び上の画面の[Reprobe Storage]ボタンを押すか、他のノードの画面を表示させると、

の様に、VG VGcDomUsが認識される。
ここで、[VGcDomUs00] → [Volume Group Properties:]と展開していくと、次の画面が表示される。

[New Logical Volume]ボタンを押下する。

スクロールダウンする。

ここで、以下の通り入力する。

[Logical Volume Name]: LVGFS00
[Content]: GFS2 - Global FS v.2
[Unique GFS Name]: GFS00
[Mountpoint]: /mnt/gfs00
[Mount]: true
[List in /etc/fstab]: true

入力後、[Create]ボタンを押下する。

確認を求めるダイアログが表示される。[OK]ボタンを押下する。

新しい論理ボリューム(logical volume, LV)、LVGFS00が作成され、GFS2でフォーマットされ、/mnt/gfs00にマウントされている。
このとき、設定を行ったノードのコンソール画面には、以下のようなエラーが表示される。

Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 370, in auto_save_callback
self.save()
File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 351, in save
self.sigs.write_xml('sigs', self.filepath)
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 570, in write_xml
f.write(self.get_xml_text_doc(obj_name))
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 529, in get_xml_text_doc
doc = self.get_xml_doc(obj_name)
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 524, in get_xml_doc
root = self.get_xml_nodes(doc, obj_name)
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 599, in get_xml_nodes
list.addChild(item.get_xml_nodes(doc, item_name))
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 625, in get_xml_nodes
root.newChild(None, name, value)
File "/usr/lib/python2.4/site-packages/libxml2.py", line 3217, in newChild
ret = libxml2mod.xmlNewChild(self._o, ns__o, name, content)
TypeError: xmlNewChild() argument 4 must be string without null bytes or None, not str

これは、『Red Hat Cluster: GNBD, CLVM and GFS・その8・Congaからの設定』と同じ。以下の通り、設定自体は正しく行われているので、無視する。

[root@dc1 lvm]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/xvda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/VGcDomUs00-LVGFS00 on /mnt/gfs00 type gfs2 (rw,hostdata=jid=0:id=65539:first=1)
[root@dc1 lvm]# cat /etc/fstab
/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
/dev/VGcDomUs00/LVGFS00 /mnt/gfs00 gfs2 defaults 0 0
[root@dc1 lvm]#

他のノードでも同様に設定する。ただし、LVの生成とGFS2のフォーマットは終わっているので、設定するのは、マウントポイントのみ。[System List] → [dc2.xencluster] → [VGcDomUs00] → [Logical Volumes:] → [LVGFS00 3.98 GB]と選択する。

ここで、

[Mountpoint]: /mnt/gfs00
[/etc/fstab Mountpoint]: /mnt/gfs00

と入力し、[Apply]ボタンを押下する。

確認を求めるダイアログが表示される。[OK]ボタンを押下する。

このとき、設定対象ノード(上の場合はdc2.xencluster)のコンソール上には、やはり以下のようなエラーが表示される。

Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 370, in auto_save_callback
self.save()
File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 351, in save
self.sigs.write_xml('sigs', self.filepath)
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 570, in write_xml
f.write(self.get_xml_text_doc(obj_name))
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 529, in get_xml_text_doc
doc = self.get_xml_doc(obj_name)
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 524, in get_xml_doc
root = self.get_xml_nodes(doc, obj_name)
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 599, in get_xml_nodes
list.addChild(item.get_xml_nodes(doc, item_name))
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 625, in get_xml_nodes
root.newChild(None, name, value)
File "/usr/lib/python2.4/site-packages/libxml2.py", line 3217, in newChild
ret = libxml2mod.xmlNewChild(self._o, ns__o, name, content)
TypeError: xmlNewChild() argument 4 must be string without null bytes or None, not str

ただし、以下の通り設定自体は行われているので無視する。

[root@dc2 lvm]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/xvda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/VGcDomUs00-LVGFS00 on /mnt/gfs00 type gfs2 (rw,hostdata=jid=1:id=65539:first=0)
[root@dc2 lvm]# cat /etc/fstab
/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
/dev/VGcDomUs00/LVGFS00 /mnt/gfs00 gfs2 defaults 0 0
[root@dc2 lvm]#

残りのノードに対しても、同様に設定する。

『その1・概要』
『その2・インストールとクラスタの構成』
『その3・iSCSIターゲットの設定』
『その4・iSCSIイニシエータの設定』
『その5・Device-Mapper Multipathの設定』
『その6・CLVMの設定』
『その7・GFS2の設定』
『その8・Congaでの設定』
『その9・考察』

2008/03/28

RHCS: iSCSI, DM-MP, CLVM and GFS・その7・GFS2の設定

前回『その6・CLVMの設定』で作成した論理ボリューム(logical volume, LV) /dev/VGcDomUs00/LVGFS00をGFS2でフォーマットし、マウントする。手順は、『Red Hat Cluster: GNBD, CLVM and GFS・その7・GFS2の設定』と同様。以下の通り作業する。

フォーマット
以下の作業をdc[123]の内の一台で行う(すべてのノードで実行する必要はない)。実行には若干時間がかかるかもしれない。

[root@dc1 lvm]# mkfs -t gfs2 -j 4 -p lock_dlm -t cDomUs:GFS00 /dev/VGcDomUs00/LVGFS00
This will destroy any data on /dev/VGcDomUs00/LVGFS00.

Are you sure you want to proceed? [y/n] y

Device:                    /dev/VGcDomUs00/LVGFS00
Blocksize:                 4096
Device Size                4.00 GB (1047552 blocks)
Filesystem Size:           4.00 GB (1047551 blocks)
Journals:                  4
Resource Groups:           16
Locking Protocol:          "lock_dlm"
Lock Table:                "cDomUs:GFS00"

[root@dc1 lvm]#

マウント
LVGFS00を、dc[123]それぞれでマウントする。

[root@dc1 lvm]# mkdir /mnt/gfs00
[root@dc1 lvm]# mount /dev/VGcDomUs00/LVGFS00 /mnt/gfs00
[root@dc1 lvm]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/xvda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/VGcDomUs00-LVGFS00 on /mnt/gfs00 type gfs2 (rw,hostdata=jid=0:id=196611:first=1)
[root@dc1 lvm]#

[root@dc2 lvm]# mkdir /mnt/gfs00
[root@dc2 lvm]# mount /dev/VGcDomUs00/LVGFS00 /mnt/gfs00
[root@dc2 lvm]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/xvda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/VGcDomUs00-LVGFS00 on /mnt/gfs00 type gfs2 (rw,hostdata=jid=1:id=196611:first=0)
[root@dc2 lvm]#

[root@dc3 lvm]# mkdir /mnt/gfs00
[root@dc3 lvm]# mount /dev/VGcDomUs00/LVGFS00 /mnt/gfs00
[root@dc3 lvm]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/xvda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/VGcDomUs00-LVGFS00 on /mnt/gfs00 type gfs2 (rw,hostdata=jid=2:id=196611:first=0)
[root@dc3 lvm]#

システム起動時の設定
システム起動時からマウントされるよう、/etc/fstabに設定を追加する。各ノードdc[123]それぞれで以下を実行する。

[root@dc1 ~]# echo '/dev/VGcDomUs00/LVGFS00 /mnt/gfs00              gfs2    rw              1 2' >> /etc/fstab
[root@dc1 ~]# shutdown -r now
＜＜略＞＞
[root@dc1 ~]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/xvda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/VGcDomUs00-LVGFS00 on /mnt/gfs00 type gfs2 (rw,hostdata=jid=0:id=196611:first=0)
[root@dc1 ~]#


[root@dc2 ~]# echo '/dev/VGcDomUs00/LVGFS00 /mnt/gfs00              gfs2    rw            1 2' >> /etc/fstab
[root@dc2 ~]# shutdown -r now
＜＜略＞＞
[root@dc2 ~]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/xvda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/VGcDomUs00-LVGFS00 on /mnt/gfs00 type gfs2 (rw,hostdata=jid=1:id=196611:first=0)
[root@dc2 ~]#

[root@dc3 ~]# echo '/dev/VGcDomUs00/LVGFS00 /mnt/gfs00              gfs2    rw            1 2' >> /etc/fstab
[root@dc3 ~]# shutdown -r now
＜＜略＞＞
[root@dc3 ~]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/xvda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/VGcDomUs00-LVGFS00 on /mnt/gfs00 type gfs2 (rw,hostdata=jid=2:id=196611:first=0)
[root@dc3 ~]#

『その1・概要』
『その2・インストールとクラスタの構成』
『その3・iSCSIターゲットの設定』
『その4・iSCSIイニシエータの設定』
『その5・Device-Mapper Multipathの設定』
『その6・CLVMの設定』
『その7・GFS2の設定』
『その8・Congaでの設定』
『その9・考察』

RHCS: iSCSI, DM-MP, CLVM and GFS・その6・CLVMの設定

DM-MPによって作成されたデバイス/dev/mapper/mpath0上にクラスタ対応の論理ボリューム(logical volume, LV)を作成する。手順は、『Red Hat Cluster: GNBD, CLVM and GFS・その6・CLVMの設定』と同様だ。

『Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる』で紹介したようにConga (Luci & Ricci)を用いてクラスタを構成していれば、クラスタメンバ上ではclvmdが起動されている。

[root@dc3 ~]# chkconfig --list clvmd
clvmd           0:off   1:off   2:on    3:on    4:on    5:on    6:off
[root@dc3 ~]# service clvmd status
clvmd (pid 2023) is running...
active volumes: LogVol00 LogVol01
[root@dc3 ~]#

初期状態では、論理ボリュームマネージャ(logical volume manager, LVM)には、ローカルのもののみが認識されている。

[root@dc3 ~]# pvs
PV         VG         Fmt  Attr PSize PFree
/dev/xvda2 VolGroup00 lvm2 a-   3.88G    0
[root@dc3 ~]# vgs
VG         #PV #LV #SN Attr   VSize VFree
VolGroup00   1   2   0 wz--n- 3.88G    0
[root@dc3 ~]# lvs
LV       VG         Attr   LSize   Origin Snap%  Move Log Copy%
LogVol00 VolGroup00 -wi-ao   3.34G
LogVol01 VolGroup00 -wi-ao 544.00M
[root@dc3 ~]#

以下の通り作業する。

設定ファイルの修正
初期状態では、LVMは、すべてのデバイスを走査する。この状態では、DM-MPによって作成されたデバイス/dev/mapper/mpath0とその背後のデバイス/dev/sd[ab]が走査されるため、同一物理ボリューム(physical volume, PV)、同一ボリュームグループ(volume group, VG)、同一LVが複数回検出されてしまい、都合が悪い。
これを回避するため、/dev/sd[ab]を走査しない様設定する。
以下の作業をdc[123]それぞれで実施する。

[root@dc3 ~]# cd /etc/lvm
[root@dc3 lvm]# cp -p lvm.conf lvm.conf.orig
[root@dc3 lvm]# sed 's/^\( *filter =\).*$/\1 [ "r\/sd.*\/","a\/.*\/" ]/' < lvm.conf.orig > lvm.conf
[root@dc3 lvm]# diff lvm.conf.orig lvm.conf
52c52
<     filter = [ "a/.*/" ]
---
>     filter = [ "r/sd.*/","a/.*/" ]
[root@dc3 lvm]#

この状態では、まだ新しいPV、VGおよびLVは設定されていないので、強制的にLVMに走査させても、変化はない。

[root@dc3 lvm]# pvscan
PV /dev/xvda2   VG VolGroup00   lvm2 [3.88 GB / 0    free]
Total: 1 [3.88 GB] / in use: 1 [3.88 GB] / in no VG: 0 [0   ]
[root@dc3 lvm]# vgscan
Reading all physical volumes.  This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
[root@dc3 lvm]# lvscan
ACTIVE            '/dev/VolGroup00/LogVol00' [3.34 GB] inherit
ACTIVE            '/dev/VolGroup00/LogVol01' [544.00 MB] inherit
[root@dc3 lvm]#

PVの作成
DM-MPによって生成されたデバイス/dev/mapper/mpath0をPVとして設定する。以下の作業をdc[123]の内の一台で行う(すべてのノードで実行する必要はない)。

[root@dc2 lvm]# pvcreate /dev/mapper/mpath0
Physical volume "/dev/mapper/mpath0" successfully created
[root@dc2 lvm]# pvdisplay /dev/mapper/mpath0
--- NEW Physical volume ---
PV Name               /dev/dm-2
VG Name
PV Size               4.00 GB
Allocatable           NO
PE Size (KByte)       0
Total PE              0
Free PE               0
Allocated PE          0
PV UUID               mVdkgs-gUtS-Rz1f-SZhm-NoIr-6kkJ-hQwle1

[root@dc2 lvm]#

他のノードでpvscanを実行すると、このPVが認識される。

[root@dc3 lvm]# pvscan
PV /dev/xvda2   VG VolGroup00   lvm2 [3.88 GB / 0    free]
PV /dev/dm-2                    lvm2 [4.00 GB]
Total: 2 [7.88 GB] / in use: 1 [3.88 GB] / in no VG: 1 [4.00 GB]
[root@dc3 lvm]#

[root@dc1 lvm]# pvscan
PV /dev/xvda2   VG VolGroup00   lvm2 [3.88 GB / 0    free]
PV /dev/dm-2                    lvm2 [4.00 GB]
Total: 2 [7.88 GB] / in use: 1 [3.88 GB] / in no VG: 1 [4.00 GB]
[root@dc1 lvm]#

VGの作成
作成したPVを利用して、新しいVG・VGcDomUs00を作成する。作成時にクラスタ対応の指定(--clustered yオプション)が必要。以下の作業をdc[123]の内の一台で行う(すべてのノードで実行する必要はない)。

[root@dc1 lvm]# vgcreate --clustered y VGcDomUs00 /dev/mapper/mpath0
Volume group "VGcDomUs00" successfully created
[root@dc1 lvm]# vgdisplay VGcDomUs00
--- Volume group ---
VG Name               VGcDomUs00
System ID
Format                lvm2
Metadata Areas        1
Metadata Sequence No  1
VG Access             read/write
VG Status             resizable
Clustered             yes
Shared                no
MAX LV                0
Cur LV                0
Open LV               0
Max PV                0
Cur PV                1
Act PV                1
VG Size               4.00 GB
PE Size               4.00 MB
Total PE              1023
Alloc PE / Size       0 / 0
Free  PE / Size       1023 / 4.00 GB
VG UUID               njS90y-VYyX-KUEc-NoH5-sCrn-anXv-4Lgudt

[root@dc1 lvm]#

このVGをclvmdに認識させるため、dc[123]それぞれで、サービスclvmdを再起動する(システムごと再起動してもよい)。

[root@dc3 lvm]# service clvmd restart
Deactivating VG VGcDomUs00:   0 logical volume(s) in volume group "VGcDomUs00" now active
[  OK  ]
Stopping clvm:[  OK  ]
Starting clvmd: [  OK  ]
Activating VGs:   2 logical volume(s) in volume group "VolGroup00" now active
0 logical volume(s) in volume group "VGcDomUs00" now active
[  OK  ]
[root@dc3 lvm]#

LVの作成
VGcDomUs00上にLV・LVGFS00を作成する。以下の作業をdc[123]の内の一台で行う(すべてのノードで実行する必要はない)。

[root@dc2 lvm]# lvcreate --extents=1023 --name=LVGFS00 VGcDomUs00
Logical volume "LVGFS00" created
[root@dc2 lvm]# lvs
LV       VG         Attr   LSize   Origin Snap%  Move Log Copy%
LVGFS00  VGcDomUs00 -wi-a-   4.00G
LogVol00 VolGroup00 -wi-ao   3.34G
LogVol01 VolGroup00 -wi-ao 544.00M
[root@dc2 lvm]# lvdisplay /dev/VGcDomUs00/LVGFS00
--- Logical volume ---
LV Name                /dev/VGcDomUs00/LVGFS00
VG Name                VGcDomUs00
LV UUID                6M8L4n-x03W-ydk3-iKFF-79U0-Dt8y-rI5SVL
LV Write Access        read/write
LV Status              available
# open                 0
LV Size                4.00 GB
Current LE             1023
Segments               1
Allocation             inherit
Read ahead sectors     0
Block device           253:3

[root@dc2 lvm]#

他のノードでもこのLVが認識されていることを確認する。

[root@dc3 lvm]# lvs
LV       VG         Attr   LSize   Origin Snap%  Move Log Copy%
LVGFS00  VGcDomUs00 -wi-a-   4.00G
LogVol00 VolGroup00 -wi-ao   3.34G
LogVol01 VolGroup00 -wi-ao 544.00M
[root@dc3 lvm]#

[root@dc1 lvm]# lvs
LV       VG         Attr   LSize   Origin Snap%  Move Log Copy%
LVGFS00  VGcDomUs00 -wi-a-   4.00G
LogVol00 VolGroup00 -wi-ao   3.34G
LogVol01 VolGroup00 -wi-ao 544.00M
[root@dc1 lvm]#

RHCS: iSCSI, DM-MP, CLVM and GFS・その5・Device-Mapper Multipathの設定

前回『その4・iSCSIイニシエータの設定』で認識されたデバイスsdaおよびsdbは、異なる経路で共有されている一つのストレージだ。つまり、sdaへのアクセスとsdbへのアクセスは等価だ。
だたし、経路(ネットワーク)が違うため、経路が信頼性の急所(single point of failure)とならない。つまり、どちらかの経路が生きていれば、このストレージへのアクセスが確保される。
以上のことを利用して、障害経路を使用せず、正常経路のみを自動的に選択する仕組みがDevice-Mapper Multipath(DM-MP)だ。

インストール直後は、DM-MPは起動されていない。

[root@dc1 ~]# chkconfig --list multipathd
multipathd      0:off   1:off   2:off   3:off   4:off   5:off   6:off
[root@dc1 ~]# service multipathd status
multipathd is stopped
[root@dc1 ~]# ls -l /dev/mapper/mpath0
ls: /dev/mapper/mpath0: No such file or directory
[root@dc1 ~]#

dc[123]それぞれについて以下を実行する。

設定ファイルの修正
DM-MPの設定ファイルは、/etc/multipath.conf。インストール直後の状態では、すべてのデバイスを無視するよう設定されている。これを修正する。

[root@dc1 ~]# cd /etc
[root@dc1 etc]# cp -p multipath.conf multipath.conf.orig
[root@dc1 etc]# sed 's/^\( *devnode\)/#\1/' < multipath.conf.orig > multipath.conf
[root@dc1 etc]# diff multipath.conf.orig multipath.conf
11c11
<         devnode "*"
---
> #        devnode "*"
[root@dc1 etc]#

サービスmultipathdの起動
DM-MPのサービス、multipathdを起動すると、デバイスが走査され、自動的に/dev/sd[ab]がグループ化され、デバイス/dev/mapper/mpath0が作成される。

[root@dc1 etc]# service multipathd start
Starting multipathd daemon: [  OK  ]
[root@dc1 etc]# multipath -l
mpath0 (16465616462656166313a3100000000000000000000000000) dm-2 IET,VIRTUAL-DISK
[size=4.0G][features=0][hwhandler=0]
\_ round-robin 0 [prio=0][active]
\_ 0:0:0:1 sda 8:0   [active][undef]
\_ round-robin 0 [prio=0][enabled]
\_ 1:0:0:1 sdb 8:16  [active][undef]
[root@dc1 etc]# ls -l /dev/mapper/mpath0
brw-rw---- 1 root disk 253, 2 Mar 28 21:27 /dev/mapper/mpath0
[root@dc1 etc]#

サービス自動起動の設定と確認
以下の通り設定し、再起動後も正しく動作することを確認する。

[root@dc1 etc]# chkconfig multipathd on
[root@dc1 etc]# shutdown -r now
＜＜略＞＞
[root@dc1 ~]# multipath -l
mpath0 (16465616462656166313a3100000000000000000000000000) dm-2 IET,VIRTUAL-DISK
[size=4.0G][features=0][hwhandler=0]
\_ round-robin 0 [prio=0][active]
\_ 1:0:0:1 sdb 8:16  [active][undef]
\_ round-robin 0 [prio=0][enabled]
\_ 0:0:0:1 sda 8:0   [active][undef]
[root@dc1 ~]# ls -l /dev/mapper/mpath0
brw-rw---- 1 root disk 253, 2 Mar 28 21:30 /dev/mapper/mpath0
[root@dc1 ~]#

RHCS: iSCSI, DM-MP, CLVM and GFS・その4・iSCSIイニシエータの設定

Xen DomU dc[123]をiSCSIイニシエータ(initiator/クライアント)として構成し、『その3・iSCSIターゲットの設定』で構成したiSCSIターゲット(target/サーバ)fs1上のストレージにアクセスできるようにする。以下の点に注意する必要がある。

各イニシエータに対して、他と重複しないイニシエータ名を設定する(/etc/iscsi/initiatorname.iscsi)。
標準では、サービスiscsiおよびiscsidがシステム停止時に正常に停止されないが、これを正常に停止するよう設定する。

ターゲット側で使用するscsi-target-utilsで提供されるサービスtgtdは、同一パス・同一イニシエータ名でのセッションでの多重接続を拒否する。従って、イニシエータ側では、ユニークなイニシエータ名を使用する必要がある。
また、tgtdは、イニシエータが正常なログアウト処理を行わずに停止した場合、そのイニシエータに対するセッションを保持し続ける。このイニシエータが再起動され、ターゲットにログインしようとすると、ターゲット側には同一パス・同一イニシエータ名のセッションが残っているため、ターゲットはこのログインを拒否する。このため、このイニシエータはストレージにアクセスできなくなってしまう。これを避けるため、2.の対応が必要となる。

以下の作業をdc[123]それぞれで実行する。

イニシエータ名の設定
イニシエータ名は、/etc/iscsi/initiatorname.iscsiに設定する。

[root@dc3 ~]# cd /etc/iscsi
[root@dc3 iscsi]# cp -p initiatorname.iscsi initiatorname.iscsi.orig
[root@dc3 iscsi]# echo "InitiatorName=iqn.2008-02.xencluster:client.$HOSTNAME" > initiatorname.iscsi
[root@dc3 iscsi]# cat initiatorname.iscsi
InitiatorName=iqn.2008-02.xencluster:client.dc3.xencluster
[root@dc3 iscsi]#

ユーザ名・パスワードの設定
デーモンiscsidの基本設定ファイルは、/etc/iscsi/iscsid.conf。ここでは、

認証手法: CHAP
ユーザ名: ken-estu-tech
パスワード: KtrK0Ye1dwV

を設定する。これは、『その3・iSCSIターゲットの設定』で設定したものと同じでなければならない。

[root@dc3 iscsi]# cp -p iscsid.conf iscsid.conf.orig
[root@dc3 iscsi]# sed 's/^#\(node\.session\.auth\.authmethod =\).*/\1 CHAP/
> s/^#\(node\.session\.auth\.username =\).*/\1 ken-estu-tech/
> s/^#\(node\.session\.auth\.password =\).*/\1 KtrK0Ye1dwV/' < iscsid.conf.orig > iscsid.conf
[root@dc3 iscsi]# diff iscsid.conf.orig iscsid.conf
32c32
< #node.session.auth.authmethod = CHAP
---
> node.session.auth.authmethod = CHAP
36,37c36,37
< #node.session.auth.username = username
< #node.session.auth.password = password
---
> node.session.auth.username = ken-estu-tech
> node.session.auth.password = KtrK0Ye1dwV
[root@dc3 iscsi]#

接続設定と確認
接続設定は、/var/lib/iscsi以下に格納されるが、普通はここを直接編集しない。代わりに、iscsiadmコマンドを使う。このコマンドは、実際に接続を行いつつ、対応する設定を/var/lib/iscsiに書き込む。
『その1・概要』で説明した通り、イニシエータからターゲットへは、

fs1.san01.xencluster: 192.168.56.191
fs1.san02.xencluster: 192.168.57.191

の二つのパスが用意されているので、それぞれについて接続設定を行う。

[root@dc3 iscsi]# iscsiadm --mode=discovery --type=sendtargets --portal=fs1.san01.xencluster
192.168.56.191:3260,1 iqn.2008-02.xencluster:storage.fs1.iSCSI00
[root@dc3 iscsi]# iscsiadm --mode=discovery --type=sendtargets --portal=fs1.san02.xencluster
192.168.57.191:3260,1 iqn.2008-02.xencluster:storage.fs1.iSCSI00
[root@dc3 iscsi]# iscsiadm --mode=node --login
Login session [iface: default, target: iqn.2008-02.xencluster:storage.fs1.iSCSI00, portal: 192.168.57.191,3260]
Vendor: IET       Model: Controler         Rev: 0001
Type:   RAID                               ANSI SCSI revision: 05
Vendor: IET       Model: VIRTUAL-DISK      Rev: 0001
Type:   Direct-Access                      ANSI SCSI revision: 05
Login session [iface: default, target: iqn.2008-02.xencluster:storage.fs1.iSCSI00, portal: 192.168.56.191,3260]
scsi 0:0:0:0: Attached scsi generic sg0 type 12
scsi 0:0:0:1: Attached scsi generic sg1 type 0
SCSI device sda: 8388608 512-byte hdwr sectors (4295 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back
SCSI device sda: 8388608 512-byte hdwr sectors (4295 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back
sd 0:0:0:1: Attached scsi disk sda
Vendor: IET       Model: Controler         Rev: 0001
Type:   RAID                               ANSI SCSI revision: 05
scsi 1:0:0:0: Attached scsi generic sg2 type 12
Vendor: IET       Model: VIRTUAL-DISK      Rev: 0001
Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sdb: 8388608 512-byte hdwr sectors (4295 MB)
sdb: Write Protect is off
SCSI device sdb: drive cache: write back
SCSI device sdb: 8388608 512-byte hdwr sectors (4295 MB)
sdb: Write Protect is off
SCSI device sdb: drive cache: write back
sd 1:0:0:1: Attached scsi disk sdb
sd 1:0:0:1: Attached scsi generic sg3 type 0
[root@dc3 iscsi]#

正常に接続できれば、デバイスsdaおよびsdbを確認できる。

[root@dc3 iscsi]# ls -l /dev/sd*
brw-r----- 1 root disk 8,  0 Mar 27 21:38 /dev/sda
brw-r----- 1 root disk 8, 16 Mar 27 21:38 /dev/sdb
[root@dc3 iscsi]#

起動スクリプトの修正
サービスiscsiおよびiscsidの起動スクリプト(initscript)/etc/init.d/{iscsi,iscsid}を最初に述べた通り修正する。これらのスクリプト中、再起動・停止(RUNLEVEL 6および0)のときに以降の処理を行わない部分があるので、これをコメントアウトする。

[root@dc3 iscsi]# cd /etc/init.d
[root@dc3 init.d]# cp -p iscsi iscsi.orig
[root@dc3 init.d]# vi iscsi
＜＜略＞＞
[root@dc3 init.d]# diff iscsi.orig iscsi
38,41c38,41
<       if [ "$RUNLEVEL" = "6" -o "$RUNLEVEL" = "0" -o "$RUNLEVEL" = "1" ]; then
<               success
<               return
<       fi
---
>       #if [ "$RUNLEVEL" = "6" -o "$RUNLEVEL" = "0" -o "$RUNLEVEL" = "1" ]; then
>       #       success
>       #       return
>       #fi
[root@dc3 init.d]# cp -p iscsid iscsid.orig
[root@dc3 init.d]# vi iscsid
＜＜略＞＞
[root@dc3 init.d]# diff iscsid.orig iscsid
48,51c48,51
<         if [ "$RUNLEVEL" = "6" -o "$RUNLEVEL" = "0" -o "$RUNLEVEL" = "1" ]; then
<                 success
<                 return
<         fi
---
>         #if [ "$RUNLEVEL" = "6" -o "$RUNLEVEL" = "0" -o "$RUNLEVEL" = "1" ]; then
>         #        success
>         #        return
>         #fi
[root@dc3 init.d]#

確認
再起動後、正常に接続が行われることを確認する。

[root@dc3 init.d]# shutdown -r now
＜＜略＞＞
[root@dc3 ~]# iscsiadm --mode=node -l
Login session [iface: default, target: iqn.2008-02.xencluster:storage.fs1.iSCSI00, portal: 192.168.57.191,3260]
Login session [iface: default, target: iqn.2008-02.xencluster:storage.fs1.iSCSI00, portal: 192.168.56.191,3260]
[root@dc3 ~]# ls -l /dev/sd*
brw-r----- 1 root disk 8,  0 Mar 27 21:42 /dev/sda
brw-r----- 1 root disk 8, 16 Mar 27 21:42 /dev/sdb
[root@dc3 ~]#

2008/03/26

RHCS: iSCSI, DM-MP, CLVM and GFS・その3・iSCSIターゲットの設定

Xen Dom0 fs1をiSCSIターゲットとして設定する。『その2・インストール』でも述べたとおり、CentOSでは、RPMパッケージscsi-target-utilsを利用することで、iSCSIターゲットとして動作させることができる。
iSCSIターゲットとして動作させる場合には、サービスtgtdを起動しておく必要がある。システム起動時にtgtdが起動されるよう設定し、システムを再起動する。以下の通り作業する。

[root@fs1 ~]# chkconfig --list tgtd
tgtd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
[root@fs1 ~]# chkconfig tgtd on
[root@fs1 ~]# chkconfig --list tgtd
tgtd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
[root@fs1 ~]# shutdown -r now

＜＜略＞＞

[root@fs1 ~]# service tgtd status
tgtd (pid 7337 7336) is running...
[root@fs1 ~]#

サービスtdtdの設定は、tdtadmコマンドで行う。しかし、設定を保存したり、保存した設定をサービス起動時に読込む、という機能は、scsi-target-utilsにはない。なので、一連のtdtadmコマンドをシェルスクリプトとして保存しておき、システム起動後に手動で実行する。
まずは、そのシェルスクリプトstart-targets.shを準備する。

[root@fs1 ~]# cat > start-targets.sh
tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2008-02.xencluster:storage.fs1.iSCSI00
tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/VolGroupXX/LogVoliSCSI00
tgtadm --lld iscsi --op new --mode account --user ken-estu-tech --password KtrK0Ye1dwV
tgtadm --lld iscsi --op bind --mode account --tid 1 --user ken-estu-tech
tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL
[root@fs1 ~]# chmod a+x start-targets.sh
[root@fs1 ~]# ./start-targets.sh
[root@fs1 ~]#

このシェルスクリプトは、tdtdを以下の通り設定する。

ターゲットID(tid) 1、ターゲット名 iqn.2008-02.xencluster:storage.fs1.iSCSI00のiSCSIターゲットを作成する。
ターゲットID 1の論理ユニット番号(LUN) 1の論理ユニットのバッキングストア(backing store)は、/dev/VolGroupXX/LogVoliSCSI00とする。
アカウントken-estu-techを作成、パスワードを設定する
ターゲットID 1に、アカウントken-estu-techを関連付ける。
ターゲットID 1は、どのイニシエータからもアクセス可能とする。

このスクリプトを実行し、状態を確認する。

[root@fs1 ~]# tgtadm --mode=target --op=show
Target 1: iqn.2008-02.xencluster:storage.fs1.iSCSI00
System information:
Driver: iscsi
Status: running
I_T nexus information:
LUN information:
LUN: 0
Type: controller
SCSI ID: deadbeaf1:0
SCSI SN: beaf10
Size: 0
Backing store: No backing store
LUN: 1
Type: disk
SCSI ID: deadbeaf1:1
SCSI SN: beaf11
Size: 4G
Backing store: /dev/VolGroupXX/LogVoliSCSI00
Account information:
ken-estu-tech
ACL information:
ALL
[root@fs1 ~]#

登録: 投稿 (Atom)