カテゴリ:プライベートクラウド( 74 )

サポート切れが迫りつつある Windows 2003 サーバー、それでも物理 -> 物理 (V2V) で移行しますか?

もう、Windows 2003 が売れた時代と言えば 2004 年から 2008 年にかけて、新しい方でももう5年程度使っているのではないでしょうか。そろそろ仮想化システムが本番化し始めた頃です。

Windows 2012 R2 であれば、サポートライフサイクルは 2023/1 までです。。そうなれば、9年近くシステム運用が可能になります。Windows 2008 なら2020/7 まで。この3年の延長期間は価値があります。

にも関わらず、物理->物理のマイグレーションは、物理的な機械故障、機器のサポート、保守部品の保持期間を考えると賞味期限に全く意味がありません。

という事で、Windows サーバーのリプレースを考えるのであれば、Windows 2012 R2 を仮想化システムとして移行してしまえばいいのです。少なくともこれから9年間は、サポート切れの心配をせず、運用できます。

機器が古くなっても、仮想イメージを新しい革袋に詰め替えるだけなので、わずか数十分の移行期間で移行ができるのです。

この期に及んで

「 Windows 2012 のインターフェースは Windows 8 と同じで使いづらいので Windows 2008 をお勧めします」

と言って「物理 -> 物理」の V2V 移行を提案してくるSIベンダーは、信じられないほど頭の構造が古い。大体、サーバーのUIがエンドユーザの生産性に関係あるわけがないのです。あるいは、 Windows 2008 のサポート切れの際に、

「4、5年後、もう一度マイグレーションで金が取れる」

という、計算が働いているのかもしれません。また、「仮想化」について全く自信がない不勉強なSI事業者でしょう。

アプリケーションの互換性の問題を意識される方もいらっしゃるでしょう。しかし Windows 2003 -> Windows 2008 へと移行するのと Windows 2012 に移行するのでは、互換性検証にかかる手間は大して変わらないはずです。要はミドルウェアが対応しているかどうかの違いです。

「2008 では動くけど 2012 では検証していない」というSIベンダーは、この4年間どういう努力を行ってきたのでしょう。


--
今は、ハードウェアを抽象化する動きが活発です。「仮想マシンだと、ディスクIOが遅い」と言って V2P の提案を否定する SI 事業者は IP-SAN という技術を知らないのでしょうか。iSCSI などの IP-SAN であれば、システムドライブも、ストレージも抽象化して、異なるポリシーで資産管理ができます。ストレージの容量が足りなくなったり、故障が増えれば、ストレージだけ買い替えてデータ移行してしまえばいい。何もハードウェアをそっくり入れ替える必要はありません。

それは勿論、何テラバイトもあるデータベースシステムであれば、物理物理の V2V 移行も意味があるのですが、所詮 WIndows 2003 時代に購入して構築したシステムであれば、ストレージの容量など、大体見積もれる筈。何テラバイトという容量は必要ないシステムがほとんどなのです。

「Raid5にホットスタンバイ付けて4Gメモリを2枚」

って何百Gバイトのディスクとメモリがそのシステムに必要なのでしょうか。多くの Windows サーバー用ソフトウェアの推奨メモリは4Gbです。完全にオーバースペックなのです。SIベンダーにとっては、1台の高性能なシステムを売るより、何台もの低価格、低スペックのPCサーバーを販売した方が、売上も上がるし保守費用も取ることができるのです。なぜこんな中途半端なスペックを顧客に推奨するのでしょう。こんなハードウェアを2~3台提案するくらいなら、5割増しのスペックで仮想化システムが構築できます。勿論顧客の負担も半分程度まで下がるでしょう

実際、2CPU16スレッド64Gbメモリ1Tバイトの1Uのサーバーハードウェアに SUSE Linux Enterprise Server (SLES11) を導入して、5台の WIndows8, 1台の Windows 2012, 2台の SUSE Linux を動作させてもまだまだ余裕という、事例を今年実施しました。

既にここでは25台の Windows7 が仮想デスクトップとして1Uマウントのサーバーで動作しています。実際の使い勝手は、クライアントWindows7 より、サーバーとの遅延がないため、「異常に早い」と好評だそうです。

これだけの設備を動かすにもUPSは1台だけ、ハードウェアの故障管理、バックアップのターゲットも2台だけなのです。スペースもわずか2Uです。

結局、「見る目がなかった」と気が付くのはユーザ企業なのですが、それだけユーザ企業の「目が肥えていない」事が原因なのです。

今まで動作していて不満がなかった Windows 2003 システムに対して、オーバースペックなテラバイト級のハードディスクと16Gというケチなメモリの使い方をしても、それほど業務には

「速くなった、良くなった」

という実感のあるシステムになりようがありません。MMインターフェースを使わない、メールのウィルススキャンや、アンチウィルス配信だとか、アクセスポリシー管理のサーバーソフトウェア、プリントサーバーなら、4G バイトのメモリと80Gb程度のディスクと2CPU(スレッド)で満足できたシステムなら、そのスケールで十分なのです。

これらの低スペックのサーバー一つ一つにKVMスイッチを繋ぎ、HUBを接続し、UPSを繋いでラックの裏でスパゲッティを料理する手間を考えると圧倒的に仮想化システムの方が楽に構築できるのです。

--
ということで、 Windows 2003 サーバーのサポート切れ問題は、システム全体をプライベートクラウド化するための良いチャンスなのです。

-Keyword-
SUSE SLES Linux 仮想化 Windows 2003 マイグレーシ サポート切れ


問い合わせ
islandcenter.jp
[PR]
by islandcenter | 2014-09-07 11:38 | プライベートクラウド | 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)

今、ネットワークでメールをやり取りして、お互いのファイルを共有して、オフィスに1台しかない高速プリンタをネットワークで使うということは当たり前な世界です。しかし20数年前、このような使い方を「当たり前」と考える文化はありませんでした。病欠の届けは朝の始業前に電話で、伝達事項は全て朝礼で、作業の指示は全て口頭でした。

当時誰が今の様なビジネスのフローを予測したでしょうか。


仮想化は当たり前な技術

システムをベアメタル(物理ハードウェア)で動かす時代はもう終わっています。物理ハードウェアはハイパーバイザーを動かすためにあり、システムはその上で仮想化して動かすのが当たり前な時代です。現代ではベアメタルのハードウェアにインストールするものは、ハイパーバイザーと必要なドライバ、あればハードウェアのリモート管理ツール程度です。

仮想化って遅くない?

場合によっては遅く感じる場合があります。特に Windows8 で標準搭載された Hyper-V から入門した場合はそう思うケースが多いでしょう。

しかし、XEN にせよ KVM にせよ、Linux上で動作する仮想システムは、ほぼベアメタルに近いパフォーマンスを出します。現在では、Windows Hyper-V 以外のハイパーバイザーは、ほぼベアメタルに近い性能が引き出せるように設計されています。

もっとも、利用する周辺機器、例えばストレージネットワーク用のHBAカードなどの都合で、性能を出すためにベアメタルをそのままシステムとして利用するケースも少なくはありません。

実際には一つのシステムで CPUや I/O の性能を100%使い切ることはありません。ほとんどオフィスで使用されるシステムリソースの90%はアイドリングなのです。メモリやCPUコアは2の倍数で増えますから2Gのメモリで微妙にたりなければ4G、8G、16Gと増やしていきます。実際にそれほど使わなくてもです。メモリは3.2Gでいいとか、HDDは20Gもあればいい、というシステムは数多くありますが、実際にはそれ以上のハードウェアを購入して使わざるを得ません。

実際、仮想化システムの一つ、VDIを導入したお客様では、ベアメタルの Windows 7 クライアントより、何十台も動作している仮想サーバー上の Windows 7 クライアントの方が速くて快適に利用しており、この選択は大成功だったそうです。

CPUの性能は年々向上しています。クロックは変わりませんが、搭載するコア数が増えているのです。わざわざ、低価格のCPU、サーバーを導入する手間よりも、ミドルクラスのサーバーに仮想集約した方が、消費電力やディスク、メモリの利用効率は上がります。

特にアプリケーションによっては2スレッド以上ではパフォーマンスが出ないアプリケーションでも、仮想化により2スレッド、4仮想化した場合では、実質4倍の性能が出る場合があります。勿論上限はありますが、一概に仮想化すると遅くなるということはありません。


再起動がムチャクチャ速い

ベアメタルのサーバーシステムを再起動してみましょう。電源投入後、真っ暗な画面が30秒ほど続き、見たくもないハードメーカのロゴを見た後。一般的なサーバー専用ハードウェアであれば、BIOSのチェックから接続された NIC やリモート管理システム、RAIDコントローラのチェックが入ってソフトウェアが起動します。まず大体4、5分ですね。イライラします。

しかし、ハイパーバイザーの上で動作する仮想化システムは最初のハードウェアのチェックが省略されるため、非常に起動が速いのです。一般的なサーバーハードウェアで軽量な Linux システムを再起動した場合、わずか30秒程度でシャットダウン、再起動してしまいます。

また、必要最低限のハードディスクの記憶容量を使う場合、DNS/DHCP程度の Linux であれば4Gもあれば十分、Windowsでも20Gもあればシステムが起動でき、必要に応じてネットワーク上のストレージと連携させれば十分に動作します。

仮想環境では、例えば「3.2Gの Windows7/32 のメモリで25GバイトのC:ドライブ」と言ったハードウェアの制限とは関係なく構成を簡単に作り出すことができるのです。

障害時の切り分けが容易

ベアメタルのハードウェアで直接動かした場合、システムダウンの原因がハードウェアにあるのか、OSにあるのか、アプリケーションにあるのかの切り分けが容易ではありません。仮想化環境で、仮想マシンがダウンした場合、多くの場合、仮想マシンそのものの問題です。おそらく別な筐体で動かしても同じ現象が出る可能性が高いのです。

一方、ハイパーバイザーそのものがダウンした場合、ハイパーバイザーの問題か、ハードウェアの問題です。私の経験では、ハードウェア本体の障害を除けば、ハイパーバイザーが原因でシステムダウンを見た経験はありませんので、大抵の場合は、ハードウェアの障害や仮想マシンの詰めすぎが原因です。

もし、空きのハードウェアプールがあれば、仮想マシンを別筐体で動かしてみればいい。それで問題がなくなれば、ハードウェアが原因だという事になります。

移行が簡単

ベアメタルの物理サーバーを新しいサーバーに更新する場合、まず、サーバーを調達するための見積もりや稟議を通して納品されます。次に必要なデータやレジストリのバックアップを取り、新しい物理サーバーをインストールし、デバイスドライバをチューニングして、果てしなく時間がかかる Windows Update をして、データのリストア、アプリケーションの再設定を行います。当然、古いシステムが新しいハードウェアで動作するという保障もありません。オペレーティングシステム自体を買い替える必要もあります。動作検証に恐ろしく時間が掛かります。

たぶん物理>物理のマイグレーション(移植)作業は数週間から数か月の計画が必要です。

仮想化されたシステムを新しい革袋に移し替える場合、単に仮想化されたシステムをコピーして起動し直すだけです。既に当たっているアップデートもそのまま引き継がれるため、単純な移行だけでもコピーに必要な時間だけで新しいハードウェアに移行できるのです。

Windowsであれば、Sysprep したコンピュータイメージファイルを起動して、必要なライセンスを(必要に応じて)設定して、Windows Update すれば、即時にリモートデスクトップ環境を構築できます。かかる時間は僅か30分。
OEMライセンスでなければ、「どこかのPCで仮想マシンを作って」そのディスクイメージを本番環境にコピーするだけで必要なコンピュータ資源が利用できるようになります。

Webサイトを構築する事業者であれば、社内でデザインとPHPとMySQLのプログラミングを完成させて、完成したイメージを納品すれば、お終いです。わざわざ顧客先のコンピュータ室の過酷な環境(低温でウルサく、すわり心地の悪い椅子)で開発せず、ゆっくり自分のオフィスでゆっくりコーヒーを飲みながら集中して開発した、あなたの「製品」を仮想環境に実装して納品完了です。しかも開発環境が手元にあるという事は、ソフトウェアのメンテナンス、改良、チューニング、他の顧客への部品の再利用ができます。

顧客としては、仮想化は発注先に「値引き交渉」をするための重要なインフラになります。


システム全体のバックアップ

システムの設定は面倒で、システムのクラッシュを予測してのバックアップとリストアは、運用者にとって悪夢の一つでした。

システムディスクが損失すると、ディスクを交換し、初期化、パッチ当て、リカバリ用のソフトウェアのインストール、テープのスキャン、そしていよいよバックアップからのリストアです。

仮想化システムの場合、システムイメージファイル1つをバックアップしておけば、修理したハードウェアでも、代替の機材であってもイメージファイルをコピーして起動してしまえばそれでお終いです。勿論「代車」から「本番機」に戻す場合も「代車」上のイメージを元に戻せば、最新の環境で利用を継続できるのです。ディザスタリカバリにもBCPにも仮想化は今や当たり前のシステムなのです。

ここに4台の物理ハードウェアのシステムがあるとすれば

当然、それぞれのハードウェアにはメモリもあれば、ディスクもある。おそらくUPSもついていて、コンセントは4つ使われている。ラックに搭載している場合もあれば、PCデスクに積んでいる場合もあるでしょう。KVMスイッチなどを使ってモニタを切り替えて運用し、それぞれのバックアップ対策も面倒で良くわからない。

だから業者に全部お任せ。業者は当然管理者パスワードを知っているから、どのような作業をしているのかは全く分からない。テープドライブも何種類もあり、実際どのように使われているのは、実は良くわかっていない。4台あるため、年に大体1台はリースや保障が切れるため、リプレースします。その計画は何か月もかけて準備したものです。

これが、中小事業者のシステムの実情ではないでしょうか。

最初の第一歩だけなのです。この4台のサーバーを一台のハイパーバイザーに実装すれば良いのです。

最初の一歩

ネットワークケーブルは1本。電源ケーブルも1本。ハードウェアの24時間4H対応のサポートは一つだけ。一つのハイパーバイザーにはネットワークを管理するDNSやDHCP、これは僅か368Mbのメモリで動作しています。
一方でアンチウィルスのパターン配信サーバー、データベースサイズは僅か10G程度ですから、これは丸ごと深夜にシャットダウンとバックアップが行われます。

ファイルサーバーはもう少し面倒でしょう。2Gバイトのメモリを持つ予備のドメインコントローラはユーザ情報とパスワードを、マシン丸ごとでバックアップされます。

他に、プリントサーバーであるとか、電子メールのスキャナーであるとか、様々な機能が1台のハードウェアで動作するのです。

また、××をインストールしたら○○が動かなくなった。という症状は、ソフトウェアの競合が発生しないため、まず発生しなくなります。

このお客様にソフトウェアを開発して納入している業者さんは、自社内で開発してアプライアンス化した「システム」のディスクイメージをUSBのハードディスクなどで納品して、仮想マシンに実装するだけです。



仮想化の最大のデメリットって何?

それは、一つのハードウェア資源を複数の部門、予算で運用されることです。比較的小規模なネットワークでは、トップダウンで予算、利用者、運用をひとまとめにできるため、早期導入できます。

しかし、ダンパー数を超えたあたりから、一つの資源を独立した複数の部門で利用するという同意を部門間で得にくくなってきます。例えば、経理が購入したハードウェアに、生産部門のシステムが載ってしまう、という事態は避けたいと考える部門担当者がいます。

これは実際の「大人の事情」です。中々外部からは見えにくい状況です。本来であれば、システム部門が中心となって、コストの安いリソースをトップダウンで共有できる体制を作り上げるのが理想なのです。中々そうも行かないのが現実の問題でしょう。

こういった事情は、構内ネットワーク導入の初期にもよく見られた傾向です。部署ごとに異なるアドレス体系を導入したり、メールアドレスが、myname@mailserver.mydept.mydiv.mybigcorp.com というような、部門による勝手メールサーバーの乱立による一意のメールアドレスではなかったりという巨大企業は日本ではよくありました。

そこでついつい、システム管理担当者は「ネットワークインフラだけに責任を持つ」という低いレベルの業務しか担当したがらなくなります。技術も業務の知識があっても残念なことです。

その後、メールアドレスなどはネーミングスタンダード(命名規則)によって管理されることが多くなりました。同様の管理手段がシステム担当者、システム担当役員にとっても大切な決定事項となります。

作りすぎる仮想マシン

あまりにも、システムの仮想化が便利だと、違う意味で困った問題が出てきます。仮想マシンの作りすぎです。ネットワーク管理サーバーから、小さなサービス専用のサーバー、ネットワーク管理用アプライアンス。自由な発想で作った仮想マシンが役に立つとそれは結構なことです。

余計なお世話と言われそうですが、作りすぎた仮想マシンを管理することもまた重荷になります。特に、サーバーとサーバーが連携するようなシステムとした場合、一つの仮想システムの障害が別なサービスに影響を与えるようだと本末転倒と言えます。

システムはシンプルが一番。シンプルなシステムほど、問題は起こりにくいのです。


SUSE Linux ってあんまりよく知らない

ドイツで生まれた SUSE Linux は商用 Linux では3割ほどのシェアがあります。特に Linux が生まれ育った東欧、北欧EU諸国の非英語圏での利用者が多いので、英語以外のもっとも多くの言語で利用されている商用 Linux と言えます。EU諸国は何かと米国製品を避けたいけれど、仕方なく使っている、という気風があるせいか、SUSE はヨーロッパ各国で人気のディストリビューションです。

Google Trends によると、SUSE はEU各地で使われ、RedHat は日本と韓国、香港、中国などの東アジアで大きな人気があるようです。RedHat はアメリカ生まれなのですが、この数年は米国国内では SUSE と人気を二分しているようです。

SUSE の "E" は Enterprise の "E" です。元来が企業向けにチューニングされているため SAP を始めとする高度なアプリケーションエンジンとして利用されてきた、高い安定性と実績があります。

Novell が買収した後、SUSE Linux は、元来、政府機関や大企業向けディレクトリ、ID管理用システムのサポートを得意とする Novell Inc. の顧客層にも受け入れられ、その勢いは RedHat を凌ぐ勢いです。

日本語の情報が少ないのは事実ですが、HPやDell, IBM と言った海外メーカーのサーバーではまず確実にサポートされています。インストールからトラブルがあるような心配はまずありません。

トラブルがあるとすれば、それは Linux そのもののトラブルです。こういった情報は他のディストリビューションでも英語でしか見つからないケースがほとんどなのです。



SUSE Linux を仮想化ベースとするメリットとは

何よりも Windows との親和性の高さは大きなポイントです。ご存じのとおり、SUSE は Novell に所有されていた時代に、Microsoft との提携しました。相互運用面で、お互いのシステムを緊密に連携できるようにチューニングされています。この提携は Attachmate グループの SUSE 部門でも有効に機能しています。例えば Hyper-V 上に SUSE Linux をインストールしてみると、自動的に Hyper-V 用のドライバが組み込まれます。このような機能は他のディストリビューションにはありません。

他のLinuxディストリビューションで充分パフォーマンスが出ないことがあっても、 SUSE Linux Enterprise Server (SLES11) と Windows の相性は非常によく、相互にサポート体制が出来上がっています。SUSE では Microsoft 用の準仮想化ドライバを提供しており、XEN でも KVM でも最適なパフォーマンスで動作する環境が用意されます。

SUSE (SLES11) + XEN で Windows を動かした場合、仮想化システムとして最高のパフォーマンスを引き出します。


SUSE は難しくないの?

SUSE (SLES11) には yast, yast2 という恐ろしく便利なツールが付いています。コマンドを覚えなくとも "yast" とプロンプトから打ち込めば、ネットワークの設定からアプリケーションのインストール、パーティションの作成、基本的なサーバー機能の設定を全て、メニュー形式で行えます。

a0056607_71258.jpg

CUIコンソールで yast を使ってサービスをメンテナンス

a0056607_791898.jpg

yast2 によるパーティション管理

何しろ、綴りを知らなくても操作ができる。

他のディストリビューションと違い、手元にハンドブックと電卓を持ち歩いて、正確なコマンドラインを打ち込むことなく、必要な設定を行う事ができるのです。

SUSE Linux をハイパーバイザーとした場合、実際にハイパーバイザーを操作する作業は、まずありません。まず、大きなトラブルがないため、Windows のように、アッチの設定を変え、コッチの設定を変え、そして動かなくなる、という運用にはならないからです。

精々、仮想マシンの再起動やシステム全体をシャットダウン、リブートする操作程度は覚えておくべきです。

ハイパーバイザーで Login: のプロンプトしか出ていない状態で、その中にいくつもの Linux や Windows のシステムが動いている。この事態は、ちょっと想像もできないし、感動ものです。

私はそう思いました。

Linux のコンソールは操作するものですか

物理ハードウェアの Linux コンソールを操作することはほとんどありません。まず、物理的な障害で、電源再投入時にハードウェアのエラーがあるときや、ネットワークの初期設定に使用するだけです。ここまでは、ほとんどが顧客の作業ではなくメンテナンス業者が行う作業です。

ネットワークの接続に問題がなければ、後の操作はほとんど Windows からリモートで行います。

シャットダウンと再起動でさえ、ほとんどリモート操作で行います。

Windowsからの操作は CUI のテキスト端末なら Putty や TeraTerm などのフリーウェア、GUIの操作なら Xming や Mobaterm などの X サーバーをインストールして操作します。物理的に、サーバーを鍵のかかる部屋に押し込めて、決まった端末からだけリモートアクセスできるようにして、セキュリティ上のトラブルを避けることができます。

仮想マシンの操作はどうやってやるの?

ほとんどの仮想マシンの操作は、Linux/Unix 系の場合 Putty とか TeraTerm のようなテキストエミュレータで行います。GUIが必要な場合は Xming などの X サーバーソフトウェアから操作します。

仮想マシンが Windows の場合は、リモートデスクトップです。実際に通信で流れるのはが画面の情報だけなので、非常に軽快に動作していることを実感できるでしょう。

実際の仮想マシンの「生のコンソール」を見たい場合は、ホストコンピュータに X サーバーソフトウェアで接続して、仮想マシン管理ツールを起動すれば、「生の仮想マシン」のコンソールを直接呼び出すことができます。若干使いづらいケースが多いので、あまり使う事はありません。

a0056607_717757.jpg

実際の操作は X サーバーか、リモートデスクトップ、リモートターミナルで行います。

精々、ネットワークの初期設定や、リモートデスクトップを有効化したら、あとは使う場合は問題が起きた場合だけでしょう。

従来のベアメタルハードウェエアを並べていた場合は、キーボードの切替機(KVMスイッチ)を使って切り替えて使っていましたが、リモートで操作する場合は、いくつものサーバーの画面をソフトウェアで切り替えて使う事ができます。

ハイパーバイザーは高価?

「仮想化は初期導入コストが高い」

と考える人が多いことは残念です。初期導入コスト以上のメリットが中々伝わらないのは、「仮想化=Hyper-V」と考えた場合です。

確かに「ハイパーバイザーだけ」の VMware や Hyper-V を使おうとすると費用はとんでもない価格になります。ハイパーバイザー自体が無料でも管理用のソフトウェアのライセンス料が高いのです。

Windows Server の Hyper-V の機能を使う場合は、アンチウィルスソフトウェアも必要です。大抵はサーバー版のライセンスですから一般的に高価になるかもしれません。Windows でアンチウィルスソフトウェアがない状態で運用するのは、冬の札幌ススキノの街を皮底の靴で歩くようなもので、気を付ければ転ばなくても、ちょっと気を抜けば転ぶでしょう。

SUSE Linux (SLES11) は普通の商用 Linux で、最低料金は年間4万1千円から無制限インスタンスで利用できます。しかもオープンソースである以上、購入するのはあくまでもサポートだけです。XEN も KVM もこの費用に含まれる、言わば「オマケ」に過ぎません。

一方 Windows Datacenter Edition は117万円もします。頻繁な Windows Update やアンチウィルスによる再起動が必要な事を考えると、実際には二重化することになります。つまり117万円×2の費用と2台分のハードウェアが必要です。

Windows8 の Hyper-V で「仮想化はお手軽だ」と思った方はいいセンスをしています。そこで Hyper-V を選ぶという理由にはならないでしょう。

本当の仮想化システムは Windows の Hyper-V で味わえるような「お手軽」で「重い」システムではないのです。

SUSE Linux (SLES11) で仮想化する場合はそんな冗長なコストをかける必要はありません。

また SUSE Linux Enterprise Server は入手のしやすさも特徴です。まず、登録だけで無料でインストールしてテストでき、サポートサブスクリプションを後に購入することができます。まさにオープンソースです。


XEN か KVM か

SUSE Linux は XEN も KVM も標準です。KVM は Linuxの x86 専用ですが、XEN はLinux だけではなく BSD から Soralis また PowerPC や IBM のzシリーズまで広く使われています。i386 時代から実績があるため Amazon や Google を始め多くの ISP, ASP で使われています。 RedHat EL では KVM のみサポートされています。Linux だけではなく BSD や Windows などを動作させるには一工夫が必要です。

ただ、KVMは、「今一番ホットな」仮想化手段で Linux とインテルアキテクチャの世界だけであればお手軽です。日本では人気があります。完全仮想化でIOをQEMU でエミュレーションします。

XENを選ぶかKVMを選ぶかは単に好みの問題かもしれません。ちょっと面倒だけど堅牢で様々なプラットフォームで動作し、実績も高く、高速なXENか、手軽で流行りのKVMか。 SUSE Linux Enterprise Server (SLES11)の x86-64版は両方をサポートしています。

フリー(無料)のLinuxで構築できますか。

止めた方がいいと申し上げます。フリーの Linux は自己責任で使うものです。システムに襲われた被害は全てあなたの責任です。

例えば SUSE Linux のフリー版 openSUSE のサポート期間は僅か14か月。出荷直後はバグも多く、一般的には安定していません。解決するための長い時間がコストとして跳ね返ってくるでしょう。

ただし、自己責任で色々なトレーニングや、最新の周辺機器、デスクトップアプリケーションを使うだけと言った目的であれば、有効な選択です。

CentOS のような長いサポートを提供するフリーLinuxもありますが、やはり、業務で使うには使う側に十分な責任感が求められます。

Linuxのハイパーバイザーにウィルスソフトは必要ですか

必要ないと考えています。
攻撃は 1) 脆弱性があり、2) 攻撃用の設定を行う 3) 実際の攻撃を実行する。の3段階があります。

Windows サーバーの場合、1) IE やフラッシュの脆弱性を使い > Windows Update を行う 2) 実際にコードを埋め込み > ウィルススキャンで防御 3) 何らかのタイミングでアタックを開始する。> ファイアウォールが許可される。

という手順で行われます。しかし Linux は 1) の脆弱性自体が公開されているケースが多く、 1) の段階でほとんどのセキュリティホールがふさがれます。 2) の段階では、Linux は x フラグ(実行フラグ)を設定する必要があったり、実際のプログラムにトロイの木馬入りのプログラムに差し替えなければならないので攻撃は困難です。 3) のアタック開始は、実際にオペレータが操作しなければなりません。

100%の安全は保障できないにせよ、Windows よりはるかに面倒な攻撃をおこなわなければならないのです。

また Linux はディストリビューションによって、ソフトウェアの実装方法が違うため「下手な鉄砲数打ちきゃ当たる」的な攻撃はまず通用しません。

攻撃する側はじっくり腰を据えて、「標的型のアタック」を行う必要があるのです。




お問い合わせは
islandcenter.jp

[PR]
by islandcenter | 2014-07-12 07:18 | プライベートクラウド | Trackback | Comments(2)

ローカルネットワークに独自のドメイン名を付けるケースって割とよくあります。

新gTLD大量出現で「名前衝突」しそうなドメイン名とは

 割と多いのではないでしょうか、オレオレドメイン使っている人。まぁ一般家庭では問題ないのでしょうが、ある程度、ネットワークに詳しい人であれば、自宅のドメイン名に .home とか、企業であれば、.corp とかのドメイン名を使っているケースですね。

 myprinter.home とか、 server.corp とか。

 問題は、新gTLD の中に .home とか .corp などのドメインを取得した場合、イントラネットの機器が内部のDNSではなく、外部のルートドメインから another.home などを見つけてしまって、イントラネットの another.home に接続できなくなるというケース。あるいは、外部の another.home という機器が実際にはないため、社内の another.home が応答しないというケース。

 もっと怖いのは社内の another.home に接続したつもりで外部の another.home に繋がってしまって、パスワードとIDを入力せよ、というフィッシングされるケース。

名前衝突(Name Collision)問題 JPNIC

 ただし .corp や .home は無期限に取得できないリストに入っているのですが、良く Windows ドメイン名で .local とか SUSE Linux では .site がデフォルトだったりするので、これは将来問題になりそうな気がします。 Windows ドメイン名がオレオレドメインだった場合、ドメイン名を変えなきゃいけない、という話になれば、ちょっと大ごとです。

 もっとも「DNS名前衝突ブロックリスト」なるものがあるそうです。これは「今は存在していないトップドメイン名」を実際にクエリされたリストで、このリストにあるドメイン名は「取得済み」として原則取得不可となっているケースです。

 実際に例えばワタクシが仕事場の内部ドメイン名として .islandcenter を使っているとして、このクエリがルートドメインにクエリが繰り返されると、私が正規の手順で .islandcenter という gTLD を取得しようとしても、ブロックリストに載っていると取得できない、という事になります。

 まだ com とか .jp とかしかトップドメインがなかった呑気な時代、オレオレドメインを作ってイントラネットで遊んでいた場合、これらのドメイン名がいつの間にかブロックリストに載っているという問題が出てきました。

 この問題が今 .moe ドメインで発生しているというお話。
http://it.slashdot.jp/story/14/07/03/0611203/「tomocha.moe」というドメインが取得できない問題、発生

 これが正しい選択なのかどうかわからないけれど、.local などのローカルドメインを使っているネットワークの場合、local.mycompany.com のようにゾーン名を変えた方が良いのだろうか。一挙には無理としても、だんだん移行した方がいいのでしょうかね。

 そもそも、新 gTLD のメリットが良くわからないし、わざわざ新しい問題を作り出しているようにも思えます。

 それに、こういった問題があることを、「一般的なDNSの教科書」には載っていなかったのです。

急浮上する「ドメイン名衝突」リスク、企業システムの点検が不可欠

お問い合わせは
islandcenter.jp
[PR]
by islandcenter | 2014-07-09 09:21 | プライベートクラウド | Trackback | Comments(0)

サーバー仮想化で「導入済み企業」が押さえるべき点、「未導入企業」が理解すべき点(全文を読むには登録が必要です)

 上記の結果をみると、「サーバー仮想化を実現するために必要なハイパーバイザーが高価である」という回答が21.0%と最も多く挙げられている

 そんなにハイパーバイザーは高価なのでしょうか。

仮想化のお値段:無制限インスタンスに払うお値段比較

 という記事を1年前に書きました。実際、この春に、導入されたお客様は、ハイパーバイザーに SUSE Linux Enterprise Server 11(年間約4万) 、1Uラックマウントの2ウェイサーバーに約90万円、これで、8つの仮想サーバーを導入しました。

 確かに1台のハードウェアとしては高価なものですが、10G baseTでのSAN構成でこの値段です。これが私がご提案する「サーバー仮想化」のお値段です。この中には仮想OSのライセンスは含まれていませんが、既にお客様はエンタープライズライセンスをお持ちです。わずか10分でSysprep イメージから、新しい Windows 2008 サーバーを構築することができるようになっています。一番困るのは Windows Update にかかる時間だけです。

 また SUSE Linux Enterprise Server (SLES11) は仮想化インスタンスは無制限です。この1台のハイパーバイザーの中で8台のWindows と Linux のエンタープライズシステムが稼働しています。

 私がご提案する「サーバー仮想化」はハードウェア込みで約100万円。これは従業員150名程度のネットワークインフラ基盤を整えるためにはそれでも贅沢な構成です。

 しかし Windows の Datacenter Edition であれば、ハイパーバイザーだけで119万円、プラス、100万円では収まらないハードウェア費用が掛かるでしょう。

 私がSI事業者のセールスマンの立場だったら、間違えなく300万から400万の売上が上がるシステムを、鼻息荒くして提案します。

 ちょっとした興奮モノの案件になります。

バックアップをどうするか

 私がご提案する仮想化サーバーのバックアップは単純です。業務が止まっている深夜に仮想マシンを  cron でシャットダウンして、バックアップコピーを作って再スタートさせる。それだけです。8GbのLinux 仮想化システムであれば40秒以内でシャットダウン、バックアップコピー、リスタートします。実質1分程度の遮断時間はありますが、実務(と言っても深夜)に影響などはありません。もっとも、ファイルサーバーなど、日々変更があるデータは一般的な方法でバックアップします。

 この一連の流れが終わるとバックアップコピーされた仮想システムはNASやテープなどの外部メディアにとコピーされます。

 実際、サーバーがロストした状態でも、仮想システムイメージがあれば、ハイパーバイザーを入れ直して起動してしまえば、問題ありません。

 幸いな事に、このお客様の場合、既に仮想化システムを導入してから5年。ハードウェアの故障は、せいぜいRaidディスクのアラート程度でした。ハイパーバイザーのトラブルもなく5年の減価償却を終えようとしています。今回ご提案したシステムは、5年前のシステムのリプレースです。

 リプレース自体も恐ろしく簡単でした。何しろ仮想システムのイメージコピーを新機材にコピーして、一方を停止し、一方を起動するだけです。

--
 仮想化する上で「共有ファイルシステムと二重化したCPU装置、HUB,ストレージが必要」と説く方もいらっしゃいます。

 しかし、仮想化しない時点でシンプレックスな構成、ホットスタンバイな構成を取っていないシステムを仮想化移行すると考えてみましょう。特にシンプレックスな単サーバ構成で厳重なバックアップを作っておけば、問題ないはずです。そもそもがシンプレックス構成であっても、アタリが良いサーバーであれば、償却期間内にハードウェア故障によるトラブルはほとんどないはずです。

しかも、ハイパーバイザーの上で動作しているのは、ハイパーバイザーと管理用のソフトウェアだけです。まず、ハイパーバイザーだけなので、トラブルも起きようがありません。もっとも Windows サーバーをハイパーバイザーとして選択した場合、「例の毎月」のパッチによる再起動が必要なので、SI事業者側はシステムの二重化は提案してくるでしょう。

 余った予算で24H4時間対応のオンサイト保守に入っておくのがベストなのです。MTTRはわずか4時間以内なのですね。

 また、エンジニアとしての経験から、

 「単純なシステムほどトラブルは少ない」

 と考えています。エンジニアとしてはどうしても複雑で高度な技術にチャレンジしたいと考えてしまいます。しかしお客様の立場で運用することを考えてみると、できるだけ単純な方が問題がないのです。

 またトラブルが発生した際のMTTR(復旧時間)も少なくて済むものなのです。実際に複雑なバックアップ、リカバリ体制を検討した場合、想定した障害と復旧プランはほとんど役に立たないでしょう。

 もっとも、24H無停止を目標とするサーバーであれば、どのみちディュプレクスしなければなりません。しかし、単純なCPU二重化、ディスクコントローラの二重化では終わらない問題があります。それはお互いの死活監視の制御です。これは仮想化以前の問題です。

 また、システムの二重化はオペレータの負荷が重要となります。

 よくある話ですが、Raidが壊れた、という事に気が付かず、全てのデータを損失したというケース。システムが二重化されている場合、障害によりシステムが切り替わっても、利用者は気が付かずに運用を続けてしまいます。オペレータのセンスが良ければ、何等かのアラートを見つけて異常事態に気が付くでしょうけど、普通の中小事業者のシステムでは、そこまで目が行きづらいものです。

 しかもシステムを無停止運用したいという、中小事業者がその様な余剰で優秀な要員を24時間体制で確保できるわけはないのです。

 そこで、実はシステムに障害が発生すると、誰もが「おかしい」と気が付くように、「壊れてしまっている」状況を作り出した方が良いのです。極論かもしれませんが、実用的な障害アラートなんですね。本当に「ご臨終」になる前に、何らかの「おかしな現象」を出した方が、施術の手段があります。

 例え、システムの停止が数時間でも、あるいは完全修復に数日かかっても、データを完全にロストしてしまうよりはよほどマシなのです。

 その時のためのバックアップは重要ですし、毎日の運用管理者(大抵は兼任)がバックアップの確保だけはルーティンジョブとして目視確認すべきでしょう。

 それほど重要なシステムであれば、レスポンス、従量課金費用を考慮した上で、大手のクラウドサービスを考慮すべきです。

 パブリッククラウドサービスは、基本的なハードウェア、ミドルウェアなどの、提供しているサービスの障害は、利用者側が忘れてもいいことです。しかし、オペレータのミスオペレーションは許容していません。

 勿論、サービス事業者の提供するサービス内容に、データのバックアップがあったとしても、それなりのオプション費用がかかります。オンラインで手元にバックアップするのであれば、従量課金での費用が莫大になりそうです。

islandcenter.jp
[PR]
by islandcenter | 2014-06-25 12:57 | プライベートクラウド | Trackback | Comments(0)

特定のデバイスが snmp に対応しているか、あるいはイネーブルにして動作しているかどうかを確認するには snmpwalk を使います。

SUSE Linux の場合、net-snmp パッケージが導入されている必要があるので、
yast(or yast2) > Software > Search "snmp" で検索して、スペースキーで Accept してインストールすることができます。

Linux のコンソールから

snmpwalk -v 2c -c public MyDeviceIP .1.3.6.1.2.1.1

を実行します。パラメータは

-v 2c ... snmp version 2c
1 - 生存確認を返すだけ(プリンタなどはこのケースが多い)
2c - 一般的に利用される
3 -- 2c と同じ内容を暗号化する(一般的に設定が面倒で使いづらい)

-c public (コミュニティ名)

MyDeviceIP のアドレスかホスト名(myserver.intra)

OID は

.1.3.6.1.2.1.1 が一番使いやすいでしょう。

.1.3.6.1.2.1 までは決まり事の様なもの、ほとんど全部のステータス
.1.3.6.1.2.1.1 は更に枝葉の部分だけを取り出すこと
.1.3.6.1.2.x.x によって枝葉の部分を特定できる。

このあたりは、snmp の詳しいサイトや教科書でリファレンスを調べましょう。
MIB とか OID について入門編はこのITmedia の記事で何となく理解できます。
図解で知るSNMP――MIB情報のすべて

-Sample-

sles11:~ # snmpwalk -v 2c -c public device.intra .1.3.6.1.2.1.1
SNMPv2-MIB::sysDescr.0 = STRING: Linux dns2 3.0.13-0.27-xen #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (86836941) 10 days, 1:12:49.41
SNMPv2-MIB::sysContact.0 = STRING: Administrator
SNMPv2-MIB::sysName.0 = STRING: dns2
SNMPv2-MIB::sysLocation.0 = STRING: Right here, right now.
SNMPv2-MIB::sysServices.0 = INTEGER: 76
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (582) 0:00:05.82
SNMPv2-MIB::sysORID.1 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.2 = OID: SNMP-MPD-MIB::snmpMPDCompliance
SNMPv2-MIB::sysORID.3 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
SNMPv2-MIB::sysORID.4 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.5 = OID: TCP-MIB::tcpMIB
SNMPv2-MIB::sysORID.6 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.7 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORID.8 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup
SNMPv2-MIB::sysORDescr.1 = STRING: The SNMP Management Architecture MIB.
SNMPv2-MIB::sysORDescr.2 = STRING: The MIB for Message Processing and Dispatching.
SNMPv2-MIB::sysORDescr.3 = STRING: The management information definitions for the SNMP User-based Security Model.
SNMPv2-MIB::sysORDescr.4 = STRING: The MIB module for SNMPv2 entities
SNMPv2-MIB::sysORDescr.5 = STRING: The MIB module for managing TCP implementations
SNMPv2-MIB::sysORDescr.6 = STRING: The MIB module for managing IP and ICMP implementations
SNMPv2-MIB::sysORDescr.7 = STRING: The MIB module for managing UDP implementations
SNMPv2-MIB::sysORDescr.8 = STRING: View-based Access Control Model for SNMP.
SNMPv2-MIB::sysORUpTime.1 = Timeticks: (582) 0:00:05.82
SNMPv2-MIB::sysORUpTime.2 = Timeticks: (582) 0:00:05.82
SNMPv2-MIB::sysORUpTime.3 = Timeticks: (582) 0:00:05.82
SNMPv2-MIB::sysORUpTime.4 = Timeticks: (582) 0:00:05.82
SNMPv2-MIB::sysORUpTime.5 = Timeticks: (582) 0:00:05.82
SNMPv2-MIB::sysORUpTime.6 = Timeticks: (582) 0:00:05.82
SNMPv2-MIB::sysORUpTime.7 = Timeticks: (582) 0:00:05.82
SNMPv2-MIB::sysORUpTime.8 = Timeticks: (582) 0:00:05.82

sles11:~ #


islandcenter.jp
[PR]
by islandcenter | 2014-04-30 12:00 | プライベートクラウド | Trackback | Comments(0)

Zabbix 2.2.1 のopenSUSE 仮想アプライアンスの提供が始まりました。

ダウンロードはこちら
http://www.zabbix.com/download.php

マニュアルに初期パスワードなどが記されています。
https://www.zabbix.com/documentation/doku.php?id=2.2/manual/appliance

以前 2.0.5 を使ってみたのですが、一言で言って「ずいぶん使いやすくなった」というのが印象です。

上のZabbixのダウンロードページから tar.gz 形式のファイルをダウンロードして、展開した後、60Gb 程の仮想イメージが解凍されるので、これをハイパーバイザーに移植して動作させます。今回はXEN イメージを使いました。他に VMware や USB 起動用のイメージもあります。OS は openSUSE 12.3 です。

このアプライアンスは http://susestudio.com/ によって作成されたものです。

SUSE Linux Enterprise Server(SLES11sp3) では KVM でも使えるようになったので、そういう選択もあるでしょう。ハイパーバイザーに実装して起動したら、DHCP でIP を貰います。IP を確認して SSH 接続すれば、yast のコマンドが使えるようになるので、固定 IP を与えるとか、zypper install yast* などを実行して不足している YOU などの機能をインストールすると良いでしょう。


-監視対象のホストの設定-

監視対象のホストを定義します
https://www.youtube.com/watch?v=C3xl27E-DmM




この状態では、何の監視も行えないので、作成したホストにテンプレートを割り当てます。
https://www.youtube.com/watch?v=87e0SFZOTWY

この部分はかなり「良くなった」と思います。従来のバージョンでは随分エラーになったのですが、重複するテンプレートを上書きして、複数のテンプレートを定義できます。ソフトキー入力なので、"snmp" と入力すると snmp 関連のテンプレートを割り当てることが出来ます。

-ちょっと後退したディスカバリー-

ここでは snmp エージェントが動作するデバイスをディスカバリーする手順を行ってみました。

# snmpwalk -v 2c -c community-name(public) Target-IP OID(.1.3.6.1.2.1 など)

でディスカバリーしてみます。
https://www.youtube.com/watch?v=K-GYsmZPGT0


残念ながら snmp, zabbix-agent, ping などでは、うまく動作中のデバイスは検出できませんでした。マニュアルをもう少し精査してみる必要があるようです。まぁ、余計なデバイスを「底引き網」するわけではないので、これはこれで良いような気もします。

-グラフの表示-

Graphは Latest Data タブから、ホストを指定して直接、マネジメント対象のデバイスの項目に Graph リンクが付いています。これは結構使いやすいでしょう。従来の Graph タブからもグラフの描画が出来ます。
https://www.youtube.com/watch?v=tA49k1jRb6w


-マップ作成-

マップ作成でホストを選ぶ所ではやはりソフトキー入力でホスト名を指定します。ホストとホストを結ぶラインの作り方がわかりにくいと思いますが、複数のホストアイコンを Shift や CTRL で選択して "Link" の横の"+" ボタンを押すと、リンクが作られます。

https://www.youtube.com/watch?v=RGkQkUAMFTs


実際には、このアプライアンスは"評価目的"なので、本格的に運用する場合は Zabbix Japan LLC のテクニカルなサポートを受けることをお勧めします。
http://www.zabbix.com/jp/

--
Zabbix は、ハードウェアプローブのアプライアンスも出てきています。他の管理ツールと違って、「インストール」などの作業が不要な所、この Zabbix ソフトウェアアプライアンスは非常に導入して評価しやすいと思います。

islandcenter.jp
[PR]
by islandcenter | 2013-12-20 13:48 | プライベートクラウド | Trackback | Comments(0)

SUSESTUDIO のさまざまなアプライアンス化されたアプリケーションアプライアンスを見ていると、もう、「サーバー向けソフトウェア」はソフトウェア単体ではなくアプライアンス販売すべきだな、と思ってしまいます。

例えば

アンチウィルス用ウェブフィルター。
スパムメールフィルター
ウェブサイトブロック
ファイアウォール
高機能なグループウェア
8ポート程度までのL3スイッチングHUB

一般的なIAサーバーであれば、簡単にスケールアップできるわけで、容量、性能が低ければハードウェアのアップグレードは簡単。しかもほぼ日本全国24時間4時間以内の修理対応が可能であれば、特殊なハードウェア組み込みアプライアンスも必要はありません。このパーツを現地に送るために2日かかるとかということもないわけです。

もっとも、それなりのハードウェアアプライアンスも必要ですよ。48ポートのスイッチングHUBなんて一般的なIAマシンでは準備できませんからね。

これらのソフトウェアアプライアンスを JeOS(Just Enough OS) として、KVMやXEN、VMware、ライブCDなんかのイメージとして販売すればよい。

ダウンロード販売して、最終的にライセンスキーを購入すれば、パッチや最新のパターンファイル、体験版では使えない致命的な機能の解除を許可する。そしてサポートも利用可能にする。

ディスクレスのハードウェアアプライアンスと違って、HDD付きであれば、例えばパケットモニタリングを行ったりもできる。

どこぞのバカな国産ソフトウェアのように特定のOSじゃないと動かないということもない。ハードウェアが陳腐化しても、新しいハイパーバイザーに移植してしまえば性能も上がる。

どうして、こういうアタマのいい商売をしないのだろうか、日本のデベロッパー達は。


islandcenter.jp
[PR]
by islandcenter | 2013-11-02 10:11 | プライベートクラウド | Trackback | Comments(0)

これで、ますますハイパーバイザーとしての Hyper-V の選択肢が遠のいたと思う。

日本マイクロソフト、Windows Server 2012 R2とSystem Center 2012 R2を発売

Windows Server 2012 R2の参考価格は、プロセッサライセンスの場合、Datacenterが119万円

119万円ですよ。消防署じゃあるまいし、値段を覚えやすい。

他の商用ハイパーバイザーが数万円からいいところ RedHat の28万円がいいところ「インスタンス無制限」だろうし、非商用 Linux であれば0円なのですね。

せいぜい、1U2ウェイのサーバーであればいいところ5,60万も出せば結構なものが買える。その上で119万のハイパーバイザーを動かすというのはどういうものなのでしょう。

4ウェイとか8ウェイとかの巨大なシステムを動かせばいいんじゃないのというご意見もありそうですが、当然高価だし、それなりの減価償却期間がかかります。クラウドは規模に応じて簡単にリサイズできるのが良い点なわけですから、処理量がおおおきくなれば、サーバーハードウェアを増やし、古いサーバーをリプレースして、能力をあげて行けば好いわけなんですね。

そこに4ウェイとかの4Uのでっかいサーバーはふつう使いません。というかまずワタシなら提案しないでしょうね。

Hyper-V で提案してくるSI事業者や、Hyper-V を使ったパブリッククラウドの可能性、というかコストパフォーマンスの見どころです。

当然、 Windows で動く以上、ファイルシステムは非効率でいつもバックグラウンドでデフラグしている NTFS なわけで、フラグメンテーションを避けるためにも、共有の巨大なSAN構成を提案してくるわけです。光ファイバーに、光専用のHBAとHUB,何しろSANディスクでNTFSってのは I/O データの NAS 程度しかありませんから、中身は ext3 とかなわけです。

化粧のまずさをさらに化粧でごまかそうとする Windows の Datacenter Edition にはこれからも注目です。
[PR]
by islandcenter | 2013-11-02 07:46 | プライベートクラウド | Trackback | Comments(0)