XEN 環境で xm consolle は、直接仮想マシンのコンソールにアクセスできる便利な方法です。

しかし、仮想マシンが Linux のようなテキスト端末が使える場合は良いのですが、仮想マシンが GUI しか備えていない場合、 RunLevel 3 やテキスト端末から

xm console windows-vm

とやってしまうと、Windows には GUI がないため悲しい事になります。コンソールのプロンプトが戻ってきません。

その様な場合、xm console を Kill する方法です。

リモートSSH接続できる場合はターミナルから kill できます。


sles11:~ # xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 10060 4 r----- 152014.7
blog 768 2 0.0
centos7 512 1 0.0
dns3 1 512 4 -b---- 1497.6
eilian 6 512 1 -b---- 103368.8
mrtg 2 128 1 -b---- 1199.7
oes11x2 3 1200 2 -b---- 33790.1
oes11x4 1500 4 0.0
opensuse12 768 1 0.0
sles11-on-iSCSI 512 4 7.7
wprs 768 2 0.0
wsus 8 2200 4 -b---- 11104.3
 <-- xm console してしまった仮想マシン。
zabbix 5 1200 1 -b---- 31230.9
zenws 2400 2 227.6


sles11:~ # ps ax | grep tty*
3539 ? Sl 0:38 /usr/lib/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null
5282 tty2 Ss+ 0:00 /sbin/mingetty tty2
5283 tty3 Ss+ 0:00 /sbin/mingetty tty3
5284 tty4 Ss+ 0:00 /sbin/mingetty tty4
5285 tty5 Ss+ 0:00 /sbin/mingetty tty5
5286 tty6 Ss+ 0:00 /sbin/mingetty tty6
23953 ? Ss 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
23954 ? S 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
23955 ? S 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
23956 ? S 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
23957 ? S 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
23958 ? S 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
24507 tty1 Ss 0:00 -bash
24694 tty1 Sl+ 0:00 /usr/lib64/xen/bin/xenconsole 8 --num 0
<--- これだ。 xenconsole 8 というのが xm list と一致する。
24810 pts/0 R+ 0:00 grep tty*
sles11:~ # kill 24694 <-- Kill する



tty1はサーバーコンソールです。ここで動作しているプロセスを grep して見つけ出し、kill します。

無事、コンソールにプロンプトが戻ってきました。

他に、リモート端末ではなく、直接コンソールから操作sして、プロンプトが戻らない場合も同様に「却って来ないプロセス」を停止する方法として応用できそうです。startx なんかでよく、プロンプトが戻らない場合もあるので、この方法で停止できそうです。

-Keyword-

SUSE SLES Linux xm console コンソール プロンプトが戻らない コンソールプロセスを切断


その他の情報は
islandcenter.jp
[PR]
by islandcenter | 2014-08-29 14:49 | SUSE | Trackback | Comments(0)

APC-UPS を SUSE Enterprise Server で使うには - apcupsd

の続き(補足)です。

SLES11sp2 までは標準で apcupsd がサポートされていましたが、 Novell/SUSE の事業部門が分けられてからは openSUSE より apcupsd をダウンロード、インストールするようになりました。

http://software.opensuse.org より search ボックスから apcupsd を探し

a0056607_1551274.jpg


パッケージをダウンロードして yast でインストールするか、 1 Click インストールします。

SUSE で 1 Click インストールができない場合、YaSTにないメニューを追加

インストール後のUPSとの接続、起動、動作確認は上の記事を参考にしてください。

--
ここでは /etc/apcupsd/apcupsd.conf の UPS 制御パラメータについて説明します。ほとんどデフォルトでも問題はないと思いますが、それぞれの電源監視ポリシーに従ってポリシーを設定し直す必要がある場合があるかもしれません。

apcupsd のパラメータの抜粋

#
# ======== Configuration parameters used during power failures ==========
#

のセクション

# The ONBATTERYDELAY is the time in seconds from when a power failure
# is detected until we react to it with an onbattery event.
#
# 以下略、この数字は、商用電源が切れてから、実際に「あ、これは停電だな」と
# UPSが認識して、「じゃぁシャットダウンの準備を始めようか」と
# アクションを開始する時間(秒)です。
ONBATTERYDELAY 6

#
# Note: BATTERYLEVEL, MINUTES, and TIMEOUT work in conjunction, so
# the first that occurs will cause the initation of a shutdown.
#
# 以下略、この数値は%です。UPSの余力が5%を切った時にシャットダウンを開始する
# という意味です。-1 を設定すると、この数値は無効化されます。
BATTERYLEVEL 5


# If during a power failure, the remaining runtime in minutes
# (as calculated internally by the UPS) is below or equal to MINUTES,
# apcupsd, will initiate a system shutdown.
# ランタイム残を指定する(分)です。
# つまり実際には ONBATTERY 状態がデフォルトの6秒続くと、その3分後には
# シャットダウンの儀式が始まるということです。
MINUTES 3

# If during a power failure, the UPS has run on batteries for TIMEOUT
# many seconds or longer, apcupsd will initiate a system shutdown.
# A value of 0 disables this timer.
#
# 以下略、シャットダウンまでのタイムアウト、0はデフォルトで無効
# MINUTES パラメータで設定すべき数値で無効のままで問題はないはずです。
TIMEOUT 0

※補足:間違いのご指摘いただきました。
MINUTES は、残存バッテリー容量と消費電力から計算されるバッテリー切れまでの残存時間でシャットダウンのタイミングを指定します。つまり軽い負荷であれば、この設定で長時間、運用を続けられます。TIMEOUT が停電検出からの時間にあたります。

すなわち、残存余力が5分切ったらシャットダウン、しかし停電から10分経過するか、バッテリー残量が 10% を切ったら必ずシャットダウンする、という設定は
BATTERYLEVEL 10
MINUTES 5
TIMEOUT 600


という事だそうです。UPSのバッテリーの残量を調べるには定期的にキャリブレーションテストを行う必要もある、という事にもなります。

SUSE Linux: apcupsd のキャリブレーションチェック

補足ここまで

# 上の BATTERYLEVEL, MINUTE, TIMEOUT はシャットダウン時間を決める重要なポイントです。

# Time in seconds between annoying users to signoff prior to
# system shutdown. 0 disables.
# ユーザにサインアウトを促すメッセージの時間(その間中促し続ける)時間
ANNOY 300

# Initial delay after power failure before warning users to get
# off the system.
# ANNOY を開始する遅延時間、商用電源が Delay で切れたと判断して、警告を
# 発生させる遅延時間
ANNOYDELAY 60

# The condition which determines when users are prevented from
# logging in during a power failure.
# NOLOGON [ disable | timeout | percent | minutes | always ]
# 商用電源が切れてからユーザのサインインを許可するかどうか
NOLOGON disable

# If KILLDELAY is non-zero, apcupsd will continue running after a
# shutdown has been requested, and after the specified time in
# seconds attempt to kill the power. This is for use on systems
# where apcupsd cannot regain control after a shutdown.
# KILLDELAY 0 disables
# 通常0でいい。シャットダウンを開始してからデーモンが稼働し続ける時間
KILLDELAY 0


-Keyword-

SUSE Linux SLES APC-UPS apcupsd 設定 apcupsd.conf

追加情報はこちら
islandcenter.jp
[PR]
by islandcenter | 2014-08-27 15:24 | SUSE | Trackback | Comments(0)

つい最近 SUSE Cloud 3 のリリースが日本でも発表されたような気がしましたが、既に英語版では SUSE Cloud 4 がリリースされています。

https://www.suse.com/products/suse-cloud/

ダウンロードはこちら
https://download.suse.com/Download?buildid=kjVizo0xnj4~

Openstack 関連のリリースの速さと勢いを感じます。昨年 SUSE Cloud2 のマニュアルを読んだ身としては、あまりにも早すぎる最新版のリリースには目もくらみます。安定したものを長い間使いたい、じっくり腰を据えて取り組みたい側としては、付いていけません。

これが今一番、SUSE としてはホットな製品だという事を感じます。
[PR]
by islandcenter | 2014-08-15 13:13 | プライベートクラウド | Trackback | Comments(0)

 Hyper-V の MTBF は低すぎる、と思いませんか?私には良くわかりません。

 これは、微妙、というより大きな数字として、コストパフォーマンスに影響します。

 Windows の MTBF が低すぎる要因として想像できるのは

- 頻繁な Windows Update -> 再起動
- 何か役割でもインストールすれば -> ほぼ確実に再起動
- アンチウィルスが必要でバージョン更新があれば -> 再起動

そして、「修正プログラムを構成中。。。。」長いこの間はトイレタイム、 MTTR 値が上がります。

 これでプライベートクラウドを構築したら、身が持ちません。まず、確実にライブマイグレーション環境が必要なわけですね。何しろハイパーバイザーが再起動したら、上に載っているシステム全部停止しますからね。だから、ライブマイグレーションは必須の必要悪。当然、導入コスト、運用コストも倍以上に跳ね上がります。

 少なくともC:ドライブのウィルススキャンは最低限、マナーと常識として必要ですから、アンチウィルスソフトウェアのプログラム本体の更新も合わせると、月に2度くらいは再起動が必要なケースが訪れます。このわずかな MTTR に対して二重化が必要なのです。

 算数が全くダメな私でも 24 × 30 日 = 720 時間のうち、下手をすれば2度、2時間程度のサービス停止があるわけですから、99.8% 程度の稼働率という事になります。この数字が妥当かどうかは、そうじゃないだろというご意見があれば、ご指摘ください。貴重なご意見です。

100% と言わなくても 99.99% 程度の稼働率ならかなりのものですが、99.9% を切る稼働率だとしたらあまりに低い。

 これは現代のコンピュータシステムのMTBFとしては「異常とも思える」低稼働率です。99.99% で 1,000 時間に1時間の停止時間です。(数字合っているかな)ほぼ3年に一度程度の稼働停止です。停電などの計画停止やマザーボードの交換でもない限り、不幸に見舞われない通常の Linux サーバーでは当たり前な MTBF 値だと思います。

 Linux を使っている限り、ハードウェア丸ごと停止という事態はそうそうあるものではありません。ディスクの交換も最近はほとんどオンラインです。不幸にも精々メモリ不良が見つかったとか、明らかに管理ツールがマザー、CPUの障害を見つけたとか、ファームウェアに問題があるとか、そんな程度です。多くの場合、24H365の4時間サポートで半日程度の停止があり得るでしょう。これは Windows だろうが VMware だろうが Linuxベースのハイパーバイザーでも避けて通れません。

 Windows システムの設計で面白いのは「理由があるから」、「理屈がある」のではなく「理由があるから」だから「理由を付け足す」というシステムの設計方法です。

 ライブマイグレーション自体は、あくまでも緊急で行うもので、「当たり前」にいつも実施するものであるとは考えません。安定しているなら、マイグレーションすべきではない。充分設定内容を考慮して、無停止で行える事が確実だという状況で行うべきものです。パブリッククラウドならいざ知らず、通常に動いている仮想コンピュータの負荷が、プライベートクラウドで急激に変化するものではありません。

それでも、MTBF 100% を限りなく目標とするなら、スタンバイ状態のハイパーバイザーの99.8% は遊んでいる事になります。つまり実稼働しているシステムのコストの実際には限りなく2倍のコストをかけて運用する必要があるということです。

 ベーシックモードで動かして他のサービスは全部止めればいいじゃん、というご意見はまぁ50%くらいは尊重しましょう。でもネットワークにトラブルが出た場合だとか、リモートでうまく接続できないような場合、難解な PowerShell だけでどれだけ修復できるのか、そもそも Windows なら GUI で操作できるから、というのが選択肢の一つなら Basic モードでインストールすること自体、ネットワークのトラブルでもあれば全然無意味です。Linux の方 CUI の方がよっぽどマシ。

 ライブマイグレーションをするようなシステムの場合、当然かなり複雑な構成となります。無停止を目指すのであれば、当然ディスクストレージも二重化しますし、HUBも二重化することになります。当然、導入するハードウェエアのコストは2倍以上。

 機器の故障率は機器の構造が複雑になればなるほど、信頼性は下がります。99%の稼働率の機器2台を組み合わせると0.99 × 0.99=0.9801 つまり98%に下がります。さらにこれが3台、4台とつながるとますます信頼性は下がる一方です。それでもMTTRを短くするためにさらに余計で、まず使う事が年に1度もあるかないかの機器を必要とします。

 これが微妙、というより大きな金額として導入と運用コストを跳ね上げます。

 当然、運用マニュアルも難解で、顧客が自前で運用できないほどの複雑怪奇さとなります。導入したベンダーのエンジニアだって理解不能。

 ということで、まず100万円もあれば十分なプライベートクラウドの1システムの提案書に1千万の見積もりを書いてきたベンダーが居たそうです。そりゃ、予算があれば1千万でも作るべきものは作れますが、私にはとてもじゃありませんがそんな大胆な見積もりを作る訳には行きません。そもそもそれほどの費用を要求するほどの作業はどう考えてもひねり出せません。

 これがパブリッククラウドで、巨大なホスティングサービスの一部であれば、数百台、数千台の運用マニュアルを作って、技術レベルの一般化もできるでしょう。しかしオンプレミスの数台から数十台のプライベートクラウドではそうは行きません。

 もし、ピンで利用しているのなら、

 PM22:00 誰も残業していない間にWindows Update 開始 -> 失敗 -> 原因追究 -> 再起動 -> 動作確認 -> 終電間に合うかな? -> 翌朝は始発で出勤 -> Dom-U の動作確認 -> 始業

 現実的な出費としては、従業員の残業代という形でしか表面化しませんが、これらの一連の作業を行うことによる時間的な、そして運用担当者の心理的な損失は、コストの中では目立たないので、判らないだけの話です。

 まぁ、多いですよ、Windows Update を定期的にやっていないお客さん。やるとハマりますからね。これが Windows の信頼性を大きく下げている要因です。

- 何だか遅いなぁー
- 余分なプロセスは全部殺したンだけどなぁ
- いいや再起動してみよう
- 何故か直った

 ということでタスクスケジューラで、週に一度、リブートさせているお客様もいらっしゃいました。これがアプリケーションサーバーなら許せるけど、プライベートクラウド基盤であれば、その上に載っている全てのゲストOSに関係してくるとなると中々容認できない状態です。

 これが本当のクラウドOSの姿なのでしょうか。まだハイパーバイザー上のゲストOSとして動いているなら、「いつもの Windows 」で当たり前のように再起動するのでしょうが、これがホストOSなら重大な運用障害となります。

もっとも、ハイパーバイザーをピンで利用して、人海戦術、属人対応するというのも手段の一つです。モノがシンプルなので、修復も容易だし MTTR も下がります。

--
実際に「この程度のシステムなら200万もかからず仮想化できるな」というシステムに1千万の見積もりを平気で出してきたSIベンダーが居たそうです。

「重要だから」「止められないから」ということで過剰なスペックを追い求めるのは如何なものなのでしょう。そして、システム管理者の心理的、時間的な負荷を減らすシステムというのはどのようなものなのでしょう。


お問い合わせ
islandcenter.jp

-Key Word-
クラウド 仮想化 ハイパーバイザー 信頼性 MTBF
[PR]
by islandcenter | 2014-08-01 10:29 | プライベートクラウド | Trackback | Comments(0)