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

Zabbix 3.0 のリリースと同時に Zabbix Appliance も公開されました。利用した「顛末記」です。

Zabbix Download 3.0 LTS KVM, Parallels, QEMU, USB stick, VirtualBox, Xen (.raw) ダウンロードはこちら

Zabbix appliance

-なんで Ubuntu ????? -

今までの Zabbix Appliance は openSUSE で構成されていたため、ほとんどの作業をroot で入って yast コマンドで、メニュー形式から変更することができました。vi 使うのは php.ini のタイムゾーン書き換える程度だったんですけどね。なぜこんなに使いづらい Ubuntu にしたのか納得できない。何かというと "access denied" とか "command not found" となるンですね。

お、出たか sudo しろって事だな。という事で、システム設定のほとんどを yast メニューで出来た openSUSE 版ではなく、地獄の sudo と sudo vi との闘いが、zabbix 以前の問題としてアプライアンス導入へのハードルを上げてくれました。

まぁ好みと慣れの問題なんですけどね。

※つくづく申し上げますが、vi で設定を編集するときは綴りを間違えないでくださいね。SUSE の yast の様にパッケージのインストールから設定まで自動化されていません。ubuntu では全部手書きです。

zabbix 2.x での実際のアプライアンス版の導入はこちらをご参考下さい。

頼む、openSUSE 版の Appliance 出すか、SUSE 版の zabbixの rpm 作ってくれ。
openSUSE で 1 Click インストールできる様にしてくれ。
と言っても無料で使っているわけだから文句は言えませんね。
まぁ、openSUSE leap 42 は安定板じゃないからなぁ、13.1 あたりの安定板を使ってほしい。

- 環境 -

動作環境は SLES12 の XEN 環境から行いました。Zabbix Appliance 3.0 は KVM/XEN と同じイメージファイルです。SLES12 の環境では XEN/KVM 両方サポートしているので、どちらでも、実装そのものはあまり変わりないでしょう。おそらく RedHat 系の KVM のみの環境でも同じように実装できると思います。

まず解凍します。
sles12:/var/lib/xen/images/zabbix # tar xvzf zabbix_appliance_3.0.1_x86_64.raw.tar.gz
./
./zabbix_appliance_3.0.1.raw
sles12:/var/lib/xen/images/zabbix # ls -al
total 81061244
drwxr-xr-x 3 root root 4096 Feb 16 18:35 .
drwx------ 19 root root 4096 Mar 10 08:34 ..
-rw-r--r-- 1 root root 10485760000 Feb 16 18:56 zabbix_appliance_3.0.1.raw
-rwxr--r-- 1 root root 1370095336 Mar 10 12:03 zabbix_appliance_3.0.1_x86_64.raw.tar.gz
sles12:/var/lib/xen/images/zabbix #

そりゃ、openSUSE だと思っていましたよ。でもドキュメント読むと

"Ubuntu version 14.04.3"

って書いてあるわけですね。そりゃぁ手慣れた手順で、アプライアンス実装しても動く訳がない。

その罠に気が付いて virt-manager を起動して、SLES12 では、次の様なパラメータで仮想マシンを実装します。

a0056607_11165514.jpg
最近はハードウェアの性能が仮想化前提で設計されているため、あまり XEN/KVM の性能差や機能差がなくなってきました。起動して初めて「何じゃこれ」という事になったわけです。

- OS Type が Ubuntu なので full virtual(完全仮想化)です。
- メモリ、vcpu はデフォルトのまま
- 仮想ディスクに解凍したイメージ raw ファイルをセット
- VM 名を任意に zabbix3 などにセット
これで OK ボタンを押すと Zabbix アプライアンスが起動します。
a0056607_11174281.jpg
DHCP なので ifconfig で ip を確認してから Ubuntu に SSH 接続してみます(メンドクサイ)ちなみに ubuntu には root というユーザがいないため、デフォルトの "appliance"/zabbix で ssh 接続します。 -l なんてオプション初めて知った。
a0056607_11181045.jpg
- IP を固定する -

yast が使えないため、まず DHCP から ip を固定するため sudo vi と闘います。
/etc/network/interfaces /etc/resolv.conf を修正します。

appliance@zabbix:/etc/network$ cat interfaces <--- デフォルトの確認
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp
appliance@zabbix:/etc/network$

# sudo vi /etc/network/interface <--- 編集、/etc/resolv.conf も編集

appliance@zabbix:/etc/network$ sudo vi interfaces
[sudo] password for appliance: 間違えちゃった....
Sorry, try again.
[sudo] password for appliance: <--- vi で編集します。

: 編集中(SUSE + yast じゃないので、綴りを間違えないように......)

appliance@zabbix:/etc/network$ cd ..
appliance@zabbix:/etc$ sudo vi resolv.conf
appliance@zabbix:/etc$ cat network/interfaces <--- 変更後の確認
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static <--- dhcp から static に、綴り間違えるなよ。

address 192.168.1.206 <--- 以下追加
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.2

<--- ここまで

resolv.conf も修正

appliance@zabbix:/etc$ cat resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.2
nameserver 192.168.1.3
search intra
appliance@zabbix:/etc$

appliance@zabbix:~$ sudo ifdown eth0 && ifup eth0 <-- auchi!! あちゃーsudo忘れた
appliance@zabbix:~$ sudo ifdown eth0 && sudo ifup eth0 <-- 正しくはこっち do not forget "sudo"
appliance@zabbix:~$ ということでコンソールから(from console)
appliance@zabbix:~$ sudo ifup eth0
appliance@zabbix:~$ ping www.yahoo.co.jp
PING www.g.yahoo.co.jp (182.22.72.251) 56(84) bytes of data.
64 bytes from 182.22.72.251: icmp_seq=1 ttl=51 time=182 ms
^C
--- www.g.yahoo.co.jp ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 182.758/193.811/204.865/11.062 ms (<---- it seems fine !)
appliance@zabbix:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:16:3e:5e:7a:61
inet addr:192.168.1.206 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::216:3eff:fe5e:7a61/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:19487 errors:0 dropped:4 overruns:0 frame:0
TX packets:1337 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:903775 (903.7 KB) TX bytes:202727 (202.7 KB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1620 errors:0 dropped:0 overruns:0 frame:0
TX packets:1620 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:92110 (92.1 KB) TX bytes:92110 (92.1 KB)

appliance@zabbix:~$

どうやら、IP の固定と、dns の設定が出来たようです。SUSE なら yast で1分の作業ですが、ここまで3時間かかりました。やっぱり SUSE 利用者には ubuntu は手ごわい。

- NTP のインストール -

なんと ntp がないじゃないか、という事で NTP をインストール、JST 設定します。SUSE の yast ならインストールから設定まで 30 秒の作業ですが、ここでもまた30分間の死闘が始まります。

appliance@zabbix:/etc$ sudo apt-get install ntp

またパスワードだ

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libopts25
Suggested packages:
ntp-doc apparmor
The following NEW packages will be installed:
libopts25 ntp
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 474 kB of archives.
After this operation, 1,677 kB of additional disk space will be used.
Do you want to continue? [Y/n] y <---- yes する
Get:1 http://us.archive.ubuntu.com/ubuntu/ trusty/main libopts25 amd64 1:5.18-2ubuntu2 [55.3 kB]
Get:2 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main ntp amd64 1:4.2.6.p5+dfsg-3ubuntu2.14.04.8 [419 kB]

: 略

Processing triggers for ureadahead (0.100.0-16) ...
appliance@zabbix:/etc$

ntp の設定をし直します。

appliance@zabbix:/etc$ sudo vi ntp.conf <--- vi で編集して
appliance@zabbix:/etc$
appliance@zabbix:/etc$ cat ntp.conf

: 略

# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
#server 0.ubuntu.pool.ntp.org <---- Comment out
#server 1.ubuntu.pool.ntp.org <---- Comment out
#server 2.ubuntu.pool.ntp.org <---- Comment out
#server 3.ubuntu.pool.ntp.org <---- Comment out

# Use Ubuntu's ntp server as a fallback.
#server ntp.ubuntu.com <---- Comment out

server ntp1.intra <---- Add my NTP server(s)
server ntp2.intra <---- Add my NTP server(s)

: 略

appliance@zabbix:/etc$

-UTC から JST に(?)-

appliance@zabbix:/etc$ cat timezone
Etc/UTC <--- Default UTC
appliance@zabbix:/etc$ sudo vi timezone
appliance@zabbix:/etc$ cat timezone
#Etc/UTC
Asia/Tokyo <--- JST にしてみる。
appliance@zabbix:/etc$

リスタートしてみる
appliance@zabbix:/etc$ sudo /etc/init.d/ntp restart
* Stopping NTP server ntpd [ OK ]
* Starting NTP server ntpd [ OK ]
appliance@zabbix:/etc$

何じゃこれ?
appliance@zabbix:/etc$ date
Sun Mar 13 04:24:36 UTC 2016 <--- JST じゃないけど ....
appliance@zabbix:/etc$

なんか違う様です。SUSE の yast の様にタイムゾーンとNTPを一発で設定できないので、何か他のテキストを書き換えないといけない様ですね。

※補足 sudo dpkg-reconfigure --frontend noninteractive tzdata とやるようです。


- グラフが表示されない -

/etc/zabbix/web/zabbix.conf.php の末尾にゴミが入っている(なんとデフォルト)とグラフは表示されないようだ。

ちなみに

Database passwords are randomly generated during the installation process.
Root password is stored to /root/.my.cnf file, (嘘ですit is not required to input a password under the “root” account.

とあるように、実際には /etc/zabbix/web/zabbix.conf.php ファイルに PHP の root パスワードが隠されています。

appliance@zabbix:~/home/temp$ cat /etc/zabbix/web/zabbix.conf.php | grep PASSW
$DB['PASSWORD'] = 'vO1xUgwjzh';

※追記 /root/.my.conf はこれで確認できました。

appliance@zabbix:~$ sudo su
root@zabbix:/home/appliance# cd /root
root@zabbix:~# ls -al
total 28
drwx------ 3 root root 4096 Mar 14 03:21 .
drwxr-xr-x 22 root root 4096 Feb 28 20:07 ..
drwx------ 2 root root 4096 Feb 28 20:03 .aptitude
-rw------- 1 root root 46 Mar 14 03:21 .bash_history
-rw-r--r-- 1 root root 3106 Feb 20 2014 .bashrc
-rw-r--r-- 1 root root 31 Feb 28 20:01 .my.cnf
-rw-r--r-- 1 root root 140 Feb 20 2014 .profile
root@zabbix:~# cat .my.cnf
[client]
password="19qfvjQngR"
root@zabbix:~#

<--- 追記終わり

- 顛末 -

本当は、Zabbix2 のDBを移行したかったのですが、 MySQL のデータのエクスポートとインポートに失敗しました。失敗した事は隠しようがないので、dns の書き換えは諦めて、とりあえず 2.2 と 3.0 の平行運用して違いを楽しんでいます。ドキュメント通りに行かないのが怖いところです。データの移行はもう少し研究しないといけませんね。

中小規模の数十台の仮想化システムのデバイスであれば、 Zabbix アプライアンスはネットワーク管理に必要十分な「見える化効果」があり、実装も楽なのですが、Ubuntu では、とても客に「使ってくれ」とは口が裂けても言えません。という事で、私の顧客では無理しないで、当分は 2.2 環境でも問題なさそうです。

また、アプライアンス固有の問題なのかも知れませんが、ビール買いに行っている間に、データの取得ができなくなって、全く機能しなくなってしまいました。再起動してもだめ。

まだ不安定ですね。こういう状況があると、2.x 系と比べても、とても実用には堪えない。やっぱり次の安定板が欲しくなります。やはり「新しいからまともに動く」と言う事よりも「うまく使えているバージョンを徹底的に使い倒す」という姿勢が必要な様です。私の目的はイベントでのトリガーでもなく、アラートでもありません。一般的なトレンドが見えればいい。そういう単純な目標であれば、あえて Zabbix3 を選ぶ理由はありません。

確かに 2.x より 3.x の方がコスメティックな部分では「違い」があるのですが、せいぜいトラフィックをグラフ化する程度であれば、無理して 3.x を導入するつもりにはなれません。SUSE 版 Appliance が出ないのなら、せめて rpm 化するか、1 Click インストール用のパッケージか susestudio で仮想アプライアンスを作るしかないな、という無理な私の希望です。

Zabbix3 アプライアンスに関しては、随分否定的な評価となりました。


- Key Word-

あわせて読みたい

Zabbix SUSE openSUSE Zabbix Appliance 3.0 XEN KVM 使えない。だめだこりゃ。SUSE 版出せ。

[PR]
by islandcenter | 2016-03-14 11:32 | プライベートクラウド | Trackback | Comments(0)

He社の社長は、部下や上司、会社よりもヘッドハンターのいう事を信じているらしく、彼の業績と言えば後任もきまらないまま突然転職する人生である。

そういうHe社のサポートが非常に悪くなった。今まで、ハードウェアの故障ランプが付けば、すぐパーツ交換に応じてくれたのだが、先日の対応は酷かった。

ハードウェアの赤ランプの後、システムの動きがすごく怪しい、明らかにクロックもずれている。そこで問い合わせたら

- 専用のツールでログを送れ

と返事が来た。専用のツールを入れていないので、リモート管理ツールのログをテキストで送ったら。

- 専用のツールじゃないと正しいログが取れない

という。専用のツールはどこにあるのか、と聞くと

- じゃダウンロードしろ

といくつかの URL を送ってきた。URL にはダウンロードのエントリーはあるが、起動方法やログの取り方の詳細は説明がない。仕方がないので、ツールの名前で調べたら、ちゃんとマニュアルがあるじゃないか?何でマニュアルがあることを URL で明示しないのか、このサポート担当者はちゃんと休養を支払った従業員なのか、いい加減なアルバイトじゃあるまいし、と思った。でどのログが必要なのかの指示もないので問い合わせると

- これこれのログを送れ

と言う。明らかに幾つか間違ったファイル名の指定もある。

結局、マニュアルを見ながら、ツールをインストールして、システムを再起動(必要らしい)して、ツールを使ってログを送ったら

- 返事がない

まぁ、再起動で赤ランプが消えたので問題なくなったようなんだけど、リモート管理ツールで最初に取得したログがそのままログにあるだけ、つまり現象は変わらない。というかそれが赤ランプの原因だろうという事はわかるのだけれど、H社のサポート氏は、正規のツールで取ったログ以外は全く信用しないらしい。それどころか、問題がなければ、シカトする。

シカトされたため客はブチ切れ、直接セールスマンに文句を言って来たら、

- たぶん問題ないでしょう

という「メール」が返ってきた。

--
どんな商売でも、直接顧客と面するCEさん始めセールスは重荷があり、直接文句は言いにくい。特にCEさんにはH社を代表して「修理に来ている」ので一番文句を言いやすいのだけれど、ほとんどのCEさんはH社の請け負い業者さんであることが多い。セールスマン氏は簡単に担当が変わる。

--
ある、ソフトウェアベンダーN社の場合、何事かの Issue があり、報告し、対応し、フィックスできたら、必ずその後にテクニカルサポートに対する Survey が第三者の企業からアンケートが送られ、テクニカルサポートの技量や対応に関して言いにくいことも得点化して報告できるシステムがある。だからだろうけれど、N社のテクニカルサポートはいつも丁寧な対応をしている。

--
私は個人事業者として、顧客システム全般の運用、障害対応、プロアクティブな運用提案をしている。それは必至にやっていますよ。何しろ3か月毎に、費用を前受しているので、次の対応もまともじゃないといつ切られても文句は言えませんからね。

しかし、多くのIT事業者さんのサポートは3年前払いだったり、1年契約前払いだったりするため、必然的にサポートのレベルは低くなる。おまけにN社の様にテクニカルサポートのサーベイシステムがあれば、テクニカルサポートも必死にやってくれるのだが、H社のようにテクニカルサポートに対して、直接顧客評価が行えないような場合、サポートのモチベーションもひどく低くなるのだろう。


--
サーバーはどこのハードウェアベンダーの物がいいか、よく聞かれるのですが、機能、性能で大して違いがなければ、正直言ってどこのベンダーでも構わないと思います。しかし、24H365日で稼働させなければならないサーバーに関しては、性能、機能で差別化できない以上、人選びだと思います。あるいは、ベンダーそのものを選ぶという事になります。人の性能、機能が明らかによいハードベンダーの製品はトラブルが少ないでしょう。He社は、昔D×cを買収し、C×9 を買収し大きくなった会社だ。D×c のCEさん含め、さすがミニコン扱ってきただけあって、サポートは非常に優秀な人間が多い。特に早稲田にある営業所から来た人は確実にプロだった。それだけに、He社のサポートのレベルの低下は残念で仕方がない。


islandcenter.jp
[PR]
by islandcenter | 2016-02-22 13:44 | プライベートクラウド | Trackback | Comments(0)

先日、とある顧客でレガシーマイグレーションの話をしていたら、SIベンダーが提示した仮想サーバーのメモリが僅か16Gbだったのには驚きました。

一体どうしてこんなサイジングがでてくるのでしょう。

私だったら仮想ハイパーバイザーを動かすなら最低32Gバイト、できれば64Gbを推奨したいところです。仮想化で使うリソースは常に6割程度に控えるのが鉄則。32Gbもあれば、古いシステムを動かしながら、新規のシステムも並行して開発ができます。しかし16Gbでは、現行システムをP2Vインポートしてオシマイ。

なのですが、そこに顧客とSI事業者の大人の事情があるのですね。

例えば、製造部門で購入したハイパーバイザーマシンでは経理のシステムは動かしたくない、逆に人事システムが動くハードウェアで、製造用システムは動かしたくない。

本来ならば、システム部門が調整をして、できるだけ少ないリソース(サーバーハードウェア)で運用すればよいのですが、できないケースが多い。特に製造業のように「現場」の強い業種に多いようです。IT部門を強化しようにもそれなりのスキルがないし、経営判断も行われない。

サービス業でも、ITを使わざるを得ない業種ではそれほどでもないのでしょうが、「ITは職場のサービス」としか考えていない業種ではその傾向が強く、経理のシステム、人事のシステム、生産のシステム、流通のシステム、など、それぞれのシステムが「一つハイパーバイザーで仮想化」された1台ごとのサーバーで動いているケースも珍しいことではないのです。なぜなら、取得するための予算が別々であり、管理もベンダーも別々だからなのですね。

これが「顧客の大人の事情」なのです。

一方、SI業者にも「大人の事情」というものがあり、顧客の経理のシステムを一括してやってきたのだから、別なシステムが納入したハードウェアに載ることを嫌がるわけです。酷いところになると、利用者のアカウントの変更する行為ですら、保守の範囲外で有料作業だと言い切る事業者すらいます。

私なんかは鷹揚だから、どんどん弄ってくれ、変更してくれ、方法わかんなかったら問い合わせてくれという基本姿勢なんですが。サポート費用も先払いじゃないから、必死にやりますよ。そういう積極的なSIベンダーは少ない。年間、先払いで保守費用をもらっているから、お金をもらってサポートしている責任感が薄いのですね。

つまり、顧客にマニュアルを読ませない。客に知恵をつけさせないという事情です。こうして顧客の能力を糠漬け化して無能化する。

そうして顧客を塩漬けにして「SI事業者の言いなりになる顧客」を育てる事が彼らのミッションなわけですね。
だから、P2V案件で単一のハイパーバイザーに16Gbのメモリなどという非常識な提案をしてくる。彼らにとっては、現行のシステムが延命できれば、次の仕事でまた新しいハイエンドのサーバーを顧客に売りつける事が出来るわけです。

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

仮想システムを構築するにあたり、CIFS しか使えない NAS をバックアップ用に選定してきた SI 屋さんが居たので、CIFS と iSCSI のどちらが早いのか、試してみました。

テストに使う NAS は QNAP の Turbo NAS TS110
http://www.tekwind.co.jp/products/entry_6719.php
です。もう6年以上愛用して、カビが生えてもおかしく無い程に古いし, Marvell 800Mhz という低スペックなNASです。昨年、HDDがお亡くなりになったので、3Tb の HDD に交換しました。ファームウェアはこんなに古い機械でも、QNAP シリーズの最新バージョンが利用できます。

- iSCSI ターゲットの設定 -

QNAP の場合、iSCSI ターゲットはウィザード形式で簡単に作成できます。EXT4 ファイルシステム上で、オンラインでも簡単にサイズの拡大ができるので、 Windows の Storage Server のように NTFS の VHD 形式ではないので、そこそこ性能が出ますが、いかんせん古さと遅さは否めません。

QNAP の iSCSI ターゲットの設定は、偉そうな Linux 系サイトに書いてある程、面倒なことはありません。ストレージマネージャから iSCSI タブにあるウィザードに従って iSCSI ターゲット名に任意の名前を付けると IQN にその文字列が追加されるだけです。わざわざ vi エディタに「正確に」綴りを間違えずに設定する必要もありません。ここでは Chap 認証は付けませんでした。
a0056607_16405779.jpg


機械は古いのですが、逆に言うと、「古くて遅い」ため、サーバーとNASとの接続プロトコルの性能差が、如実に現れる事になります。

Windows10 の Microsoft 製 iSCSI イニシエータは「コントロールパネル」>「システムとセキュリティ」>「管理ツール」の中にあるので、ここで、設定済の iSCSI 「ターゲットを」 「検索」して選んで「接続」します。Chap 認証を付けておいた場合はターゲットで設定したパスワードが必要でしょう。
a0056607_16412132.jpg


新規に作成して、接続した後は、フォーマットされていないため、ディスクマネージャからフォーマットして使います。ちなみに、フォーマットして利用した iSCSI ターゲットの仮想ディスクは、他のマシンでマウントすることもできます。つまりHDDを取り外して、他のPCに繋げる事と同じことですね。


- CIFS の性能を見てみる -

一番イラつくのは、巨大なファイルの転送でしょう。という事で 3G 程ある SUSE Linux のインストール用DVDの ISO ファイルを CIFS でコピーしてみます。
a0056607_16414334.jpg


3分11秒かかりました。1Gビットネットワークで 12~3% 程度の帯域を使って通信しています。明らかに古いNASの性能が足を引っ張っているようです。

スループットは 150Mbps 程度で全体の最大15%程度でしょうか。
a0056607_16415832.jpg


次に iSCSI マウントしたディスクにコピーしてみます。
a0056607_16422170.jpg


初速は出るのですが、その後は、TS-110 の性能がモロに出ます。それでも 20 MB/s から 25 MB/s 程度は出ています。
a0056607_16423835.jpg


2分25秒でした。 大体20%程度のスループットです。

--
数字に弱い私の脳みそですが、 iSCSI は CIFS より 1.5倍くらい早い、という事が言えます。


Zabbix で QNAP TS-110 の I/O を見てみると、前半の CIFS アクセスより後半の iSCSI アクセスの山が高い事がよくわかります。
a0056607_16425860.jpg


CIFS を使ったリモートディスクのマウントは、他のPCからもアクセスができる、というメリットがありますが、iSCSI は単一のホストからのアクセスしかできません。 -- もっとも、ターゲットストレージを複数作って複数のサーバーから異なるデータ領域にアクセスはできますが -- バックアップ用途や、サーバーの増設ストレージとして考えれば、良い選択であると言えます。

こうした性能のわずかな違いが、仮想化システムのハイエンドな領域で違いとなって出てきます。なお QNAP でも openiSCSI でも Windows Storage Server でも取った領域そのままのサイズのでかいファイルが作成されるようです。国産 NAS の「ハイエンド」と称する「LANxxxx」などのモデルでは Windows Storage Server を使って NTFS フォーマットしています。Windows Storage Server は見た目 Windows サーバーそのものなのですが、ところどころちゃんとデチューンされているようで、SOHO向けが限度で、あまり性能が出ないだろうと思います。Windows Storage Server じゃなくて、ちゃんとした Windows Server 買えよな、という事なのですね。このあたりは独自OSをNASとしてチューニングした QNAP や Synology, asuster などの iSCSI 機能付きの NAS を中規模ネットワークのミドルレンジの NAS として利用したほうが良いと思います。

仮想環境でのネットワークアタッチストレージ(NAS)は、本回線(構内LAN)とは切り離し、ストレージ専用のネットワークとして独立して運用させるのが基本です。サーバーとNAS間で凄まじい通信が発生します。サーバーNICが2ポート以上のものが推奨されます。

islandcenter.jp
[PR]
by islandcenter | 2016-02-08 16:43 | プライベートクラウド | Trackback | Comments(0)

先日、知り合いの会社の社長から「マイナンバーに対応した情報漏洩対策を考えろと言われてこまっている」という話を頂きました。

私の答えはこうです。

「情報漏洩に完全な対策はない。漏洩した時のメディアへの言い訳をまず考えろ」

と答えました。全てそこから情報漏洩対策は始まるのです。

情報漏えい対策で一番重要なのは

「どういった謝罪を行うか」

という事なのです。

アムトラック事故の際の謝罪の仕方は、 「現代における最良の謝罪の1つ」と言われているそうです。


1:実際に『すみません』などの謝罪の言葉を使用する
2:混乱・失敗を認める(「アムラックが全面的に責任をとり」の部分)
3:どのように事態に対処するか解決策を伝える
4:他人に押しつけたり、非難せずに何が起こったのか説明する
5:事態の改善を約束する
6:自分がどれほど人を傷つけたか・不快にさせたかを理解していることを知らせる
7:「2番」とは別に、「私は間違っていました」など、間違いを認める言葉を使用して容赦を求める
8:アムトラックの謝罪文を読んでどこが上記の7つに当てはまっているか、2回以上確認する

という事で、謝罪のファーストインプレッションから受け止められるネガティブな印象をまず低減させます。

一般的なインシデントと違い、情報漏えいは、自分たち自身が一次被害者であるにも関わらず、二次被害者が存在し、一番迷惑を被るのが彼ら二次被害者なのです。一次被害者にとっては痛くも痒くもない。しかし、問題を起こした当事者であるという認識を持って対応すべき事なのです。

情報漏えいは気が付かない

それでは、情報漏えいは、なぜ Issue として気が付くのでしょう。

スリならば、財布がないことに気が付いて「ヤラレタ」と思うわけですが、情報漏えいは財布の中身をコピーするだけの行為であり、悪意のある人間にとっても、単なるコピーに過ぎない些細な価値しかありません。被害者は気が付きません。いくら盗まれたかも気が付きません。実際、某教育産業での情報漏えいも、結果としては盗んだ情報が名簿屋にとっては数十万円にしかならない価値しかなかったようです。

しかし、見知らぬ教育機関からDMを受け取ったヒトは非常に不愉快な思いをしたでしょう。

情報漏えいが、内部監査によって発覚する可能性はまず9割はありえません。

たとえ、監査に必要なソフトウェアが導入されていても、監査する量があまりに膨大で、その中から「あってはいけない Issue」 を発見する、というのは、コンサート会場の手荷物検査より退屈で、ブツが見つかるものではないのです。そこに担当者を張り付けるというのは、非効率そのものです。

特権ユーザだけの行動管理ができるソフトウェアを導入したい、というリクエストがありましたが、私は

「無駄だから止めておいたほうがいい」

と思いました。

特権ユーザは、自分が監視されていることも知っているし、どこにログがあって、どこに穴があるのかをすべて知っています。そのため、特権管理者を別に監視するための人を更に雇う必要があるのです。果たしてそれだけの価値があるのでしょうか。

銀行の様な「ナマの現金」を扱っている業種ならともかくも、一般的な事務、情報システムでは無駄な投資になるだけでしょう。

そこで、一般的には情報漏えいの Issue は、外部からの告発や問い合わせ、中立機関からの通報によるものなのです。例の教育産業での情報漏えいも、漏れた個人情報が関係ない団体からのDMが増えた事により、問い合わせがあったからなのですね。

想定される謝罪から、逆想定できること

それは「セキュリティ根性論」です。

数十個あるパスワードを全部、メモにも書かず、使いまわしもせず、月に一度変える。

これでも情報漏えいがあれば「根性がないユーザが悪い」という事になります。すでにパスワード認証というものは崩壊しているのです。

今の時代、セキュリティは根性がなければ守る事はできません。根性論ベースで語るシステムでは容易に破られるのですね。もちろん、「根性論では片づけない」ためのシステムソフトウェアもあるにはあるのですが、それはあくまでもSIベンダーの商売文句に過ぎないのです。

社保庁事件は「どこが杜撰なのか」

社保庁事件は、厳重に管理されているマスターから、「抽出」されたデータが、パスワードもなしに放置された事が「杜撰な管理と運用」と言われています。

システムで守れるのは「マスターデータ」までで、そこから取り出されたデータをどのように業務にユーザが利用するかは「ユーザ根性論」で語られるわけです。

マスターデータであれば、誰が開いて、抽出した内容をダウンロードしたかまではシステムで追跡できるでしょう。

しかし、この抽出されたデータがどのように利用され、共有サーバーだとかNASだとかローカルドライブに保管されたかなんて追跡のしようがありません。ファイルをメモリに書き出した事を記録するソフトウェアがあっても、ファイル名しか記録がないため、抽出されたデータがどのようなファイル内容なのかをチェックすることもできないのです。

ファイルの中に「機密」と書かれたキーワードがあれば、印刷やメール添付しようとすると自動検出して警告を出せる、という製品もありますが、こんなものは、売り上げに走るSI業者がヨロコンで無知な顧客に売り込もうとするには非常によいプロダクトです。

だけどファイルそのものにパスワードロックがかかっていれば、スキャンもできません。パスワードロックがかかっている添付ファイルをスキャンできない、アンチウィルスソフトウェアと全く逆の意味で、

意味ねぇじゃん。

という事になります。つまり、ここでもセキュリティ根性論がものを言うのですね。

セキュリティ根性論

じゃ、セキュリティ根性論とは何かと言えば、従業員、職員のモラルに尽きるという事です。モラルが下がっている職場では、明らかにセキュリティ根性も下がります。よく、海外で理不尽な方法で馘首されたネットワーク管理者がデータを持ち出したとか、管理者パスワードを全部変えて退職したとかの事件があります。まさに職場のモラルが下がると、セキュリティ根性もモラルも下がります。


自分が勤めている会社がヤバそうな場合、社内備品を勝手に自宅に持ち帰る、という話はよく聞きますが、全く同じ状況が発生するわけです。

そこで、セキュリティ製品、行動管理製品を必要とする企業の半分は「モラルが崩壊しているヤバい取引先」じゃないか? と勘ぐってしまいます。銀行の融資屋さん的に言うと「要注意取引先」に分類されます。もちろんすべてじゃないのですけどね。

逆に

「ウチはちゃんと従業員教育をして根性入れ直ししているよ」

という組織もあります。あるIT系のライターさんが、とある企業の年に一度は必ず従業員が受けなければならない「講習会」に参加して「唖然」としたことがあったそうです。

なんと、参加者は「講習会中に全員居眠り」、テキストも古く、担当者は総務のコンプライアンス担当者。内容は去年と同じ物の使いまわしだったというのです。これで「セキュリティ根性の入れ直し」なんてのがどれほど無意味なものなのか、がよく分かるかもしれません。少なくとも外部の講師を呼んで、毎年新鮮な内容で行うべきです。給料で動くプロパーではなく、報酬で動くプロを雇うべきなのです。

言い訳から逆算するセキュリティ対策

情報漏えいは、現代の技術では中々防げない根性論なわけですが、それでもシステム的に最低限の対策を施すことにより

「今回は世間をお騒がせしました、該当する皆さまに深くお詫び申し上げます」

と言った後、「杜撰さ」を感じさせない対策は幾つかあるのでしょう。

手軽なのが、ノートPCのファームウェアのパスワードロックや、USB記憶媒体への書き込み禁止。あるいは、外部媒体へ書き出したデータの暗号化の義務付けです。これはシステムで管理できます。

また、データコピーが実質できないシンクライアントシステムも有効です。

たまに金融機関で「財務情報が入ったPCを電車で紛失」という事故がニュースになります。しかし、ほとんどのケースでは「世間をお騒がせしました」レベルの謝罪で終わっていて、後追い発表もありませんし、メディアの追及もありません。紛失したら、データにアクセスできなくなる、そういうシステムが組み込まれているので、組織そのものが致命的なダメージを受けるような Issue にはならないのです。

つまり「杜撰な管理」だった、というイメージを残しません。

更にお金をかければ、操作記録管理システムを導入することですが、これは、非常にコストがかかります。コストだけではなく、情報漏えいそのものを検出できません。ほとんど事故の後の後追い調査に有効であるだけです。情報漏えい対策というより、金融機関などのコンプライアンス対策として考えた方が良いでしょう。

外部からのアタック対策

多くの情報漏えい事故は、内部からの漏えいです。まともなセキュリティを施している限り、外部から侵入するというのは困難です。

ただ、そうとも言えないのが社保庁を狙ったピンポイント攻撃です。

ここでも重要なのは、セキュリティ根性論です。マルウェア付き添付ファイル、一見まともに見えるメールとリンク先。こういったアナを敵は突いてくるのです。

一度、自称「システム管理のプロ」が顧客先に高い給料で転職してきたことがあります。

特権ユーザでログインしたまま、彼はメールの添付ファイルだとか、ショートカットをダブルクリックして開きまくっているのを見て、私は「口ポカンで目がテン」になりましたね。

「あ、こいつど素人だな」

典型的な「Windows しか知らないシステム管理者」だったのです。サーバーの特権ユーザで、こういった無知な操作をしたら、どういう事故が起こるか、まともな技術者だったら当たり前の配慮が全くない。

まとめ

情報漏えいの基本的な対策とは

1) まず Issue に対する謝罪の内容を考えよ。
2) 情報漏えいに万策はない。常にあり得る危機だという危機感を忘れるな
3) セキュリティは根性論、社員、職員のモラル向上に力を注げ。
4) 謝罪に対してどのような対策が必要なのか逆算して考えよ。
5) 謝罪内容を逆算して実施できる機能から、まず実装せよ。

という事になります。

お問い合わせは
まで





[PR]
by islandcenter | 2015-12-03 04:23 | プライベートクラウド | Trackback | Comments(0)

それは NEC がクラウド市場のプラットフォームの敗北を意味している。

国内x86サーバー市場、2014年のシェア1位はNEC

IDC Japan の調査によると 2014 年の x86 系サーバーの出荷額、台数ともに NEC が首位だそうです。2位は富士通、3位はHP。一方、

製品カテゴリー別の分析では、1ソケットのタワー型サーバーの出荷台数シェアはNECが1位を占めているが、2ソケットのラックマウント型サーバーとブレードサーバーではHPが1位となる。

そこで NEC の製品ラインアップを見てみたところ、Celeron から Pentium のサーバーからラインアップが揃い、ハイエンドのラインアップが少ない。

一方、私は HP か Dell しかやらないので、おおよそ理解しますが、これら外資系メーカーはローエンドより、ミッドレンジ、ハイエンドサーバーが主力なのです。

NECの主力である「1ソケットタワーサーバー」とは、間違えなく小規模の事業所の事務所内に設置できる、小型で静穏性の高いサーバーでしょう。

言い換えると、これらの NEC の主力サーバーはリソースの集約化、高密度化には向きません。Celeron や、Pentium 、このシリーズの上級モデルでも XEON E3 シリーズが主力です。このクラスでは、到底プライベートクラウドを実現するにはチト物足りない。

もっともその程度のジョブのために「サーバーが必要だ」という事になれば、AWSなどのパブリッククラウドの利用で十分じゃないか、という事になります。これらの、大手クラウド事業者が NEC のハードウェアを使うわけじゃないでしょう。ほとんどが ODM (OEM の製造委託先製品)ブランドのものですね。

この絵で見えてくるものが、「安いNECブランドの製品を購入する中小事業者と事業者のIT部門を牛耳るSIベンダー」という構図です。

従業員30人の零細事業者の給与、売り上げ、経費管理などにはもってこいのスペックなのですが、SI事業者からすれば手離れはいい。何しろ、年間サポート費用をパッケージベンダーに支払わせれば、サポート費用は掛からない。

「ワンストップソリューションを提供」を謳っても、実質、ハードベンダーとソフトベンダーのサポートに丸投げできるわけだし、ご自慢のワンストップソリューションで顧客から、年間サポート費用を取ることができる。

つまりほとんどやっている事もないのに、自動的にお金が入るシステムです。しかも、その費用は台数毎に入ってくる。

こういった顧客に、プライベートクラウドの仮想化を提案しても、入ってくるサポート料金は1台だけです。何のことはない。これらの中小規模のSI事業者は、クラウドや仮想化技術には全く無知なだけだという事なのですね。

今の時代、小規模の事務所織システムであれば、Celeron のサーバーでも十分なオーバースペックです。それでも1台ごとにUPSだのの付帯設備をつけてしまえば、充分なヘビー級のトータルシステムとなってしまいます。

彼らが恐れているのは、パブリッククラウドへと顧客が移行する事なのですね。

残念ながら、小規模事業者には、そういう知恵がないため、SI事業者の「お勧め」をそのまま受け入れてしまうという構図が見えてきます。少なくとも NEC という「サーバーベンダー」はオンプレミスでは勝利しているが、クラウドでは勝ち目がない、という事がこの記事から見えてきます。

小規模プライベートクラウドなら



[PR]
by islandcenter | 2015-10-07 10:56 | プライベートクラウド | Trackback | Comments(0)

サポート切れが迫りつつある 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)