ラベル 覚書 の投稿を表示しています。 すべての投稿を表示
ラベル 覚書 の投稿を表示しています。 すべての投稿を表示

2013年5月12日日曜日

websphere 起動方法

ミドルウェアの起動順序・停止順序は、ミドルウェア間やプロセス間の依存関係に基づいて決定します。連携している一連のミ


ドルウェアの起動作業は、バックエンド・システムから実施することが一般的です。ミドルウェアの停止作業はその逆となり、

フロントエンド・システムから実施することが一般的です。

例えば、WASからDB2やWebSphere MQを参照している場合、起動順序はDB2やWebSphere MQを起動した上でIHSとWASを起動

する流れにし、停止順序はIHSとWASを停止した上でDB2やWebSphere MQを停止する流れにします。

上記ではIHSとWASを一括りにしましたが、IHS、WASは以下のような複数のプロセスで構成されており、これらのプロセスの起

動順序・停止順序についても考慮が必要になります。

• IHSプロセス

• (IHS管理サーバー・プロセス)

• アプリケーション・サーバー・プロセス

• デプロイメント・マネージャー・プロセス

• ノード・エージェント・プロセス   IHS、WASを構成するプロセスの起動は、管理する側から管理される側という順序で実施することが一般的です。停止はその逆

となり、管理される側から管理する側という順序で実施することが一般的です。

IHS、WASの起動   IHSプロセス:

起動コマンド

UNIX/Linux環境:/bin/apachectl start

Windows環境:\bin\httpd.exe -k start -n

停止コマンド

UNIX/Linux環境:/bin/apachectl stop

Windows環境:\bin\httpd.exe -k stop -n

IHS管理サーバーは、IHSをデプロイメント・マネージャーの管理対象として統合する構成において、IHSをノード・エージェント経由で管理しない場合に必要になります。主にIHSとWASを共存させない構成で使用します。

IHS管理サーバー・プロセスの起動・停止には、

UNIX/Linux環境ではadminctlコマンド、
Windows環境ではhttpd.exeコマンド(Windowsサービス)

を使用します。

IHS管理サーバー・プロセス:

起動コマンド

UNIX/Linux環境:/bin/adminctl start

Windows環境:\bin\httpd.exe -k start -n

停止コマンド

UNIX/Linux環境:/bin/adminctl stop

Windows環境:\bin\httpd.exe -k stop -n

WASプロセスの起動・停止

WASの主なプロセスには、デプロイメント・マネージャー・プロセス、ノード・エージェント・プロセス、アプリケーション・サーバー・プロセスがあります。各プロセスの起動・停止にはWASコマンド行ツールを使用します。なお、管理セキュリティー機能を有効化している環境では、各プロセスを停止する際に認証のための管理ユーザー名とパスワードが必要になります。

デプロイメント・マネージャー・プロセスとノード・エージェント・プロセスが起動している状態であれば、WAS管理コンソールからアプリケーション・サーバー・プロセスの起動・停止を行うことも可能です。

デプロイメント・マネージャー・プロセス:

起動コマンド

UNIX/Linux環境:/bin/startManager.sh

Windows環境:\bin\startManager.bat

停止コマンド

UNIX/Linux環境:/bin/stopManager.sh [ -user <管理ユーザー名> -password <パスワード> ]

Windows環境:\bin\stopManager.bat [ -user <管理ユーザー名> -password <パスワード> ]

ノード・エージェント・プロセス:


起動コマンド

UNIX/Linux環境:/bin/startNode.sh

Windows環境:\bin\startNode.bat

停止コマンド

UNIX/Linux環境:/bin/stopNode.sh [ -user <管理ユーザー名> -password <パスワード> ]

Windows環境:\bin\stopNode.bat [ -user <管理ユーザー名> -password <パスワード> ]

アプリケーション・サーバー・プロセス:

起動コマンド

UNIX/Linux環境:/bin/startServer.sh <サーバー名>

Windows環境:\bin\startServer.bat <サーバー名>

停止コマンド

UNIX/Linux環境:/bin/stopServer.sh <サーバー名> [ -user <管理ユーザー名> -password <パスワード> ]

Windows環境:\bin\stopServer.bat <サーバー名> [ -user <管理ユーザー名> -password <パスワード> ]

Windows環境では、Windowsサービスを使用してデプロイメント・マネージャー・プロセスの起動・停止、ノード・エージェント・プロセスの起動・停止を行うように設定することも可能です。Windowsサービスへの登録にはWASService.exeコマンドを使用します。

2012年5月22日火曜日

ストレージ技術 覚書3

◆サーバー仮想化とストレージ仮想化

■サーバ仮想化
 サーバー仮想化では、1台の物理サーバー上に複数の仮想サーバーを動作させます。そのため、物理サーバーを統合し、使用率を向上させ電力やサーバー・スペースにかかる費用の削減なども可能です。仮想サーバーは、物理サーバーに比べ、圧倒的に迅速にユーザーに提供できるだけでなく、逆にサーバー・リソースが不要となった場合でも、容易に「廃棄」することが可能で、プロジェクトの効率化を実現します。

 さらに、サーバー仮想化環境では、物理サーバーの負荷変動や要件に応じて、指定したタイミングで仮想サーバーを物理サーバー上で移動させることが可能です。これは、物理環境で常につきまとってきた互換性に要する複雑さを軽減させる第一歩と言えます。

 ストレージ仮想化と別々にとらえられがちなサーバー仮想化技術ですが、サーバー仮想化においては、SAN(Storage Area Network)すなわちストレージ階層において、集約された高速大容量のI/Oのリード/ライトや複数サーバーのイメージの移動が発生します。そのため、パフォーマンスや容量増加の適切な対応、可用性向上、さらに効率的かつ最適化されたパス管理などを実現するストレージ仮想化がサーバー仮想化を支える重要な技術となります。

■ストレージ仮想化
 ストレージ仮想化によって、サーバーに影響を与えない、複数のディスク階層間、異機種混在環境を含む、ストレージ筐体(きょうたい)間での無停止のデータ移行が実現されます。後ほど詳しく触れますが、「今すぐ活用できるストレージ仮想化技術」としても仮想プロビジョニングや仮想LUNなどの先進のストレージ仮想化テクノロジーがEMCのSymmetrixやCLARiXだけでなく、各社の高性能なSANストレージ製品で提供されています。ストレージ仮想化の本質とは、複数のストレージ階層を単一の管理基盤の下で統合するものです。これによって、すべてのストレージ階層を容易かつ迅速に構成、管理し、環境を劇的に単純化し管理にかかるすべての手間とコストを削減します。

◆ストレージを効率良く運用する仮想プロビジョニング
(1)仮想プロビジョニング
 仮想プロビジョニングでは、サーバー、アプリケーションに対して、実装している以上の容量を仮想的に割り当て、プール化された共通プールが実際に使用している分だけが物理的な割り当てとなるため、利用率を大幅に向上できます。


 通常、新規のアプリケーション用などにストレージをプロビジョニングする場合、管理者は現時点で必要な容量ではなく、将来必要となる容量を考慮してプロビジョニングを行います。その際、ストレージ容量がなくなり、アプリケーションやビジネスのプロセスが停止してしまうリスクを軽減するため、また近い将来、再度プロビジョニングしなければならない頻度を減らすために、管理者ははじめから実際に必要以上の物理ストレージを割り当てしまいがちです。それにより、調達や運用の費用の悪化をもたします。

 これらの問題を解決するのが仮想プロビジョニングです。これは「シン・プロビジョニング」ともよばれ、必要な場合にのみ共通プールから物理ストレージを使用して、ホストに自動的に割り当てます。仮想プロビジョニングによって、ストレージの有効活用だけでなく、従来のストレージ・プロビジョニングにかかっていた手間や時間を劇的に削減することが可能です。

(2)仮想LUN
無停止でデータを移行する仮想LUN


 仮想LUN(Logical Unit Number)は、単一のストレージ・システム内において、移行元となるLUNから同じ、もしくはより大きいサイズの移行先LUNに対して、アプリケーションの停止を伴わないデータ移行を実現するテクノロジーです。仮想LUNは下記の価値をユーザーにもたらします。
・ストレージ筐体内での情報ライフサイクル管理(ILM)の実現
・パフォーマンスの向上
・無停止のシステム構成変更

 仮想LUNにより、効果的な情報ライフサイクル管理戦略の構築と実行が可能です。情報ライフサイクル管理とは、あらかじめ定義したポリシーに従ってアクセス頻度の少なくなったデータを、高速なファイバ・チャネル・ドライブからより低速で大容量、安価なSATAドライブなどに自動移動させる技術です。これにより、ハードウエア・リソースをより効率的に使用し投資対効果の最大化を図ることが可能です。

 さらに、仮想LUNは過負荷のディスクから負荷の低いディスクにデータを移行させることで、パフォーマンス向上を実現します。従来、多くの通常の移行技術では、LUNの特性の変更は許されません。一方、仮想LUNは、異なる特性のLUNへ移行することが可能で、パフォーマンス向上を実現します。また、仮想LUNによって、ディスク・アレイ・エンクロージャー間を無停止でデータ移動させることが可能です。そのため、ホストにかかるオーバー・ヘッドを削減し、システムを停止しないサービス・レベルを維持した構成変更を実現します。

(3)完全に自動化されたストレージ階層化 FAST(Fully Automated Storage Tiering)
FASTによる完全に自動化されたストレージ階層化

 仮想LUN機能をベースにEMC独自のテクノロジーとして提供しているのが、FAST(ファスト:Fully Automated Storage Tiering)です。FASTではストレージ・インフラストラクチャの管理を劇的に容易にし、ストレージにかかる全体的なコストが大幅に削減されます。

 またFASTは、変化するパフォーマンス要件に応じてストレージ階層間の動的なデータ配置や移行を自動化することで、適切なデータを適切なストレージ階層に適切なタイミングでの配置が可能です。コストとパフォーマンスに関する要件を最適化して、ストレージ階層化によるメリットを最大化します。

 特にEMCのハイエンド仮想ストレージSymmetrix V-Maxにおいては、価格性能比の観点から分類される、ストレージ階層に関するすべての選択肢を同一筐体で提供します。一例としては、以下の内容になります。

・「階層0」ストレージとして
最小限の遅延と高いパフォーマンスが求められるトランザクションへの対応としてフラッシュ・ドライブ。
・「階層1」として
パフォーマンス重視のアプリケーションへの対応として、15,000回転のファイバ・チャネル・ドライブ。
・「階層2」として
大量のデータの一括処理やバックアップなど比較的低いパフォーマンスでも十分で、コスト要件を重視する大容量SATAドライブなど。

 FASTでは、システムにかかる負荷は能動的に監視されます。これは使用頻度の高いデータはより高パフォーマンスのフラッシュ・ドライブへ自動的に移動され、逆に使用頻度の低いデータは、より大容量のSATAドライブに自動的に移動するという具合です。FASTはこれらの処理を動的かつサーバーを停止させず、ビジネス継続性や可用性に影響を与えずに実行します。

 また今日、フラッシュ・ドライブは、ストレージ業界に大きな変革をもたらしていますが、FASTによって、より多くのユーザーがフラッシュ・ドライブのメリットを享受できるため、導入の加速が期待されます。

(4)仮想環境でのパス制御
(5)物理と仮想環境のエンド・ツー・エンド管理
仮想環境でのパス制御、物理と仮想環境のエンド・ツー・エンド管理

 従来の仮想サーバー環境における複雑で限定的なフェイル・オーバーとロード・バランシング・ソリューションに対して大きな優位性を提供するのがEMC PowerPath/VEテクノロジーです。例えば、従来のパス制御に関するソリューションは、VMware VMotionなどの仮想マシン(VM)の移動に伴う、ストレージ・インターフェースの飽和による予期しないパフォーマンス劣化を避けることができませんでした。これに対し、高度なロード・バランシングとフェイル・オーバー機能を持つPowerPath/VEでは、仮想環境において常に高いパフォーマンス・レベルを維持します。PowerPath/VEはVMwareおよびHyper-Vの両方をサポートします。

 物理と仮想環境を包含するエンド・ツー・エンドのリソース・マッピングと管理は、仮想化を支える重要な技術です。EMCでは、物理と仮想環境における統合管理を実現するためのストレージ管理ソリューションを提供しています。そのためVMware vCenterと連携し、仮想マシンを特定し、適切なストレージ・リソースを割り当てるなどが可能です。

 今後、ますます現実化される仮想データセンターの進展においては、高度に統合されたサーバーやアプリケーションが、ペタ・バイト級の大容量ストレージを高パフォーマンス、高可用性のもとでアクセスする環境の構築、効率的な運用が必要です。

 そしてそれを支えるストレージ仮想化は、サーバー仮想化と両輪をなす重要なテクノロジーなのです。

2012年5月21日月曜日

ストレージ技術 覚書2

◆アクセス頻度によってストレージを使い分ける「ILM」

 ストレージ仮想化を使った応用的な機能として、ILM(Information Lifecycle Management)がある。ILMは、情報(データ)が生成され、利用され、最終的に破棄されるまでのライフサイクルを、主にアクセス頻度に注目して数段階に分類し、それぞれの段階で適切なストレージ・デバイスを使い分けようという発想だ。

 通常、生成されて間もない「新鮮な」情報は参照/更新ともに高頻度で行われる。この段階の情報は、アクセスが高速なストレージ・デバイスに格納しておかないと業務効率を低下させる要因にもなる。このため、通常は手持ちのストレージ・デバイスの中でも最も新しく最も高速なシステムがこうした用途に充てられる。

 例えば決算期にのみ参照されるデータであれば、保存用のアーカイブ・ストレージに移動しておき、決算期にはそこから取り出してくる、という運用でも効率面での悪影響は軽微にとどまるだろう。むしろ、オンライン・ストレージからめったに参照されないデータを排除することができれば、そのメリットがデメリットをはるかに上回ることが期待できる。

 こうしたデータの移動は、残念ながら人力で実施することが極めて困難だ。日ごと/週ごと/月ごとといった形で定期的に生成されるファイルであれば、ちょっとしたスクリプトを書く程度の手間で半自動化も可能かもしれない。しかし、通常はファイルに対してどの程度の頻度でアクセスが発生しているかの情報を把握することすら困難であり、データを移動してしまうとアプリケーションからデータを見つけることができなくなるなど、さまざまな弊害が出てくる。そのため、ILMはコンセプトとしては分かりやすいものの、実装は簡単ではないソリューションとなっている。

 現実のILMソリューションでは、仮想化技術と組み合わせることで実装上の困難を解消している例が大半だ。

 これには、仮想ボリュームと物理デバイスのマッピングをアプリケーションからは隠ぺいされた形で動的に変更できるという仮想化の特長が生かされている。データをその鮮度とアクセス頻度に応じた物理デバイスに移動しつつ、アプリケーションから見た場合のパスは不変に保つ、といった実装が可能なのは、仮想化技術ならではと言ってよいだろう。

2012年5月20日日曜日

ストレージ技術 覚書1

仮想化技術全般に共通する目標は、物理的なデバイスの詳細を隠ぺいし、制約を回避するために論理的なインターフェースを構築/提供すること、である。


ストレージの場合、基本となる物理的なデバイスとは、個々のHDDのドライブ単体ということになるだろう。

企業の情報システムでは、HDDの単体容量という制約を回避する技術は必須となる。

◆RAIDによるHDDの統合
 HDDの場合、「分割」と「統合」という2つの方向の「仮想化」がどちらも長く利用されてきている。

 まず分割は、パーティション分割としておなじみの手法だ。HDDの容量を分割し、それぞれを独立したHDDのように見せかけることができる。

 一方、統合に関しては、主にRAID(Redundant Arrays of Inexpensive Disks)が用いられてきた。RAIDとは、安価で低信頼のHDDを複数組み合わせて信頼性を確保しようとする技術だが、結果的にHDDの単体容量を超える記憶領域をつくり出し、物理デバイスの制約を超えた運用を可能にする。

 例えば、1TBのHDDを3台用意し、Dドライブ、Eドライブ、Fドライブとして接続したとする。この場合、ユーザーが利用可能な記憶容量は合計で3TBとなるが、この使い勝手は3TBのサイズのドライブが1台接続されている場合と同じにはならない。

どのデータをどのドライブに記憶したか、という情報をユーザーが正確に把握しておく必要があるという問題もあるが、

最大の問題は、1TBを超えるサイズのファイルを記録することができない、という点にある。

仮に、サイズが2.5TBの巨大ファイルがあったとしたら、このファイルを保存するためには最低でも3つの断片に分割して各ドライブに分散して記録し、使用する際にはこの断片をつなぎ合わせるという作業をユーザーが行うことになる。

一方、RAID-0によるストライピングを使う場合、ユーザーは3TBのドライブをDドライブとして使用することが可能になる。ここにはもちろん、2.5TBのサイズのファイルをそのまま記録することができる。物理的な実体としては1TBのドライブが3台あることに変わりはないが、これを統合して仮想的な3TBのドライブを創り出す

◆RAIDの限界
 RAIDで複数のHDDを統合する場合、当然ながら統合対象となるHDDはすべてRAIDコントローラーの配下に接続されている。ユーザーの目から見える具体的なシステム・イメージとしては、外部ストレージの筐体(きょうたい)内に収納されたHDD群が1つのRAIDシステムを構成している、と見える。

 逆に言えば、ストレージが複数台あれば、その数だけのRAIDシステムがあることになり、利用率の不均衡などの無駄が生じる可能性が高い。

 仮想化されたストレージでは、仮想化システムが配下のRAIDシステムの容量を束ねて仮想的なボリュームを創り出し、これに対するインターフェースをサーバー側に提供する。これにより、ストレージ筐体(=RAIDシステム)の境界を越えてボリューム容量を拡張できる。

 現在のエンタープライズ・ストレージでは筐体当たりの最大容量はPBレベルまで達しており、この容量では記録不可能な巨大サイズのファイルを扱うことがあるとは思えないので、筐体をまたがったボリュームの統合は、サイズ的な制約を理由としているわけではない。ここではむしろ、論理的な統合によって運用の効率化や簡素化が実現できることが主たるメリットとなる。

◆仮想化によって得られるメリット
 ストレージ仮想化では、ストレージ・システムの筐体の境界をまたいだ容量の統合が可能になるため、容量を余らせているストレージ・システムの容量を別のストレージ・システムの容量とつなぎ合わせて活用する、といったことが可能になる。システム全体にわたる大規模なボリュームの整理統合を行うことなく、空き容量を活用することができるようになるため、ストレージ・システムを新たに追加購入しなくても当面の容量不足に対応可能となるわけだ。これは、IT投資の抑制にもつながるし、既存のITシステムの利用率を向上させることで投資効果を高めることにもなる。

 また、ストレージ・システムの境界をまたいだ統合は、物理的なデバイスの詳細をサーバー側から隠ぺいすることと同義でもある。サーバー側では、仮想化システムが提供する仮想ボリュームに対してアクセスしており、仮想ボリュームが実際にどの物理デバイスにマッピングされているかについては全く知らされない。

2012年5月16日水曜日

日本ビジネスの覚書

日本経済の問題点の覚書
①円高
 ギリシャ問題でさらにヨーロッパが不安定⇒円高
②税収の落ち込み
③日本経済の疲弊
 震災復興の遅れが心配
④建設インフラの劣化
 昭和40年代に建設された道路、下水道、橋の劣化
⑤財政赤字
⑥国外脱出組の増加
⑦少子化と老齢化

2012年5月15日火曜日

教育 その1

Webアプリケーションの教育指針
①Webシステムの説明
 ブラウザとWebサーバについて
 HTTPおよびHTTPSの通信制御について
 Webプログラミング説明
②Webプログラミングの目的
 最終的にはHTMLの作成
③データベースとの接続
 Namingサービスの利用
④プログラミングについて
 プログラミングのデータとリテラル
 データ構造
 アルゴリズム
 変数
 制御文
⑤各プログラミング言語仕様