先日行いました、
Microsoft Small Business Server 2003から、
Microsoft Windows Server 2008へのアップグレード作業について、
移行作業の問題点や、注意点をまとめます。

まず、Microsoft Small Business Server 2003とは？

Microsoftが小規模事業所向けに販売しているサーバーOSで、
基本的にWindows Serverのコア機能に、
Webベースのファイル共有サービスである、
Microsoft Windows SharePoint Services
電子メールサーバー
Microsoft Exchange Server
データベースサーバー
Microsoft SQL Server
等をバンドルしたものとなっております。

一見、Windows Serverの上位版と思われますが、
以下のような制限があります。（SBS2003の場合）

1、最大ユーザー数またはデバイス数が75まで
2、BDC（バックアップドメインコントローラー）が立てられない

この2が非常に問題で、新しいサーバーへ移行する際、
一般的な移行方法である、
・PDCからBDCへデータベースを複製
・PDCをメンバサーバーへ降格し、BDCをPDCへ昇格
・新サーバーをBDCとして追加し、データベースを複製
・新サーバーをPDCへ昇格
という方法が取れません。

※ADではPDC、BDCという呼び方はしませんが、ここでは便宜上この表現にしています。

MicrosoftからはTransition Packという、
SBSをWindows Serverにアップグレードする製品も用意されていますが、
今回はハードも移行するため、
強引ではありますが、
・新サーバーに新ドメインを作成
・旧サーバー稼働中にクライアントを一旦ドメインから外し、ワークグループ構成へ
・旧サーバーをネットワークから切断し、新サーバー稼動
・クライアントを新ドメインへ加入
・クライアントのプロファイルをコピー
という流れで移行を行いました。

というのも、稼働中のSBS2003が元々NT4からアップグレードしたものであり、
原因不明のエラーも発生していたため、
この際、まっさらな新ドメインに移行し、今後のトラブルを軽減したかった。。。
という理由もあります。

次回はサーバーの事前準備などを紹介します。

○VmwareHA構成

vCenterServer上から各ESXサーバをクラスタグループへ登録しようとすると、登録完了せずにエラー終了してしまう。原因を調べると以下2点を満たす必要がありました。

●ホスト名が名前解決できること。

ホスト名の名前解決はDNSサーバを立てるが面倒な場合は、各サーバの「/etc/hosts」ファイルを編集し対応することも可能です。

●サービスコンソールのGWアドレスと通信できること。

デフォルトで「Isolation Address」としてサービスコンソールのGWアドレスが指定されます。「Isolation Address」とはサーバがNW障害により隔離されたかを判定するアドレスです。この「Isolation Address」とESXホストが通信出来ない場合、ESXホストは自身が隔離されたと判断し、クラスタグループへの登録を拒絶します。HA構成へ加入する場合、実在するGWアドレスを指定し通信ができなくてはいけません。

●VmwareDataRecovery

「DataRecovery」インストール・設定し、いざデータバックアップを行うと「Failed to create snapshot」というエラーが表示され一向にバックアップされません。エラー文から原因が読み取れず、悪戦していましたが、Vmwareのホームページで原因を調査していると、「DataRecovery」のコンソールから詳細ログの取得方法を見つけました。コンソール上から「/usr/bin/datarecovery-support」コマンドを実行すると、各ログファイルがtarボールで固めて提供されます。ログファイルを確認すると、「Host address lookup for server hoge　failed:」という一文を見つけました。DataRecoveryからEsxのホスト名が名前解決できないことが原因でバックアップ処理が途中でエラーになっていたようです。インターネット上に情報がなく苦労しました。

●仮想OSのLinux環境で時計がずれる。

そもそも仮想OSの時刻がずれる原因は、Linux(kernel2.6)標準のタイマ割り込みが1000Hzなのに対し、Vmwareが100Hzなことが原因です。vmの仮想環境では、1000Hz間隔で処理しきれません。Linuxはタイマ割り込みをカウントして時間を管理しているため
1000Hzだとカウントを取りこぼしてしまい。時計がずれる。。らしいのです。

/etc/grub.confを修正。
kernel行に末尾に追加

※dividerは割るときの係数となるので1000Hz / 10 = 100Hzとなる。
※clocksource=acpi_pmはACPIから時間情報を取得する。

○サーバ仮想化導入サービス

写真）　設置・組み立てした19インチラック

次に機器をラッキングし、配線作業へ移ります。ブレードサーバは大幅にケーブル本数を削減できます。ブレードサーバとエンクロージャは内部的にネットワーク接続されるため、外部に露出されるケーブルはとても少なくなります。
既存のラックマウントサーバの配線状態とブレードサーバの配線を見比べて頂くと一目了然です。

写真）　配線状態の比較（既存ラックマウント/ブレードサーバ）

それではいよいよ設定作業へ入ります。
設定のポイントとなる個所について解説します。「共有ディスクのRAID構成について」
共有ディスクは仮想OSのイメージ群が格納される最も重要な領域です。ディスクの冗長性を考えRAID構成で運用します。RAID構成は、RAID10を選択しました。高いディスクIOパフォーマンスと高可用性を実現できる仕組みです。300GBのSASディスク12台をRAID10で構成すると以下のような構成となります。ディスク2台ずつペアを組みRAID1（ミラーリング）し6つできたペアをストライピングします。

図）　RAID10のディスク構成

RAID10では使用できるディスク容量は1/2となり1.8TBになります。仮想OS1つに割り当てる容量を80GBとした場合、作成できる仮想OSは1800GB÷80GB < 23個　となります。最終的には仮想OSを30以上動かしたいのでディスクを増設するしかないなと思っていましたが、なんとVmware vSphere4からシンプロビジョニング機能が利用できるようになりました。シンプロビジョニングとは、ストレージを仮想化して割り当てることで、ストレージの物理容量を削減できる技術です。仮想OSに80GBを割り振り、20GB利用しているとします。通常であれば、仮想OSの80GB分ストレージを消費しますが、シンプロビジョニングの場合、実際利用している20GBしか消費しません。サーバのディスク利用率は多くても2/3程度です。シンプロビジョニングにより無駄なくストレージを利用し、多くの仮想OSを配置できます。
また、RAID10はミラーリングしたグループをストライピングするため、データを複数のディスクへ分散して書き込みます。分散書き込みされることで、高いIOパフォーマンスが望めるはずです。
試しに仮想OS上からディスクのIO速度を計測してみました。

表）　IO速度の比較

	hdparm -t	1GBファイル作成
共有ディスク（RAID10）上の 仮想OS	282.67 MB/sec	185 MB/s
ローカルディスク（SAS）	209.84MB/sec	129MB/s

RAID10の分散書き込みの効果で185MB/sと高いパフォーマンスを計測しました。納得の数字です。ディスクIOがボトルネックになることはなさそうですね。

次回からは仮想システムVmware設定の勘所について説明します。

» Vmware設定の勘所

○サーバ仮想化導入サービス

・移行するサーバのリストアップをする。
仮想化が不向きなサーバは移行しない。
　　　　　　　┣　リソース消費が激しいもの。（ウィルス、SPAM対策サーバなど）
　　　　　　　┣　物理デバイスと密着している。（IP電話管理サーバなど）

・移行するサーバのリソースの使用状況を確認
　　　　　　　┣　CPU、メモリの性能に対する平均利用率と最大利用率を算出。
　　　　　　　　　　　（例　CPU）Intel(R) Pentium(R) 4 CPU 3.00GHz
　　　　　　　　　　　　　CPU数　１
　　　　　　　　　　　　　コア数　１
　　　　　　　　　　　　　周波数　3000MHz
　　　　　　　　　　　　　平均利用率　30%
　　　　　　　　　　　　　最大利用率　80%
　　　　　　　　　　　　　CPUの平均利用率900（1*1*3000*0.30）
　　　　　　　　　　　　　CPUの最大利用値2400（1*1*3000*0.80）

これらの算出したリソース量を積算し、一台のホストサーバのリソース内に収まるように仮想サーバ数を調整する。リソース内に収まるようにと書いたがホストサーバのリソースを100％とした場合、仮想OS群が利用するリソースの利用率はホストサーバに対して60%程度が望ましいと思う。理由としては、VmwareHA機能を有効にし、同様のスペックのサーバを3台準備した場合のことを考えたい。Vmwareのホストサーバのリソース利用率が3台とも60%程度になるように調整する。この状態で、1台のホストサーバが故障し仮想OSを他の正常なホストサーバへ転送する必要が発生した場合どうなるだろうか。故障したサーバの60%のリソースが30％ずつに分散され、残りの2台の余分なリソースで運用を賄うことができる。残り2台の正常なホストサーバは利用率を60%程度に抑えてあるため、故障したサーバのリソース30%が転送されても60%+30%=90%となり、3台で運用していた仮想システムを2台で応急的に運用が可能なのである。このように冗長性を考えた場合は他のホストサーバが故障した時のことを考え、リソースに余地を残しておくことが重要である。弊社の場合は3台構成でHAを組みため60%程度にリソースを抑えて運用している。

　　　　　　　┣　HDD容量の算出。
　　　　　　　　　　　VSphere4からの機能。シンプロビジョニング機能をフル活用。
　　　　　　　　　　　OSで確保したディスク容量ではなく、実際に利用しているディスク容量のみ消費される。

　　　　　　　┣　ディスクIOがボトルネックになりやすい。
　　　　　　　　　　　SASストレージをRAID10で構築することにした。

　　　　　　　┣　消費電力
　　　　　　　　　　　（HPBladeSystemPowerSizingToolを利用）
　　　　　　　　　　　既存物理サーバは約５KVAの消費。
　　　　　　　　　　　ブレード3台+仮想化構成では1.5KVA以内に収まる計算。

「HP BladeSystem Power Sizing Toolの結果」

・ネットワーク設計
弊社の環境では8個のNICを利用することにした。仮想スイッチに対し冗長性を考慮して2個ずつ物理NICを割り振る。外部スイッチへの接続は別々の物理スイッチにチーミング接続し経路障害に備える。データバックアップは帯域を圧迫するため専用のネットワークを準備した。

仮想スイッチ	ポート・グループ	用途
vSwitch0	仮想マシンポートグループ	ホスティング用
vSwitch1	サービスコンソールポート	vCenterServeからの管理
vSwitch2	VMkernelポート	VMotionで利用
vSwitch3	仮想マシンポートグループ	データバックアップ用

以上の設計プランをもとに実際に構築作業を行います。構築作業で苦労した点など今後記載していく予定です。

» 構築作業まずはじめは。

○サーバ仮想化導入サービス

大きな問題としては以下が挙げられます。

これらの問題を解決し、「止めないサーバ」を実現するため、自社サーバ・NW機器を新規で入れ替ええることとなりました。

○シングルポイントを排除する。
　電源・回線・NW機器・サーバ全てを2重化または多重化する必要があります。

○消費電力は１０KVA以内で。
　電源トラブル時に8時間稼働可能な発電機はとても重宝していますが、発電容量が10kVAまという縛りがあります。全ての機器＋空調を併せて10KVA以内の消費電力で運用しなくてはなりません。ここ数年サーバが安価になったこともあり、年々購入台数が増加傾向にあります。このままの増加ペースでは近い将来、消費電力が10KVAをオーバーし、サーバを増設できない事態となります。省電力サーバという選択肢もありますが、劇的な効果は期待できないと思います。

○サーバ環境の統一。
　サーバ環境を統一し、自社開発したコンテンツの動作確認を一元的に行えるようにします。サーバ環境の統一とは、ハードウェア・OS・ミドルウェアのバージョンを揃えることです。環境を統一することで人為的ミスを抑止します。

以上を踏まえ、機器選定をし考案したシステム構成は下記となります。

「ISPの2重化」
東北電力系とNTT系の光回線を利用してインタネットプロバイダを2重化。どちらか一方のキャリアで障害が発生してもサーバが通信を継続できる。インタネット接続用のルータも当然キャリア毎に準備します。

「ロードバランサ設置」
回線を2重化するためと、サーバの負荷分散を行うためロードバランサ装置を設置します。今回選定したロードバランサDNSを利用した仕組みで冗長性と負荷分散機能を提供します。また、ロードバランサ装置自体の故障も考慮しActive-Standby構成でもう一台ロードバランサを準備します。HA（High-Availability）構成としました。

「スイッチイング経路の多重化」
スイッチ経路を敢えてループ構成（通常なら輻輳。）にして、STP（スパニングツリープロトコル）を有効にします。万が一、ケーブルやポート障害または、スイッチ故障が発生しても多重化された経路から、別経路を自動的に学習して通信を再開する仕組みです。

◎「ブレードサーバと仮想化システムの導入」
消費電力を10KVA以内で多数のサーバを運用するため、ブレードサーバと仮想化システムを組み合わせて運用することとなりました。

「電源モジュールの共通化」
ブレードサーバはエンクロージャという入れ物となる部分に電源モジュールが設置され、そこでAC/DC変換を行い、各ブレードサーバへ電力供給されます。各サーバの電源でAC/DC変換を行うよりも効率的なため変換ロスを減らし、消費電力を抑制できます。

「サーバの仮想化」
また、仮想化システムと合わせて利用することで、「サーバの台数増加は消費電力の増加」という現状から回避することができます。仮想化システムを利用して、1台の物理サーバで仮想サーバを10台動作させます。ですから、今まで10台分サーバで消費していた消費電力が、1台分のサーバ消費電力しか消費しなくなるのです（単純に10分の1にはなりませんが。）これは大きな効果が期待できます。

「ハードウェア環境の統一によるメリット」
その他、ブレードサーバになることで、サーバのハードウェア環境が統一されます。ハードウェアに対する保守業務・保守部品が統一されることで、作業が簡素化され、単純なヒューマンエラーを減らせます。

「仮想化による恩恵」
また、仮想化システムの基盤となるVmware上で動作する仮想サーバはハードウェアを仮想デバイスとして認識します。「仮想サーバ」−「仮想レイヤ」−「物理サーバ」というレイヤードとなり、「仮想サーバ」の管理を「物理サーバ」から切り離して行えるようになります。動作している「物理サーバ」が変わったとしても常に同一の仮想環境を得られる仕組みとなっています。数年後サーバをリプレイスするときにVmwareが動作する機器ならば異なる機器でも同一の仮想環境で運用できることとなり、サーバ移行のための、動作検証の手間を多く省けるメリットがあります。フリーOSを多く利用している弊社としては非常に有効です。各サーバメーカでフリーOSの動作検証はほとんど実施していないため購入して自社でテストするまでOSが動作するかわからないのが現状です。失敗することも少々あります。Vmwareが動作さえすれば、全ての仮想OSが現状通り動作するとなれば、サーバ選定で迷うことはなくなりますね。

今までの経験やノウハウを基に考案した、止めないサーバ構成について説明させて頂きました。次回はサーバ仮想環境の設計について説明したいと思います。

» 仮想環境の設計のポイント

○サーバ仮想化導入サービス

　1)ユーザ増加と共にサーバ台数を増え、OS のバージョンが統一されなかったりして、サーバ 管理の手間が増えるという問題。

　2)電源系の問題。サーバには UPS を経由して電源を供給しています。しかし、UPS 自体の電池の寿命で機能しなかったり、また、出力される AC 電源ラインの波形の問題で周辺機器にトラブルを引き起こしたりする問題もあります。

　3)非常用発電装置の電源容量の問題。UPS だけでは、サーバを正常に停止するための時間を稼ぐだけだった(10〜20分程度)ので、8時間程度発電できる非常用発電装置を設置することにしました。(雷などで停電が頻発した時期があったので、導入の決断をしたのだが、設置後は不思議なことに停電が少ない(涙)。しかし、発電装置の導入によりサーバを止めることは無くなったのでサーバ管理の最大の問題である再起動に手間は格段に減ったことは間違い無いです。問題は、その電源容量には限界があることです。サーバを増やし続けることは出来ないのです。

　4)PC のトラブルは電源系とハードディスクに集中します。PC それぞれに電源を持たせることはトラブルの元になる可能性があるのです。

　この様な経験から自社サーバを新規で入れ替えることにしたのであるが、その条件は次の様なことにしました。・・・内容は次回に!!

○サーバ仮想化導入サービス

本社の道路を挟んだ向かい側（文学の森側）の歩道に看板が設置されました。

ぜひ、近くに寄ったら見てみてください！

Yahoo Pipesとは、米Yahooが提供しているウェブサービスで、
さまざまな情報を取得しマッシュアップすることができます。
YahooPipesを使うには、米Yahooのアカウントが必要になるので注意してください。
(Yahoo Japanのアカウントではダメ)

では、早速作ってみましょう。

まず、Yahoo Pipesのトップページの「Sing In」からログインしてみてください。
米Yahooのアカウントがない場合は、「Join Now」から新規アカウントを作成を選んでください。

Sing In後にトップ画面から「Create a pipe」を選択します。

すると、次のような画面がでてきたと思います。

左側のsource、User Inputsなどと書かれた画面がモジュール選択画面です。
ここからモジュールを選択し「Drag module here」と書かれた画面へドラッグすることで、
モジュールが追加されます。

さて、今回、広告カットのために使うモジュールは、次の三つです。
■Fetch Feed
RSSの取得を行うモジュール
■Filter
ルールを定めてフィルタリングを行うモジュール
■Pipe Out
結果を出力するモジュール

次の画面のようにFetch FeedとFilterをドラッグして、追加してみてください。
Pipeoutは自動的に追加されます。

次に、Fetch Feedの下についてる○(インタフェース)をドラッグするとパイプが伸びますので、
それをFilterの上の部分についてるインタフェースにつなげてください。
同じ要領で、FilterからPipe outにつなげます。
次のような画面になります。

これで、どのようなワークフローで広告をカットするのかが、大体さだまりました。
まず、Fetch FeedでRSSを取得→Filterでカットする広告を指定→PipeoutでRSSとして出力のながれで、RSSの広告をカットしてやりたいと思います。

次に、具体的な処理にはいりたいと思います。

まず、広告をカットしたいブログのRSSのURLをFetch Feedに入力します。

次にFilterです。
今回は、Blockとallを選択します。
これは、ルールがすべて当てはまったとき不許可(RSSとして出力しない)にするという事を指しています。
ちなみに、Permitは許可の意味で、anyはルールの一部が当てはまったときという意味です。
ルールの定め方については後述します。

次に、ルールを定めます。
大抵、ブログなどで広告として流されるRSSは、
タイトルに「【広告】」「PR：」などの文字が含まれている場合が多いです。
ですので、これを利用してカットする広告のルールを決めてやります。

Yahoo Pipesの画面で△ボタンをクリックすると、次の画面のようなポップアップがでてくるので
「item.title」を選択。

次に「contains」を選択。
containsとは、含まれているという意味です。

広告のタイトルに含まれている文字を入力してやります。

これで完了です。
SAVEをクリック後、名前をつけて保存してください。

できたプログラムは、MyPipeから確認することができます。
My Pipeからできたプログラムを選択し、Get as RSSをクリックすることで
広告カットしたRSSを取得することができます。

あとは、Google Readerなりお気に入りのRSS Readerに登録して、
広告レスのRSSを読みましょう！

はじめまして、NKテックの新人白石です。
先日、吉野家が期間限定ですが牛丼の値段を270円に値下げしました。
そして、その後、すき家、松屋が吉野家に次いで牛丼を値下げしました。
値段は吉野家より20円安い250円です。

なぜ、このような価格戦争が起こるのか？
それはゲーム理論の囚人のジレンマ問題で説明ができます。

すき家&松屋
	定価	値下げ
吉野家定価		(吉:売上現状維持、す&松:売上現状維持)	(吉:売上減 す&松:売上増)
値下げ (吉:売上増, す&松:売上減)	(吉:売上減 す&松:売上減)

囚人のジレンマについてご存知な方ならわかると思いますが、
すき家&松屋は吉野家の値下げに対して、
(相手の手をそのまま返す)しっぺ返し戦略をとったわけです。
(しっぺ返し戦略:相手と同じ手を繰り出すことで、自分が優位立てる戦略)

吉野家以下の価格になれば、吉野家：売上減、す＆松：売上増という状態になり。
吉野家よりも優位な状態になることがわかるかと思います。
(対して、同じ値段に値下げしたのでは、どちらも売り上げ減となります)

■ なぜ吉野家が値下げに踏み切ったのか
この四つの選択肢で、
一番良いの各社協調し定価で商品を売り続けるという戦略です。
各社、売り上げをある程度維持できます。

しかし、現状維持ではまずい会社があります。
この三者の中で、赤字を出しているのは吉野家だけです。
つまり、吉野家は現状維持ではまずいわけです。
そうした中、吉野家は値下げに踏み切りました。
そうなると、今度はすき家と松屋が売り上げが下がるので値下げします。

価格戦争というのは、こういうスパイラルに陥ってるわけです。

■ 最後に
最近、東京の自由が丘のすぐ近く、都立大学駅前あたりに行ったのですが、
吉野家がソバ専門店を開いてたのを見ました。
理由は、近くの松屋に客をとられてしまったので路線を変更したらしいです。

　しかし、現実には外部サーバを使うことのデメリットも色々と経験させられました。

1)ハードディスクトラブル
サーバのハードディスクがクラッシュしたことがあった。データセンターとの連絡は取れたが、なんと「ディスク交換は平日のみ」。土日は「連絡」だけで対処出来ないとのこと。・・サービスの意味が分からない(涙)。

2)ロードバランサのトラブル
某金融機関の Web サイトを公開する際に、サーバ停止のリスクを避ける意味もあってロードバランサのサービス契約をした。but　なんとロードバランサ自体のトラブルで 二台のサーバは動作しているにも拘わらず、Web が見られない状態に陥った。・・フェイルセーフの意味を知らないのだろうか?(涙)

3)サービス停止
海外の安価なサーバサービスや国内ベンチャーのサーバを利用して、サービス停止の憂き目にあったことが2度ほど・・(涙)

　つまり、大手と言えども完全の安全ということは無いし、また、サーバが手元にあれば緊急的な対処も出来るのに外部のレンタルサーバはトラブル時に何も出来ないことを体験した。これが自社サーバを使い続けた理由でもあります。もちろん、自社サーバに拘ったのはそれだけが理由ではないです。
　当社の Web サイトはスタート当初より perl や php で制作した CMS 機能を組み込むことが進めてきました。外部サーバでは、使用環境に制限があったり動作に不具合が出たりすることもあったので、自社サーバの方が使い勝手が良かったのです。サーバ管理者のコストが掛かるのは覚悟しても・・です。

○サーバ仮想化導入サービス