従量制課金のLBいかがすかー（仮）
•
0 likes•830 views
九州インフラ交流勉強会(Kixs) Vol.003 ロードバランサーの夜 -LB Night Fever- での ブロケード中川さんの発表資料です。
Recommended
More Related Content
Similar to 従量制課金のLBいかがすかー（仮）
Similar to 従量制課金のLBいかがすかー（仮） (20)
More from Tomonori Takada
Recently uploaded
Recently uploaded (7)
従量制課金のLBいかがすかー（仮）
- 2. Brocade vADC <仮想LB> ソフトウェア、仮想アプライアンス、クラウドインスタンス、 包括的なADC製品 © 2016 BROCADE COMMUNICATIONS SYSTEMS, INC. INTERNAL USE ONLY 2 Brocade Services Director Load balancer （vTM） Web Application Firewall • Load Balancer –アプリケー ショントラフィックの可視化と コントロール • 信頼性、可⽤性、セキュリティ などを提供 • アプリケーション アウェア ファイアウォール • 脅威から、アプリケーションを 保護 • ライセンスの容量買い： 柔軟に適⽤できるサービス コントローラ • ADCの⾃動デプロイ、プロ ビジョニング、メータリン グ vTM SD
- 3. ロードバランサーの移り変わり © 2016 BROCADE COMMUNICATIONS SYSTEMS, INC. INTERNAL USE ONLY 3 専⽤ロードバランサー 集約 （コンソリデーション） 仮想化・マルチテナント • サービス個別対応 - シングルテナント • 複数システムへの対応 - マルチテナント • ⾼スペックHWリソース共有 vTM LB LB X86 サーバ • サービス毎にロードバランサ - シングルテナント/ シングルインスタンス • ライセンスによるグレードUp LB LB LB LB Serv 1 Serv 2 Serv 1 Serv 1 Serv 2 Serv 2 Serv 1 Serv 2
- 4. スモールスタート可能なライセンスモデル（永年モデル / 期限付きモデル有） © 2016 BROCADE COMMUNICATIONS SYSTEMS, INC. INTERNAL USE ONLY 4 vTM Throughput 1Gbps 2 Gbps 10 Gbps++ Single Device, License Upgrade DEVELOPER EDITION： ライセンスKey無 1Mbps/100 SSL tps http://www.brocade.com Products ＆ Services ⇒Network Functions Virtualization ⇒Brocade Virtual Traffic Manager 無料a b LB A ライセンスの考え⽅： 筐体a+bではなく、 BrocadeはAだけ 1M/50M/400M/1G/2G/5G/10G/20G… 固定ライセンス？ 更にSDを利用ならば ソフトならではライセンスモデル：
- 5. Service Director @Enterprise ライセンスの統合管理 • Brocade Service Director • ADCインスタンス ‒ インスタンスをオンデマンドで用意 ‒ 複数Versionを使い分け • ライセンス ‒ 規模に応じたライセンスをオンデマン ドで配備 ‒ WebAppFW/機能もオンデマンドで • メータリングとロギング 5 Brocade VDX 8770 Brocade VDX 8770 VDX 67xx VDX 67xx VDX 67xx VDX 67xx VDX 67xx VDX 67xx VDX 67xx VDX 67xx Brocade VDX 8770 Brocade VDX 8770 ライセンスを分け合える ライセンスサービスシステムによる 「容量買い」を実現 vTM SD
- 7. Service Directorでのライセンス概念 1G 3G 300円 1000円 Bulk License 10G 1G 2G 500M 500M 500M 500M 500M 500M
- 8. 例えば・・・ HQ Bulk License 10G IT Dep. 部⾨A 部⾨B ⼦会社A 部⾨C 1G 1G 2G 2G
- 9. クラウド連携機能からクラスタリング、スクリプト対応まで 9 Auto Scaling （⾃動的なリソース拡張） Cluster/HA （⾼性能&⾼可⽤性） Traffic Script/Rule Builder （トラフィックを⾃由にコントロール） PUBLIC CLOUD • オンデマンドでリソースのスケールアッ プ/ダウン。 • AWSやRackspace等外部Cloudとの連携 も。 • スケールに応じて複数台でクラスタ構成。 • クラスタ内でのコンフィグ同期による運⽤ 性の向上。 • vipを処理するTMのグループ分けが可能。 • Active-Active/Active-Standbyどちらもサ ポート。 • 柔軟かつ⾼度なトラフィックコントロール。 • 他社⽐較で⼤幅に簡素化されたスクリプト。 • Brocade Communityページ（旧SteelApp Slashページ）で多数のサンプルスクリプト やナレッジを参照可能。 Business Policy ADC Policy Traffic Script © 2016 BROCADE COMMUNICATIONS SYSTEMS, INC. Like JavaScript/Perl （vs TCL Base） ♯Traffic IP Group（tip）:SLB⽤の論理IPアドレス ♯Virtual server（vip）: tipに紐付けるvirtual port（Protocol/パターンRule） ♯Pool（real server）: vipに紐付けるreal server群とPort番号（Node） TRAFFIC IP GROUP “A” 3 TRAFFIC MANAGERS TRAFFIC IP GROUP “B” 2 TRAFFIC MANAGERS vip1 vip2 vip3 vip4 vip5 その他：豊富なADC機能 vTM
- 10. どこでも稼働 Publicクラウド/エンタープライズでの豊富な実績 • グローバルクラウド（Market Place/Cloud Launcher） ‒ Amazon Web Services様、Microsoft Azure様、 Google Cloud Platform様、Rackspace様 • 国内クラウド ‒ Bit-Isle様/IIJ様/IDCフロンティア様/KDDI様/Nifty様 （アルファベット順） • 各種Enterpriseのお客様 ‒ 自社設備での稼働 • オンプレからクラウドへ移行した事例も(EPSON) ：BYOL可能 © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. 10 vTM SD
- 11. 本題？の従量制課金を利用するには？ • Brocade自体はSDを介した月額課金 or 1時間単位の課金を提供し ております。お客様がご利用されるのは概ね下記2パターン。 1. CSP(Cloud Service Provider)となりサービス提供 ‒ エンドユーザへは月額、1時間単位でそのまま課金することもできま すし、SDで収集しているトラフィック利用状況を元に自由に課金シ ステムを構築可能！ 2. CSPのエンドユーザとなり利用 ‒ 様々なCSP様がvTMを提供していますので、それを利用する。次ペー ジの参考料金参照願います。 © 2016 BROCADE COMMUNICATIONS SYSTEMS, INC. INTERNAL USE ONLY 11
Editor's Notes
- Brocadeの virtual Delivery Controller 仮想ロードバランサーであるvTM : Virtual Traffic Manager そのvTM上でオプションで稼動させたり、単独で稼動させる事もできるvWAF : vTMの帯域やWAF、Web Accelerator、 FIPS（Federal Information Processing Standardization） のライセンスを管理するSD FIPS（連邦情報処理標準）
- 専用HW ・・・ 可用性、拡張性 集約 ・・・ 時期等による余剰なリソースを有効活用 仮想化 ・・・ X86の進化、VMWare、KVMなど含め仮想化の進化 シングルインスタンスを仮想化上で稼動。 ライセンスの付替で帯域変更可能（vCPUやメモリ付与の変更アリ） ※HWより対応早い（HW 1ヶ月-2ヶ月、SW 2-3日）
- 先ほどのvADCシリーズの部分でもあったように、月額のCSPLモデルもありますが、 永年モデル（パーぺチュアル） 期限付きモデル（サブスクリプション） vTMの帯域ライセンス ライセンスは、他社は、筐体での入出力(a+b) VTMは筐体での入出力ではなく、LBの戻りの帯域で判断(Aのみ) 幅は、10M/200M/１G/２G/５G/10G/20Gから新しくなり →50M/400M/1G/2G/5G/10G/20G/40G ちなみに、操作性などを確認したいなら、 プロダクション環境（本番）には不可ですが DeveloperEdition 1M/100SSLあります！！ とは言え、正規ライセンス追加でそのまま利用できます。 （ただ、AWSは特別Versionなので少しだけ操作性など異なります）
- In this diagram, we can see an example of three ADCs, small, medium and large. I have used just three SteelApp Traffic Manager instances, deployed in the traditional way, each with a fixed size capacity set by license key, but an organization may have hundreds of individual load balancers or ADCs. . But what you can also see here is that none of these three instances are running at full capacity – they each have an overhead which is not used, a reserve held back in case of peak throughput surges. The reason IT managers do this is because it takes time to add more capacity if we need it. In the case of a traditional load balancer appliance, it might take a few weeks to order a larger appliance, install in a rack and configure. If we are just adding a new feature or expanding the capacity of a virtual ADC, it might still take an hour to order a new license and install before we can use the new capacity. But suppose you could share that capacity across all the ADCs? In this diagram, I have brought all three of my ADCs into a single resource pool, and I can share out the capacity between them. I can see from the resource utilization graph that this gives me better utilization of my resources, but it also means I can allocate spare capacity immediately, to any ADC that may need additional throughput, scaling to meet changes in demand in seconds.
- In this diagram, we can see an example of three ADCs, small, medium and large. I have used just three SteelApp Traffic Manager instances, deployed in the traditional way, each with a fixed size capacity set by license key, but an organization may have hundreds of individual load balancers or ADCs. . But what you can also see here is that none of these three instances are running at full capacity – they each have an overhead which is not used, a reserve held back in case of peak throughput surges. The reason IT managers do this is because it takes time to add more capacity if we need it. In the case of a traditional load balancer appliance, it might take a few weeks to order a larger appliance, install in a rack and configure. If we are just adding a new feature or expanding the capacity of a virtual ADC, it might still take an hour to order a new license and install before we can use the new capacity. But suppose you could share that capacity across all the ADCs? In this diagram, I have brought all three of my ADCs into a single resource pool, and I can share out the capacity between them. I can see from the resource utilization graph that this gives me better utilization of my resources, but it also means I can allocate spare capacity immediately, to any ADC that may need additional throughput, scaling to meet changes in demand in seconds.
- In this diagram, we can see an example of three ADCs, small, medium and large. I have used just three SteelApp Traffic Manager instances, deployed in the traditional way, each with a fixed size capacity set by license key, but an organization may have hundreds of individual load balancers or ADCs. . But what you can also see here is that none of these three instances are running at full capacity – they each have an overhead which is not used, a reserve held back in case of peak throughput surges. The reason IT managers do this is because it takes time to add more capacity if we need it. In the case of a traditional load balancer appliance, it might take a few weeks to order a larger appliance, install in a rack and configure. If we are just adding a new feature or expanding the capacity of a virtual ADC, it might still take an hour to order a new license and install before we can use the new capacity. But suppose you could share that capacity across all the ADCs? In this diagram, I have brought all three of my ADCs into a single resource pool, and I can share out the capacity between them. I can see from the resource utilization graph that this gives me better utilization of my resources, but it also means I can allocate spare capacity immediately, to any ADC that may need additional throughput, scaling to meet changes in demand in seconds.
- Auto Scaling Openソースにはない機能。 また、通常のHW系のLBなどはPluginでの連携。 → AWS/RackSpace、vSpherとの外部連携。 Password/認証Key 事前登録で、 Poolが足りない時に、過分になった際に、 上下の閾値で増減する。 （簡単に言えば、ESXi側からか、VTM側からのキックかの違い） ・ACT/Standbyも出来るが、HAでのACT/ACT構成 他社と異なる機能。（TIP＋vip＝VIP） 全部がACTで上からのMulticastトラヒック待ち。 また、ClusterでAZを跨いで設定同期できる機器は世の中で少なし！！ ・トラヒックスクリプト（F5でいうiRuleに近いモノ） 更にモジュール選択で、ベースプログラムが出来るRule Builderがある。
- グローバルクラウドを除き、 日本国内：1,400インスタンス以上