（RH）手放しでMURALを推してみる
はじめに
IBMでは社外ツールも積極的に利用していますが、その中でコミュニケーション・ツールの１つであるMURALを紹介したいと思います。 とにかくビジュアルがよく、使っているだけで仕事に取り組むテンションも上がります。
情報共有を行うためのコミュニケーション・ツールは世に沢山存在しており多様な働き方をサポートしてくれています。
チャット・ツール、リモートミーティング・ツール、電話会議・ツール・・・
MURALはオンラインのホワイトボードツールです。
MURALとは？
Mural supports digital collaboration for teams, whether they’re co-located or remote, through a virtual collaboration space for gathering collective thought, brainstorming, whiteboarding, and team planning.
使い方
サイトを訪れ、ログインするだけです。 アカウントは新規で作成してもいいし、facebookやGoogleのアカウントを利用することもできます。
特に使い方の説明がなくても始められますが、Tutorialもあります。
MURALの価値
- 操作が直感的で使用開始が簡単。
- とにかくビジュアルが美しい。
- リモートにおいてもホワイトボードを使った会議ができる。
- 空白のホワイトボードもあるし、レイアウトのテンプレートもある。
- 画像も別のサイトから簡単に挿入できる。
- 投票機能もありボード上で投票できる。
- 付箋の種類が豊富。
電話やWebカメラを用いたリモート会議では、文字や声とともに誰かの作成資料を共有して会話することも多いのですが、会議中のディスカッションの流れで資料更新してイメージ共有したいと思うことが良くあります。
どんどん案を書いていきたいようなブレーンストーミングの場合や、構造的な内容を伝えるためには、このような電子ホワイトボードがあると助かります。
（HF） つれづれてみました。
現在は、基盤構築案件のPMを担当していますが、 日々の仕事で忙殺されていると、普段はあまりゆっくり考えたりしないのですが、プロジェクト管理の切り口でキーワードをいくつか連ねてみたいと思います。
１．「プロジェクトの成功」と「経営の視点から見た成功」
プロジェクトメンバーの視点
情報システム開発ではプロジェクトメンバーにとっては、プロジェクトの成功裏の開発・完了こそが「プロジェクトの成功」を意味しますが、それだけではだめなんでしょうね。
経営の視点
お客様/自社含めて経営する立場からすると、プロジェクトのアウトプットが、運用に至って初めて、投資に見合った成果かどうかを評価出来る訳ですが、通常そのタイミングにはプロジェクトは解散していたりする場合があります。
やはり狙った効果を達成できなければ、たとえ予算内・期限内で、品質要求を達成してたとしても成功ではないんですね。
システム化構想の最上流は運用局面にあり、運用部門でシステム効果の結実が確認されて終結となるべきという考え方です。（運用局面での実証性あっての投資となる）
２．「プロジェクト」と「プログラム」・「ポートフォリオ」
環境変化が多い状況では、プロジェクトマネジメントの実践だけでは「組織戦略と目標」の達成が困難となりつつあるので、上位概念が考え出されています。
戦略的目標を達成するためにグループとしてマネジメントされるプロジェクト、プログラム、サブポートフォリオ、および定常業務の集合の事をいいます。
経営戦略の単位を識別し、規模や優先順位、リスクの判断と決定を通じて戦略達成を図り、プログラムマネジメントや、プロジェクトの取捨選択と資源配分の意思決定を行うのが、ポートフォリオ・マネジャー となります。
プログラム：
ポートフォリオ内でグループ化されており、ポートフォリオを支援するように調和のとれた方法でマネジメントされる、サブプログラム、プロジェクト、またはその他の作業によって構成されます。
切り出された戦略施策の塊を、プログラムとして定義。業績の達成を実現するフレームワークとして“プログラマブルな意思決定”プロセスを適用するのが、プログラム・マネジャー となります。
当然、上記を担当する人は会社の経営戦略 や、戦略の施策に関して理解・把握している必要があります。
普段プロジェクトを担当している範囲では、あまり上記を意識せず、プロジェクトの成功裏の完了を目指して日々の活動をする訳ですが、経営者の立場から俯瞰してみると、全体の中から限られた箇所しか見ていない事に気がつきます。
３．プロジェクトと経営の期待を結びつけるためのプロジェクトマネージャの視点
近年のプロジェクトは、戦略プログラムと機能別組織（LOB:Line Of Business）が交差する機能の部分で発生するケースが増えてきているとの事で、プロジェクトの価値や責任、役割が、単体のプロジェクト・スコープからでは見えづらくなってきています。
プロジェクトを担当するプロジェクト・マネジャーにとって、プロジェクトと経営の期待を結びつけるためには、もう一段高い視点から状況を把握する枠組みが必要となってきているんですね。
（プログラムも群をしてとらえ、企業戦略を実装するためのポートフォリオマネジメントに統合された枠組み）
４． 「ITIL V3」と「プログラムマネジメント」及び「ポートフォリオマネジメント」
ITサービスマネジメントのベストプラクティスを集めたフレームワークである「ITIL V3」は、開発したシステムの運用への移行、確実な運用、継続的な改善活動、そして再びサービス・ストラテジーのプロセスへの、ライフサイクルとしてまわしていく枠組みを提唱しています。
PMIの「ポートフォリオマネジメント」、「プログラムマネジメント、「ITIL V3」 共にサービスライフサイクルの視点で捉え、ビジネス管理とのAlignmentを強く意識しています。
作るだけでなく、運用して、改善して作り直すといった事を継続して回す事が重要なんですね。
ITIL® (Information Technology Infrastructure Library)
５． BRM（Business Realization Management）
プロジェクトを進めるにあたって、プロジェクト管理の方向感や、期待されていること、 経営戦略とプロジェクトの関係を理解している事が求められてきています。
ベネフィット(Benefits)の具体的な実現の枠組が必要という事で、PMI（Project Management Institute Inc.）にて、 BRM（Business Realization Management）が発表されています。
ベネフィットをもたらす事がプロジェクトの目的であり価値である
組織にベネフィットをもたらす事がプロジェクトの究極の目的であり、プロジェクトの本質を再認識したうえで実践することが大切という事で、フレームワークが考え出されています。
BRMのフレームワークでは、3つの段階
１）ベネフィットの特定（Identify Benefits）
２）ベネフィットの実行（Execute Benefits）
３）ベネフィットの維持（SustainBenefits）
が定義され、各段階における課題や実践例が簡潔にまとめられています。
６．マイクロサービス・アーキテクチャー
クラウド上で稼働する IT システム開発プロジェクトからのフィードバッを集めたもので、小さなサービスを組み合わせて、一つのアプリケーションを開発します
以下の9つの特徴を持ちます。
・Componentization via Services（サービスによるコンポーネント化）
・Organized around Business Capabilities（ビジネス機能に基づいたチーム編成）
・Products not Projects（プロジェクトではなく製品として捉え開発運用する）
・Smart endpoints and dumb pipes（インテリジェントなエンドポイントとシンプルなパイプ）
・Decentralized Governance（非中央集権的な言語やツールの選択）
・Decentralized Data Management（非中央集権的なデータ管理）
・Infrastructure Automation（基盤の自動化）
・Design for failure（障害、エラーを前提とした設計）
・Evolutionary Design（先進的な設計）
上記に、Products Not Projects（プロジェクトではなく製品として捉え開発運用する）というのがあります。
製品として捉えるとの事です。
プロジェクトのアウトプットを一連の機能として見るのではなく、製品としてどのようにユーザーのビジネス能力を高める事の助けができるのかといった事に焦点が当てられます。
いままでの、アプリケーション開発ではプロジェクトを通して一連の機能を作成・提供し、完了後はメンテナンス組織に渡され、それを構築したプロジェクトチームは解散する事となります。
それが、プロジェクトではなく製品として捉え開発運用する となった場合には、開発チームが本番プロダクトの全面的な責任を負う「開発した人が構築し、実行する」とう流れに変わります。
作るだけでなく、運用して、改善して作り直すといった事を継続して回すところを主眼においているところは、サービスライフサイクルの視点で捉え、ビジネス管理とのAlignmentを強く意識する「ポートフォリオマネジメント」、「プログラムマネジメント、「ITIL V3」 とも通じるものがあると思ったりしています。
７．フルスタック・エンジニア
「開発した人が構築し、実行する」という事になるのであれば、必要となるのは、
Webアプリサーバー関連技術だけでなく、ネットワーク、OS、DB、ビジネスロジックの知識が必要になります。
従来であれば専門の技術者が分業してプロジェクトを進めるのに対し、フルスタック・エンジニアはすべて一人で対処出来うるスキルを持っているイメージだそうです。
ちなみに、フルスタックの世界には、専任のPMはいないとの事。
どちらかといえば、開発者がFull-stack Engineerスキルを身に付け、PMPレベルのPM知識を付け、アーキテクティングが出来るようになる事が求められていくそうです。
おわりに
最近の流れを受けて、「デベロッパーこそ新しいキングメーカー」と言われているようです。
（The New Kingmakers: How Developers Conquered the World
ISBN: 978-1449356347（オライリー））
デベロッパーのコミュニティでは新しいルネッサンスが進行中だそうで、そちらの動向も注目しておいた方が良いと思います。
（開発者が数人でビジネスを小さく立ち上げて、大きく起業）
Systems of Record(SoR)のミッション・クリティカルなシステムに対しては、現時点ではクラウド化は馴染み切らなかったりするので、オンプレミスの環境に残り続けているものはあると思いますが、API化等の周辺の動きを受けて様変わりはしていくのだろうなと思います。
時代の要請にに応じたトレンドが変わろうとも、一貫して言える事は、経営（お客様/自社含めて）の期待をどのように自らの活動に結びつけるのかという事を意識し続ける必要があるという事かと思います。
ここ数年には、IT業界の風景も一変していると思いますが、どうなっていますかね。
（参考）
・ProVISION No.63 進化するプロジェクトマネジメント
企業の期待に応えるプロジェクトマネジメント
https://www-304.ibm.com/connections/blogs/ProVISION61_65/resource/no63/63_article2.pdf
・ProVISION No.82 グローバル化時代のプロジェクト&プログラムマネジメント
変革に挑むマネジメント・フレームワークとそれを実行するための専門職
https://www-304.ibm.com/connections/blogs/ProVISION81_85/resource/no82/82_contribution.pdf
・PMI日本支部アニュアルレポート 2016
https://www.pmi-japan.org/topics/pdf/PMIJ-annual_REP2016_single-page.pdf
・考え方を変えてクラウドの能力を最大限に引き出す
第 1 回 クラウド・ソリューションと従来の Web アプリとの比較
https://www.ibm.com/developerworks/jp/cloud/library/cl-get-the-most-out-of-cloud-1-trs/index.html
・考え方を変えてクラウドの能力を最大限に引き出す
第 2 回 クラウド・ソリューションを機能させる
https://www.ibm.com/developerworks/jp/cloud/library/cl-get-the-most-out-of-cloud-2-trs/
・考え方を変えてクラウドの能力を最大限に引き出す
第 3 回 経験から学んだ教訓、トップ 11
https://www.ibm.com/developerworks/jp/cloud/library/cl-get-the-most-out-of-cloud-3-trs/
・Microservices
https://martinfowler.com/articles/microservices.html
構造的に物事を考える(T.O)
構築現場や保守において、トラブルだったりテスト指針を作るときに
いつも立ち止まって考えることがあるので、今回はそれを紹介したいと思う。
実はあるとき、ある２人の人と別々のタイミングで、一緒に仕事をすることになって、
"構造的に考える。ということが本当に必要なのである。"という事に気が付いた。
しかし、"三つ子の魂100まで"である。。。
咄嗟の時にはなかなか実践できないが、煮詰まっている・・・と感じるときに、
立ち返る基点となった。
さて、以前の私は以下のような状態であった。
(いまも構造的に見れていない時はあるので、発生しがちではあるが)
====================
○トラブルや問題に対してその部分だけ見ていてなかなか解決しない。
○構築時に手順ミスで誤った設定をしてしまい、修正をする。
しかし、後々になって別のミスを発見し、修正する。(無限ループ)
○テストを実施するために、抜け漏れなく充足しているのか、
資料を作っても第三者には伝わりづらい。
====================
確かに、どこの現場でもありがちな事かもしれない。
では、構造的に考えるとどうなるのか。。。は、
すぐ解決、ミスしない、伝わる。。。と単純明快である。
前置きが随分と長くなってしまったが、
構造的に考えるということを実践していくためにはどのようにすれば良いのか。
私が気をつけている点を記載していく。
====================
○全体像を把握する(登場人物を把握する) -> 俯瞰する、鳥瞰する、時間軸も入れる
○全体像の中をグループ化する ->
○全体像の中の関係性を把握する
○個を具体化していく
====================
である。なんだか、ちょっとずれているんじゃないのかな。とは思われるかもしれない。
しかし、
トラブルの時なんかは
全体像を把握して、しかるべき人に伝える。ということが重要で
全体像を把握すると言うことは、"事象・影響・原因・子因・対応策"の5大要素の内、事象と影響が判明する。
私自身、何かの製品に長けている訳ではないので、お客様・営業・SE・サポート部門に上記を伝えている。
そうすることで、全体で正しい状況を共有でき、トラブルが起きているシステムの関係性を把握する事で
調査対象を絞り込み、関係箇所を調査することで、行き当たりばったりの調査を行うことを避けることができる。
構築時のミスについても
ミスすると言う事象がどうしておきてしまったのか。と言う全体像を把握することで
意外な真因(手順書で変更パラメータが別記されておらず、分かりづらい)が判明し、手順書のフォーマット変更で
ミスを減らせることができるかもしれない。
また、資料作りの際は
全体感を提示して、グループ化、関係性の提示をすることで
当時その場に居た人だけではなく、後からプロジェクトに参加した人にも当時考えた経緯などが分かる資料となる。
テスト仕様書等の資料については、システム全体を把握し提示することで対象のスコープ範囲を明示し
それぞれのグループ、関係性をマトリックスを使って提示し、サーバ内のプロダクトについても同様に整理、具体化していくことで
漏れなく確認していくことが可能である。
なお、構造化についてあまり本などでは紹介されていないように思うが
"ロジカル・シンキング"という本の中で、[グルーピング]という部分をたまに読み返す。
https://www.amazon.co.jp/%E3%83%AD%E3%82%B8%E3%82%AB%E3%83%AB%E3%83%BB%E3%82%B7%E3%83%B3%E3%82%AD%E3%83%B3%E3%82%B0%E2%80%95%E8%AB%96%E7%90%86%E7%9A%84%E3%81%AA%E6%80%9D%E8%80%83%E3%81%A8%E6%A7%8B%E6%88%90%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB-Best-solution-%E7%85%A7%E5%B1%8B-%E8%8F%AF%E5%AD%90/dp/4492531122
最後に、、、
実作業者をやりながら、構造的に考える、、、というのは私にとってはまだまだ難しい。
個別具体的な対処を行ってしまうと、どうしてもそこだけに着目してしまい俯瞰することができずにいる。
本当だったら幽体離脱か二重人格化するなどして、自分で2役こなせればよいのだが、
いまだそのような能力は身につけられていない。
そういった時は積極的に第三者に助けてもらうか、実作業を第三者にやってもらうようにしている。
どの現場においても俯瞰している人が居る。という事は全体最適化、トラブルの早期解決としては大事だと考えている。
（中上）VMware On IBM Cloudを試してみた（注文編）
こんにちは、IBMの中上です。
前回に引き続き、VMware vSphere製品について扱ってみようと思います。
今回は、Tipsの紹介というよりは、自身の勉強も兼ねて、VMware On IBM Cloudを試してみたので、この紹介です。
1. VMware On IBM Cloudについて
一言で言えば、IBMが提供するIaaSのクラウドサービス上にVMware環境をデプロイできるというサービスを指します。
※IBMが提供するIaaSは「SoftLayer」という名称で提供されていましたが、現在は「Bluemix Infrastructure」として統合されています。サービス提供開始以後しばらくは「VMware On SoftLayer」などの表記も見られました。
詳しくは、以下を参照ください。
2. VMware On IBM Cloudのデプロイ方法
VMware環境をデプロイする方法は大きく分けて3種類あるようです。
- ベアメタルサーバを注文して、OSインストール不要を選択する
- VMware Cloud Foundationを使用する
「VMware Cloud Foundation」とは、IBM Cloud (Bluemix) 内で選択可能なデプロイ方法で、Bluemix Infrastructure (旧SoftLayer), VMware vSphere, vSAN, NSXなどのサービスを一括で展開するサービスです。なお、Bluemixでは、vCenter Serverのデプロイも可能です。
こちらの方法はまだ試したことがないので、今回は1の方法で注文を行うことにします。
3. 注文してみた
IBM idを既に取得済みであることを前提とします。
SoftLayer管理ポータルにログインしたら、画面中央の「デバイス」をクリック
すると、以下のような画面が出てきます。
今回は物理サーバを借りて、vSphere ESXiを導入します。また、あくまで実験用途なので、「ベア・メタル・サーバー」の「時間単位」を選択します。
新しい画面が開き、選択可能な物理サーバ一覧と費用が記載されたページが表示されます。
今回は最も小規模な物理サーバーを選択します。
（投稿日現在の為替レートで考えると、サーバー自体は63円/時間ぐらいですね）
すこし待つと注文画面へと進みます。
「数量」を変更すれば、複数台注文することも可能なようです。
「注意：データセンター選択が必要です」と表示があり、SoftLayerが展開されているデータセンターから、物理サーバーを展開したい場所を選択する必要があります。
ここで、ちょっと不親切なのですが、例えば「tok02 - Tokyo」（＝東京データセンター）を選択可能なのですが、後続の注文処理を進めていくと「注文の検証中にエラーが発生しました」と表示され、注文が戻されてしまいます。
これ、要は、TOK02では「物理サーバーのサービス提供は実施されていない」ということのようです。
（じゃあ、リストに表示しなければいいのに…）
やむなく今回は「San Jose 1」を選択し直し、以下の処理を続けます。
画面をスクロールしていくと「オペレーティング・システム」の選択画面が出てきます。
今回は「Other」→「No Operating System」を選択します
このあと、Hard Dirves、ネットワークのオプション、電源装置他の選択を行います。
全て選択が完了したら、ページ末尾の「注文に追加」をクリックします。
画面が遷移して「精算」という画面が表示されます。
画面右側に時間単位の費用が表示されます（Hard Diskやネットワークオプションの都合、ちょっとだけ費用が増して$0.61/hとなっています）
画面をスクロールしていくと、ホスト名を指定することができます。
これを指定して、画面右側にある「注文の送信」というボタンを押すと、実際の注文が行われます。
注文が完了すると、画面が遷移して、以下のページが表示されます。
画面をスクロールすると、注文したサーバーの構成が表示されます。
あわせて、以下のようなメールが届きます。
記載のある通りですが、1~4時間程度で物理サーバーが使用可能な状態になるようです。
SoftLayer管理ポータルで「デバイス」→「デバイスの詳細」を開くと、セットアップの進行状況を確認できます。
何度か更新していると「状況」が「アクティブ」になり、使用可能な状態になりました。
今回はOS導入も実施していないため、30分程度で用意されました。
以上で、物理サーバーの注文まで完了です。あとはこれに、vSphere ESXiをインストールするだけですね（ここからがまた大変だったのですが、これ以降は次回に続きます）
4. 終わりに
インフラSEをやっていると、プロジェクトでHW調達、設置、セットアップ等をこなすことは少なくはないのですが、やはり、時間もかかるし、結構面倒くさいものです。
これが30分程度で使用可能な状態で提供されるというのは、とても良いものですね。
このあと、ネットワーク越しにインストール作業を行っていくことになるわけですが、ここで、クラウドを使用することによるデメリットも幾つか経験することになります。
詳しくはまた次の記事で。
※管理画面や提供サービス、オプション等は、本記事投稿時点から随時更新される可能性がありますので、ご注意下さい。
この記事の執筆者：中上
担当プロジェクトがほぼ完了となり、束の間の平穏が訪れつつあります。
（志賀）超初心者向け：完全無償な検証環境を作る方法（VirtualBox+Vagrant）[CentOS導入編2]
VirtualBox+VagrantでCentOSの仮想環境を実装する（実践編つづき）
前回の続きで、作成したVagrantの環境で実際に仮想マシンを作成してみます。
４：ゲストOSをVagrant経由で起動・停止・削除してみる
以下のコマンドを実行します。
仮想マシン名を省略すると、定義されているすべての仮想マシンが対象になります。たくさん定義していてうっかり全部起動してしまうとリソースが足りなくなって処理途中でハングしますのでご注意ください。
まずは起動です。初回は起動とともに仮想マシンを作成します。
PS C:\asitestenv> vagrant status
Current machine states:
client1 not created (virtualbox)
client2 not created (virtualbox)
This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.
PS C:\asitestenv> vagrant up
Bringing machine 'client1' up with 'virtualbox' provider...
Bringing machine 'client2' up with 'virtualbox' provider...
==> client1: Importing base box 'CentOS6-9-Server'...
==> client1: Matching MAC address for NAT networking...
==> client1: Setting the name of the VM: asitestenv_client1_1501650989537_83989
==> client1: Fixed port collision for 22 => 2222. Now on port 2201.
==> client1: Clearing any previously set network interfaces...
==> client1: Preparing network interfaces based on configuration...
client1: Adapter 1: nat
client1: Adapter 2: hostonly
（中略）
==> client1: Setting hostname...
==> client1: Configuring and enabling network interfaces...
==> client2: Importing base box 'CentOS7-3-Server'...
==> client2: Matching MAC address for NAT networking...
==> client2: Setting the name of the VM: asitestenv_client2_1501651051208_54393
==> client2: Fixed port collision for 22 => 2222. Now on port 2202.
==> client2: Clearing any previously set network interfaces...
==> client2: Preparing network interfaces based on configuration...
client2: Adapter 1: nat
client2: Adapter 2: hostonly
（中略）
==> client2: Setting hostname...
==> client2: Configuring and enabling network interfaces...
PS C:\asitestenv> vagrant status
Current machine states:
client1 running (virtualbox)
client2 running (virtualbox)
This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.
PS C:\asitestenv>
状態がrunningになっていること確認できました。
Vagrantで自動作成したLinux系仮想マシンは、vagrantユーザでssh鍵認証でログイン可能です。"vagrant ssh {仮想マシン名]"コマンドでも可能ですが、複数仮想マシンを起動する前提ですし、ここはあえてteratermで接続する方法を紹介しておきます。
鍵ファイルのパスを以下コマンドで確認します。
PS C:\asitestenv> vagrant ssh-config
Host client1
HostName 127.0.0.1
User vagrant
Port 2201
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no
IdentityFile C:/asitestenv/.vagrant/machines/client1/virtualbox/private_key
IdentitiesOnly yes
LogLevel FATAL
Host client2
HostName 127.0.0.1
User vagrant
Port 2202
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no
IdentityFile C:/asitestenv/.vagrant/machines/client2/virtualbox/private_key
IdentitiesOnly yes
LogLevel FATAL
PS C:\asitestenv>
IdentityFileエントリにある鍵ファイルを指定してsshログインします。
接続してOSバージョンやホスト名、NW設定等できていることを確認できました。
[vagrant@client1 ~]$ hostname
client1
[vagrant@client1 ~]$ cat /etc/redhat-release
CentOS release 6.9 (Final)
[vagrant@client1 ~]$ ifconfig -a
eth0 Link encap:Ethernet HWaddr 52:54:00:2A:86:4C
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::5054:ff:fe2a:864c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:672 errors:0 dropped:0 overruns:0 frame:0
TX packets:457 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:76066 (74.2 KiB) TX bytes:63492 (62.0 KiB)
eth1 Link encap:Ethernet HWaddr 08:00:27:AF:9D:0B
inet addr:192.168.50.14 Bcast:192.168.50.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:feaf:9d0b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:98 errors:0 dropped:0 overruns:0 frame:0
TX packets:88 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:15692 (15.3 KiB) TX bytes:14905 (14.5 KiB)
（以降略）
停止コマンドを実行します。
PS C:\asitestenv> vagrant halt
==> client2: Attempting graceful shutdown of VM...
==> client1: Attempting graceful shutdown of VM...
PS C:\asitestenv> vagrant status
Current machine states:
client1 poweroff (virtualbox)
client2 poweroff (virtualbox)
This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.
PS C:\asitestenv>
ここでまた"vagrant up"を実行したら、上記の停止したclient1/client2が起動してきます。もしhalt前に変更を加えていた場合でも、その設定は残っています。
今回はそのまま削除コマンドを実行します。
PS C:\asitestenv> vagrant status
Current machine states:
client1 poweroff (virtualbox)
client2 poweroff (virtualbox)
This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.
PS C:\asitestenv> vagrant destroy
client2: Are you sure you want to destroy the 'client2' VM? [y/N] y
==> client2: Destroying VM and associated drives...
client1: Are you sure you want to destroy the 'client1' VM? [y/N] y
==> client1: Destroying VM and associated drives...
PS C:\asitestenv> vagrant status
Current machine states:
client1 not created (virtualbox)
client2 not created (virtualbox)
This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.
PS C:\asitestenv>
これで完全に削除されました。ここで再び”vagrant up"を実行すると、初回同様にBox定義からインポートしてVagrantfileの内容に従い仮想マシンを１から作成されます。
ここまでで環境の作成とテストが完了です。
最後に
ここまでやるとお気づきになると思いますが、恐らく初心者が仮想環境を作る上で一番のハードルになると思われるネットワーク周りの設定が「サーバのIPアドレスを指定するだけ」です。これを手動でやろうと思うと、VirtualBox側のネットワークアダプタを定義した後に、操作性の低いコンソール画面上でOSをインストール→ssh疎通のための設定をすることになります。（しかもたいていキーボードが英語になっていて地味にイライラを増幅する。）じっと画面遷移を見守っているといつの間にかssh疎通可能なマシンが立ち上がっているって、本当にすばらしいです。
ここまで持ち上げましたが、使い込んでいくとオープンソースなのでもちろんバグに遭遇したりもします。あくまでテスト環境として、お勧めです。
（志賀）超初心者向け：完全無償な検証環境を作る方法（VirtualBox+Vagrant）[CentOS導入編1]
VirtualBox+VagrantでCentOSの仮想環境を実装する（実践編つづき）
今回は前回の続きで、CentOS6/7をVirtualBox+Vagrantで自動構築する仕組みを実装していきます。また量が多いので、Windowsは次の機会に回します。
Vagrantを利用して仮想マシンを起動・停止・削除する方法は次の記事でご紹介します。
２：各OS用のBoxファイルを作成してBoxを定義する
BoxとはVagrantを使用してインスタンスを作る際の雛形になるイメージファイルです。Vagrant上でこのイメージファイル定義を追加する必要があります。
具体的にやることは
1:イメージファイルを用意する
2:"vagrant box add"コマンドを実行してVagrant上で定義する
これだけです。なお、1で用意するのはイメージファイルではなく自分で作成したVirtualBox上のインスタンスでもOKです。（= つまり、自分で好きなようにインスタンスを作って簡単に展開可能！）
1:イメージファイルを用意する
イメージファイルは以下から簡単に見つけられます。
https://app.vagrantup.com/boxes/search
ただ、こちらは登録さえしてしまえば誰でも登録できるものです。セキュリティ的な観点から考えるとできるだけ公式から提供されているものを使いたいところです。
CentOS6/7は公式から提供されてました。
https://app.vagrantup.com/centos
Boxファイルとしては以下においてありました。ここにある、”CentOS-N.box”のリンクを使います。
http://cloud.centos.org/centos/6/vagrant/x86_64/images/
http://cloud.centos.org/centos/7/vagrant/x86_64/images/
2:"vagrant box add"コマンドを実行してVagrant上で定義する
以下のコマンドを実行します。
定義：vagrant box add [定義するBox名] [Boxファイルのフルパス]
参照：vagrant box list
定義後に参照コマンドを実行した、定義したBox名が表示されればOKです。
PS C:\asitestenv> vagrant box add CentOS7-3-Server http://cloud.centos.org/centos/7/vagrant/x86_64/images/CentOS-7.box
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'CentOS7-3-Server' (v0) for provider:
box: Downloading: http://cloud.centos.org/centos/7/vagrant/x86_64/images/CentOS-7.box
box: Progress: 100% (Rate: 466k/s, Estimated time remaining: --:--:--)
==> box: Successfully added box 'CentOS7-3-Server' (v0) for 'virtualbox'!
PS C:\asitestenv> vagrant box add CentOS6-9-Server http://cloud.centos.org/centos/6/vagrant/x86_64/images/C
entOS-6.box
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'CentOS6-9-Server' (v0) for provider:
box: Downloading: http://cloud.centos.org/centos/6/vagrant/x86_64/images/CentOS-6.box
box: Progress: 100% (Rate: 864k/s, Estimated time remaining: --:--:--)
==> box: Successfully added box 'CentOS6-9-Server' (v0) for 'virtualbox'!
PS C:\asitestenv>
PS C:\asitestenv> vagrant box list
CentOS6-9-Server (virtualbox, 0)
CentOS7-3-Server (virtualbox, 0)
PS C:\asitestenv>
なお、もしインターネットにつながらない端末でvagrant box addを行いたい場合には、いったん上記リンクから別のマシンにBoxファイルをダウンロードの上ファイルを端末に配置し、ファイルのフルパスをローカルの保管場所に指定してあげることもできます。
３：検証環境に合わせたVagrantfileを作成する
Vagrantは自動でいろいろなファイルを作業ディレクトリに作成するので作業用にひとつディレクトリを作るとよいです。Vagrantの概念ではこのディレクトリ単位でひとつの「プロジェクト」と呼び、インスタンスの作成/削除を行います。
作成したディレクトリ（ここではC:\asitestenv）に移動して、Vagrant初期化コマンド"vagrant init"を実行すると、同ディレクトリにVagrantfileが作成されます。このファイルに作成したいインスタンスの定義詳細（ホスト名やIPアドレス等）を記載します。
PS C:\asitestenv> vagrant init
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
PS C:\asitestenv>
このまま、Vagrantのプロジェクト状態を確認します。
PS C:\asitestenv> vagrant status
Current machine states:
default not created (virtualbox)
The environment has not yet been created. Run `vagrant up` to
create the environment. If a machine is not created, only the
default provider will be shown. So if a provider is not listed,
then the machine is not created for that environment.
PS C:\asitestenv>
この内容から、「このディレクトリにあるVagrantfileにはdefaultという仮想マシンを作るための定義がしてあり、かつ、defaultはまだ作成されていない(not created)」ということが分かります。defaultを作成して起動すると"not created"の箇所が"running"になり、停止すると"poweroff"とステータスの記載が変わります。
同ディレクトリにあるVagrantfileを開いてみると、デフォルト設定がだらっと一通り書いてありますので、適当にファイルのバックアップを取って、Vagrantfileの中身を全部削除し、以下のように記載してみます。中身は後ほど解説します。
Vagrant.configure("2") do |config|
# client1 base configuration
config.vm.define :client1 do |client1|
client1.vm.box = "CentOS6-9-Server"
client1.vm.network :private_network, ip:"192.168.50.14"
client1.vm.hostname = "asiclient1"
client1.vm.synced_folder ".", "/vagrant", disabled: true
end
end
変更を保存して、もう一度状態確認
PS C:\asitestenv> vagrant status
Current machine states:
client1 not created (virtualbox)
The environment has not yet been created. Run `vagrant up` to
create the environment. If a machine is not created, only the
default provider will be shown. So if a provider is not listed,
then the machine is not created for that environment.
PS C:\asitestenv>
仮想マシン名がdefaultからclient1に変わってます。これで、なんだかよく分からないけれどとりあえずclient1の仮想マシン定義ができました。
更に、client2の記載をVagrantfileに追加してみます。
Vagrant.configure("2") do |config|
# client1 base configuration
config.vm.define :client1 do |client1|
client1.vm.box = "CentOS6-9-Server"
client1.vm.network :private_network, ip:"192.168.50.14"
client1.vm.hostname = "asiclient1"
client1.vm.synced_folder ".", "/vagrant", disabled: true
end
# client2 base configuration
config.vm.define :client2 do |client2|
client2.vm.box = "CentOS7-3-Server"
client2.vm.network :private_network, ip:"192.168.50.15"
client2.vm.hostname = "asiclient2"
client2.vm.synced_folder ".", "/vagrant", disabled: true
end
end
この状態で状態確認すると以下のようにclient2の仮想マシン定義が追加されていることが確認できます。
PS C:\asitestenv> vagrant status
Current machine states:
client1 not created (virtualbox)
client2 not created (virtualbox)
This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.
PS C:\asitestenv>
パラメータについてひとつひとつ簡単に解説です。
config.vm.define仮想マシン名(clientN)を定義して、
clientN.vm.box ・・・使用するBoxイメージ
clientN.vm.network・・・ネットワークの定義(ネットワークの種類とIPアドレス)
clientN.vm.hostname・・・ホスト名
clientN.vm.synced_folder・・・ゲストOSとホストOS間での共有フォルダ設定（デフォルトON）
clientN.vm.synced_folderについては、この行であえて使用しない設定(disabled:true)にしています。CentOS6/7ではホストOSに入っているVirtualBoxとVboxGuestAdditionsのバージョン差異が原因でマウントエラーになるバグが存在することが分かっているためです。（ホストOS側にあるVBoxGuestAdditions.isoを新しいものに差し替えてバージョン差異を解消してあげるのが根本解決方法ですが、今回は初心者向けゆえここでは触れずにおきます。参考： https://utano.jp/entry/2014/11/vagrant_guest_additions_update_error/）
Vagrantで自動構築する内容は、上記のようなパラメータ単位で指定できるものもありますし、その他にもユーザを作成する、特定のモジュールを追加インストールする等の細かい処理もVagrantfile内でスクリプトを定義して実行することも可能です。
このあたりの詳細を知りたければ調べてみることをお勧めします。
（参考：https://www.virment.com/vagrantfile-settings/）
では次回、ここまで作ってきたVagrantfileの内容で、仮想マシンを実際に作ってみたいと思います。
（志賀）超初心者向け：完全無償な検証環境を作る方法（VirtualBox+Vagrant）[準備編]
はじめに
インフラSEをしていると、コマンドを打ったときの挙動を見たい、スクリプトの動作確認をしたいなど、ちょっとした検証作業をしたい、ということが往々にして発生するかと思います。
入社してすぐの頃に実感したことですが、自分で好きに使っていい検証環境があるって大事です。どんな影響があるか分からないコマンドがあって、でもどう動くのか知りたい。こういう状況であれば、マニュアルを読むより実際に実行したほうが絶対に早いし覚えます。
じゃあどうやって環境を用意するか？昨今IaaS系クラウドでインスタンスを作ってみるのも割と簡単です。が、「完全無償」で「恒久的に使える」環境を作る、となるとなかなかない。1年間限定だったり、ある範囲を超えると課金対象になったり細々した制約がある。
現実的な解は「自分の使っている作業端末に仮想環境を作る」ことだと思います。
これは、VirtualBoxやKVM（無償の仮想化ソフトウェア）を用意すれば割と簡単に実現します。が、欲しい仮想環境がLinuxならCentOS等フリーウェアでどうとでもなるとして、Windowsが欲しいとなると出現するライセンス料の壁。無償でどうにかするには30日間の試用期間という期間の壁。これを超えるにはどうするか？
「都度サーバを作り、検証が終わったらインスタンスごと消す」が一番簡単です。しかし、VirtualBox上で都度インストール作業するのも面倒くさい。このへん簡単にできないかな、と思ったときに有効な手段、それがVagrant（無償の仮想環境構築ソフトウェア）での構築自動化です。
また、ローカルで仮想環境を作る利点として、ネットワークについて知識が乏しくてもセキュリティ的に問題ないマシンを簡単に作れます。IaaSクラウドでインスタンスを作ったところで、勉強用のサーバに監視設定なんてまずやりません。また、サーバについてよくあるNW要件は「サーバからインターネットにアクセス可能だが、インターネットからサーバへのアクセスは原則不可で、作業端末からだけはサーバへ疎通可能」だと思いますが、この状態にするためにはサーバ側でセキュリティの穴あけ設定等々こまごましたことが必要になります。それも初心者には結構なハードルです。初心者だから検証環境が欲しいのに！この矛盾。
適当に作った勉強用のサーバが気付いたら悪意の第３者の踏み台にされていたのに全然気付きませんでした、なんてことになったら、いくらなんでもインフラSEとしては笑えません。その点、端末内に仮想環境を作った場合は仮想マシンに到達できるネットワークは端末の内部で閉じています（「ブリッジアダプターの設定をあえてしない限り」という注意はありますがデフォルト作成されないので、意図的に設定しない限りは考慮不要)。結果、端末のセキュリティ設定さえされていれば中の仮想マシンはどんな設定をしていても安全は確保できます。おまけにVagrantで仮想マシンを作るとデフォルトでNATネットワークが作られるので、サーバからインターネットへの通信も特に意識することなく実現し、作業端末からサーバへの通信もvagrantユーザで確実に保証されます。
まとめると、検証環境が欲しいとき
→ローカル(作業端末)に仮想環境で都度作る
メリット：
セキュリティの確保が比較的簡単
フリーウェアを使えば確実に無償
デメリット：
作業端末のHWスペック(CPU/メモリ/記憶領域)がある程度潤沢に必要
作業端末にフリーツール導入禁止等の制約があるなら使えない
→クラウドを使う
メリット：
(クラウドサービスの範囲内で)マシンスペックやツールの制約がない
作業端末に依存せずどこからでもアクセス可能
デメリット：
予期せず課金されてしまう可能性がある
セキュリティを確保するために一定の知識が必要
先日、以下のような検証環境を「誰でも簡単に無償で作れるようにしてほしい」というリクエストが来て、自分のノートPC(Windows7/X1 Carbon)上にVirtualBox＋Vagrantで作ってみました。七転八倒したものの、最終的にまとめると手順はシンプルになったので、今回はその方法を「4月に入社したばかりの新入社員(OJT等で1回くらいOSのインストール作業くらいしたことあるかな程度)」向けの粒度でシェアしたいと思います。
手順概要：
０ : ホストOSのCPUがIntel VT-Xに対応している場合は有効化する
１：環境に合ったVirtualBoxとVagrantをインストールする
２：各OS用のBoxファイルを用意してBoxを定義する
３：検証環境に合わせたVagrantfileを作成する
４：ゲストOSをVagrant経由で起動・停止・削除してみる
※今回は0/1のみ紹介し、2-4は次の機会に回したいと思います。
前提環境：
HW : Lenovo X1 Carbon
OS : Windows7 Professional
以降は上記環境を前提として手順概要を順を追って記述します。
なお、Macでも手順1で使用するインストーラが違うくらいでほとんど同じ(のはず)です。
VirtualBox+VagrantでCentOSの仮想環境を実装する（準備編）
０ : ホストOSのCPUがIntel VT-Xに対応している場合は有効化する
仮想環境を作る上で、使用しているHWのCPUがIntel系でVT-Xに対応している場合はVT-Xを有効化する必要があります。今はIntelが主流ですし、ある程度のマシンスペックであれば大抵のPCがひっかかるんじゃないかと思います。これが無効のままだとゲストOSを起動しようとしたタイミングでエラー(VERR_VMX_MSR_LOCKED_OR_DISABLED)が出るのでご注意ください。
対応しているかどうかの確認方法
コンピュータのプロパティ画面でプロセッサの項目を確認です。googleでCPU名を検索→一番上に出てくるIntel公式の製品仕様ページを開いてVT-xで検索、で出てきます。「はい」だと対応しています。
VT-xを有効化する方法
BIOSから変更します。やり方や画面遷移はHWに依存するので「HW名 VT-x 有効化」あたりで検索して製品のサポートページを見つけ、これを見ながら変更してください。
ちなみにX1 Carbonの場合は以下でした。
https://support.lenovo.com/jp/ja/solutions/ht500006
１：環境に合ったVirtualBoxとVagrantをインストールする
どちらのインストーラも無償提供されてます。Windowsであればインストーラを実行して画面遷移に合わせてぽちぽち次へを選択してデフォルトインストールしていけば終わりますので割愛します。
VirtualBox → 今回は4.2.2を使用（最新は2017/08/02現在5.1.26）
http://www.oracle.com/technetwork/server-storage/virtualbox/overview/index.html
Vagrant → 今回は1.8.6を使用（最新は2017/08/02現在1.9.7）
使ったバージョンが古いのは会社用PCに導入できるフリーウェアの制約があったからです。。。（フリーウェアは会社の許可がない限り導入禁止。今はどこもそんな感じなんでしょうか。）
VirtualBoxは起動してこの画面が出てくればOK。
Vagrantはコマンドプロンプトで以下を実行してバージョンが表示されればOKです。
導入で特にエラーは起こらなかったのにコマンドが見つからない系のエラーが返ってきた場合は、PATHの設定を確認してみてください。
(KING) VMware VMotionについて
こんにちは、日本IBMの王です。
現在担当しているプロジェクトで現場の作業を実施し、ある製品のある機能がすごいと思ったので、ご紹介したいと思います。
それはVmotionです。
VmotionはVmware社の仮想化支援ソフトの一つで、システムのライブマイグレーションを実行するソフトです。
どんな時にvMotionを使うのか。
Vmotionの応用範囲は非常に広い。例えば、物理仮想マシンのメモリの増設やホストの定期メンテナンスなどで、起動している仮想マシンをシャットダウンすることなく、動かしたまま別の物理サーバに移動することができます。低コストで高い可用性を確保したりすることができる。
現在私は担当しているDC移転プロジェクトにおいて、停止不可のシステムを待受環境への退避が必要ある。
稼働中の仮想マシンを停止せず、異なる物理サーバ間で移行するのはvMotionが実現できる。
この機能はどうやって実現するのか。
vMotionの仕組みを見てみましょう。
vMotionは主に3つのアクションによって実現する。
まず、Fibre Channel or iSCSI Storage Area Network(SAN)or Network Attached Storage(NAS)などの共有ストレージに保存されるファイルセットとして、仮想マシン全体の状態をカプセル化する。VMware vStorage VMFSを使用すると、複数のVMware ESXiが同じ仮想マシンファイルに同時にアクセスできる。
２番目は、仮想マシンのアクティブなメモリと正確な稼動状態を、高速なネットワーク経由で迅速に転送するテクノロジーです。これにより、移行元のESXホスト上で即座に実行できます。Vmotionは、実行中のメモリトランザクションをビットマップに記録することで、ユーザーに転送時間を意識させません。vMotionは、メモリおよびシステムの状態すべてを移行先のESXホストにコピーした後、移行元の仮想マシンをサスペンドし、ビットマップを移行先のESXホストにコピーして、移行先のESXホスト上の仮想マシンをレジュームします。このプロセスにかかる時間は、ギガビットイーサネットネットワークで２秒未満です。
３番目は、仮想マシンで使用されるネットワークを、基盤となるESXホストで仮想化するテクノロジーです。これにより、移行後も仮想マシンのネットワークIDとネットワーク接続が維持されます。vMotionは、プロセスの一環として仮想MACアドレスを管理します。移行先マシンがアクティブになると、vMotionからネットワークルータに対してpingが送信され、仮想MACアドレスに対応する新しい物理アドレスがネットワークルータで認識されているかどうかを確認します。Vmotionを使用した仮想マシンの移行では、正確な稼動状態、ネットワークID、およびアクティブなネットワーク接続が維持されるため、ダウンタイムの発生やユーザーへの影響はありません。
『VMware社：https://www.vmware.com/files/jp/pdf/vmotion_datasheet.pdf』
Vmotionの移行は仮想マシンを実行するコンピューティングリソースを変更できます。また、仮想マシンのコンピューティングリソースとストレージの両方を変更することもできます。
つまり、vmotionで仮想マシンを別のホストのみ移行できますし、互換性のあるデータストアのみに移行もできます。また、特定のホストに移行し、そのストレージを特定のデータストアに移行することもできます。
この記事の執筆者：王
2016年入社。若くないが、社会人２年目です。
エンタープライズ系のお客様を担当するインフラSE。
趣味はバスケットボール。バスケ経験16年以上。
現在、社会人バスケ大会「DUNK CUP」と「Sports One 3x3 CUP」に出ています。
(利根川)空調設備も意外と大事!?
人間でも扇風機に局所的にあたっていると風邪をひくという説がありますがサーバーも同じでした。。
Flex System x240 M5 CMM の Event Log に、不定期に以下の警告イベントが記録され、アラート発報される。
Message:
Hot air exiting from the rear of the chassis might be recirculated in the inlet air at the front of the chassis. High Temperature: xx℃, Low Temperature: xx℃.
１）温度警告のメッセージだが設定値はノード間の最高温度と最低温度の差を設定するため（defalt=5で1-9を設定)最大温度差の"9"を設定したが
現象は解消せず。
２）発生しているラックは14ノード搭載されておりほぼ満杯の状態であるため、ラック下部と上部の温度差が大きいと（9度以上)判断。
３）ラック下部が冷えすぎ、上部に冷気が届いていない、という仮説で空調吹出口をラック全体にあたるよう変更（吹出口を真下でなく少しずらした）したところアラートが出なくなった。
ラック内で温度差が出ない（空気循環が正常になる）ように空調とサーバーのラッキング（隙間をあけるとか）を考える必要がある。
(YK) AWSの運用をして率直に感じたこと
長年、IBM Power Systems をベースにインフラ構築をしてきましたが、とあるきっかけで1年半くらいAWSの運用をしたので、率直に感じたことを書いてみます。
ただ、IBM Cloud をよく知らないので、AWSとの比較はまだ別の機会にでも投稿しようと思います。
まず、ちょっと驚いたのが、災対環境が簡単に構築できてしまうことです。
AWSは サイトが物理的に Availability Zone と呼ばれる データセンターに分かれていて、このZoneを跨いで冗長構成を組むことが簡単にできてしまいます。
Zone間の通信は高速回線で繋がれていますが、若干速度が落ちるのでシビアな業務では注意が必要です。
あとは、Cloudなので当たり前ですが、部品を組み合わせるように、ロードバランサーやサーバー、ディスクの増強等を簡単にできてしまうところは、オンプレミス中心で仕事をしてきたSEとしては大変便利に感じます。
ここまでは利点について書いてきましたが、運用していて苦労した点についても書かないといけないですね。
それは、AWS側からの突然やってくるOS再起動要求です。
機器の老巧化や、障害、メンテナンス等の理由で「2週間以内に再起動してください」というお知らせがやってきます。運用としてはそこからスケジュール調整をするのですが、だいたい短期間に次から次へと、この厄介なお知らせがやってくるのです。1週間で数十台を再起動したこともありましたが、対象サーバが本番環境でないことをいつも願っていました。
当初は、AWSサイト間でディスク共有できない等の制約があったため、OracleRACが組めないこともあり、DBサーバの再起動では切替のためにサービスを数分止めなければならず、停止調整に苦労しました。
ただ、現在はディスク共有するサービスも追加されているようです。
とはいえ、一番苦労したのは純粋な障害対応ですが、、、
以上
