【Cisco Data Center Forum 2014】　Cisco ACI (Application Centric Infrastructure) – 株式会社サイバーエージェント様による事例紹介とデモンストレーション

Cisco ACI (Application Centric Infrastructure)

株式会社サイバーエージェント様による事例紹介とデモンストレーション

及川尚

プロダクトマネージャ

4/16/2014

Cisco Confidential 2 © 2013-2014 Cisco and/or its affiliates. All rights reserved.

Application Centric Infrastructure

APIC

Physical Networking

Compute Multi DC WAN and Cloud

L4–L7 Services

Storage

Integrated

WAN Edge

Hypervisors and Virtual Networking

Nexus 9500

Nexus 9300 and 9500

Nexus 2K

Nexus 7K


アプリケーション開発者とインフラ管理者間の障壁

開発チーム

アプリケーションレイヤ

サービス・提供・消費の関係

インフラチーム

VLANs

サブネット

プロトコル

ポート

アプリケーション開発者の言葉をインフラ管理者の言葉に翻訳して、実装を行う必要性

3

ACL


APIC

アプリケーションの自由な配置アプリケーションネットワークプロファイル

ADC APP DB F/W

ADC WEB

HYPERVISOR HYPERVISOR HYPERVISOR

CONNECTIV

ITY POLICY

SECURITY

POLICIES QOS

STORAGE

AND

COMPUTE

APPLICATI

ON L4..7

SERVICES

SLA

QoS

Security

Load

Balancing

APP PROFILE


アプリケーションとインフラ管理者の適切な分離

すべてのフォワーディングはポリシーの要請によってダイナミックに変更される • IPアドレスはFabric上どこへでも自由に配置可能

• セキュリティとフォワーディングは完全に分離され、仮想・物理を問わず一貫して適用される

• デバイスは自律的に必要なネットワークの設定変更を実施（vMotion/Live Migration)

DB Tier

Storage Storage

Application Client

Web Tier

App Tier

アプリケーションポリシーモデル: アプリケーションの要件を定義 (アプリケーションネットワークプロファイル)

ポリシーの適用: 各デバイスはポリシーの要求にしたがって、ダイナミックな設定変更を実施

VM VM VM

10.2.4.7

VM

10.9.3.37

VM

10.32.3.7

VM VM

APIC


マルチハイパーバイザ・オーバレイ対応ファブリック

• VLAN, VxLAN, そして

NVGRE に対応した統合型

ゲートウェイを実装し仮想・物

理間の通信でも各種カプセ

ル化の違いを吸収

• ハイパーバイザ・カプセル化

の違いによるネットワーク分

離が発生しない

仮想・物理の統合

Network Admin

Application Admin

PHYSICAL SERVER

VLAN VXLAN

VLAN NVGRE

VLAN VXLAN

VLAN

ESX Hyper-V KVM

Hypervisor Management

ACI Fabric APIC

APIC


Time (s)

ケーススタディ – ビッグデータ分析処理

Based on common network load and link failure scenarios

ACI:最適化されたアプリケーションパフォーマンス

Congestion Management

60%

60%

90%

パフォーマンスの劇的な改善

Dynamic Load Balancing

Dynamic Packet Prioritization

アプリケーション計算完了時間30%削減

Network Utilization


ACI:アプリケーション認識アプリケーションレベルの可視化

Actions:

No new hosts or VMs

Evacuate hypervisors

Re-balance clusters

PetStore Event

PetStore Dev • Leaf 1 and 2

• Spine 1 – 3

• Atomic counters

PetStore Prod • Leaf 2 and 3

• Spine 1 – 2

• Atomic counters

PetStore QA • Leaf 3 and 4

• Spine 2 – 3

• Atomic counters

VXLAN

Per-Hop Visibility

Physical and

Virtual as One

ACIファブリックは今までにない分析機能を提供します。

アプリケーション、テナント、インフラごとの情報を提供:

• ヘルススコア

• 遅延

• アトミックカウンター

• リソースの利用状況

ワークロードの配置、移動にも柔軟に対応

Triggered Events

or Queries

APIC


ACI: Layer 4 - 7 サービスインテグレーション

• 仮想・物理アプライアンスを問わない一貫したサービス連結のプラットフォームを提供

• ポリシーは集中管理

• 複数のオペレーションモデルを提供 • 従来型 • サードパーティ、マルチベンダ統合

• 一貫したポリシーアーキテクチャ • 仮想・物理 • ポリシーは完全にポータブル

Web

Server

App Tier

A

Web

Server

Web

Server

App Tier

B

App

Server

Chain

“Security 5”

Policy Redirection

Application

Admin

Service

Admin

Serv

ice

Gra

ph

begin end Stage 1 …..

Stage N

Pro

vid

ers

inst

inst

…

Firewall

inst

inst

…

Load Balancer

……..

Se

rvic

e P

rofile

“Security 5” Chain Defined


APIC

Opflex: オープン,拡張性を備えたポリシープロトコル

OPFLEX の設計思想: Policies:

• Who can talk to whom

• What about

• Ops requirements

デバイス固有のコンフィグを抽象化 1.

柔軟性、拡張性をXML/JSONで提供 2.

様々なデバイスをサポート。仮想スイッチ、物理スイッチ、ネットワークサービス。高レベルの互換性

3.

OpenStack/OVSにおけるリファレンス実装とオープンスタンダードAPI

4.

OPFLEX

PROXY

OPFLEX

AGENT

OPFLEX

AGENT

OPFLEX

AGENT

HYPERVISOR SWITCH ADC FIREWALL


ポリシーエンドポイントがポリシーを解釈し、デバイスレベルの設定に変換

Opflexはどう動くのか？

POLICY APIC

APICのようなポリシーコントローラがアプリケーションの要件を定義

ハードウェエアポート,

VLANS, ACL

部分的なポリシー

4

IMPLICIT RENDER

ポリシー通知ポリシー解決 3 2

1


TENANT AND APPLICATION AWARE

READ / WRITE ALL FABRIC INFO

PUBLISHED DATA MODEL

OPEN SOURCE

オープンエコシステム・オープンソース

ASA

12

APIC

新たなパートナー:

サイバーエージェントがACIを選んだ理由

髙橋哲平 [email protected]

Network Manager Ameba Division

Apr. 16, 2014


会社紹介：今年でAmeba10周年

1998年 3月株式会社サイバーエージェント設立 2004年 9月ブログサービス「アメーバブログ（現Ameba）」を開始


Amebaの成長とデータセンターの拡張

98 04 05 07 08 10 11 13 14 年年年年年年年年年

Ameba ブログ開始

Ameba 会員数 50万

Ameba 会員数 200万

Ameba Social 参入

Ameba 会員数 1,000万



CA 設立

DC 1 +DC 2 +DC 3

+DC 4

-DC 1

-DC 3

+DC 8 +DC 9

-DC 4

+DC10 予定

+DC 5 +DC 6

+DC 7 -DC 6

DC = データセンター青字が増赤字が減（老朽化or統合）

ブログ、子会社向けインフラの提供開始

Ameba専用DCとして提供開始

物理サーバ（メイン）、仮想サーバの両提供開始

仮想サーバ（メイン）、物理サーバの両提供。障害耐性向上、運用効率化。子会社収容再開


Ameba NWで目指しているところ

ＳＫＢＮＷ = 捨てやすい(S) 構築しやすい(K) 分散可能型(B) ＮＷ

Ameba Cloud AS:24284

Region: tky01

Az: a Az: b Az: c Az: d

VPLS

Az: a

商用 Cloud

Internet

・DCの親子関係を作らない並列展開

・インフラエンジニアを介さないインフラ提供

・Multi Cloud化準備（Private, 商用cloudの併用）

今後の下記動向をキャッチアップ、どこに転んでもうちのサービスに利益となるようなインフラを選択できるMulti Cloud化の準備を進める・商用Cloudでどこがグローバルでシェアを取って行く？・国内商用Cloudの動向は、何に強みを出していく？・Open Cloudの動向は、このまま商用に押されてしまう？・メーカー、DC事業者の方向性（価格含む）を柔軟に Privateへ取り入れる


Ameba NWで抱えている課題・設計、開発、検証、運用と全て自社で実施しているため人的リソースが限られている

・仮想環境のテナントNW追加が簡便ではない

・機器の管理台数増加で運用の手間がかかる

・ NWと周辺S/Wとの連携が容易ではない（NW側にAPIを用意したい）

■ 上記の理由からＮＷコントローラを実装したかった。

が、様々な機器を検討・検証したが弊社要件にマッチする製品がなかった。例)

• コントローラへの依存度が高すぎる（コントローラ障害が恐ろしすぎる） • S/W思想はよいが、ポート数などH/Wが追い付いていない • 数百Rack単位の商用では使い物にならない。拡張性に難あり。 • IPv6がサポートされていない • 10Gや40Gがサポートされていない。などなど


ACIを選んだ理由

USER

管理UI

Cloud controller API

仮想HostSV

物理SV LB

・テナント分割が容易

・ NW機器の一元管理が可能。別途NW用のadminツールの用意が不要

・クラウドコントローラや監視サーバからは、APICをたたくだけ

・ APICが全台落ちたとしてもトラフィック転送に影響がない

・ 10G/40G実装機器として次世代インフラとして十分対応可能

・ IPv6対応(予定)

ACI

APIC

Ameba Infraで目指しているところの一つ

・インフラエンジニアを介さないインフラ提供

ユーザへのインフラ提供方法：サーバ, NW, ロードバランサー, FWの設定を一つの管理UIより簡単に一括設定できるようにする。

過去、NWのAPI提供遅れにより上記実現は手間のかかるものだったが、ACIの登場により容易に実現できるようになった。

Thank you.

Technology

【Cisco Data Center Forum 2014】 Cisco ACI (Application Centric Infrastructure) – 株式会社サイバーエージェント様による事例紹介とデモンストレーション

【Cisco Data Center Forum 2014】　Cisco ACI (Application Centric Infrastructure) – 株式会社サイバーエージェント様による事例紹介とデモンストレーション