7月26日OpenStack最新情報セミナー(2017年7月)を途中から聞いてきたので
(途中で帰ったけど)メモメモ
(途中から)
OPNFV
・OPNFV
関心様々:アジアはハード売りたいんだろうな
トランスフォーメーション・メタモルフォーゼ
・OPNFV蝶の世界を先取り
・今のオペレーターさんさまざま
→蝶を目指して
■OPNFV Docter
・自己紹介
・Doctorがやっていること
大前提:NFV アプリの冗長構成
NFV前
仮想化:ハードの状況は見えない→ハンドオーバーできない
インフラは壊れたことは知っている:しらせる
・Doctorが目指している世界
IaaSプロバイダー
VMは壊れることがあります。→とまります
サービスプロバイダー
動いていない →切り替え
エンドユーザー
サービス使えない →気づかない
・Doctor Project
まの
通知
アクションは上位に任せる
・成果
デザイン
OPNFVいれなくても使える
デモ:YouTubeにあがっている
・要件
リソースの状態
すぐに通知
モニタリングの機構
こリレーション
・機能足りない:OpenStack
イベントドリブンで動くようにする
・Doctorブループリントつ in OpenStack
・関連するOpenStackの動き
Admin API
違うバージョンのNOVA
テレメトリ情報をDBへ
テレめとりがイベントベースに
せーろメーター/Aodh-イベントアラーム
・Nova-フォースダウンを提案
・Doctorインテグレーション
インストールのインテグレーションしている
リリース:改善されている→リリースマネージャー
・Doctor CI Job
・テスティングツールのえんハンスメント
大規模デモテストできるように
admin出ない人が見れないチェック
Profiler
Doctor Status:大体終わってきている(やりのこしているものもある)
・障害通知→メンテナンスで使える
ビデオ見れる(wikiにいけば)
Novaのタグ機能つかっている
リタイヤメント
■NFVアプリケーションをOpenStackで動かすために
・NECがんばってるよTime!
・NFV概要(NFVとは)
専用のファームの世界観から→仮想化されたネットワーク機能(VNF)
NFVの課題
・キャリアグレード品質
下回り:壊れないハードウェア
またがったことによる問題
ハード障害が見えなくなる→切り替えどうする!
SCTP:経路も含めた冗長
・NECのNFV基盤に対する取組
2012年から
OpenStackあったが、当時要件を満たせなかった
世界初vEPC商用稼働:独自基盤で
ETSI(えっちー)NFV→OpenStackが標準に
→IceHouseを使うものの・・・
RedHatと協業→OpenStack利用
NECCSを発表
独自基盤時代
・VNFに必要な要件を実装
・OpenStack Controller相当の機能実装
・ComputeServerでの機能実装
DPDK-VS
リソース優先制御
KVMモニタリング
HW障害通知
・NFVI施策:リソース優先制御
施策1:CPUリソース優先制御:NICE値を変える
→だれがどうスケジューリングする?
施策2:ネットワークIO優先
施策3:ディスクIO優先
NW性能向上:DPDK-VS、DPDK-VxLAN
OpenStack改造時代
・ETSI NFV
どうやらVIMはOpenStackがデファクトスタンダードらしい
RedHatと提携、Communityでの機能実装を促進→kiloで
RedHat社と共同でOpenStackのキャリアグレード
プラグイン:作りこみ大部分 拡張性ボロボロ
→自前で作った
・HW構成を意識した配置
SR-IOV
EPT Hugepage
性能比較:
・OpenStack利用時代:今どうしてる
VNFを動かすためのOpenStack機能はおおむね実装完了
→パラメータチューニング
ヒーリング:できるだけ最大で動けるように
OpenStack以外の基盤コンポーネントの効率的な構築
運用改善
・現在の営み
AIを活用し、NFV化による解析煩雑性を解消
人のせいにしたい世界観→ログとログの関係
リアクションマニュアル→次のバージョン→一生慣れない
■OpenStackを利用したNFVの商用化
・自己紹介
・ネットワーク仮想化のメリット
つながりやすさ
信頼性
すらいどしぇあみてね
2.商用化の取り組み
ドコモの取り組み
2005ねんよりネットワーク仮想化
ETSI NFV
まの:ぜんたい
OpenStack,KVM
対象とするキャリア向けVNF
リアルタイム処理思考
高いネットワークI/O
VNFのVNFcレベルでHA・FailOver
L2/L3レベルでのHA機能
テレコム向けVNFの特徴
1機能=3~VNF→50VMとか必要になる
動かす:1000VM?もっと?
ネットワーク複雑
VNFの更新:ここでおかしくなる
1個でも失敗するとロールバック:ロングトランザクション
・VNFの高い性能要件を満たすために
仮想CPUはオーバーコミットしない
仮想メモリーはオーバーコミットしない
DVS-DPDK
SR-IOV
・SR-IOVの活用
SR^IOVとvSWの使いところ
仮想NICなど、SR-IOVの制約
SR-IOVの中身
L2,L3SW
・実際は?
基盤ベンダとVM側のドライバーが違い、大変
パケットがドロップ
切り分けはほぼ不可能
オフロード機能
・HW差分を隠ぺいしたうえでサーバー内部構成を意識
DPDK OVSの性能のためにCPU SockettoNICを考慮
OpenStack活用+SR-IOV、ホスト設計差分による課題
論理識別子の命名方法の工夫による解決
識別の工夫による結果
・ヒーリング
ATCA時代:壊れたときにダウンさせる(中途半端にしない)
方法
オートヒーリング
VNFM
VIM
マニュアルヒーリング
オートヒーリングの動作
キャリアネットワーク関連からの解決法
障害情報の正規化
Fencing機能
作業自動化
ハードウェア差分をなくすための障害情報の統一化
OPNFV Doctor
・今後
コアネットワークの進化
仮想化進める
5G時代の新たなビジネスを実現するネットワークの発展
(途中で帰ったけど)メモメモ
(途中から)
OPNFV
・OPNFV
関心様々:アジアはハード売りたいんだろうな
トランスフォーメーション・メタモルフォーゼ
・OPNFV蝶の世界を先取り
・今のオペレーターさんさまざま
→蝶を目指して
■OPNFV Docter
・自己紹介
・Doctorがやっていること
大前提:NFV アプリの冗長構成
NFV前
仮想化:ハードの状況は見えない→ハンドオーバーできない
インフラは壊れたことは知っている:しらせる
・Doctorが目指している世界
IaaSプロバイダー
VMは壊れることがあります。→とまります
サービスプロバイダー
動いていない →切り替え
エンドユーザー
サービス使えない →気づかない
・Doctor Project
まの
通知
アクションは上位に任せる
・成果
デザイン
OPNFVいれなくても使える
デモ:YouTubeにあがっている
・要件
リソースの状態
すぐに通知
モニタリングの機構
こリレーション
・機能足りない:OpenStack
イベントドリブンで動くようにする
・Doctorブループリントつ in OpenStack
・関連するOpenStackの動き
Admin API
違うバージョンのNOVA
テレメトリ情報をDBへ
テレめとりがイベントベースに
せーろメーター/Aodh-イベントアラーム
・Nova-フォースダウンを提案
・Doctorインテグレーション
インストールのインテグレーションしている
リリース:改善されている→リリースマネージャー
・Doctor CI Job
・テスティングツールのえんハンスメント
大規模デモテストできるように
admin出ない人が見れないチェック
Profiler
Doctor Status:大体終わってきている(やりのこしているものもある)
・障害通知→メンテナンスで使える
ビデオ見れる(wikiにいけば)
Novaのタグ機能つかっている
リタイヤメント
■NFVアプリケーションをOpenStackで動かすために
・NECがんばってるよTime!
・NFV概要(NFVとは)
専用のファームの世界観から→仮想化されたネットワーク機能(VNF)
NFVの課題
・キャリアグレード品質
下回り:壊れないハードウェア
またがったことによる問題
ハード障害が見えなくなる→切り替えどうする!
SCTP:経路も含めた冗長
・NECのNFV基盤に対する取組
2012年から
OpenStackあったが、当時要件を満たせなかった
世界初vEPC商用稼働:独自基盤で
ETSI(えっちー)NFV→OpenStackが標準に
→IceHouseを使うものの・・・
RedHatと協業→OpenStack利用
NECCSを発表
独自基盤時代
・VNFに必要な要件を実装
・OpenStack Controller相当の機能実装
・ComputeServerでの機能実装
DPDK-VS
リソース優先制御
KVMモニタリング
HW障害通知
・NFVI施策:リソース優先制御
施策1:CPUリソース優先制御:NICE値を変える
→だれがどうスケジューリングする?
施策2:ネットワークIO優先
施策3:ディスクIO優先
NW性能向上:DPDK-VS、DPDK-VxLAN
OpenStack改造時代
・ETSI NFV
どうやらVIMはOpenStackがデファクトスタンダードらしい
RedHatと提携、Communityでの機能実装を促進→kiloで
RedHat社と共同でOpenStackのキャリアグレード
プラグイン:作りこみ大部分 拡張性ボロボロ
→自前で作った
・HW構成を意識した配置
SR-IOV
EPT Hugepage
性能比較:
・OpenStack利用時代:今どうしてる
VNFを動かすためのOpenStack機能はおおむね実装完了
→パラメータチューニング
ヒーリング:できるだけ最大で動けるように
OpenStack以外の基盤コンポーネントの効率的な構築
運用改善
・現在の営み
AIを活用し、NFV化による解析煩雑性を解消
人のせいにしたい世界観→ログとログの関係
リアクションマニュアル→次のバージョン→一生慣れない
■OpenStackを利用したNFVの商用化
・自己紹介
・ネットワーク仮想化のメリット
つながりやすさ
信頼性
すらいどしぇあみてね
2.商用化の取り組み
ドコモの取り組み
2005ねんよりネットワーク仮想化
ETSI NFV
まの:ぜんたい
OpenStack,KVM
対象とするキャリア向けVNF
リアルタイム処理思考
高いネットワークI/O
VNFのVNFcレベルでHA・FailOver
L2/L3レベルでのHA機能
テレコム向けVNFの特徴
1機能=3~VNF→50VMとか必要になる
動かす:1000VM?もっと?
ネットワーク複雑
VNFの更新:ここでおかしくなる
1個でも失敗するとロールバック:ロングトランザクション
・VNFの高い性能要件を満たすために
仮想CPUはオーバーコミットしない
仮想メモリーはオーバーコミットしない
DVS-DPDK
SR-IOV
・SR-IOVの活用
SR^IOVとvSWの使いところ
仮想NICなど、SR-IOVの制約
SR-IOVの中身
L2,L3SW
・実際は?
基盤ベンダとVM側のドライバーが違い、大変
パケットがドロップ
切り分けはほぼ不可能
オフロード機能
・HW差分を隠ぺいしたうえでサーバー内部構成を意識
DPDK OVSの性能のためにCPU SockettoNICを考慮
OpenStack活用+SR-IOV、ホスト設計差分による課題
論理識別子の命名方法の工夫による解決
識別の工夫による結果
・ヒーリング
ATCA時代:壊れたときにダウンさせる(中途半端にしない)
方法
オートヒーリング
VNFM
VIM
マニュアルヒーリング
オートヒーリングの動作
キャリアネットワーク関連からの解決法
障害情報の正規化
Fencing機能
作業自動化
ハードウェア差分をなくすための障害情報の統一化
OPNFV Doctor
・今後
コアネットワークの進化
仮想化進める
5G時代の新たなビジネスを実現するネットワークの発展