カテゴリー「サーバ・OS」の21件の記事

July 31, 2016

ライブマイグレーションに失敗した話

VMwareサーバの老朽化に伴って新しい物理サーバを用意して次々とライブマイグレーションしていたとき、1VMのみライブマイグレーションに失敗するという症状に見舞われました。

よくあるライブマイグレーションに失敗する事例としては、マイグレーション先のハードウェアリソース不足、異なったCPUを使っている、実は移行先のハードウェアが壊れていた等いろいろあると思いますが、今回の場合はちょっと違いました。

結論から言うと、このVM(仮想サーバ)のみ割り当てCPUコア数が1となっていたからでした。

ライブマイグレーション実行後しばらくは順調に行ってましたが、しばらくするとVMに一切アクセスができなくなる、いわゆるフリーズ状態となってしまいました。そこでもう一度vmstatを回しながらライブマイグレーションを行うと、「r」の列が高い数値を見せて、その後固まりました。「r」列というのは実行中プロセス数と実行待ちプロセス数の総和ですが、この数値が高いということはCPUリソースが足りていないことを意味します。これを手掛かりに原因がわかったのでした。

|

June 09, 2016

Hyper-V環境からVMware環境への移行

Hyper-V環境とVMware環境が混在していて、今後VMware環境に統合しようと、せっせとHyper-V上のゲストOSを(サーバオーナーと交渉して)撤去していました。しかしふと思いつきました。「ひょっとしてHyper-VのゲストOSイメージをVMwareのゲストOSイメージに変換するツールがあるのでは?」と。ということで探してみたら「Vmware vCenter Converter Standalone」というツールがあっさりと見つかりました。

 

ということで今回はHyper-V環境からVMware環境への移行したときのことを書いてみます。

 

【移行手順】
1. 「Vmware vCenter Converter Standalone」(無料)をダウンロードしてきてインストールして起動します。すると非常にシンプルな画面が現れますので、「Convert machine」をクリックします。


1

2. Hyper-Vの管理ツールであるSCVMM(System Center Virtual Machine Manager)のログイン情報を入力します。

 

3. 移行するゲストOSを選択します。

 

4. 移行先であるvCenterもしくはVMwareサーバのログイン情報を入力します。

 

5. 移行先のクラスタやハイパーバイザーを選択します。

 

6. オプションを設定します。ここで特に注意すべきは、「Data to copy」でThick->Thin provisioningにすることと、NICのVLAN情報を正しいものに変更しておくことです。

2


【やってみて気づいたこと】
(1) 移行後ネットワークがつながらなかったです。どうやらHyper-V用NICが消えて新たにVMware用NICが付与されるようです。よってWindowsの場合はIPを再度振り直し、Linuxの場合は設定ファイルからMACアドレス情報とUUID情報を書き換えるか削除する必要があります。

(2) Windowsの場合、移行前と移行後のActive Directoryの所属ドメインを変える必要があります。移行前にlocal account(administrator権限必須)を生成後ドメインからワークグループに変更して移行し、移行先で再度ドメインに加入するのが良さそうです。

(3)Linuxにて「udev: renamed interface eth0 to eth1」のようなメッセージが出て、eth0が使えなくなってしまうことがあります。これはHyper-V用NIC情報が残ってしまっているからです。この場合、「/etc/udev/rules.d/70-persistent-net.rules」を書き換えたりいろいろしなければならなそうです。

|

December 16, 2013

LinuxでのNIC冗長化(bonding)を少し深く考えてみる

サーバNIC(Network Interface Card)の可用性向上や負荷分散にはNIC冗長化が有効です。NIC冗長化については拙著「インフラエンジニアの教科書」にも記しましたが、bonding、チーミング、リンクアグリゲーションなど様々な呼び名があります。今回はLinux上でのNIC冗長化の話しとなりますので、bondingについての話題となります。

【bondingとは】
bondingとは、複数のNICが搭載されているマシンのNICを束ねて1つの仮想的なNICとして扱うことのできる技術です。例えば1GbpsのNICポートが4つ搭載されているサーバとL2スイッチの間を4本のLANケーブルで接続してbonding設定を有効にさせると、冗長化が行われて最低1本が正常であれば1~3本に問題があっても通信が継続できたり、負荷分散が行われて通信帯域幅を4Gbpsに拡張されたりといった使い方ができます。

Linux Kernelに標準搭載されているbondingでは以下のように7つのmodeがあります。

mode 名称 負荷分散 冗長性 primary
指定 
Switch
機能 
監視
モード
送信 受信 MII ARP
0 balance-rr SW依存 × Ether Channel
全スレーブを順繰り(ラウンドロビン)に使ってパケットを送信。
送信のみ負荷分散。
1 active-backup × × 不要
1つのスレーブのみを active interfaceとしパケットを送信。
active interfaceに障害が発生した場合、他の backup slave を active interfaceに切り替え、冗長性を確保。
2 balance-xor SW依存 × Ether Channel
送信元/先 MACアドレスを元に送信スレーブを決定しパケットを送信。
送信のみ負荷分散。
3 broadcast SW依存 不明 要(設定不明)
全スレーブに同一パケットを送信。
このモードは通常の用途で使用されないので無視。
4 802.3ad SW依存 802.3ad ×
IEEE 802.3ad(LACP)に準拠したリンクアグリゲーション。
5 balance-tlb SW依存 不要 ×
スレーブの負荷に応じて送信スレーブを決定しパケットを送信。
送信のみ負荷分散。
6 balance-alb 不要 ×
balance-tlbの機能に加え、受信も負荷分散。
参考文献: bondingドライバの違いについて


【負荷分散する際気を付けること】
「1Gbpsを4本を束ねると4Gbpsになる」という理屈は理解しやすいですが、適切なmodeを選び適切に設定しないと、例えば送信側は4Gbpsのままだけど受信側は1Gbpsのままといったようなことが起こりがちなので注意が必要です。

bondingを設定する際、ネットワークスイッチ側でも設定が必要な場合とネットワークスイッチ側の設定が特に不要な場合があることにも注意が必要でしょう。

ただしネットワークスイッチ側の設定が特に不要な場合だと言われているmodeにおいてもネットワークスイッチやそのファームウェアバージョンによってはまれに正常に動作しなくなる場合も見受けられるので、本番環境に投入する際には事前検証が必須です。著者の所属する会社のネットワークエンジニア某氏によるとmode4をお勧めしていました。

【Linux Kernelのbondingは実運用に耐えうるものか?】
著者の経験ではLinux Kernelのbondingはどこの会社でも一般的に使われているものなので、適切に設定されていれば安定性についてはそれなりに信頼できそうです。他のホームページでは2つのNICポートでの事例ばかりですが、4つのNICポートでも8つのNICポートでも普通に動作します。

bondingを可用性向上目的で用いる場合は、mode1にてそれぞれのNICポートの配線を別々のネットワークスイッチに接続することをお勧めします。一方bondingを帯域幅増強目的で行う際は、全ての配線を同一ネットワークスイッチに接続するのが一番安定するはずです。ただしこれはネットワークスイッチの挙動に依存する部分でもありますので、複数ネットワークスイッチでも安定的に動作する可能性を否定するものではありません。このあたりはネットワークスイッチベンダーに問い合わせみると良いでしょう。

| | Comments (0) | TrackBack (0)

October 28, 2009

これだけは知っておきたい サーバの常識

本日「これだけは知っておきたい サーバの常識」という本を技術評論社から出版させていただきました。著者は小島太郎さん、佐藤尚孝さん、そして私(監修)です。

この本には以下の特徴があります。

・サーバの全体像を理解することができる入門書です。(専門学校の授業教材などにいかがでしょうか)
・電車の中でも読み進められるように、やさしい文体で書いています。(堅苦しすぎると寝ちゃいますので)
・でも必要なことは端折らずに詰め込んでいます。(エニーキャスト方式とか、ローエンドサーバとハイエンドサーバの違いとか・・・)

よくある入門書だと、ただサーバの機能や用語がずらずらと書かれているだけで、一通り読んでもサーバの全体像がイメージできないということがよくあります。サーバの機能や用語を調べるだけだったらネットで検索すれば十分です。

そんなこともあり、この本ではサーバの全体像を理解してもらいながら、結果的に今自分は何を知っていて何を知らないのかを自分自身で発見してもらえるように構成しました。この本を読んだ後別の本でさらに勉強を進めていき、壁にぶちあたったらまたこの本に戻って確認する、という使い方でしょうか。


この本で込めたかったメッセージは2つあります。

1つ目は、「ハイエンドサーバってこんなにすごい。ハイエンドサーバで使われた機能や仕組みがどんどんミドルエンドサーバやローエンドサーバに技術移転されてきている。なので将来のサーバ像を知りたければ今のハイエンドサーバを見ればいい」ということです。今Windows7などで「64bitだからメモリをたくさん使えたり、仮想化が使えたりするのですごい」と叫ばれていますが、ハイエンドサーバではそんなの数十年前から普通に実現されていました。

2つ目は、このblogで繰り返し述べているように、ローエンドサーバであってもハイエンドサーバであっても、要はCPU、メモリ、ディスクI/O、そしてネットワークという要素で構成されているということです。普段なかなかハイエンドサーバを見る機会はないかと思いますが、このことさえ押さえておけばどうってことはないということです。


是非店頭でご覧いただけたらと思います。よろしくお願い致します。

※追記
技術評論社金田さん、著者の小島さん、佐藤さん。この半年本当にお疲れ様でした!

| | Comments (0) | TrackBack (0)

July 30, 2009

「生きてる」自宅サーバー運用

7月にThinkITさんで自宅サーバー関連の連載を持たせてもらいましたのでご紹介させていただきます。


第1回:自宅サーバーを立てるメリットとデメリット このエントリーをブックマークに追加
第2回:自宅サーバーを作ってみよう このエントリーをブックマークに追加
第3回:自宅サーバーを粋に使いこなそう このエントリーをブックマークに追加

※余談
ThinkITはシンクアイティーではなくてシンクイットと読むとのこと。お間違いなく。^^

| | Comments (1) | TrackBack (0)

August 18, 2008

Windowsサーバをインストールする際は自動更新に気をつけよう

Windowsサーバのインストールに慣れていない初心者の多くが一度は経験する設定ミスがあります。それは「セキュリティパッチの自動更新を有効」にしてしまうというものです。

セキュリティパッチを自動更新する設定は何故いけないのか。もちろん事前検証なしにいきなり本番系サーバにセキュリティパッチを適用するのは怖いというのもあるのですが、それよりもっと怖いのはパッチによっては適用後に勝手にOS再起動までされてしまうことです。本番系サーバが突然OS再起動されてしまう問題の大きさはあえて語るまでもないですね。

この設定ミスが厄介なのは、


  1. OSインストール中に通知領域に自動更新を即すアラートが頻繁に出てくるので、つい何も考えないで設定を有効にしてしまう可能性があること。
  2. もし毎日OS再起動されてしまうのであればこの問題まで特定されすいが、実際は数ヶ月に1回程度なので忘れた頃にやって来ること。
  3. 数ヶ月に1回程度しか再発しないため、その場で問題究明まで至らなかった場合放置される可能性が高いこと。
気をつけましょうね。

| | Comments (0) | TrackBack (0)

May 19, 2008

サーバをシャットダウンする作法(UNIX系OS編)

サーバのシャットダウンの仕方で、その人がどの程度の力量を持っているかなんとなくわかってしまいます。それくらいサーバのシャットダウンは奥深いです。そこで今回はサーバをシャットダウンする作法について考えてみたいと思います。

【初級:いきなりシャットダウンしてしまう】
サーバ管理初心者がサーバをシャットダウンするシーンを見ていると、rootでログインしたかと思ったらいきなりshutdownと打ち始めました。個人PCならまだしも、サーバでそれをやるのは危険ですよね。誰かそのサーバ上で作業しているかもしれないし。

【中級:上がっているサービス・プロセス・TCPコネクションなどを確認してシャットダウン】
サーバ管理中級者になると、サーバをシャットダウンする際は、まずはTCPコネクションがないかなどを確認してから、立ち上がっているサービスやプロセスを全て落とし、その後シャットダウンします。慣れているのですごい勢いでタイピングしてシャットダウンするのが中級者の特徴です。

【上級:とにかく慎重にシャットダウン】
サーバ管理上級者ともなると、とにかく慎重です。一行タイピングする毎に入力した内容を何度かチェックして間違いないことを確認してからEnterキーを押す。そしてsync、sync、syncと3回くらいタイピングし、その後最後に作業漏れがないか数秒考え、それでも問題ないと確信したらシャットダウンを行います。上級者のシャットダウンはとにもかくにも慎重なのが特徴です。

【サーバをシャットダウンする作法】
サーバというのはその名の通り、サービスを行う機械です。その機械を止めるという行為はサービスを止める行為に他ならないので、正しい手順で慎重かつ確実にサービスを停止していくのがサーバをシャットダウンする際の作法になります。


なお参考になるかわかりませんが、私がサーバをシャットダウンする直前に手癖的に打ってしまうコマンド群をご紹介します(下記全てのコマンドを打つ必要はないのですが、慎重かつ確実のためにあえて)。ちなみに同じUNIX系OSでもOSによって多少コマンドやオプションが異なりますのでご注意ください。

# ps -ef|more
# netstat -an|more
# w
# free

※追記(2008/5/20)
sync3回ってネタだよね、という狙い通りのご指摘ありがとうございました。正確には調べてませんがたしかに最近のUNIX系OSはsyncしなくてもよいと聞いたことがあります。よって「sync3回叩く人は古い人だ」という注意書きを入れるか迷ったのですが、ひょっとしたらUNIX系OSの中には未だにsyncが必要なものがあるかもしれないのであえて残しておきました。

| | Comments (3) | TrackBack (2)

September 12, 2007

割と便利な帯域制限方法(Linux編)

※帯域制御ではありません。帯域制限ですのでご注意を。

帯域制御をしようと思うとそこそこ面倒くさい(もしくはお金がかかる)ですが、大雑把でよければ簡単に帯域制限できる方法があるのでご紹介します。それはインタフェース的に制限をかけてしまうという方法です。

例えば1000baseTのNICを使っていたら、そのNICはおそらく10baseT(Half/Full)、100baseT(Half/Full)、1000baseT(Full)の5種類のモードに対応していると思われます。そのNICに対して思いっきり帯域を絞りたいのであれば10baseT(Half)に設定すると10Mbps以上の帯域が使われることがなくなるといった感じです。

【設定方法】
さて、設定方法ですが、例えば10baseT(Half)に設定しようとした場合、まずはお使いのNICが10baseT(Half)に対応しているか確認します。

対応しているようであれば

とすれば10baseT(Half)として認識されるようになります。

| | Comments (0) | TrackBack (0)

August 16, 2007

Linuxでそこそこ安全かつ楽にサーバを立てる方法

【1.初めに】
要望がありましたので、今回はLinux(実際はRedhat系Linux)でそこそこ安全かつ楽にサーバを立てる際の手順を記してみます。

※一応注意:今回は、試しにサーバを立てる程度であればこのくらいで十分ではないかと思うレベルを想定しています。サービスに投入するサーバでは私はもっと細かいところまで手を入れています。

【2.そこそこ安全かつ楽にサーバを立てる手順】
さて、いよいよ本題です。サーバを立てる際は、不必要なものを全て取り除いてから必要なものを追加していくというのが基本になります。以下の手順1~5では不要なものの除去、手順6~7で必要なものを追加し確認しています。それを踏まえまして。

■手順1. OSをインストールします。(私はLinuxであればCentOSを入れることが多いです。その際私はインストールの種類をカスタムにしパッケージグループの選択では開発ツール以外全部チェックを外すことが多いです)

■手順2. OSにrootでログインしたら、「yum update」で全てのパッケージをupdateします。

■手順3. 「chkconfig --list」で各サービスのrunlevelを確認し、不要なサービスを例えば「chkconfig gpm off」の要領で止めていきます。ちなみに私の場合だと以下のサービスだけ残してあとは全て止めてしまっています。

・syslog
・network
・iptables
・anacron
・smartd
・sshd
・crond
・xinetd
・ntpd

■手順4. 「netstat -ln」(もしくは「netstat -l」)で現在開いているポート番号を確認し、不要なネットワークサービスを止めていきます。

ただnetstat -lnだけだとどのプログラムからポート番号を開けているのかわからないので、それを確認するために「lsof -i」を実行します。

ここで例えばcupsd(631番ポート)が不要だと思えば「chkconfig cupsd off」で、vsftpd(21番ポート)が不要だと思えば「chkconfig vsftpd off」でそれを止めればいいわけです。

■手順5. リブートします。リブートが完了したら、試しに「netstat -an」や「ps -ef」を実行してみてください。最初と比べて不要なものがほとんどなくなりとてもすっきり感じるはずです。

■手順6. 必要なサービスを追加します。例えばhttpdであれば「yum install httpd」といった感じです。もちろん言うまでもなくソースコードを入手してコンパイルしてインストールする方法もあります。

■手順7. 最終確認です。「dmesg」「more /var/log/messages」「more /var/log/secure」「ps -ef」「netstat -an」などの出力結果を一通り眺めてみて特に変なところがなければ終わりです。もし少しでも変だと感じる点があったら是非徹底的に調べてみましょう。

さて、こうして構築されたサーバですが、最後に気をつけたいことが1つあります。それはポートを開いているプログラムにセキュリティホールがないかどうかです。例えば現在TCP22番ポートはopensshが、TCP80番ポートはapache2が開けているとします。外部からアクセスできるこの2つのポートにセキュリティホールがあったら問題なので、セキュリティホールのないバージョン(原則最新バージョン)であることを常に意識することが重要になります。

【3.最後に】
今回ご要望をいただいた方曰く「OSのインストール自体は何度もやったことがあるけど、サーバを立てるとなるといまいちどうやっていいかわからない」とのことです。この件繰り返しになりますが、サーバを立てる際は不必要なものを全て取り除いてから必要なものを追加していくというのが基本になります。その基本を踏まえて今回具体的な手順を記してみました。参考になりましたら幸いです。

| | Comments (12) | TrackBack (2)

May 01, 2007

コマンドリファレンス集

システム管理者にとってコマンドリファレンスは重要な商売道具の一つです。私がよく利用するコマンドリファレンスをご紹介します。印刷して持っておくと便利ですよ。データセンターなどに常備しておくのもお勧めです。

■Linuxコマンド集
http://itpro.nikkeibp.co.jp/article/COLUMN/20060224/230573/

■Linuxコマンド逆引き大全
http://itpro.nikkeibp.co.jp/article/COLUMN/20060224/230579/

■Windowsコマンド集
http://itpro.nikkeibp.co.jp/free/NT/WinKeyWord/20040805/1/

■UNIXコマンドリファレンス
http://www5.plala.or.jp/vaio0630/ftp/command.htm

■Emacs簡易コマンドリファレンス
http://park15.wakwak.com/~unixlife/emacs.html

■Vi機能別主要コマンドリファレンス
http://www.glasscom.com/tone/linux/Reference/Vi/ViReference1.htm

■awk reference manual
http://www.forest.shimane-u.ac.jp/nagayama/etc/awk.html


| | Comments (0) | TrackBack (0)