携帯キャリアを変えました。

キャリアメールを捨てる準備ができたので、14年使ったauからドコモにMNPしました。
データ通信はイーモバにまかせてFOMAの通話契約のみ。(これポイント)
一括0円のキッズケータイにMNPして2000円でSIMサイズをマイクロに変更。
ハーティ割引なのでその他の手数料は無料。

端末はZenfone5にしました。ただし最近でたLTE対応の国内版ではなく、expansysから3G版を購入。
最近はSIMフリーでもLTE版だとFOMA契約で通話できないのが多いらしいので。

イーモバ：2400円(現在、容量制限なし。)
Softbank：3円
docomo：744 円(無料通話1000円と家族通話無料。年間契約縛りもなし)

とだいぶ通信料を圧縮しました。
イーモバのGL06Pは二年割引が終わったら解約してMVNOにする予定。

ということで、私の携帯アドレスを知ってる人は消しておいてください。
番号は変わってないので、なんかあったらLINEで。

OSC 2014 .Enterprise

【DevOpsを実践する為のChef活用テクニック】
資料はslideshareで公開されました
http://www.slideshare.net/yandod/devopschef-42626945

・"DevOps"の言葉は2009年 6月、Velocity2009の講演で出た。
・インフラを自動化すればDevOps、ではない。
　→
バージョン管理システムの共有
ワンステップによるビルドとデプロイ
フィーチャーフラグ
メトリクスの共有
IRCとインスタントメッセンジャーのbot

メールだけでcloseなコミュニケーションができますか？
☆slack がおすすめ。（チャットツール）

●好まれるツール
・Ansible
　→シンプル。プログラマに好まれる傾向
・Puppet
　→設定ファイルに近い。インフラエンジニアに好まれる傾向
・Chef
　→中間に近い。

●Chef
・構成管理ツール
・Chef社の製品。
　→製品に合わせて社名変えた。ドメインも変えたからリンク切れで大変。
・Ruby/Erlang

・主要なバージョン
Chef 0.10.x
Chef 11.x
　→アーキテクチャ、インストール方法が変更
Chef 12.x
　→課金体系の変更。Chef Solo と Clientの統合

Chef12からはオープンソース版と有償版の機能の差がほぼなくなった。
　→Chef11は有償版にしかない機能がたくさんある。

☆Chef Soloは廃止予定。
　→chef-client local に統合される
Chef soloがなくなるというのは風評被害だ！

☆クックブックにはrubyのコードもかけます。

●Chefの問題点
・上から順に実行されない
・アンチパターンが存在する
・孤独なChef使いになってしまう

☆テストスイートがありますので、CIできます。

資料のURLはtwitterで。

【分散処理技術Apache HadoopとHadoop関連技術の最新動向】
●Hadoop概要
・HDFS
　→コモディティサーバを大量に使用。故障発生が前提の設計
・Hadoop MapReduceフレームワーク
　→Googleが検索インデックス作成のため考案。少なくとも3000台までスケールアウトしても性能向上することが知られている。バッチ処理前提。

●Hadoopの利用シーン
おすすめの商品を表示するシステム
・１日に数GB以上
・数ヵ月～数年分を利用
が分析で扱うデータ

RDBMSで扱うには難しい規模のデータを処理する。
HadoopとRDBMSを使い分ける。

●Hadoopの特長
・分析系のデータ集計・抽出といった大容量処理だけではなくう、純バッチの高スループット化など、多数のレコードの処理に向いている
・データを蓄積、変換するといった使い方でコストパフォーマンスが高い

●クラスタの概要（Hadoop1系）
・集中管理型の分散処理

・Hadoop１系には課題が。
　→マスターノードの可用性
　→分散処理の仕組みとしてMapReduceしか支えない
　→分散処理マスターノードJobTrackerの処理ネック

●Hadoop2系
・HDFS上に蓄積したデータをMapReduceだけでなく、様々なアプローチで処理するための仕組み（YARN）を確率
・処理の管理はApplicationMasterの役割
・処理はコンテナによって実行される

●Hadoop最新情報
・2.6.0がリリースされました。
・YARN関係の可用性を向上

・StoragePolicyに応じて配置を変えられる。
　→同一スペックのサーバでクラスタを組む必要はなくなりました。

●Apache Tez
・YARN上での処理に最適化された実行エンジン
・AppicationMasterの起動回数削減
・HiveやPigのクエリ・コードを流用できる。

●大規模ユーザのYARN環境への移行
・Twitter,PaypalなどがHadoop2系に移行している。

【ZabbixとJobScheduler連携による運用システムOSS化の実現】
http://www.slideshare.net/ikedai/osc2014-enterprise-zabbixjobscheduleross

・多くのOSSは用途に特化した形で提供
　→APIをベースに各ツールを連携することがポイント。

・ZABBIX と Job Schedulerに着目したのは高機能＆拡張性の高さ

・ZABBIXは自動化機能が充実
　→監視設定パターン化、監視設定自動化、運用自動化

・JobScheduler
　→ドイツのSOS社が開発

●Jobの考え方
・Standalone Job
・Job Chain
・Schedule
・Job定義は様々な記述が可能

●HyClops JobMonitoring
・12/10 OSSとして公開

●３つのメリット
１．ジョブの失敗や遅延をZABBIXで検知
２．ジョブ実行時の状態の比較をZABBIXで行う
３．ジョブ実行時の高不可に備えた監視設定

HyClopsJMの機能詳細
・JobSchedulerからのアラートをフックして、ZABBIXにアイテム登録可能
・トリガー閾値の自動変更
　→ジョブ実行中のみ有効なトリガーを登録することができる。
　→閾値変更ジョブとして登録

●デモ
うまくいきました。

●HyClopsJMのセットアップ
Chefのクックブックもあるよ！

【大規模商用システムの統合監視を実現するPandora FMS Enterprise】
つかったことがないので、どんなもんかなーと聞きに行ったんですが、

・Zabbixに対抗して機能を取り込んだ
・ただし、目標にしたバージョンが低かった
・最新の2.4には機能で負けています…

という感じ。
UIはPandoraの方がはるかにわかりやすいです。
Zabbixは3.0で大幅にUIが変わるようなので期待。

遂に日本上陸！ 真のハイブリッドクラウド 『VMware vCloud Air』

VMware vCLoud Air
EXTEND YOUR DATA CENTER TO THE CLOUD WITH THE PLATFORM YOU USE, KNOW AND TRUST.

Finally, disaster recovery that's simple, affordable and easy to deploy.
Welcome to VMware vCloud Air Disaster Recovery.

【VMwareのクラウド戦略と『VMware vCloud Air』】
マーケティング向きの話です。

●真の透過的なクラウドを実現する
vCloudとVMwareのプライベートクラウドは
・既存と新規アプリケーション
・シームレスなネットワーク
・共通の管理機能
・共通のサポート

●互換性のないクラウドへの移行はロックインを意味する。

※vCloud Airこそがロックインじゃないの？

●vCloud Airのサービス内容
・オンプレミスの退避先として Disaster Recoveryを提供します。
・リソースプールでの貸し出しが特色です。リソースプールこそがVMwareらしさ。
・アメリカでは１年半前からサービス開始しています。
・オンプレミスの増強としての使用が可能です。単一管理できます。

【『Airの価値は本物か？』ユースケースを徹底検証】
・Ver4.0になるときに、社内公募で"vSphere"の名前を決めました。球＝完全な形、というイメージ。
・Airはどこにでもあるもの、みんなで共有してるもの、との意味を込めています。

※久々に"ShadowIT"を聞きました。
以前は共有ストレージがメインだったが、最近は仮想マシンそのものを勝手に使うのが多い。
　→Amazonの仕業だ！（倉田てつを風に）

●vCloud Airはどんなクラウド？
・いって戻って来れる
・すぐに使える
・安心して使える仮想化基盤
・簡単＆低コストですぐにできる災害対策

☆リソースは実際に使える分です。HAで半分にはなりません。HAはデフォルトでサービスに入っています。

●ユースケース
１．保守切れに伴うクラウド移行
　→90種類のゲストOSがあります。MS-DOS6まで！

２．開発・検証環境のオフロード
　→開発マシンをそのまま本番へ移行できます。
　→Azureより２倍以上速いです。AzureはインスタンスタイプでCPU変わるらしいです。
　→WebClientPluginでパブリックのリソースも見えます。

３．災害対策先としての活用
　→アメリカでのアンケートではオンプレミスでvSphereを利用している企業の７割が災害対策先を持っていなかった。
　→DRしている、という企業でもデータ転送してるだけ、というのが多いです。
　→VM毎に保護する／しないを選択し、vSphereの無償レプリケーション機能で継続的にコピー。
　→Azure,AWSとSLAの数字は一緒だが、基準が違います。

●VMwareでの活用例
・ExchangeServerをオンプレからAirに移行しました。

【まずはこれ！vCloud Airのテクノロジー＆ロードマップ】
今度は技術よりな話。

●コアサービスの違い
１．Virtual Private Cloud
・サーバホスト共有型。ライセンスモビリティは限定的
・CPUは50%予約
・メモリはすべて予約割り当て。オーバーコミット不可
・VPC毎に１つのエッジゲートウェイ
・SLA 99.9%

２．Dedicated Cloud
・専有型のサーバホスト
・CPU／メモリは100%専有
・メモリオーバーコミットが可能
・リソースプールの分割が可能
・複数のエッジゲートウェイ
・SLA 99.95%

●RaaS
・ストレージに非依存
・ディスク輸送による初期データ転送可
・DRのテスト、フェイルオーバーVMの30日の動作が基本サービスに含まれる。
・vSphere5.1以降で使用可能

●サービスの拡張
・現状、ネットワーク帯域は上り下りとも無料
　→将来的には課金するかも。
・ビルトイン型のHA機能
　→HA用にリソースを確保する必要はありません。

●vCloudAirはネットワーク設計の自由度が高い
・エッジゲートウェイの向こうは自由です。
　→DHCPの強要、使えるIPアドレスの制限などはありません。
・専用線、IPsecもサポートしています。

●エッジゲートウェイ
・標準サービス
　→Firewall、SLB、VPN、StaticRoute、NAT、DHCP、IP Routingが標準サービス
・エッジゲートウェイに接続されないネットワークも作成できます。
　→Isolatedネットワーク
・Firewall
　→デフォルトdenyです。
　→横方向のフィルタリングもできますので、DMZ的な使い方もできます。

●vCloudAirとの接続方法
・インターネット接続（標準提供）
・IPsec-VPN（標準提供）
・ダイレクトコネクト
　→コロケーション接続も可能

☆L2延伸はNSXでアップデート予定（現状はちょっと使いづらい）

●移行方法
・OVFによるインポート
・vCloud Connector
　→vCloudAir側のvCCノードはあらかじめデプロイ済みです。
　→オンプレ側はvCCサーバ、vCCノードの仮想アプライアンスをデプロイ
・オフライン転送

●仮想マシンのバックアップ
・DataProtectionServiceでマシンイメージが保存できます。
・オプションでバックアップサービスもあります。

●一元管理
・プラグインでvCenterから同じオペレーションができます。
・カタログテンプレートの自動同期が可能です。

●ロードマップ
・オブジェクトストレージ
・DaaS
・DBaaS
・MBaaS
・分単位課金のインスタンス
などを提供予定

☆ネットワークの自由度が高いのはいいですね。

【さわってみよう。VMware vCloud Air】
簡単に使えます、をわからせるために参加型のデモ。

・仮想マシンのvCPUは16まで。
・OSの起動画面含めて見えます。
　→普通にvmdkから起動する画面が見えました。
・仕込みではないことを確認するために、NATの設定に挙手。
　→普通のL3が設定できます。Internal to InternalのNATも可能。
・vCloudConnectorによるローカルからAirへの移行デモでVMが表示されないトラブルw
・パブリックーオンプレ間で移行したときもサイジングの問題が発生しづらいです。

・最後はDisasterRecovery のレプリケーションデモ
　→レプリケーションタイプに”パブリッククラウドに複製”があります。
　→たいしたことないように見えますけど、DCの選定、バックアップ用のハードウェア選定とかからの手間考えたらどうです？
　→”テストリカバリ”が可能です。

vSphere環境のパフォーマンス／キャパシティ／ログ管理セミナー

【vSphere環境におけるパフォーマンス管理の最新アプローチ】
vRealize Operaitonsを使えば
・パイプラインの待ち発生も監視できます。
・ストレージのレイテンシーも細かく監視できます。
・必要なリソース量は使った量だけでなく、”どれだけ必要とされたか”も加える。
・パフォーマンス、構成情報のレポーティング機能も追加されました。
・レポート作成をスケジューリングすることもできます。
・管理パックを追加することによって、ストレージなども管理できます。
　→6.0向けの3rdパーティパックはまだリリースされてません。
・NWもストレージも全体を俯瞰して管理できます。（NSXのみ、とかではない。）

【事例に学ぶ、仮想環境の運用のキモ】
・ハイパースレッディングによって、仮想マシンのパフォーマンスがあがることはないが、オーバーコミットしやすくなる。
　→２倍程度で問題が起こった経験はない。
・DRSはレベル３にしておけば、4～500VM程度でも１日１回vMotionするかしないかぐらい。
・vRealize Operationsは５分データを180日保存してくれるので、後からの分析が可能。
・需要ベースでのオーバーコミット方針はvRealize Operationsみたいなツールを使わないと健全性の担保が難しい。
・健全性の評価は仮想マシンレベルで行いたい。
・”いつもと違って負荷が高い”→健全性のスコアが悪い。
・１次切り分けはフロー（チェックリストでok）を作っておくとスキル／ナレッジトランスファーも楽になるよ。
・カスタムダッシュボードには閾値、判断指標を埋め込めるので手順書と首っ引きにならなくて済む。

【仮想環境に最適なログ管理とは？】
vRealize Log Insightの話。

・理想的なログの管理サイクル
　→現実はほど遠いですね…

・ログは非構造化データです。とりあえず集めてから機械学習で分類します。
　→一部製品はエージェント側であらかじめ分類してから転送します。

・2.5からはコンテンツパックのダウンロードはメニューからたどれます。どこかから拾ってくる必要はありません。
・Windows/Linuxのエージェントをご用意しました。
・ADの情報を送りたかったらエージェントのiniファイルに追加してね。
　→それはダメだろ…

・カスタムクエリはダッシュボードにも登録可能。

●デモ
・ネットワーク機器からのログを転送しておいて後からトラブルシュートするデモ。
　→社内でやりたいですね。ネットワーク機器はSyslog転送で使えます。

Hinemos World 2014

【Hinemos5.0 ロードマップ】
公式キャラクタ「もにた」が誕生しました！
https://pbs.twimg.com/media/B3_qhQmCMAAd1Hh.jpg

●5.0は
・RPMでインストールできます
・Webクライアントになります
　→全機能が使用できます。従来型のリッチクライアントも提供。
・ノードサーチ機能
　→IPを範囲指定して複数サーバの一括登録が可能
・自動デバイスサーチ機能
　→追加デバイスを検知します。

・マルチマネージャ接続
　→１台のHinemosクライアントで複数のHinemosマネージャに接続できます。

・性能改善
　→10000ノード、100000ジョブが可能。ver4.1比で３～４倍の性能向上

●Auto-Managed Infrastructure
・環境構築
　→Hinemosクライアントで設定すれば、全サーバ向けに環境構築が可能

例：ファイル配布
・配布先に応じて、ファイルの内容を置換可能。
　→%IPADDR%など。（Hinemosマネージャが持つ情報で置換して配布）
　→ファイル更新時は配布前に差分をGUIで確認可能

☆SSH,WinRMを使用しているので、Hinemosエージェントは不要！

●監視の強化
・新しい監視
　→HTTPシナリオ監視、JMX監視

●ジョブの強化
・正常終了するまで繰り返し実行
・テスト実行

●対応OS
・マネージャ
　→RHEL/CentOS/OracleLinux 7 のみ…

●デモ
・iPadでHinemosマネージャに接続
・100台のサーバを一括登録
・環境構築機能で100台にapacheをインストール
・HTTPシナリオ監視の設定を追加
・100台のサーバにエージェントをインストール

うーん、やっぱりsshログインでroot＆パスワード認証は気持ち悪い…
しかも、パスワードをDBに登録しておけるようにするとか。

●Hinemosオプション
・HAオプション
　→共有ストレージなしでできます。フェイルオーバ時のジョブ／監視もロストしません。

・クラウド管理オプションとVM管理オプションを統合して、xCloud管理オプションとします。

●その他
☆docker対応の機能も開発中。

【ルールエンジンを使った運用管理自動化のすすめ】
http://atomitech.jp

BRMSって知らなかったけど、いろいろあるんですね。
複雑な携帯料金プランの計算にも使用しているようです。

●ルールエンジン機能を持った自動運用管理機能の適用例

※重要顧客のシステムから発報されたエラーが他のシステムの大量アラートに埋もれる、ってのは例が悪すぎ。重要顧客なら別に担当者おくべきだろ…

まあ、それはそれとして。
判断基準を 手順書から拾うのではなく、ルール化してアラートメールの抑止、監視対象から除外などを自動化するのは楽でいいと思う。

実装してくれるベンダーも募集！だそうです。

【Hinemos徹底解剖～監視編～】
・フィルタチェックはエージェント上で行います。
・WindowsイベントログはWindows PowerShellを使用して収集します。
・カスタム監視はエージェントがサーバーから監視間隔などを取得してキャッシュしています。その設定に従って、エージェントが収集して送信します。サーバ起点ではありません。
・エージェントはマネージャと定期的に通信します。エージェント側の即時反映用UDPポートにサーバからアクセスがあった場合にはエージェントが変更された値を取りに行きます。
・マネージャが停止していた場合、エージェントからの通知処理はリトライしません。
・ログローテーションはファイルサイズの変化で判断します。
・Hinemos4.1からログファイル名の指定に正規表現が使用できるようになりました。
　→apacheのようにローテート後に日付が付与されるようなタイプは正規表現を使わないようにしましょう。

【Hinemos運用管理のすすめ 監視編】
・OS同梱パッケージとHinemosだけでインストールできます。
・内部DBとしてPostgreSQLを使用しています。

pingを"ピング"って発音されると違和感が…

・ノードは複数スコープに所属可能。

・通知はジョブからも利用可能
・ログエスカレーション通知はsyslog形式で外部ログサーバや上位のHinemosサーバに送信する。

・監視設定は14種類の監視種別から選択します。
・Utilityオプションを使えば設定値のXML-Excel変換が可能です。
・ジョブ制御に営業日カレンダーを設定できますが、監視設定でも同じカレンダーが使えます。
・レポーティングオプションを使えば、自動的にレポート作成してメール送信ができます。

●まとめ
☆システム監視ソフトウェアを使いこなすことに悩んでいませんか?
・監視設計により注力
・通知への対処により時間をかける
ためにHinemosが役立ちます。

来場者抽選の大当たりということで本をいただきました。