「OpenStack最新情報セミナー」に行ってきた！

１２月３日

OpenStack最新情報セミナー

に行ってきた！まずは、昼の部をメモメモ

---

■OpenStack環境構築入門

ユーザー、テナントの管理
・OpenStackのアカウント構造
　テナント
　　複数のユーザーを束ねたグループ
　ロール
→はじめにテナントdemo,ユーザーdemoがある

・テナント（プロジェクト）の作成

・ユーザーの追加
　→主プロジェクト：複数のプロジェクトに所属することがある

・新しいユーザーでログイン
　　→標準的なパブリックイメージを管理しておく
　　→外部ネットワークも管理者設定
　　　自分でネットワークをつなぐ

・テナントのリソース制限
　　→クォータの設定でリソース制限が可能

・ネットワークトポロジー
　　EXTNET
　→ソフトウェアのルーターを作成する

ネットワークの管理
・ネットワーク構造図
　Open vSwitchで
　フローティングIP
・仮想ネットワーク図

・新規ネットワークの作成
　　外部は設定してあるとする
　　ネットワーク→サブネット→DNSの設定
・新規ルーターの作成
・ルーターと外部ネットワークの接続
・ルーターと内部ネットワークの接続
　　→テナントごとに分けるようなSDNも

OSイメージの管理
・参考：標準的なイメージがある
　KVMで
　cloud-init：SSHとか、インスタンスに必要な初期的処理をまとめたもの
　イメージの作りこみ
　　　共通のもの
　　　Chef,Ansibleで
・Cinderの動作
　　　LVMでやっている
　　　差分ディスクをつくるほうがあってる？
・Ubuntu Serverイメージの登録
・キーペアの作成
　　　公開鍵をコピペする

コンピュートノードの追加
・open vSwitchに接続
・Nova,Neutronの設定
・動作確認

OpenStackの監視リファレンス
・Nova Controllerノードの監視
　　ポート
　　プロセス
・MySQLノード、RabbitMQノードの監視
・Keystoneノード監視
・Glanceノード監視
・Cinderノード監視(tgtdも）
・Dashboardノード監視(apache2）
・Networkノード(neutron)
・Nova Computeノード
・Swift-Storageノード

まとめ
・コマンドのマニュアルを読もう
・Open vSwitch以外のSDNとの連携
・Juno版手順書絶賛改訂中

---

■OpenStack運用管理最前線
　ミラクルリナックスの人

・OpenStackSummitParisで聴講した内容
・Tech Talk：Hatoholを使ったSIPサービスのQoSソリューション

OpenStackSummitParis　参加した理由
・OpenStackに関連したサービスを計画中
・Hatohol

注目したセッション
・運用管理
　　監視、障害管理、パフォーマンス、DRなど
→構築と運用に苦労

３つの事例
・大量VMの一斉起動CERN
・Ceilometerを使った不適切行為の検出(Cisco)
・大規模監視の大量アラート(RackSpace)

大量VMの一斉起動CERN
・CERN：加速器
・問題
　１２００VM立ち上げに４時間
　　→スケジューラーとGlanceがボトルネック
・対策
　１．VMイメージをNovaキャッシュに事前配布
　２．事前配布の効率化
　　　　VMイメージの取得、圧縮
・提案
　１．Novaのプロキシサポート
　２．Glance自身の圧縮イメージサポート

Ceilometerを使った不適切行為の検出(Cisco)
・不適切な利用をどうやって検出するか
　１、情報収集
　　　Ceilometerを使ってデータサンプル
　２、機械学習
　３．結果評価

・事前学習
　ベンチマーク HBench
　高負荷
　アイドル状態

・不適切使用
　DDOS
　仮想通貨のマイニング

・アルゴリズム
　　PCA
　　SVM
　　ランダムフォレスト→いちばんよかった
　　ナイーブベイズ
　　Logistic リグレッショん
　　ニューラルネットなど　

大規模監視の大量アラート(RackSpace)
問題
・障害が発生すると大量のアラート→何を調べたら
・リソース枯渇で突如サービス停止

・対策
１．すばやく原因特定
　　イベントとアラートの相関を取る
　　→必要ないアラート抑制
　　アラート相関のマッピング
　　　apacheでエラーになったらholizonで当然エラーになるのは抑制する

２．リソース枯渇の予測
・測定対象リソースの平均値や最大値
・一定期間中（例えば１週間）の変化率を求めて、リソース枯渇時期予測
　標準偏差を使うと精度上がる
→周期的に変化するパターンの対応

Hatoholを使ったSIPサービスのQoSソリューション
・Zabbixのスケールアウトの限界：DB
→Jun27,2013誕生日
・統合運用ツールとして生まれ変わった
　　https://github.com/project-hatohol/hatohol

統合管理内容
・イベント管理
・インシデント管理
・ログ管理
・リソース管理

OSSの連携で運用統合：Hatoholでやること
イベント管理
　　Nagios
　　Zabbix
　　Ceilometer
インシデント管理
　　RedMine
ログ管理
　　Fluentd
　　Zabbix
リソース管理
　　SSH

ソフトウェア構造
・Hatohol　フロント
・REST+JSONで→カスタマイズが面できる
・Hatohol　サーバー


機能：統合監視

機能：アクセスコントロール
・マルチテナント監視

事例：A QoS Solution for SIP Service

---

■OpenStack Neutronの機能概要
・ML2プラグイン
　　DVR→うごかしてみた
　　L3HA
　　IPV6
・Neutronプラグイン
　　Open Contrail動かしてみた

・自己紹介／会社紹介

OpenStack　Neutron
・Openstackの基本モジュール
　Nova
　ネットワーク
　ストレージ
・Openstackの概念図
・Openstackのプロジェクト
　　→Neutron：ネットワーク

Neutronの基本的なモデル
・Neutronの実現するネットワーク
　　・マルチテナントネットワーク
　　　　複数テナントのプライベートネットワーク制御
　　・API経由の制御
　　　　ベンダー固有のコンフィグの排除

・Neutronの基本的なモデル
　SNAT,IPマスカレーと
　ほらいずんでみると・・

Neutronの実装
・L2ネット
　　複数のNova　ComputeでL2ネットワーク
・L3ネット
　　ネットワーク間ルーティング
・DHCPサーバー
　　IPアドレス払い出し
・メタデータ
　　ぷろきし

Neutronの構成概要
・Neutronの構成
　　プラグイン、DB
　　APIエクステンション

Neutronのプラグイン
・ML2プラグインに統合されてきている

ML2プラグイン
・Neutron標準
・複数のプラグイン同時利用可能
　　・Typeドライバ
　　・メカニズムドライバ
・VXLANとOpen　ｖSwitchを使った場合
　　使用するエージェント
　　　Neutron
　　　L2
　　　L3
　　　DHCP
　　　メタデータ

・ML2-プラグインを使った場合のプロセス
　SNAT：namespaceで作る
　Qrouter：
　DHCP→DHCPマスク

・通信フロー
　　DHCP
　　同一仮想ネットワーク間通信：おめあてにパケット
　　別仮想ネットワーク：QRouter（デフォルトゲートウェイ）→お目当て
　　　　→どういつマシン内でも：通信料増える
　　SNAT：NATされて外の世界
　　フローティングIP：QRouterでNAT

ML2プラグインまとめ
・冗長化
・トラフィック集中問題：EAST⇔WEST間通信が多い
・プロセス大量問題

ML2プラグインの新機能
・L3HA
　　ネットワークノードの機能を冗長化

・DVRを使った場合の構成例
　　QRouter

・見え方は基本変わらない。

・通信フロー
　　DHCPは変わらない
　　同一仮想ネットワーク：変わらない
　　別の仮想ネットワーク：QRouter→直接相手にいく
　　SNAT：かわらない
　　FloatingIP：FIP→NAT→外のはずが。。。そう動かない
　　　→QRouterのIPアドレスを確認しよう

・L3HA
　　ネットワークノードの冗長か
　　IPアドレスの冗長か　VRRP
　　　Keepaliveが帰らない
　　　GARPを送信→ARPキャッシュを更新

　　OpenStackユーザー会の人の資料みるとわかる

・ML2－Plugin　IPV6サポート

Juno以降
　冗長か：ネットワークノードの冗長か
　トラフィック集中問題：分散ルーティング可能
　プロセス大量問題
　Namespace大量問題

OpenContrail
・ML2とやれること変わらない
・仮想のLBなど作れるL3VPN、
・WebUI／RESTAPI
・BGPベースのVPN

プロセス：シンプルに見えている
通信フロー
　・同一は同じ
　・別のとき：vRouterで処理（Qrouterいらない）
　・SNAT：
　・フローティングIP：そのまま

サービスチェイニング
・仮想サービスの組み合わせ
・L3VPNとL2VPNの連携
・アナリティクス機能

OpenContrail
・プロセス大量問題、ネームスペース大量問題は起こらない

事例：
TCP cloud

セミナー資料すらいどしぇあ
最近YouTubeチャンネル開設
　チャンネル登録してね

３つのおねがい
・アンケート
　　（Nuage Network)

「大規模バッチシステム構築のソフトウェア革命」を聞いてきた

１２月２日、
超高速開発＆エンタープライズアジャイル２０１４
に行って来た！のつづき
順番はちがうが、つぎ

大規模バッチシステム構築のソフトウェア革命

をメモメモ

---

・バッチシステムの肥大化
　属人性
・４つのポイント
　　飛躍的な生産性の向上
　　肥大化の防止
　　見える化
　　性能、品質は劣化しない

飛躍的な生産性の向上
・業務ロジックがうめこまれる
　　→仕様をリポジトリに登録
・リポジトリに登録
　　出力単位
　　入力（テーブル・リレーション・ソート／属性）
　　加工：いかにビジネスルールがかけるか
　　なにを出力（明細表／クロス集計）
・高度な集計
　　重点品
　　通常販売
→出力定義をいじるだけで変えられる→生産性向上

なぜ、
・業務ロジックの独立
　　媒体は選択になっている
・業務ロジックそものもの独立
　　定義も
・日付のコントロール
・属性・コード値／選択
・処理の自動化

自動化
　・ループ処理を書かずに記述
データ構造変換

　　メタデータの一元管理

　　どんなバッチ処理でも

ポイント２　システムの肥大化防止
・ETLプログラム→処理数をへらした
・既存のプロセスに簡単に乗っけられる

従来：膨大な処理、中間DB
→１つの処理で複数の目的
→１つの処理で複雑な加工演算

ETLツールの場合

ポイント３：見える化
・ツールの中で自動的に管理
・テストケース漏れ：そんなところに影響あった？
　　影響分析
・実装と設計書が合う→保守性
・１０人月の作業を数分で

ポイント４：高品質
・I/Oをいかに減らすか→処理数の削減
・ストリームデータ処理＝シーケンシャル処理で作れるか

プロジェクト面
・PMOがひつよう→いない→リポジトリ

PDCA

プラットフォーム
Javaが動けば動く

今後
・モデルドリブン
・ストリームデータ処理

サンプル概要
・添付の２ページの定義だけで出来ている

「超高速開発ツールSapiensのご紹介」を聞いてきた

１２月２日、
超高速開発＆エンタープライズアジャイル２０１４
に行って来た！のつづき

超高速開発ツールSapiensのご紹介

をメモメモ

---

・２１年目になる
　イスラエルでつくられる
　IBM　AS-400,Windows,Linux,Unixでうごく

・プログラムなしでアプリケーション作れる

・作った人まだいる
　考えた理由
　　時間と金をかけた割りに、なかなか良いものできない
　　　プログラムの生産性きわめて悪い→ものすごい人いる→こんらん
　　　仕様をがんじがらめに決める→やるまえに仕様決まる理由ない
　　　１９８０年代→プログラムを一切なくす→ウォーターフォールから脱却
　　プラットフォーム前提にアプリを作る
　　　→どの機械でも本当はいい
　　　　環境を意識しないでアプリを作る

・ネガティブなことは書かなくて良い
　　→ポジティブシンキング
　　　　在庫引き当て→あとは推論する
　　　　図で書く

・お絵かきしながらアプリケーションを作る
　　→プロトタイピングスパイラル

・データベースを持っている
　　→DB1→Oracle,DB2にマッピング
　　　階層型DB(IMS)も

・データモデル→ルールモデル

・企業も苦しい

・JMSにすべていれて、サーバーで実行する

---

＜＜所感＞＞

つまり、統合CASEツール？