経営の期待に応える OpenStackの導入検討、次の一歩 や、やってやる、やってやるぞ！新型のOpenStackがなんだ！ Satoshi Naito <[email protected]> Senior Solution Architect, Red Hat K.K. 2015.11 スピーカー 内藤について ● ● ● 出身 – 沖縄 好きな言葉 – 稔るほど頭の垂れる稲穂かな 趣味 – サーフィン – ガンダム 仕事 エンドユーザ様、パートナ様のOPENSTACKの導入や活用、 イノベーションの加速を支援させて頂いています 2 アジェンダ ● 経営の期待と現実、現場のジレンマ ● 導入検討における2つのハードル ● 経営への説明 – ● ● OpenStackとオープンイノベーション 導入構成の検討 – 検討する上での心構え – プラグインの検討 Appendix： – グランドデザインでの検討項目例 3 ある日 OPENSTACKを検討しなさい ！！ 4 調査してみたものの、、、 仮想化基盤とクラウド基盤は どうやら何か違うようだ インストールしたが動作しない アップデートしたら動作しない 今日起動したら動作しない コンポーネント多すぎ。。。 わけがわからない。。。。 ！！！！ 何から考えれば良いのか？ 新しいバージョンがリリースされました！！ 5 そして、、、 どれくらいコスト削減できるのか？ なぜ必要なのか？ 本当に必要なのか？？ 今やらないといけないのか？？？ ！！！！！！！！ 6 導入における2つのハードル OpenStack導入の『プロジェクト化』にむけて ● 経営への説明 – ● OpenStackへの正しい理解、経営視点での導入目的 導入構成の検討 – 本番利用を想定した構成 7 経営への説明： なぜOpenStackを導入したのか 導入したユーザの声 – 運用効率の改善 – 組織におけるイノベーション能力の強化 – コスト削減 – オープンな技術の採用/ロックイン排除 8 経営への説明： なぜOpenStackを導入したのか 導入したユーザの声 何となくわかるが、、、、 OpenStackでないとダメなのか？ – 運用効率の改善 – 組織におけるイノベーション能力の強化 何の話をしているのか もはやよくわからない。。。 今より下がる気がしない。。。 – コスト削減 今の基盤でそんなに困ってない。。。 – オープンな技術の採用/ロックイン排除 9 ユーザの声を理解するためには、2つの背景を知る必要があります ユーザがOpenStack上で実現しようとしていること OpenStackそのもの 10 ビジネスに要求される競争力 競争優位のイノベーションは多くのチャレンジによって生まれる より多くのチャレンジが、より多くのイノベーションを起こし、より高い競争力になる 結果 Challenge 会社 A 結果 Challenge 結果 結果 Challenge Challenge 会社 B 優位 結果 Challenge Time より短期間でより多くのチャレンジを実現する IT システムが必要不可欠 11 開発チームの取り組み例： 継続的インテグレーション 単体テストを自動化し、ソースコードの変更の たびに『頻繁に繰り返し』テスト結果を得る ● 継続的インテグレーションのメリット – 自動化による作業コストの低減 – 早期フィードバックによる手戻りの低減 – 品質の維持、etc... インフラへのインパクト 開発の自動化が進むほど、手作業を前提と したインフラ側作業がボトルネックに。 12 OpenStackの開発コミュニティとは OpenStackコミュニティは、IAASにおけるオープンイノベーションの中心 ● OpenStack Foundation によるコミュニティリーダーシップ – ● OpenStackコミュニティおよび関連コミュニティの巨大なエコシステム – ● ベンダー中立、極めて良好なコミュニティ運営 関連コンポーネントもOpenStackを強く意識し開発が加速 様々なユーザやベンダが参加する、R&Dの開かれた開発プロジェクト – 利用ユーザからの各種提案やソース提供等、様々な貢献 – 3万人を超えるOpenStack開発者によるイノベーション 13 OpenStackの提供するクラウドとは オープンイノベーションに支えられ進化し続けるクラウド ● オープンソース & コモディティサーバをベースに構築 ● APIで各種クラウドリソースを抽象化した『自動化するためのシステム』 ● クラウド管理者は、自動化した結果をクラウドサービスとして提供 ● クラウドユーザは、自動化された結果をクラウドサービスとして利用 ● ● 例： クラウドユーザは、『まるで占有しているかのように、サーバ、ネットワー ク、ストレージ等をセルフサービスで制御できる』 クラウドサービスの仕組み改善、新規クラウドサービス等、継続して進化 14 OpenStackを導入するとは、 ビジネスの競争力を生み出すITを実現するために IAASにおけるオープンイノベーションの集大成を導入すること であり OpenStack内外のイノベーションサイクルに参加すること です OpenStack導入が遅れるほどシャドーITは進行します 15 導入における2つのハードル OpenStack導入の『プロジェクト化』にむけて ● 経営への説明 – ● OpenStackへの正しい理解、経営視点での導入目的 導入構成の検討 – 本番利用を想定した構成 16 packstackでインストールしてみたが、、、 インストールしたが動作しない アップデートしたら動作しない 今日起動したら動作しない コンポーネント多すぎ。。。 わけがわからない。。。。 ！！！！ 何から考えれば良いのか？ 新しいバージョンがリリースされました！！ 17 packstackでインストールしてみたが、、、 インストールしたが動作しない アップデートしたら動作しない 今日起動したら動作しない コンポーネント多すぎ。。。 わけがわからない。。。。 ！！！！ 何から考えれば良いのか？ 新しいバージョンがリリースされました！！ 18 レッドハットの製品化プロセス コミュニティ向け エンタープライズ向け RED HAT ENTERPRISE LINUX オープンソース コミュニティ RED HAT ENTERPRISE LINUX OPENSTACK PLATFORM ● RDOはRHELにおけるfedoraと同じ位置付け ● RDOでは、packstackで触ってみる、までにしておく レッドハット OPENSTACK 評価版 検索 19 OpenStackのコンポーネント クライアントPC パブリックネットワーク テンプレート イメージ保存 テンプレート イメージ検索 Webコンソールアクセス Network Node 仮想ネットワーク作成 Swift 仮想マシン イメージ Glance Horizon Neutron Nova テンプレート ダウンロード Nova Nova Nova Compute Compute Compute 管理ネットワーク 仮想マシン起動 Keystone （RabbitMQ） （MariaDB） 認証サーバ メッセージキュー データベース 20 ブロックボリューム提供 Cinder LUN LUN LUN 検討する上での心構え “OpenStackはシステムです” ● クラウドコントローラの基本構成 – Webサーバ - APPサーバ - DBサーバ – 非同期連携にメッセージキュー（RabbitMQ） 基盤チームという観点で見ると、 従来のシステム ： 社内のAPPチームが開発したアプリケーションを配備 OpenStack ： OpenStackコミュニティが開発したアプリを配備 基盤チームにも継続的インテグレーションの考え方が要求される 21 クラウドサービスの継続的な改善のために 2つのOpenStack環境を用意 ● クラウドユーザ向けOpenStack本番環境 – ● クラウドユーザがセルフサービスで利用するための環境 クラウド管理者向けOpenStack開発環境 – クラウド管理者が様々な試行錯誤をするための環境 ● サービスの開発/検証/改善他 ● アップグレード他 22 プラグイン（サービスのバックエンド）の検討 クライアントPC パブリックネットワーク テンプレート イメージ保存 テンプレート イメージ検索 外部のSDN製品と連携 Webコンソールアクセス Network Node 仮想ネットワーク作成 Swift 仮想マシン イメージ Glance Horizon Nova Nova Nova Compute Compute Compute Neutron Nova テンプレート ダウンロード 管理ネットワーク 仮想マシン起動 Keystone （RabbitMQ） （MariaDB） 認証サーバ メッセージキュー データベース 23 ブロックボリューム提供 Cinder 外部のストレージと連携 LUN LUN LUN Neutronプラグインの検討 Neutron： ネットワーク仮想化サービス ● ● 本番を見据える場合は、必ず3rdパーティ製品を組み合わせる – OpenStackに同梱されるOpen vSwitch（以下OVS）は利用しない – OVSは性能的ボトルネックと単一障害点を同時に解消できない 3rdパーティ製品検討の注意点 – OpenStackに対応する製品を選択 – 製品によって、機能/構成/価格が大きく異なる – 稼動後のNeutronプラグイン変更は困難 – 検討段階初期からネットワークチームと協力し検討 24 ストレージ検討エリア 1 Cinder： 仮想ディスクイメージの管理サービス ● Amazon EBS相当の機能 ● 仮想マシン用ボリューム用に外部ストレージを利用 ● – OpenStackに対応する製品を選択 – OpenStack対応でも対応機能にバラつきがあるため注意 – Cinderコントローラ側にハードウェア要件がある場合もあり 外部ストレージは要件に応じて複数の外部ストレージを接続可能 – 性能重視： 性能（IOPS） > 容量 – 容量重視： 性能（IOPS） < 容量 etc... 25 ストレージ検討エリア 2 Glance： 仮想マシンイメージ管理サービス ● 仮想マシンイメージ置き場用に内蔵ディスク or 外部ストレージを利用 ● 外部ストレージの場合、OpenStack対応は必須ではない ● OpenStack対応製品ではCinder連携等メリットあり Swift： オブジェクトストレージサービス ● Amazon S3相当の機能 ● Swift APIのみ利用し、Swift対応のストレージを利用することも可能 ● Swiftをそのまま利用する場合は、コモディティサーバの内蔵ディスクを利用 26 RHEL-OSPパートナーソリューションガイド RHEL OSPの各リリースにて、 各種プラグイン製品を認定&サポート – – – サーバ（従来通り） ネットワーク ストレージ 認定プラグイン製品を利用することで、 コンポーネントの組合せ問題を軽減 詳細：https://access.redhat.com/ecosystem/ ネットワーク/ストレージは『ソフトウェア認定』の扱い 27 クラウドコントローラ & インストーラ ● コントローラの冗長構成（コントローラHA） – インストーラ： OSP-Director（packstackはHA構成を作成できない） – 3ノード+共有ストレージなし – ● クラスタ構成はOSP-Directorが作成 ● 2ノード+共有ストレージ構成はNG（クラウドでは3ノードが定石） 物理マシン/仮想マシンどちらもOK サンプル OSP-Director コントローラ3 コントローラ2 コントローラ1 本番環境 OSP-Director VM コントローラ3 VM コントローラ2 VM コントローラ1 VM 開発環境 28 物理ネットワークサンプル ネットワーク： Midonet ストレージ ： Ceph User Network External Network RHN MidoNet Network Gateway OpenStack Tenant Network Internal API Network OpenStack Controller OpenStack Compute Storage Network Storage Management Network Provisioning Network OSP-Director Red Hat Ceph Storage 29 物理ネットワークサンプル & コンポーネント配置 ネットワーク： Midonet ストレージ ： Ceph User Network External Network OpenStack Midonet GW x2 RHN MidoNet Network Gateway OSP controller x3 （Midonet API含） （Ceph Mon含） Midonet NSDB x3 OpenStack Ceph Controller MGT Tenant Network Internal API Network OSP Nova-compute x6 （Midonet Agent含） OpenStack Compute Storage Network Storage Management Network Provisioning Network OSP-Director Red Hat Ceph Storage 30 WE CAN DO MORE WHEN WE WORK TOGETHER THE OPEN SOURCE WAY 31 Thank You Appendix： グランドデザインでの検討項目例 33 グランドデザインでの検討項目例 1 ● ● ユースケース/稼動させるワークロードが明確でない場合 – まずは、シンプルなWebアプリケーションを想定 – 基盤側も、機能を絞り、シンプルな構成でプロトタイプを構築 – プロトタイプから関連部門と共に成熟させる – シンプルな構成にすることでアップグレードの負担を軽減 物理環境 – 単一データセンタ or 複数データセンタ – プロトタイプなら、単一データセンタで検討するべき 34 グランドデザインでの検討項目例 2 ● 利用サービス – プロトタイプであれば、まずはコアサービスのみでOK ● ● ● コアサービス： Keystone/Horizon/Nova/Neutron/Cinder/Glance/Swift オプションサービス Heat/Ceilometer/Ironic/他 認証 – 既存のActiveDirectoryとの連携有無 – AD連携させる場合はKeystoneのバックエンドも合わせて検討 35 Red Hat Forum 2015 Energize Your Enterprise
© Copyright 2024 ExpyDoc
