計画停電対策(2) --- データセンターを利用する

計画停電対策の王道は、やはり予備電源設備を完備したデータセンターの利用となる。

下図は今回、客先へ提出したデータセンター利用提案書の一部(改変)である。　既にインターネットVPNを構築済であるため、今まで本社で運用していたサーバ群をデータセンターに移し、データセンターを中心としたVPNネットワークを再構築する。　今まで支社からアクセスしていた Terminal Server　だけでは 本社からのアクセスを捌き切れないので、Terminal Server をもう一台増設する。

これで、データセンター内のサーバは停電の心配がなくなるが、計画停電区域にある本社、支社等は停電時、当然ながら、センターのサーバへのアクセスはできない。　そこで、前回書いたように、本社、支社ではONUやルータといった必要最低限の通信機器はUPSに接続するとともに、必要最低限のノートPCを用意し、停電中もセンターのサーバへアクセスできるようにする。

注：

支社のクライアントPC 上の FileMaker からデータセンターのFileMaker Server にアクセスして処理を行うと、インターネットを介して多量のトラフィックが発生するため処理は遅くなる。　Terminal Server (Terminal Service) を利用すると、処理は Terminal Server 上で実行され、処理の結果たる画面イメージあるいは印刷イメージのみが支店のクライアントPCあるいはプリンタに 送付されるため、高速に処理を実行することが可能。　また、データ書出は支社のPCやストレージに行うこともできる。

計画停電対策(1) --- ノートPCサーバとHyper-Vで乗り切る

震災発生が3/11。　計画停電（輪番停電）なるものがその後発生し、その間、サーバを停止させなければならないと判明したのが3/13(日)。　当事務所がある調布が第2グループに含まれており、15日に計画停電があると判ったのが14日夜。

当社では客先のデータベースを運用している関係上、至急、以下のような対策を検討した。

1.発電機導入

探してみるとヤマハのEF1600iS（13万円～、1.6kVA、燃料はガソリン）なるものが良いらしい。ルータ、ONU、最小限のサーバなら、停電時も運用できそうだ。　さっそく販売店に問い合わせてみると、「政府・メーカーから在庫分はすべえて被災地に送るようにと指示されていて、当面入荷の見込みはない」とのこと。　あっさり頓挫。

2.客先へのサーバ移動

客先の所在地が計画停電の範囲外にある場合に検討の余地がある。　サーバを新設する場合はすべて一から再構築になり、DNSやSSLも再申請・再設定になる可能性あり。また、夏場は千代田、港、中央以外の東京23区も停電の対象地域となるらしいので、この場合は解決策にはならない。

3.データセンター

データセンターであれば電源は保障される筈なので、上記2前段の問題は残るものの、停電対策には一番良い解決策と思われる。　が、コストが高い。

4.ノートPCサーバへの移行とUPS増設

現サーバ環境をノートPC（Windows Server 2008 R2 + Hyper-V）に移行し、停電時は増設したUPS で乗り切る。　結局、これを採用した。　開発用のノートPC（CORE I5/8GB）に Windows 2008 と Hyper-V をインストールしてあったので、ここに必要最低限の現サーバ（複数）の環境を移行。Hyper-Vのお陰で1台の物理マシンに複数のサーバOSをインストールして運用できる。　このノートPCの内蔵バッテリは最大6時間持つ仕様だが、テストしてみると3時間弱で切れてしまう。そこで、UPS（APC Smart-UPS 1500）も2台増設した。

1台はノートPC専用、もう1台はONUとルータに接続。この構成で3時間程度の停電であればUPSバッテリも余裕をもって乗り切ることができる。　また、停電後2時間程度でバッテリは満タン状態に戻るので、1日6時間停電がある場合でも、停電と停電の間に3時間の余裕があればどうにかなりそうである。

かくして、上記4の方法で行くことを14日午前に決定、14日午後一でUPSを発注、サーバ環境をノートPCサーバに移行作業開始、17日午後より運用を開始した。　Smart 1500が発注から中2日で到着したのは幸運だった。（その後、Webのショップを覗いてみたが、軒並み売り切れになっていた。3/30現在、在庫があるショップも僅かにあるが、14日時点に比べると、割高になっている。）

以上　

『売上猫くん on MySQL』開発日記 - 番外22 -SQL SECURITY の DEFINER/INVOKER指定

ようやく再リリース！、と思ったのもつかの間。　MySQLデータベース neko のインストール後、テーブル（実際はビュー）にアクセスできない現象が発生。　CREATE VIEW するときの SQL SECURITY [DEFINER | INVOKER]に問題があることがわかったので、以下、そのメモ。

（ということで、1/25現在、ダウンロード停止中 ）
（1/25 18:00～、ダウンロード再開）

DEFINER/INVOKER

DEFINER指定：
Stored/Viewに対して実行アカウントがExecute/Selectできる権限さえあれば、Stored/Viewの内容はDEFINERの権限で実行される→Stored/Viewが実行できない可能性は少ない（DEFINERがroot@localhost なら、ほぼ確実に実行できる筈。）

INVOKER指定：
Stored/Viewに対してExecute/Selectできる権限があっても、Stored/Viewの内容は実行アカウントの権限に基づき実行される→Stored/Viewが実行できない可能性は、DEFINER指定に比し大きい。

例：
CREATE DEFINER = 'admin'@'localhost' PROCEDURE p1()
SQL SECURITY DEFINER (or INVOKER)
BEGIN
UPDATE t1 SET counter = counter + 1;
END;

DEFINER指定：実行アカウントに Execute権限さえあれば、t1テーブルのUPDATE権限は不要（ 'admin'@'localhost'の権限で実行される）

INVOKER指定：INVOKER（実行者） は　Execute権限とUPDATE権限の両方必要。　

尚、下記サイトでは、セキュリティ上、INVOKER の使用を推奨している。

参考サイト
http://dev.mysql.com/doc/refman/5.0/en/stored-programs-security.html

（対応の日本語頁は無く、DEFINER | INVOKERに関する日本語サイトも少なし）

以上

（土屋）

関連リンク：『売上猫くん on MySQL』開発日記の記事一覧