HDDの温度を監視するには HDDtemp パッケージを使います。SUSE Linux Enterprise Server (SLES11) のパッケージには含まれていません。おそらく SLES を使うレベルのハイエンド、高信頼性のシステムでは、ハードウェアの障害は、ハードベンダーのツールを使うのが正論という事でしょう。

ということで、SUSE Linux の場合 opensuse のサイトから、1 Click インストールするのが正解です。

http://software.opensuse.org/

より、"hddtemp" を検索して、SUSE Linux に適合したパッケージを選び、1 Click インストールします。あとはウィザードに従ってインストールします。
a0056607_16251843.jpg


ヘルプを見てみます。


sles11:~ # hddtemp --help
Usage: hddtemp [OPTIONS] [TYPE:]DISK1 [[TYPE:]DISK2]...

hddtemp displays the temperature of drives supplied in argument.
Drives must support S.M.A.R.T.

TYPE could be SATA, PATA or SCSI. If omitted hddtemp will try to guess.

-b --drivebase : display database file content that allow hddtemp to
recognize supported drives.
-D --debug : display various S.M.A.R.T. fields and their values.
Useful to find a value that seems to match the
temperature and/or to send me a report.
(done for every drive supplied).
-d --daemon : run hddtemp in TCP/IP daemon mode (port 7634 by default.)
-f --file=FILE : specify database file to use.
-F --foreground : don't daemonize, stay in foreground.
-l --listen=addr : listen on a specific interface (in TCP/IP daemon mode).
-n --numeric : print only the temperature.
-p --port=# : port to listen to (in TCP/IP daemon mode).
-s --separator=C : separator to use between fields (in TCP/IP daemon mode).
-S --syslog=s : log temperature to syslog every s seconds.
-u --unit=[C|F] : force output temperature either in Celsius or Fahrenheit.
-q --quiet : do not check if the drive is supported.
-v --version : display hddtemp version number.
-w --wake-up : wake-up the drive if need.
-4 : listen on IPv4 sockets only.
-6 : listen on IPv6 sockets only.

Report bugs or new drives to .
hddtemp version 0.3-beta15



hddtemp にデバイスを引数に指定します。


sles11:~ # hddtemp /dev/sda
/dev/sda: WDC WD20EZRX-00DC0B0: 45°C
sles11:~ # hddtemp /dev/sdb
/dev/sdb: WDC WD30EZRX-00DC0B0: 48°C
sles11:~ # hddtemp /dev/sdc
/dev/sdc: ST31500541AS: drive is sleeping


Sleep 状態のディスクの温度は表示されませんでした。
この HDD は hdparm の設定で眠っているようです。

SUSE Linux hdparm で HDDの省電力化を試す。

起こしてみましょう。


sles11:~ # ls /mnt/sdc
backup lost+found tmp
sles11:~ # hddtemp /dev/sdc
/dev/sdc: ST31500541AS: 43°C


稼働中のHDDより5度ほど低いようです。

お問い合わせは
islandcenter.jp

-Key Word-
SUSE Linux Enterprise Server 省電力 熱対策 HDD温度監視
[PR]
by islandcenter | 2014-07-31 16:27 | SUSE | Trackback | Comments(0)

Windows 2008 R2 のクリーンアップウィザードを使うには、リブートが必要という嘘のような本当の話。

Windows Update をかけると13ECエラー
Update fail - MS .net 4.5.1 - Error code 13 EC

C:ドライブの容量不足だそうです。

Windows 2008 のC:ドライブを圧縮するには、スタートボタン>アクセサリの管理ツールの中にクリーンナップウィザードを起動すれば、アイコンが出てくるはずです、がありません。

デフォルトではインストールされないので、サーバーマネージャから「役割」で「デスクトップエクスペリエンス」をインストールする必要があります。

ちなみに、これをインストールすると

「再起動」

が要求されます。ウソだと思うでしょう。私も冗談かと思いました。

a0056607_15342510.jpg


冗談じゃなくて、本当のところが Windows のすごさです。


お問い合わせは
islandcenter.jp
[PR]
by islandcenter | 2014-07-29 15:35 | Windows | Trackback | Comments(0)

Linux で使えるX端末やフリー、無料ツール類のご紹介です。

Windows で使えるX端末としましたが、異論が多いでしょうね。正しくはXサーバーと言います。端末なのにサーバーとはこれいかに? サーバーとは、自分が接続する対象なのに、自分が操作するコンピュータが「サーバ」だと言う認識は、機能的な問題とは考えることは困難です。

したり顔で、「実体の構造的な、仕組みは云々」の説明をしても、初心者にとっては、「端末」ということになるわけです。だってそれ以外に説明のしようがありませんよね。

Windows で Unix/Linux 系の X で動作するアプリケーションをリモートで操作する、という行為なので、X端末と言う言い方のどこがオカシイのか、仕組みの問題ではなく、素人考えから入れば、「X端末」という考え方は、それほど「オカシイ」とは思いません。

ですから、「テキスト端末」「X端末」という言い方で、私は説明する様にしています。

ということで「Windows で X のアプリケーションを使うには」、あるいは「持っていると便利」な Linux 管理のための Windows 用端末などのアプリケーションを紹介しましょう。


Xming と Putty の組み合わせ

実は、一番愛用しています。何しろ軽くて、速い。お手軽です。

http://www.chiark.greenend.org.uk/~sgtatham/putty/

http://www.straightrunning.com/XmingNotes/

Putty は SSH のテキスト端末です、X ming は X 端末(Xサーバ)です。 Xlaunch で接続すると、外部の SSH 通信に Putty の SSH トンネルを使うもののようです。

xming は、プログラム本体と、フォントの二つをインストールします。

Simon Tatham氏が開発した Putty.exe は PuttyJP.exe として日本語化もされていますが、ほとんど英語版だけで問題なく使えます。日本語は UTF-8, ISO2022、EUC-JP などに対応しています。Shift-jis を使うには PuttyJP 版が必要です。もっともほとんど ShitJis が必要なケースはないので、英語版で十分です。

SSH キーは "Simon Tatham" のレジストリの中に作成されます。ターミナルに出力された結果を "Copy to Clipboard" もできます。コマンドを実行した内容と結果を、メモ帳に張り付けて必要な編集をして、LibreOffce Writer に張り付ける、なども簡単です。

Putty は起動方法も簡単だし、単体で動くし、堅牢です。

Xming のターミナル(xterm)は日本語化されていません。が、勿論、Linux 上の言語が日本語であれば、表示は問題なくできます。

a0056607_16434819.jpg


特に SUSE Linux のドキュメントや Novell の Cool Solution のサイトでは、かなり使われているようで、SUSE Linux との相性は安定しています。

ただし openSUSE 12.x 以降ではどう頑張っても使えません。でも SUSE Enterprise Server (SLES) では問題はまずありません。

セッションは1つしか使えません。

時折、キョドる場合があります。 SSH の鍵交換がうまく行かないようなのですが、その場合は Simon Tatham 氏のレジストリの中の SSH キーを削除してあげると、まずうまく動いてくれます。

TeraTerm

おなじみ、国産テキストターミナルエミュレータです。ルータ屋さんなんかはずいぶん愛用しているようです。私は個人的にはあまり使う機会がないので、まず使った事はありませんが、 VNC 接続を SSH で行うテクニックでは良く紹介されています。

Telnet

最近聞かなくなりました。Windows 7/8 では標準でなくなってしまいました。Windows 7/8 のコマンド画面から > "Telnet" とやると、「あれ?」ということになります。コントロールパネルの「プログラムと機能」の中に Telnet クライアントがあるので明示的にインストールしないと動きません。

a0056607_16443986.jpg


SUSE Linux 11 以降でも、標準ではインストールされないので、Yast から明示的にインストールする必要があります。telnetd も明示的にインストールして、サービスを起動します。

このご時世でまず、サーバー側でデーモンを動かすことは、あり得ないでしょう。

時々ポートの状態を調べる為に使いたいと思う時があるのですが、「ないものはない」のでインストールしないと使えないのはちょっと残念ですね。

NX Free

NoMachine社 の NXfree は無償版ですがセッション数に制限があります。有償版はセッション数に制限がありません。かなり爆速だ、という評価もありましたが、私はそうは感じたことがありませんでした。

https://www.nomachine.com/download

サーバーとクライアントがあり、Linux サーバーには nxserver をインストールして起動しておく必要があります。これもちょっとハードルが上がります。

実際の使用感はこちら
NX Free で SUSE Linux に接続してみる

ただ、デスクトップ画面のステータスバーなどが全て表示できるので、これはこれで便利です。

MobaxTerm

最近、ハマっているいるのがこの MobaxTerm です。私の様に Cygwin に挫折した方には良い選択肢です。

http://mobaxterm.mobatek.net

テキスト端末と、X アプリケーションが起動できて、しかも sftp のクライアントでもある。しかも複数のセッションを開いて、同時に違うコンピュータのXアプリケーションを操作できる所も便利です。

SUSE Linux Enterprise Server (SLES) では xming でも問題ないのですが、openSUSE では xming はうまく動きません。

MobaxTerm では、その様な問題はなかった、と報告できます。ということでopenSUSE を Windows でイジクルには有難い存在です。

ただし、日本語化されていないため、テキスト端末で日本語表示はできません。(追記 UTF-8 のみ、SUSE Linux では問題ありませんでした)
a0056607_16595945.jpg


またちょっとキョドっている(挙動不審)な所があるので、そのあたりはもう少しこなれて欲しなと思います。

RealVNC,UltraVNC

この二つは、接続するサーバー側の vncserver のポートを使うものです。使った後は、vncserver のポートを kill します。

結構面倒で、緊急時以外は使いません。

使った感想はこちら
SUSE Linux で VNC 接続をする

通常は平文で通信するので、TeraTerm のセッションを開いた状態から、 TeraTerm からSSH トンネルを使って接続するのが常套手段の様です。

動きがもっさりしているので、やはり緊急手段としてしか使いません。


WinSCP

これは、エクスプローラライクなファイル SSH ファイル転送ツールです。ファイルを大量に Windows <---> Linux でコピーする場合に便利なツールです。

http://winscp.net/eng/docs/lang:jp

ただ、デフォルトでは UTF-8 が有効ではないので、「接続」する際に「環境」で UTF-8 を明示的に ON にしないと日本語は文字化けします。
a0056607_1702410.jpg


WinScp の秀逸な所は多機能である所です。そのまま、Linux 上のファイルも編集できる機能があり、MovaxTerm と組み合わせると、そこそこに使えるシステム開発、管理の環境で利用できます。

dig

dig は bind のパッケージに標準で付いているコマンドです。あの古臭い nslookup を使う位なら、より使いやすい dig を使っています。bind はISC社のオープンソースなので、Microsoft としても dig を実装するのはオープンソースの著作権の問題もあるのでしょう。

ダウンロードページ
BIND

Windows の dig 自体は Bind の Windows 用パッケージに含まれているので、 dig.exe, host.exe あと DLL 関係を全部、どこかのディレクトリなり USB メモリなりに入れて置けば、 dig 単体で使えます。

本当は、「ちゃんと nslookup 使えるようにしろよ」と言われそうですが、どうしても DNS は Linux から入ったので、Windows/Linux の nslookup は見にくいし、情報も少ないし、使いづらいのですね。

お問い合わせは
islandcenter.jp
[PR]
by islandcenter | 2014-07-29 10:37 | SUSE | Trackback | Comments(0)

SUSE Linux Enterprise Server (SLES11) で DNS(Bind) のバージョンを隠す方法です。

小規模ネットワークのイントラキャッシュサーバであれば、別に隠すことが重要なわけではないのですが、 Bind も脆弱性の多いソフトウェアなので、もしこれが外部に向けた DNSである場合は、バージョンを隠しておくことは重要です。バージョンをむき出しにしておくと、

「戸締り悪いな」

という印象があり、アタッカーが粘着的にほじくり返して、自分の気が付かなかった脆弱性を見つけられてしまうという事にもなりかねません。ということで、 Bind のバージョンを隠してしまう方法です。


まず、設定したての Bind のバージョンを確認してみます。

sles11:/~# dig @localhost chaos txt version.bind

; <<>> DiG 9.6-ESV-R5-P1 <<>> @localhost chaos txt version.bind
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9153
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;version.bind. CH TXT

;; ANSWER SECTION:
version.bind. 0 CH TXT "9.6-ESV-R5-P1"

;; AUTHORITY SECTION:
version.bind. 0 CH NS version.bind.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 23 16:32:18 2014
;; MSG SIZE rcvd: 70


ということで、リモートホストでも同じ方法でバージョンが確認できます。専門にハッキングしているヒトからすると、これは”××のディストリビューション使っているな”とわかるものらしいので、他の脆弱性を晒されるヒントになりかねません。

yast でバージョンを隠します。
# yast から Network Service > DNS server > Basic Option で option のフィールドを開きます。
a0056607_8511164.jpg

オプションリストの下の方に version というのがあるので、これを選択し、引数に "任意の文字列" (文字列は " Double Qurtation" で囲みます) をセットします。
a0056607_8542925.jpg


これで DNS からどういったバージョン番号が帰ってくるか。


sles11:/~# dig @localhost chaos txt version.bind

; <<>> DiG 9.6-ESV-R5-P1 <<>> @localhost chaos txt version.bind
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7803
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;version.bind. CH TXT

;; ANSWER SECTION:
version.bind. 0 CH TXT "byebyebaby"

;; AUTHORITY SECTION:
version.bind. 0 CH NS version.bind.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 23 16:34:56 2014
;; MSG SIZE rcvd: 67

sles11:/~#


ということで "bybybaby" が帰ってきました。

ここではオフザケなので、何でも良いのですが、あまりにふざけたバージョン文字列を返すと、逆効果で”その筋”のニンゲンを燃え立たせてしまう逆効果もあります。

無難に "unknown" を返すのが良いでしょう。


お問い合わせは
islandcenter.jp
[PR]
by islandcenter | 2014-07-23 17:30 | SUSE | Trackback | Comments(0)

SUSE Linux Enterprise Server11 (SLES11) で apache2 (HTTPサーバー)をインストールして動作確認するまでの全操作を全公開します



SLES は、ほぼ素のまま、タイムゾーン以外はほとんどデフォルトで、固定アドレスを付けただけです。リモートテキスト端末から初めてログインして、インストールを開始しました。

最近は Linux ベースのアプリケーションでもウェブブラウザで実行するものが多く、Apache のインストールごときで、時間は取られたくないものです。

途中に PHP, Perl などのスクリプトを有効にするチェックがあります。動画ではチェックしていませんが、PHP などを利用するソフトウェアを後で導入したい場合は、ここでチェックしておくのが良いでしょう。

コマンドをしらなければ "yast" と叩けばいい。これが SUSE Linux の最大の特徴です。

-Keyword-

SUSE Linux Apache HTTP サーバー インストール方法 簡単な設定方法 

お問い合わせは
islandcenter.jp
[PR]
by islandcenter | 2014-07-19 14:35 | SUSE | Trackback | Comments(0)

SUSE Linux Enterprise Server11 (SLES11) で Bind (DNSサーバー)をインストールして動作確認するまでの全操作を全公開します。



SLES は、ほぼ素のまま、タイムゾーン以外はほとんどデフォルトで、固定アドレスを付けただけです。リモートテキスト端末から初めてログインして、インストールを開始しました。

Bind のパッケージも named の設定もない所から、テキスト端末で yast ツールで、内部DNSキャッシュを作り、イントラ向けの幾つかのレコードを作るまでの手順です。

ほとんど TAB と スペースキーで、インストールから、稼働までを行っています。
(内容には突っ込みどころ満載かもしれませんね)

実際の Bind のもう少し詳細な設定は「DNSの教科書」を見る必要があるでしょうが、これだけ簡単にできることはとても素晴らしい事です。

同様に samba, apache2, パーティションの変更、ソフトウェアの変更、サービスの起動などはこのように yast でほとんど用が足りてしまいます。

コマンドをしらなければ "yast" と叩けばいい。これが SUSE Linux の最大の特徴です。

-Keyword-

SUSE Linux DNS Bind インストール方法 簡単な設定方法 

お問い合わせは
islandcenter.jp
[PR]
by islandcenter | 2014-07-19 08:40 | SUSE | Trackback | Comments(0)

高可用性、高信頼性で堅牢な SUSE Linux Eternprise Server (SLES11) を XEN ハイパーバイザーとして利用する場合の、 SLES をインストールするポイントを説明します。

SLES11 は既にインストール済み、MobaXterm を使って Windows 側から操作しました。ハイパーバイザーは、 Core i5 の低電圧版、一般的なミドルランクの8G メモリの SATA ディスクのホワイトボックスPCです。既に、二つの Windows と4つの Linux サーバーが動作している「かなり重い」サーバー(?)です。

terminal をまず、XEN サーバーに接続します。

# yast & から virt-manager を起動するか
# virt-manager & を直接起動します。

"Not Connect" > 右ボタンで "Connect"

作成します "Create New"

設定はほとんどデフォルトです。デフォルトで SLES11 が選択されています。 8Gディスク と 4vcpu, 512Mb メモリです。
a0056607_12284919.jpg


SLES11 は 512Mb メモリでも、十分 GUI でインストールできます。他のディストリビューションでは、インストールに1Gバイト程度メモリを要求する場合がありますが、SUSE は 512Mb で十分です。
a0056607_1231999.jpg

ここでは、メモリが余っていたので1Gバイト与えましたが、通常のインターネットサーバーなどではそんなに必要としないでしょう。VPN だとか、簡単な HTTP サービスであればインストール後に /etc/xen/vm ファイルを編集して 192Mb でも動作します。

インストールのソースファイルを選びます。ここでは ISO ファイルを選びます。
システムパーティションは SLES11 では 8G ですが、gnome デスクトップを外したり、英語以外の言語の選択を外せば、 4G でも十分なスペースです。

ここで注意するのは xvd ファイルが先頭、 CD/DVD の ISO が2番目にあることです。間違えてセットした場合は、 Up/Down ボタンで位置を設定し直します。(ISOが先頭にあると再起動に失敗します)

xvd ファイルは /var/lib/xen/images/MyVm/disk0.raw となります。 disk0.raw では、単体ファイル名でどの VM なのかわからないので MyVm.disk0.raw などとリネームしておくのが良いでしょう。

NICは自動的に準仮想化ドライバが選択されます。Eth0しかない機材なので br0 しか選べませんが、NIC の複数差しの場合、任意に接続できるNICへのブリッジインターフェースが選べます。例えば、 br0 の Domain-0 は幹線に、dom-U の br1 は DMZ に配置する仮想マシンに、と言った具合ですね。

Centos7 で試したのですが、RedHat 6/7系の非XEN対応のディストリビューションでは、完全仮想化しか道はありません。

それでは実際にインストールを開始します。


デフォルトでは English/English Keyborad ですから 106 キーに変えるために、キーボードを Japanese に変更します。 License Agreement の Agree をチェックして次へ進みます。
a0056607_12435128.jpg


私個人としては、別にメニューが日本語化されても嬉しくありません。却って、日本語のメニューを英語に翻訳して考えるという無駄な努力が必要なので、全ての表示は英語でいい、と割り切っています。

タイムゾーンの設定です。マウスを使って Asia/Japan を選択します。
"Hardware Clock set to UTC" のチェックは外します。
a0056607_1248210.jpg

どうせ仮想化されたマシンなので、Dom-U 側からは CMOS クロックを変更できません。また、ハードウェアクロックを強制的に UTCにした場合、ハードウェア側のログなどが UTC になります。あまり喜ばないお客様が多いので、いつもこうしています。

ただし、インターネット公開用サーバーの場合、時間帯は UTC を選ぶべき場合があります。それでも、仮想サーバーは直接ハードウェエアクロックを制御しませんので、このチェックは外します。

基本的なインストールのシナリオです。
1) 物理サーバー
2) XEN/KVM などの仮想 domain-u
3) XEN サーバー
4) KVM サーバー
a0056607_14574590.jpg

これで、サーバーの性格が決まってしまいます。物理ハードウェアをハイパーバイザーとする場合、 3),4) のどちらか好みを選びます。ただし XEN/KVM をインストールした場合、デバイスドライバのコンパイルに必要なカーネルソースや、アクティベーションに必要な FireFox ブラウザなどはインストールされないので、追加でインストールします。

ちなみに KVM のハイパーバイザー上に SLES をインストールすると、自動的に KVM に最適化されたドライバがインストールされました。

今回は仮想マシンなので2) です。

サマリ画面が開いたら "Expert タブ"を開きます。追加言語や RunLevel, 追加用アプリケーションソフトウェアなどはここからインストールします。

追加言語として Japaneseをチェックしておきます。少なくとも、これで、使うアプリケーション(と言ってもブラウザ位ですが)が日本語表示のためのフォントのインストールなどが行われます。
a0056607_125344.jpg

言語の追加のため、インストール量の見積もりが変わりますよ、という警告にOKします。

デフォルト RunLevel は 5 (XDM)なので 3 にします。
a0056607_1257176.jpg

どうせ仮想マシンなので、コンソールを開くことはないでしょう。余分なメモリは使いたくありません。

サマリ全体を確認してください、それではインストールを開始します。

幾つかライセンス同意の画面が出ます、 I Agree を押して、最後に Install を開始します。


このインストールにかかる時間は一般的なPC環境であれば25分程度、サーバーなど SAS-Raid のハードウェアで 12,3 分程度、 SSD なら5分ほど、ファイルコピー、rpm のインストールにかかります。

-ということでコピーを待つ  (^_^)y== - ~~

コピーが終わると、自動的に再起動します。

a0056607_14254795.jpg


一旦、仮想コンソールが閉じますが、 Virt-Manager から、作成中の仮想マシンを右ボタンから Open します。 SUSE の初期起動画面、 Geeko のスクリーンが出ます。邪魔な場合は F2 キーでクリアできます。

実際 Virt-Manager で見ると、こんなに沢山の VM があることに驚いてしまいました。

a0056607_142910100.jpg


root のパスワードスクリーンです。 Test 用のボックスがあるので、特殊キーや NUM ロックがかかっていないか確認します。
a0056607_1431492.jpg


この後、"サーバー名.ドメイン名" をセットし、ネットワークの設定をします。
a0056607_1435255.jpg


IPv6 は無効に、ファイアウォールはここでは一応 Disable にしておき、SSH のポートを開けておきます。
Network Interface のラインをクリックして、IP の設定をします。
a0056607_14382253.jpg


DNS, Default Gateway(Router) の設定を行います。
a0056607_14401917.jpg


ネットワークのテストは "No" を選びます。Yes を押して、はまり込むと、ドエライ苦労が待っています。まずはインストール作業を優先しましょう。このスクリーンは2、3度出ますが、特にスキップしなくても、自動的に次の画面に移動します。
a0056607_14431073.jpg


その後、CA管理画面、ユーザ作成方法(デフォルトは Local) ユーザ(オペレータ名)をセットします。

ハードウェアの設定が終わりました。
AutoYast は同じサーバーを沢山設定するためのテンプレートなので、設定は不要です。
チェックを外します。
a0056607_14455347.jpg


YaST インストーラが終了して、 RunLevel 3 で起動します。
a0056607_14484612.jpg



お問い合わせは
islandcenter.jp
[PR]
by islandcenter | 2014-07-18 15:44 | XEN | 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)

来年の春にでもプレビュー版が出るとのウワサさえある Windows9 について、昼寝をしながらの勝手な意見です。

Windows9 は 32ビットか 64ビットか

 よかろう、Windows9(仮)は 64 ビットが正しい。どうせほとんどのよほどの低スペックのPC以外は4Gバイト以上のメモリを踏査し、メインストリームPCは8Gバイトのメモリです。このスペックでは32ビットは考えられません。ただ、最近の円安の影響で、様々なPCパーツが値上がりしている状況からすると、中々メモリ8Gモデルというのは出にくい状況でしょう。

 ただし、一部のタブレット、発展途上国向けのような低価格なホームエディションは32ビット版が残る可能性はあります。
 クラムシェルノート、デスクトップは64ビット、ハンドヘルドのPC,スマートフォンもどきは32ビットという棲み分けになるでしょう。メリットは 64 ビット版 Windows で作成した文書がスマートフォンで閲覧でき、32ビット版でメモしたアイディアが64ビット版でファイナル文書に加工できる所です。

しかし、そんな操作はいまどきの Android や iOS 搭載のタブレットとの組み合わせで十分行える仕事なのですね。Windows 32 bit 版やタブレットの存在価値は低い。精々タブレットシェアでは Windows は10%がいい所かでしょう。

 困ったことに Windows 8 x64 版はデバイスドライバの認識が甘い所があります。 Windows7 で使っていたワンセグチューナーは見事に動きませんでした。仕方がないので、ブラジルワールドカップを見るために、新しいチューナーユニットを購入させられました。

 また、Bluethooth のダメさもあります。まだ、ノートブックについているウェブカメラはと Bluetooth ユニットは認識できていません。ますますつなげるデバイスドライバは選ぶ必要が出てきそうです。Windows7 32bit で動いていたレーザープリンターは何とかメーカーから、Windows 8 出荷後1年でドライバが出てきました。たぶん Windows 9 用は出ないでしょう。それまで、Windows 7/8/9 を切り分けて使うしかありません。

 アプリケーションは相変わらず 32 ビット版が中心でしょう。デベロッパーがわざわざ「今動いている」ソフトウェアをコンパイルし直して 64ビット化するとは思えません。Office でさえ、Excel 方眼紙を愛用するユーザがいる限り 64 ビット化される事はないでしょう。64 bit 版 Excel を使うのは天文学者かDNAを解析する技術者くらいでしょう。もっとも彼らが Windows を使うという保障はありません。 Linux であればネイティブに動く 64 ビットアプリケーションは山ほどあるし、コンパイラという開発環境があれば、カスタマイズされた単機能のアプリケーションも自由に作れます。

 アンチウィルスソフトウェアは早く64ビット化して欲しい。64ビットコードを調べるために32ビットコードで動くのでは効率が3倍から下手をすると10倍くらい実行速度が違います。これからは、マルウェアも64ビット化するでしょう。

 アプリケーションが32ビットである以上、ローエンドユーザはメモリは4Gも使いません。8Gバイトのメモリを積んだ 64 ビット版 Windows は自己満足のためか、Hyper-V で発揮するでしょう。ただ、私のように馬鹿みたいにアプリケーションを常駐させるユーザにとってはいい選択です。

 デスクトップPCにタッチパネルが必要だという言うのはそもそも冗談みたいなものです。そんな液晶24インチモニタにタッチ機能が付いているのは見たことがないし、さらに孫の手が付属しているパネルなんて見たことがありません。(いいですね、孫の手付の24インチモニタ、ワイプとかズームとかできる。特許取ろうかな)

だから、Windows にタッチ機能は必要ではない。結局、操作はキーボードとマウスです。

バージョン番号は

 Windows8 のバージョン番号は Windows NT 6.3 です。Windows 9 が NT7 となるのは甚だ怪しい話でしょう。なぜなら、様々なリークにある情報では、インターフェースの改良はあっても、基本機能の改良をしているという話は耳に入ってこない。となると、 Windows9 は Windows8.1 upgrade の改良版でしかない。つまりメジャーアップデートと言っても Windows NT 6.4 となる可能性が高いのです。もっとも Windows NT のメジャーバージョン番号が変わった時は要注意なのは言うまでもありません。NT 6.0 の Vista がいい例ですね。

 いい意味でも悪い意味でもWindows9 は Windows NT 6 系の引き継ぎでになるでしょう。

 インターフェースの改良はコスメティックなもので、表面的な改良に過ぎません。

 ここで疑問となるのは、果たして Windows は進化するつもりがあるのだろうかということです。今一番 Windows に欲しい機能は、新設計のファイルシステムです。いつまでも FAT を Convert コマンド一発で数分で変換できるようなファイルアロケーション、年中バックグラウンドで走るデフラグのないファイルシステムです。どうもそんなリークがない以上、相変わらずパフォーマンスの悪いNTFSが主力のファイルシステムとなるのでしょう。


-ゲームとSNSと天気予報-

 Windows ストアには色々魅力的なアプリケーションが増えてきました。ゲームとかSNSとかゲームとか天気予報とか、ニュースとかゲームとかです。

 つまり、ゲームとニュースと天気予報以外に使いたいと思えるソフトウェアが何もない。ストアアプリのテキストをコピーペーストする機能もない(あるのかも知れないがマウスでやる方法を知らない)

 ゲームにしても iOS や Android からの移植です。

 困ったことにほとんどのクラムシェルノートには加速度センサーもGPSもタッチパネルもありません。あったとしても、ここで Android や iOS との差別化が難しいのです。Android でヒットしたゲームでも、マウスとキーボードの操作ではどうしてもうまく操作できません。わざわざ Windows で使う意味がないのです。あえて言えば、「あの Android の名ゲームが Windows に移植」された程度の話題でしかありません。わざわざ Windows で面白いゲームがあったから、iPod で探してゲームするくらいです。

 最悪なのは、ニュースなどを「更新」して別なアプリケーションに切り替えた時です。 Windows アプリは最小化したりバックグラウンドに移動した時に、状況がサスペンドしてしまいます。つまり「更新」ボタンを押して更新が終わるまでぼーっと更新画面を眺めていないと新しいニュースがダウンロードされストックされません。SNSにしてもそういうことです。

 ストアアプリは残るでしょうが、重要性が低くなるでしょう。何しろゲームとニュースと天気予報しか使えませんからね。

 PCでできてタブレットで出来ないことは、例えば税金の申告表を作るとか、年賀状をデザインするとかです。これは十分に生産的な作業です。今のタブレットでは、画面のハードコピーを印刷するだけでも一騒動かかります。ビットの年賀メールは遅れても、アトムの年賀状は書けないのがタブレットの欠点です。

さて Windows9 は買いか

 Windows9 という名の「商品」が出てきても、今のところ金出して「欲しい」と思わせるイノベーションが予測出来ません。あくまでもリーク情報からなので推定するしかないのですが、 Windows 8.x の厚化粧版という印象しかありません。もし、Windows 8.1 upgrade のようにアップデートで対応できたのなら試す機会はあるでしょう。「商品」として購入してアップデートまでしたいとは思いません。

 もし、アップデートするのであれば Windows NT 7.0 になった時の Windows でしょう。もっとも x.0 版の Windows のひどさは有名なので NT 7.1 が出た時が本命になるでしょう。

 Windows NT 7.x では全く新しいディスク管理システム、例えばよく使うデータはSSDへ、デッドデータは自動圧縮して低速ストレージで圧縮。ディスクを追加したらシングルボリューム化が容易にできる。(バグ多そうだ)

 ディスクのプロパティから「断片化」のタブが消えている。データの損失なく、高速なシャットダウンとスタートアップ。アクティブアプリケーションを最小化した時の無駄なメモリの解放。メモリ512Mbもあれば十分に使えるパフォーマンス。アプリケーションのサンドボックス化。高速なファイルのインデックス処理。ファイルの自動振り分け。ストアアプリのバックグラウンド実行。

 何かと問題の多い、CIFS や MS Browser もこの際、廃止するか、将来はないものとして、ネットワーク標準のプロトコルを使う。DNSを尊敬し、ファイル共有は ssh で行う。どうせ、Microsoft 独自のものはクローズである以上、グローバルに展開する他の標準的なシステムとは異質なものです。

 そのためには幾つかのステークスホルダーを捨てる勇気が必要でしょう。いや必要なのです。少なくとも Windows 7 のメインテナンスが後数年、Windows 8 はあと5、6年使えるなら、それは十分な期間です。


ビジネスとしての Windows

 Windows8 の嫌らしい所、それは、Microsoft アカウントとの統合です。そりゃ確かに Microsoft アカウントと統合しておけば便利なことは様々あるのですが、ビジネスに Microsoft アカウントは必要ありません。本来ならば、OneDrive なんかは、ドメインに統合してしまって、ドメインログオンで、ローカルネットワークのサーバー上に Sync させてしまえばいい話です。月々の課金もなければ、容量もポリシーで制限するか無制限かが自由に管理できる。

 そうなると、本当に大事なのは実は Windows 端末ではなく、Windows サーバーの方にです。そして、 Windows タブレットがドメイン管理できるようになれば、 OneDrive で保存したドキュメントを Windows タブレットで参照したり、修正したりといった作業ができます。

 もっと Windows Pro 版はサーバーとの緊密な連携を行うべきだろうし、タブレットや Windows Phone もドメインへの参加が行えるようにすべきなのです。そうしないと Android/iOS 勢との差別化ができないでしょう。

 Windows Store もドメイン経由で利用できるようにすれば良いでしょう。業務アプリはもっと簡単に端末に配布すべきなのです。Windows サーバももう少し賢くなるべきです。そもそも低速な WAN 回線で数百Mbものストアアプリをダウンロードできるのは、全ユーザ人口の数十%と認識すべきです。Windows Update Service の機能の中にストアアプリのキャッシュ機能を組み込むべきなのです。


--
顧客の現場では、圧倒的に Windows 7 の32ビット版が主流です。これは特に XP ディスコン対策を早めにやった現場ほど著しいようです。

「私たちの一般的なビジネスには 64 ビット版は不要」

 というご意見も頂きました。賢い選択だったと思います。
 しかし、これから、どうしても64ビット版 Windows が主流になるとすれば、どの様な選択がベストか。

 今のところ、「今一番先が長い」と思われる Windows 8.1 Upgrade 64版が一番のおすすめです。地道なUIの改良が期待できます。

 今さら Windows7 の64ビット版を提案する積極的な理由はありません。どうせメインストリームサポートも終わって、後は壊死するのを待つだけです。あえて64ビットドライバの検証を行うのも無駄でしょう。今は Windows 7 32 ビット版で十分、という顧客であれば、あえて「噂される」Windows9 を待っても良いでしょう。それまであと1年ともいわれる余裕があります。


お問い合わせは
islandcenter.jp
[PR]
by islandcenter | 2014-07-07 10:43 | Windows | Trackback | Comments(0)