講師：デル 鈴木様 日時：2014/10/08 タイトル：OpenStack Infrastructure at any Scale - Simple is BEST!? - 概要： - OpenStack Dell’s PoV - OpenStack 公式ドキュメントのネットワーク部分抜粋 - DELLが考えるOpenStack Networkingの考慮点 - DELLジャパンの取り組み - Driving OpenNetworking

1. OpenStack Infrastructure at
any Scale
- Simple is BEST!? -
Takanori Suzuki
Email: takanori_suzuki@dell.com
Twitter: @takanorisuzuki

2. Agenda
• OpenStack Dell’s PoV
• OpenStack 公式ドキュメントのネットワーク部分抜粋
• DELLが考えるOpenStack Networkingの考慮点
• DELLジャパンの取り組み
• Driving OpenNetworking
2

3. Who am I?
• 名前
3
– 鈴木孝規 （すずきたかのり）
• 職歴
– 日本企業でインフラエンジニア
– 外資でネットワークエンジニア
– デルでネットワークが関係すること全般
• 趣味
– 乗馬、子育て

4. OpenStack
Dell’s PoV

5. OpenStack is NOT a product
Physical Infrastructure
• Compute
• Storage
• Networking
5
Access control
ID mgmt
Cloud Operating
System
Maintenance & Support
• Code
• Hardware
• Help Systems
Enterprise
Cloud
Security Mgmt
Policy Mgmt
Applications
App. mgmt, PaaS
Monitoring &
Analytics

6. What OpenStack brings …
6
Control
Enterprise
Cloud
Flexibility
Vast growing
eco-system
True choice
Catalyst for
Innovation
Visibility
Reduced risk of
Alligator
encounters!

7. Our Focus
7
Enrich the
OpenStack community
Bridge OpenStack
and the enterprise

8. Dell’s Commitment to OpenStack
8
“Dell … was one of the first of the hardware vendors to grasp
the fact that cloud is about provisioning services,
not about the hardware.”Maxwell Cooter, Cloud Pro
Proven solutions Proven components
• First OpenStack cloud solution provider
• Pioneering OpenStack partner
Only tier 1 day 1 hardware provider
• Deep partner ecosystem
with single point of service and support
• ONLY company with automated software for
multi-node OpenStack provisioning: Crowbar
• Dell OpenStack experts continually invest
in the community
• Gold Foundation Member with 2 board positions
Save on licensing
fees
Innovate
aggressively
Scale operations
efficiently

9. 9
OpenStack is
Open
Innovation

10. OpenStack
公式ドキュメントの
ネットワーク部分抜粋

11. Official Document for OpenStack Networking
• Architecture Design Guide Chapter 5. Network focused
11
– http://docs.openstack.org/arch-design/content/network_focus.html
• Configuration Reference Chapter 7. Networking
– http://docs.openstack.org/icehouse/config-reference/content/ch_configuring-openstack-networking.html
• Operations Guide Chapter.5 Scaling
– http://docs.openstack.org/openstack-ops/content/scaling.html
• Operations Guide Chapter 7. Network Design
– http://docs.openstack.org/openstack-ops/content/network_design.html
• High Availability Guide Chapter 5. Network controller cluster stack
– http://docs.openstack.org/high-availability-guide/content/ch-network.html
• Security Guide Chapter 11. Networking
– http://docs.openstack.org/security-guide/content/networking.html
• Cloud Admin Guide Chapter. 7 Networking
– http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html

12. Official Document for OpenStack Networking
12
௒᪥䛿䝁䝁䛻ὀ┠䟿
• Architecture Design Guide Chapter 5. Network focused
– http://docs.openstack.org/arch-design/content/network_focus.html
• Configuration Reference Chapter 7. Networking
– http://docs.openstack.org/icehouse/config-reference/content/ch_configuring-openstack-networking.html
• Operations Guide Chapter.5 Scaling
– http://docs.openstack.org/openstack-ops/content/scaling.html
• Operations Guide Chapter 7. Network Design
– http://docs.openstack.org/openstack-ops/content/network_design.html
• High Availability Guide Chapter 5. Network controller cluster stack
– http://docs.openstack.org/high-availability-guide/content/ch-network.html
• Security Guide Chapter 11. Networking
– http://docs.openstack.org/security-guide/content/networking.html
• Cloud Admin Guide Chapter. 7 Networking
– http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html

13. Architecture Design Guide Chapter 5. Network focused
Contents
• Contents
13
– User requirements
– Technical considerations
– Operational considerations
– Architecture
– Prescriptive examples
– All OpenStack deployments are dependent, to some extent, on network communication in order to function
properly due to a service-based nature.
– In some cases, however, use cases dictate that the network is elevated beyond simple infrastructure.
– This chapter is a discussion of architectures that are more reliant or focused on network services.
– These architectures are heavily dependent on the network infrastructure and need to be architected so that
the network services perform and are reliable in order to satisfy user and application requirements.
• Some possible use cases include:
– Content delivery network, Network management functions, Network service offerings, Web portals or web
services, High speed high volume transactional systems, High availability, Big Data, Virtual desktop
infrastructure (VDI), Voice over IP (VoIP), Video Conference or web conference, High performance
computing (HPC)

14. Architecture Design Guide Chapter 5. Network focused
Contents
• Contents
14
– User requirements
– Technical considerations
– Operational considerations
– Architecture
– Prescriptive examples
– All OpenStack deployments are dependent, to some extent, on network communication in order to function
properly due to a service-based nature.
౑䛔᪉䛻䜘䛳䛶䛿䝅䞁䝥䝹䛷䛿䛺䛟䛺䜛
Ᏻᐃ䛧䛯䝛䝑䝖䝽䞊䜽䛻䛴䛔䛶䝕䜱䝇䜹䝑䝅䝵䞁୰
– In some cases, however, use cases dictate that the network is elevated beyond simple infrastructure.
– This chapter is a discussion of architectures that are more reliant or focused on network services.
– These architectures are heavily dependent on the network infrastructure and need to be architected so that
the network services perform and are reliable in order to satisfy user and application requirements.
• Some possible use cases include:
– Content delivery network, Network management functions, Network service offerings, Web portals or web
services, High speed high volume transactional systems, High availability, Big Data, Virtual desktop
infrastructure (VDI), Voice over IP (VoIP), Video Conference or web conference, High performance
computing (HPC)

15. Architecture Design Guide Chapter 5. Network focused
User Requirements
• User requirements
15
– User experience
– Network performance problems can provide a negative experience for the end-user, as well as productivity and economic loss.
– Regulatory requirements
– Networks need to take into consideration any regulatory requirements about the physical location of data as it traverses the network.
– Another network consideration is maintaining network segregation of private data flows and ensuring that the network between cloud
locations is encrypted where required.
• High availability issues
– Often, high performance systems will have SLA requirements for a minimum QoS with regard to guaranteed uptime,
latency and bandwidth. The level of the SLA can have a significant impact on the network architecture and
requirements for redundancy in the systems.
• Risks
– Netowrk misconfigurations, Capacity planning, Network tuning, Single Point Of Failure (SPOF), Complexity, Non-standard
features
• Security
– Security is often overlooked or added after a design has been implemented. Consider security implications and
requirements before designing the physical and logical network topologies.

16. Architecture Design Guide Chapter 5. Network focused
User Requirements
• User requirements
16
– User experience
– Network performance problems can provide a negative experience for the end-user, as well as productivity and economic loss.
– Regulatory requirements
䝛䝑䝖䝽䞊䜽䛜䝖䝷䝤䝹䛸Ⰽ䚻኱ኚ䛰䛛䜙Ẽ䜢௜䛡䛶
ἲᚊ䛾䛣䛸⪃䛘䛶ᶵᐦ䝕䞊䝍䛾㌿㏦䛸䛛䝕䞊䝍䛾ಖ⟶ሙᡤ䜒ὀព
– Networks need to take into consideration any regulatory requirements about the physical location of data as it traverses the network.
– Another network consideration is maintaining network segregation of private data flows and ensuring that the network between cloud
locations is encrypted where required.
• High availability issues
– Often, high performance systems will have SLA requirements for a minimum QoS with regard to guaranteed uptime,
latency and bandwidth. The level of the SLA can have a significant impact on the network architecture and
requirements for redundancy in the systems.
• Risks
– Netowrk misconfigurations, Capacity planning, Network tuning, Single Point Of Failure (SPOF), Complexity, Non-standard
features
• Security
– Security is often overlooked or added after a design has been implemented. Consider security implications and
ᛀ䜜䛜䛱䛰䛡䛹䝛䝑䝖䝽䞊䜽タィ䛾๓䛻䝉䜻䝳䝸䝔䜱せ௳䛿⪃䛘䛶䟿
requirements before designing the physical and logical network topologies.

17. Architecture Design Guide Chapter 5. Network focused
Technical Considerations – Layer-2
• Technical considerations
17
– Layer-2 architecture limitations
– Layer-3 architecture advantages
– Network recommendations overview
– Additional considerations
• Layer-2 Ethernet usage has these advantages over layer-3 IP network usage:
– Speed
– Reduced overhead of the IP hierarchy
– No need to keep track of address configuration as systems are moved around. Whereas the simplicity of layer-2 protocols might work well
in a data center with hundreds of physical machines, cloud data centers have the additional burden of needing to keep track of all virtual machine
addresses and networks. In these data centers, it is not uncommon for one physical node to support 30-40 instances.
• Layer-2 architecture limitations
– Number of VLANs is limited to 4096
– The number of MACs stored in switch tables is limited
– The need to maintain a set of layer-4 devices to handle traffic control must be accommodated
– MLAG, often used for switch redundancy, is a proprietary solution that does not scale beyond two devices and forces vendor lock-in
– It can be difficult to troubleshoot a network without IP addresses and ICMP
– Configuring ARP is considered complicated on large layer-2 networks
– All network devices need to be aware of all MACs, even instance MACs, so there is constant churn in MAC tables and network state
changes as instances are started or stopped
– Migrating MACs (instance migration) to different physical locations are a potential problem if ARP table timeouts are not set properly

18. Architecture Design Guide Chapter 5. Network focused
Technical Considerations – Layer-2
• Technical considerations
18
– Layer-2 architecture limitations
– Layer-3 architecture advantages
– Network recommendations overview
– Additional considerations
• Layer-2 Ethernet usage has these advantages over layer-3 IP network usage:
– Speed
– Reduced overhead of the IP hierarchy
– No need to keep track of address configuration as systems are moved around. Whereas the simplicity of layer-2 protocols might work well
䝇䝢䞊䝗䠛
ᑠつᶍ䛺䛖䛱䛿VM䛾ሙᡤ䝖䝷䝑䜽䛧䛺䛟䛶䛔䛔䛛䜙L2䛷䜒䛔䛔䛛䛺
in a data center with hundreds of physical machines, cloud data centers have the additional burden of needing to keep track of all virtual machine
addresses and networks. In these data centers, it is not uncommon for one physical node to support 30-40 instances.
• Layer-2 architecture limitations
– Number of VLANs is limited to 4096
– The number of MACs stored in switch tables is limited
– The need to maintain a set of layer-4 devices to handle traffic control must be accommodated
– MLAG, often used for switch redundancy, is a proprietary solution that does not scale beyond two devices and forces vendor lock-in
– It can be difficult to troubleshoot a network without IP addresses and ICMP
– Configuring ARP is considered complicated on large layer-2 networks
– All network devices need to be aware of all MACs, even instance MACs, so there is constant churn in MAC tables and network state
VLAN4096䛿ព㆑䛩䜛ᚲせ䛒䜛䛡䛹㉸䛘䛺䛔䛺䜙↓ど
MLAG᪩䛔䛡䛹䝧䞁䝎䞊䝻䝑䜽䠛
኱䛝䛔L2⤌䜐䛸BUM䚸䛸䛟䛻ARP䛷୙Ᏻᐃ䛻䛺䜛
ARPchanges as instances are started or stopped
䛾䝍䜲䝮䜰䜴䝖タᐃ䛻Ẽ䜢௜䛡䛺䛔䛸䛧䜀䜙䛟㏻ಙ䛷䛝䛺䛟䛺䜛
– Migrating MACs (instance migration) to different physical locations are a potential problem if ARP table timeouts are not set properly

19. Architecture Design Guide Chapter 5. Network focused
Technical Considerations – Layer-3 advantages
• Technical considerations
19
– Layer-2 architecture limitations
– Layer-3 architecture advantages
– Network recommendations overview
– Additional considerations
• Layer-3 architecture advantages
– Layer-3 networks provide the same level of resiliency and scalability as the Internet
– Controlling traffic with routing metrics is straightforward.
– Layer 3 can be configured to use BGP confederation for scalability so core routers have state proportional to the number of racks,
not to the number of servers or instances.
– Routing ensures that instance MAC and IP addresses out of the network core reducing state churn. Routing state changes only
occur in the case of a ToR switch failure or backbone link failure.
– There are a variety of well tested tools, for example ICMP, to monitor and manage traffic.
– Layer-3 architectures allow for the use of Quality of Service (QoS) to manage network performance.
• Layer-3 architecture limitations
– The main limitation of layer 3 is that there is no built-in isolation mechanism comparable to the VLANs in layer-2 networks
– Furthermore, the hierarchical nature of IP addresses means that an instance will also be on the same subnet as its physical
host. This means that it cannot be migrated outside of the subnet easily
– For these reasons, network virtualization needs to use IP encapsulation and software at the end hosts for both isolation,
as well as for separation of the addressing in the virtual layer from addressing in the physical layer
– Other potential disadvantages of layer 3 include the need to design an IP addressing scheme rather than relying on the
switches to automatically keep track of the MAC addresses and to configure the interior gateway routing protocol in the switches.

20. Architecture Design Guide Chapter 5. Network focused
Technical Considerations – Layer-3 advantages
• Technical considerations
20
– Layer-2 architecture limitations
– Layer-3 architecture advantages
– Network recommendations overview
– Additional considerations
• Layer-3 architecture advantages
䜲䞁䝍䞊䝛䝑䝖䛸ྠ䛨䝺䝧䝹䛷ᣑᙇ䛷䛝䛶ቯ䜜䛻䛟䛔䛧౑䛔䜔䛩䛔
䝁䜰ഃ䛷䛿L2䛸㐪䛳䛶䝣䝷䝑䝕䜱䞁䜾䛺䛔䛛䜙Ᏻᐃ䛩䜛
䝃䞊䝞䞊䛸䛛ᛀ䜜䛶䝷䝑䜽༢఩䛷⟶⌮䛩䜜䜀䛔䛔䛛䜙ᴦ
Ping䛸䛛L3䝖䝷䝤䝹䝅䝳䞊䝔䜱䞁䜾䛾䝒䞊䝹䛿䜏䜣䛺౑䛘䜛䜘䛽䠛
– Layer-3 networks provide the same level of resiliency and scalability as the Internet
– Controlling traffic with routing metrics is straightforward.
– Layer 3 can be configured to use BGP confederation for scalability so core routers have state proportional to the number of racks,
not to the number of servers or instances.
– Routing ensures that instance MAC and IP addresses out of the network core reducing state churn. Routing state changes only
occur in the case of a ToR switch failure or backbone link failure.
– There are a variety of well tested tools, for example ICMP, to monitor and manage traffic.
– Layer-3 architectures allow for the use of Quality of Service (QoS) to manage network performance.
• Layer-3 architecture limitations
䜲䞁䝇䝍䞁䝇䛾⛣ື䛜IP䝉䜾䝯䞁䝖䛻౫Ꮡ䛩䜛䛛䜙L2䜘䜚⡆༢䛨䜓䛺䛔
䛷䜒௬᝿䝛䝑䝖䝽䞊䜽⤌䜑䜀ゎỴ
L2䛰䛸MAC⮬ືᏛ⩦䛧䛶䛟䜜䜛䛡䛹IP䛿䝎䜲䝘䝭䝑䜽䝹䞊䝔䜱䞁䜾䛾タᐃ䛜ᚲせ
– The main limitation of layer 3 is that there is no built-in isolation mechanism comparable to the VLANs in layer-2 networks
– Furthermore, the hierarchical nature of IP addresses means that an instance will also be on the same subnet as its physical
host. This means that it cannot be migrated outside of the subnet easily
– For these reasons, network virtualization needs to use IP encapsulation and software at the end hosts for both isolation,
as well as for separation of the addressing in the virtual layer from addressing in the physical layer
– Other potential disadvantages of layer 3 include the need to design an IP addressing scheme rather than relying on the
switches to automatically keep track of the MAC addresses and to configure the interior gateway routing protocol in the switches.

21. Architecture Design Guide Chapter 5. Network focused
Technical Considerations – Network recommendations overview
• Network recommendations overview
21
– OpenStack has complex networking requirements for several reasons. Many components interact at
different levels of the system stack that adds complexity. Data flows are complex. Data in an OpenStack
cloud moves both between instances across the network (also known as East-West), as well as in and out of
the system (also known as North-South). Physical server nodes have network requirements that are
independent of those used by instances which need to be isolated from the core network to account for
scalability. It is also recommended to functionally separate the networks for security purposes and tune
performance through traffic shaping.
– A number of important general technical and business factors need to be taken into consideration when
planning and designing an OpenStack network. They include:
– A requirement for vendor independence. To avoid hardware or software vendor lock-in, the design should not rely on
specific features of a vendor’s router or switch.
– A requirement to massively scale the ecosystem to support millions of end users.
– A requirement to support indeterminate platforms and applications.
– A requirement to design for cost efficient operations to take advantage of massive scale.
– A requirement to ensure that there is no single point of failure in the cloud ecosystem.
– A requirement for high availability architecture to meet customer SLA requirements.
– A requirement to be tolerant of rack level failure.
– A requirement to maximize flexibility to architect future production environments.

22. Architecture Design Guide Chapter 5. Network focused
Technical Considerations – Network recommendations overview
• Network recommendations overview
22
– OpenStack has complex networking requirements for several reasons. Many components interact at different
OpenStack䛾䝛䝑䝖䝽䞊䜽䛿䛔䜝䜣䛺⌮⏤䛜䛒䛳䛶」㞧䛻䛺䜛
ከᩘ䛾䝁䞁䝫䞊䝛䞁䝖䛾᥋⥆
䝕䞊䝍䝉䞁䝍䞊ෆ䛾ᶓ䛾㏻ಙ(East-West)䛸䝅䝇䝔䝮እ㒊䜈䛾㏻ಙ(North-South)
䝁䜰䛸䝜䞊䝗䛿䝛䝑䝖䝽䞊䜽䜢䜟䛡䛶⪃䛘䜛
ᶵ⬟䜔䝉䜻䝳䝸䝔䜱せ௳䛤䛸䛻䝛䝑䝖䝽䞊䜽䜢䜟䛡䜛
levels of the system stack that adds complexity. Data flows are complex. Data in an OpenStack cloud moves
both between instances across the network (also known as East-West), as well as in and out of the system
(also known as North-South). Physical server nodes have network requirements that are independent of
those used by instances which need to be isolated from the core network to account for scalability. It is also
recommended to functionally separate the networks for security purposes and tune performance through
traffic shaping.
– A number of important general technical and business factors need to be taken into consideration when
planning and designing an OpenStack network. They include:
– A requirement for vendor independence. To avoid hardware or software vendor lock-in, the design should not rely on
䝧䞁䝎䞊䝻䝑䜽䜲䞁䜢㑊䛡䜛
specific features of a vendor’s router or switch.
ᣑᙇᛶ䜢☜ಖ䚸ᣑᙇ᫬䛾䝁䝇䝖䜒Ᏻ䛟
ᰂ㌾ᛶ䜢᭱኱䛻䛧䛶䚸ᑗ᮶䛾䛹䜣䛺䜰䝥䝸䜿䞊䝅䝵䞁䜒䝃䝫䞊䝖䛷䛝䜛䜘䛖䛻
༢୍㞀ᐖⅬ䛿䛺䛟䛭䛖
䝷䝑䜽༢఩䛾㞀ᐖ䛻䜒⪏䛘䜛䜘䛖䛻
– A requirement to massively scale the ecosystem to support millions of end users.
– A requirement to support indeterminate platforms and applications.
– A requirement to design for cost efficient operations to take advantage of massive scale.
– A requirement to ensure that there is no single point of failure in the cloud ecosystem.
– A requirement for high availability architecture to meet customer SLA requirements.
– A requirement to be tolerant of rack level failure.
– A requirement to maximize flexibility to architect future production environments.

23. Architecture Design Guide Chapter 5. Network focused
Technical Considerations – Network recommendations overview(Cont’d)
• Keeping all of these in mind, the following network design recommendations can be made:
23
– Layer-3 designs are preferred over layer-2 architectures.
– Design a dense multi-path network core to support multi-directional scaling and flexibility.
– Use hierarchical addressing because it is the only viable option to scale network ecosystem.
– Use virtual networking to isolate instance service network traffic from the management and internal
network traffic.
– Isolate virtual networks using encapsulation technologies.
– Use traffic shaping for performance tuning.
– Use eBGP to connect to the Internet up-link.
– Use iBGP to flatten the internal traffic on the layer-3 mesh.
– Determine the most effective configuration for block storage network.
• Additional considerations
– OpenStack Networking versus legacy networking (nova-network) considerations
– Redundant networking: ToR switch high availability risk analysis
– Preparing for the future: IPv6 support
– Asymmetric links
– Performance

24. Architecture Design Guide Chapter 5. Network focused
Technical Considerations – Network recommendations overview(Cont’d)
• Keeping all of these in mind, the following network design recommendations can be made:
24
– Layer-3 designs are preferred over layer-2 architectures.
– Design a dense multi-path network core to support multi-directional scaling and flexibility.
– Use hierarchical addressing because it is the only viable option to scale network ecosystem.
– Use virtual networking to isolate instance service network traffic from the management and internal
L3䛜䛔䛔䜘
㧗ᐦᗘ䛺䝁䜰౑䛳䛶
IPnetwork 䛾㝵ᒙ໬䜢䛧䛺䛔䛸䝇䜿䞊䝹䛷䛝䛺䛔䜘
traffic.
䝛䝑䝖䝽䞊䜽௬᝿໬䛿ᚲ㡲
䛸䜚䛒䛘䛪BGP౑䛳䛶䝯䝑䝅䝳ᵓᡂ
䝤䝻䝑䜽䝇䝖䝺䞊䝆䛿≉Ṧ䛰䛛䜙䝛䝑䝖䝽䞊䜽Ẽ䜢௜䛡䛶
– Isolate virtual networks using encapsulation technologies.
– Use traffic shaping for performance tuning.
– Use eBGP to connect to the Internet up-link.
– Use iBGP to flatten the internal traffic on the layer-3 mesh.
– Determine the most effective configuration for block storage network.
• Additional considerations
– OpenStack Networking versus legacy networking (nova-network) considerations
– Redundant networking: ToR switch high availability risk analysis
– Preparing for the future: IPv6 support
– Asymmetric links
– Performance

25. Architecture Design Guide Chapter 5. Network focused
Technical Considerations – Prescriptive examples
25
• A large-scale web application has been designed with cloud
principles in mind. The application is designed to scale horizontally in
a bursting fashion and will generate a high instance count. The
application requires an SSL connection to secure data and must not
lose connection state to individual servers.
• An example design for this workload is depicted in the figure below. In
this example, a hardware load balancer is configured to provide
SSL offload functionality and to connect to tenant networks in order to
reduce address consumption. This load balancer is linked to the
routing architecture as it will service the VIP for the application. The
router and load balancer are configured with GRE tunnel ID of the
application's tenant network and provided an IP address within the
tenant subnet but outside of the address pool. This is to ensure that the
load balancer can communicate with the application's HTTP servers
without requiring the consumption of a public IP address.
• Because sessions persist until they are closed, the routing and
switching architecture is designed for high availability. Switches are
meshed to each hypervisor and each other, and also provide an
MLAG implementation to ensure that layer-2 connectivity does not
fail. Routers are configured with VRRP and fully meshed with switches
to ensure layer-3 connectivity. Since GRE is used as an overlay
network, Networking is installed and configured to use the Open
vSwitch agent in GRE tunnel mode. This ensures all devices can reach
all other devices and that tenant networks can be created for private
addressing links to the load balancer.

26. Architecture Design Guide Chapter 5. Network focused
Technical Considerations – Prescriptive examples
26
• A large-scale web application has been designed with cloud
principles in mind. The application is designed to scale horizontally in
a bursting fashion and will generate a high instance count. The
application requires an SSL connection to secure data and must not
lose connection state to individual servers.
• An example design for this workload is depicted in the figure below. In
䜽䝷䜴䝗⎔ቃྥ䛡䛾䝕䝄䜲䞁䠛
this example, a hardware load balancer is configured to provide
SSL offload functionality and to connect reduce 䝻䞊䝗䝞䝷䞁䝃䞊䛿address consumption. This load SSLto tenant networks in order to
balancer 䜸䝣䝻䞊䝗⏝
is linked to the
routing architecture as it will service the VIP for the application. The
router LBand 䛿䜰䝥䝸䜿䞊䝅䝵䞁䛾load balancer are configured with GRE VIPtunnel application's tenant network and provided an IP address 䜒ᥦ౪
ID of the
within the
tenant subnet but outside of the address pool. This is to ensure that the
load balancer can communicate with the application's HTTP servers
without requiring the consumption of a public IP address.
OVS䛷GRE䝖䞁䝛䝹䠛
MLAG䛷䝃䞊䝞䞊෕㛗໬
• Because sessions persist until they are closed, the routing and
switching architecture is designed for high availability. Switches are
meshed to each hypervisor and each other, and also provide an
MLAG implementation to ensure that layer-2 connectivity does not
fail. Routers are configured with VRRP and fully meshed with switches
to ensure layer-3 connectivity. Since GRE is used as an overlay
network, Networking is installed and configured to use the Open
vSwitch agent in GRE tunnel mode. This ensures all devices can reach
all other devices and that tenant networks can be created for private
addressing links to the load balancer.

27. DELLが考える
OpenStack Networkingの
考慮点

28. OpenStackの標準的な物理構成
28
Spine Switch Spine Switch
Leaf Switch Leaf Switch Leaf Switch Leaf Switch
Leaf Switch Leaf Switch
Compute Node
Compute Node
Compute Node
Compute Node
Mgmt Switch
Controller Node
Network Node
Management Node
FB/FW/Router
Mgmt Switch
Controller Node
Network Node
Management Node
LB/FW/Router
Mgmt Switch
Compute Rack ManagementNetwork Rack ManagementNetwork Rack

29. Fabrics Trend: The changing data center core
Modular migration to fixed-form factor
29
Density: Fixed vs. Chassis
40GbE per RU @ Line Rate (L3)
70
60
50
40
30
20
10
0
Conventional
ActCihvaes sFisa Cborreic
Chassis Fixed
2008 2010 2012 2014 2016
Data Center – Modular vs. Fixed Ethernet Switch
50
40
30
20
10
0
Chassis Fixed
2010 2012 2014 2016
Source: Dell Oro, 2013
Power: Fixed vs.
Chassis
Max Watts /

30. Cloud Big Data 従来のアプローチ
30
PARTITIONED CAPACIT
Y
Core
Dist
Access
VM
Network
Topology
Capacity
Topology
L2

31. Cloud Big Data 適切なアプローチ
31
Spine
UNIFORM
CAPACITY
Leaf
VM
Network
Topology
Capacity
Topology
L3
L2

32. Uniform fabric for Cloud Big Data
Name Node
32
Database
1280 Server ports
(64) (16)
L3
L2
vSwitch vSwitch
VM VM VM VM
Job Tracker
Rack
1
Rack
2
Rack
3
Rack
N
Node Secondary NN
Node
Node
Node
Node
Client
Node
Node
Node
Node
Client
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Block I/O
NAS
Object

33. Uniform fabric for Cloud Big Data
Name Node
Node Secondary NN
Node
Node
Node
Node
33
(64) (16)
L3
L2
Rack
1
Job Tracker
Rack
2
Client
Node
Node
Node
Node
Client
Firewall
Firewall
World
LB
LB
vswitch
VM VM VM
vswitch
VM VM VM
vswitch
VM VM VM
vswitch
VM VM VM
vswitch
VM VM VM
vswitch
VM VM VM
x86 Gateways

34. 10GE OpenStack Pod – Overlay based
34
10GE Cluster Interconnect
Line rate, Low Latency
VLT VLT VLT L3
Open vSwitch
Server cabinet 1
40 nodes
Nova Compute
• L2-in-L3 Overlay (GRE/VXLAN/STT)
• 40 Nodes per rack
• 4 racks, 160 nodes
• 2.5:1 oversubscription @ ToR
Server cabinet 2
40 nodes
Cloud API
Compute
Scheduler
Server cabinet 4
40 nodes
L2
10GE
ToR
160G
ECMP
160G
ECMP
160G
ECMP
160G
ECMP
160G
ECMP
160G
ECMP
Spine
Leaf
Core
x8
• Layer 3 Fabric with 2 Spine x 8 Leaf
• 2 switches per rack w/ VLT (S4810)
• Layer 3 handoff to Core via Leaf
Nova Compute
VM VM VM
Open vSwitch
VM VM VM
Nova
Volume
Swift /
Glance
vF
W
vLB
Message
Bus
OVS
Controller
L2-in-L3
Distributed Edge Overlay

35. サーバとLeaf-Switch(ToR)の冗長化
35
• 10G NIC x2枚をBonding
– Bonding mode=4(802.3ad)、またはmode=2(balance-xor/Static LAG)
– 10G NICの選定は性能や機能に大きく影響
– VXLAN OverlayをするときはH/W offload機能が有効
– TOEはたまに悪さすることも。。。
– [参考Blog] Linux Bonding mode=0の恐怖
– http://ja.community.dell.com/techcenter/b/weblog/archive/2014/05/16/
linux-bonding-mode-0
• Leaf(ToR)のダウンリンク冗長化
– MLAG推奨、スタッキングは非推奨
– MLAGの切り替え時間はmsecオーダー
– コストダウンするなら10G Twinaxを利用、相性問題注意
• Leaf(ToR)のアップリンクはBGPで冗長化
– BGP ECMPで最大16パス
– ダウンリンクとの帯域ボトルネックに注意
– OverSubscriptionは1:1～3:1の要件が多い
– アップリンクは40Ｇを使う
– コストダウンするなら40G DACを利用、相性問題注意
• ToRのオーバーサブスクリプションは3:1を目安に
• 何かあったとき用に管理LANは独立させてください
40G 40G
10Gx8
LA
G
10G 10G
Management

36. スタッキングとマルチシャーシLAG
36
ISL
MLAG vs Stacking Active Standby
• 䝇䝍䝑䜻䞁䜾䛿䝁䞁䝖䝻䞊䝹䝥䝺䞊䞁䛜୍䛴
• MLAG䛿䝁䞁䝖䝻䞊䝹䝥䝺䞊䞁䛜Act/Act 䛷2䛴
• 䝇䝍䝑䜻䞁䜾䛿෕㛗໬ᢏ⾡䛷䛿䛺䛟ᣑᙇᢏ⾡
• MLAG䛿ᣑᙇᢏ⾡䛷䛿䛺䛟෕㛗໬ᢏ⾡㻌
MLAG
Terminology Mapping to VLT
• MLAG = VLT
• 䝇䜲䝑䝏㛫䝸䞁䜽(ISL) = VLTi

37. Active Fabric solutions at any scale
37
Server/VM density
Fabric scale
Micro Scale Fabric
Macro Scale Fabric
Hyper Scale Fabric
Pay-As-You-Go model for
small-scale Data Centers
Dense, energy-efficient, low
latency solutions
Massively scalable with 40GbE
interconnects inside fabric

38. OpenStack Neutron
38
• OpenStack Installation Guide for Ubuntu
– Basic environment configuration
– OpenStack Networking(neutron)
– Figure 2.1 Three-node architecture with OpenStack
Networking (neutron)
• Neutronの考慮点
– Network Nodeはパワフルに！
– ハードウェア連携Plug-inは要注意
– GRE/VXLAN Encapsulation
– Hyper-VisorでもI/O性能がだいぶ変わる

39. Midokura MidoNet Network Virtualization Platform
Logical Switching– Layer 2 over Layer 3, decoupled from
the physical network; VXLAN L2 Gateway with S6000
Logical Routing– Routing between virtual networks
without exiting the software container
Distributed Firewall – Distributed Firewall, Kernel
Integrated, High Performance, avoids buying hardware
Distributed Load Balancer – Application Load Balancing
in software, avoids expensive hardware
Distributed VPN – Site-to-Site Remote Access VPN in
software, avoids expensive hardware
MidoNet API – RESTful API for integration into any Cloud
Management Platform
Any application – Supports Pricing: Model based on per host per year premium support any application
Emulates entire network topologies, with intelligence at the edge
Decentralized control plane, VXLAN, OpenFlow, OpenStack support
39
Any Application
Virtual Networks
Any Cloud Management Platform
MidoNet Virtualization Platform
Logical L2
Distributed VPN
Existing Network Hardware
Distributed
Firewall service
Distributed
Load Balancer ser
Service
Logical L3
KVM, ESXi, Xen LXC

40. Active Fabric Controller (AFC) for OpenStack
40
Simple
• Zero-touch provisioning
• Centralized control plane
• Built-in support for L4-L7
Flexible
• Ready for DC and Cloud solutions
• Hypervisor agnostic
• Blades, rack servers, and VMs
Programmable
• Single interface for fabric-wide mgmt control
• Language-agnostic APIs (REST)
• Simple/Extensible object model
Horizon UI
Blade Servers
OpenStack
Neutron
Plug-in
Object Model API
Controller software
Rack Servers
Storage Arrays
L4-L7 Services
Controller
UI
Simple, Flexible Programmable
fabric for Openstack Cloud
Deployments

41. OpenDaylight “Helium”
41

42. まとめ: OpenStack Networking
42
Spine Switch Spine Switch
Leaf Switch Leaf Switch Leaf Switch Leaf Switch
Leaf Switch Leaf Switch
Compute Node
Compute Node
Compute Node
Compute Node
Mgmt Switch
Controller Node
Network Node
Management Node
FB/FW/Router
Mgmt Switch
Controller Node
Network Node
Management Node
LB/FW/Router
Mgmt Switch
Compute Rack ManagementNetwork Rack ManagementNetwork Rack

43. まとめ: OpenStack Networking
43
Spine Switch Spine Switch
L3 ECMP
MLAG / Over Subscription
Leaf Switch Leaf Switch Leaf Switch Leaf Switch
Leaf Switch Leaf Switch
Compute Node
Compute Node
Compute Node
Compute Node
Bonding
Hyper-Visor / Encapsulation NIC H/W
offload
Mgmt Switch
Controller Node
Network Node
Management Node
FB/FW/Router
tolerant of rack level failure
Dedicated Management Mgmt Switch
Network
Controller Node
Network Node
Management Node
LB/FW/Router
Mgmt Switch
Compute Rack ManagementNetwork Rack ManagementNetwork Rack

44. DELL Japanの取り組み

45. 45
OSCA™ 概要
⽬目的
効率率率的でセキュアなコスト効果の⾼高い、オ
ープンで標準化されたクラウド環境の提⾔言
および、参加メンバーの
クラウド関連ビジネスの活性化
Ø 柔軟な拡張性と省省電⼒力力を追求した
クラウドインフラの提供
Ø 共同検証やサービス開発による技術の向上
Ø 動作確認のとれたベスト・プラク ティ
ス・ソリューションを提供
参加対象
⽬目標
• IT分野における共同検証やサービス開発に よる技
術の向上
• データセンターやクラウド市場開拓拓を⽬目指してお客
様にご安⼼心してお使いいただける サービスやソ
リューション、インフラを提供
• クラウドサービスを展開しているSI
• クラウドを導⼊入しているお客様
• ISV / OSS

46. 46
OSCA™ 参加メンバー 2014年年10⽉月現在
五⼗十⾳音順

47. OSCA™ 技術資料料
47
Wiki ページ
OpenStack Wiki page
• OpenStack / Hadoopを⽤用いたオープンなクラウドの運⽤用
• OpenStackのリファレンスアーキテクチャ
• OpenStackでクラウド構築のための準備
Hadoop Wiki page
• OpenStack / Hadoopを⽤用いたオープンなクラウドの運⽤用
• Apache Hadoopのリファレンスアーキテクチャ
Crowbar Wiki page
• OpenStack / Hadoopを⽤用いたオープンなクラウドの運⽤用
ホワイトペーパの公開
q サーバ 1 台で構築する Red Hat OpenStack Preview Step by
Step Guide
q サーバ 1 台で構築する OpenStack Swift Step by Step Guide
q 第12世代 Dell PowerEdge サーバを活⽤用した PostgreSQL ベ
ストプラクティス
q Red Hat KVM – 異異種仮想化製品間における仮想マシン移⾏行行
q Red Hat Storage Server概要
q CloudStackで実現するクラウド環境構築検証
q VDIガイド
q Red Hat OpenStack 3.0 運⽤用検証報告書 (VMレンタルサービ
ス編)
検証および
デモ環境
各種セミナー開催

48. 48
OSCA™ に関する情報/お問い合わせ
http://www.osca-jp.com
E-Mail: info@osca-jp.com
TEL：03-6893-2307

49. 49
ITエンジニアのためのコミュニティー
Dell テックセンター
テックセンターとは
• Dellが提供するITエンジニアのための情報共有サイトです。
• Dellの技術エキスパートによるブログで最新技術トレンドをレポートいたします。
• ハードウェアやソフトウェアのセットアップをビデオで紹介しております。
• 構成ガイド、最適化ガイドなど技術ドキュメントも満載です。
• フォーラムを提供：ユーザー間でのベストプラクティスの共有が可能です。
Dellのテクノロジーに関する最新情報と情報交換
http://www.jp.dell.com/japantechcenter/
• サイトに登録いただければフォーラムに参加し、
技術ディスカッションにも参加することができ
ます。
●DELLロゴは、⽶米国Dell Inc.の登録商標です。

50. 50
DellのOpenStackソリューション
Dell Cloud Manager
OpenStack Reference Architecture
Neutron Plug-‐‑‒in
OpenCrowbar
Active Fabric Manager
DevOps
Dell EqualLogic
Dell PowerEdgeシリーズ
Dell Networkingシリーズ
Cinder Driver
IaaS cloud
AWS /
Azure /
Others.

51. 51
Dell Red Hat Cloud Solutions
Dellは Red Hat Enterprise
Linux OpenStack Platform
の世界初のOEMベンダー
OpenStack – NOW open
for business
http://www.dell.com/learn/us/en/uscorp1/secure/2014-04-16-dell-partner-red-hat-openstack-private-cloud

52. 52
Dell Red Hat Cloud Solutions
OpenStackでエンタープライズ環境に適した標準的なオープンクラウ
ドソリューションを実現する
• OpenStackをエンタープライズ環境で安⼼心して利利⽤用
して頂く為にデルとレッドハットは共同開発を推進
• エンタープライズグレードの検証認定済みで、⾼高度度な
スケーラビリティ、セキュリティおよびサポート付の
クラウド基盤ソリューション
• 導⼊入⽀支援から保守サービスを提供
• 特定のエンタープライズユースケースを想定したアプ
リケーションの展開を⽀支援

53. 53
Dell Red Hat Cloud Solutionコンポーネント
検証済みハードウェア。
もっとも安定した最新の
Dell PowerEdgeサーバ
とForce10スイッチで信
頼できるOpenStackソ
リューションを提供
検証済みのReference Architecture
と事前設定済み構成により環境構築の
経費と効率率率を向上
Red Hat Enterprise
Linux OpenStackプラ
ットフォームのセキュリ
テ、安定性、サポートを
提供
Dell Red Hat
Cloud
Solutions
Dell Professional
Services
Dell ProSupport

54. Dell | Red Hat OpenStack Lighthouse Program
OpenStackでプライベートクラウド構築を手軽に始めたい企業に向けた期間限定の特別価格プログラム
v Red Hat Enterprise Linux OpenStack Platformの初期導⼊入コストを抑え、短期
間でプライベートクラウドの環境構築を実現します。
54
【プログラム内容】
60 ⽇日間有効なPOC 向けRed Hat OpenStack サブスクリプション
Red Hat OpenStack 検証準備⽀支援
Red Hat OpenStack リモート技術⽀支援(30時間)
Red Hat OpenStack 管理理者トレーニング＆エキスパート認定試験 x 2名様分
【デル・ハードウエア】
Dell PowerEdge R720 Servers (x3)
Dell Networking S55 Switch, 1GB networking (x1)
【提供条件】
お客様事例例紹介のご協⼒力力に同意していただくことをお願いします。
【お問い合わせ】
デル株式会社
エンタープライズソリューション統括本部
ソリューションビジネス開発部
E-‐‑‒MAIL : JP_̲ESG_̲BDM@Dell.com
【本プログラムに関するご注意】 記載内容は製品の改良良のため、予告なく変更更されることがあります。

55. 55
OpenStack Demo/POC環境
Dell DSC東京にてお客様向けに無償のDemoやPOC環境を提供
OpenStack DemoPOC向けDellハードウェア
• 28本のラック
• 数百台のサーバ
• ストレージCompelent/
Equallogic
• OpenStack Icehouse
(CentOS6.5)
• Redhat OpenStack
Platform 4.0(Habana)
• Cinder + Equallogic

56. 【ご参考】NICT – 北陸StarBED技術センター
56

57. 57
デル テックセンターに情報配信中
OpenStackに関するホワイトペーパ、構築⼿手順などを随時公開
OpenStack Icehouseをインストールしてみました
http://ja.community.dell.com/techcenter/b/weblog/archive/2014/05/07/openstack-‐‑‒icehouse.aspx
Redhat OpenStack構築⼿手順(Packstack使⽤用)
http://ja.community.dell.com/techcenter/b/weblog/archive/2014/03/11/redhat-‐‑‒openstack-‐‑‒packstack.aspx
OpenStack Equallogic Cinder driver設定⽅方法
http://ja.community.dell.com/techcenter/b/weblog/archive/2014/03/07/openstack-‐‑‒equallogic-‐‑‒cinder-‐‑‒driver.aspx
http://www.jp.dell.com/japantechcenterデル テックセンター検索索

58. Dell 13G Server released
• デル最新サーバーブログ
58
– Part 1: 最新Dell PowerEdge 第13世代サーバ 製品の概要とラインナップ
– http://ja.community.dell.com/techcenter/b/weblog/archive/2014/09/09/13gblog-part1
– Part 2: Haswell CPU とDDR4 メモリ
– http://ja.community.dell.com/techcenter/b/weblog/archive/2014/09/17/13gblog-part2
• 【参考】Intel Xeon E5 v3 Family
– http://ark.intel.com/ja/products/family/78583/Intel-Xeon-Processor-E5-v3-Family#@Server

59. PowerEdge R630
2S/1Uラックサーバ、2ソケットで最高のコンピューティング、メモリ、ストレージ密度を実現
• 概要
59
– 高性能2S/1Uラックサーバは、さまざまなリソースにおいて極
めて高い密度を実現しているため、非常に柔軟にデータセンタ
ーを拡張できます。強力なプロセッサー、大容量メモリ、およ
び非常に高速なストレージを高密度で組み合わせることで、
要求の厳しいさまざまな環境において正しく動作する、汎用性
の高いサーバが実現します。冗長性を備えた埋め込み型高速ハ
イパーバイザなどのRAS機能を搭載することで、高い信頼性が
得られます。
• 対象ワークロード
– クラウドアプリケーション、仮想化、データベース、
ハイパフォーマンスコンピューティング（HPC）、Web技術、
およびXaaSに適した設計
1.8インチドライブ（24台）搭載R630
• メリット
2.5インチドライブ（8台）搭載R630
– コンピューティング、メモリ、およびストレージの驚異的な密度
– 優れたパフォーマンスと高い信頼性
– 直感的な管理ツールを使用した簡単なライフサイクル管理
䝟䝣䜷䞊䝬䞁䝇 ྍ⏝ᛶ ᣑᙇᛶ䚸I/O䚸䝇䝖䝺䞊䝆
• 2SインテルXeon E5-2600v3プロセ
ッサー（CPUあたり最大18コア）
• DDR4 DIMM（1.5 TB） x 24
• 最大で2基のダブルワイドまたは4基
の
シングルワイドの内蔵GPU処理アク
セ
ラレーターをサポート
• 冗長電源装置（PSU）
• ホットプラグ対応の交換可能なPSU、
HDD、およびファン
• フェイルセーフな仮想化を実現するデュアル
SDカード
• ライフサイクルコントローラやOpenManag
eを搭載したiDRAC8 Expressまたは
Enterprise
• iDRAC QuickSync（オプション）
• 最大16台の2.5インチHDDまたは
8台の3.5インチHDD
• さらなるパフォーマンス向上のためのRAIDオ
プション
• PCIe Gen3拡張スロット x 7とRAID専用スロット
x 1
• Dell Fluid Cache for SANとSanDisk DAS Cach
eをサポート
• セレクトネットワークアダプタ:
• 1 GbE x 4、10 GbE x 2

60. PowerEdge R730
2S/2Uラックサーバ、クラス最高の汎用サーバ
• 概要
60
– 高性能2S/2Uラックサーバは極めて優れた柔軟性を提供し
ます。R730は、クラウド、仮想化、Web技術、HPCなどの要求
の厳しい環境において正しく動作します。最大2台のGPUをサ
ポートするため、医療画像またはグラフィックス処理の多い
VDIに最適です。
• 対象ワークロード
– クラス最高の仮想化、クラウドアプリケーション、
Web技術、HPC、XaaSプロバイダ、VDI、医療画像
– VDIを拡張するために最適化されたI/Oを備えた、
優れたデスクトップ仮想化サーバ
– 拡張ストレージと2基のダブルワイドGPUを使用する、高画質
の医療画像およびVDI解像度
• メリット
– IOを最適化したVDIに最高の拡張性を提供
– 脅威的な密度と高い信頼性を実現
– 直感的な管理ツールを使用した簡単なライフサイクル管理
䝟䝣䜷䞊䝬䞁䝇 ྍ⏝ᛶ ᣑᙇᛶ䚸I/O䚸䝇䝖䝺䞊䝆
• 2SインテルXeon E5-2600v3プロセ
ッサー（CPUあたり最大18コア）
• DDR4 DIMM（1.5 TB） x 24
• 最大で2基のダブルワイドまたは4
基の
シングルワイドの内蔵GPU処理ア
クセ
ラレーターをサポート
• 冗長電源装置（PSU）
• ホットプラグ対応の交換可能なPSU、
HDD、およびファン
• フェイルセーフな仮想化を実現するデュアル
SDカード
• ライフサイクルコントローラやOpenManag
eを搭載したiDRAC8 Expressまたは
Enterprise
• iDRAC QuickSync（オプション）
• 最大16台の2.5インチHDDまたは
8台の3.5インチHDD
• さらなるパフォーマンス向上のためのRAIDオ
プション
• PCIe Gen3拡張スロット x 7とRAID専用スロット
x 1
• Dell Fluid Cache for SANとSanDisk DAS Cach
eをサポート
• セレクトネットワークアダプタ:
• 1 GbE x 4、10 GbE x 2

61. PowerEdge R730xd
2S/2Uラックサーバ、クラス最高のストレージ密度を誇るサーバ
• 概要
61
– 強力な2S/2Uラックサーバは、今日のXaaSプロバイダ、
Hadoop / ビッグデータの利用者、共同利用によるホスティング
で求められるストレージ効率のスケールアウトを重視して設計
されており、Microsoft Storage Spacesなどのアプリケーション
を使用してインボックスのストレージ階層化をオプションで提
供します。
• 対象ワークロード
– クラス最高の仮想化、クラウドアプリケーション、
Web技術、HPC、XaaSプロバイダ、VDI、医療画像
– VDIを拡張するために最適化されたI/Oを備えた、
優れたデスクトップ仮想化サーバ
– 拡張ストレージと2基のダブルワイドGPUを使用する、高画質
の医療画像およびVDI解像度
• メリット
– 最高のスケールアウトストレージ
– 2Uフォームファクタあたり最高のドル / GB
– 直感的な管理ツールを使用した簡単なライフサイクル管理
䝟䝣䜷䞊䝬䞁䝇 ྍ⏝ᛶ ᣑᙇᛶ䚸I/O䚸䝇䝖䝺䞊䝆
• 2SインテルXeon E5-2600v3プロセッ
サー（CPUあたり最大18コア）
• DDR4 DIMM（1.5 TB） x 24
• 最大4台のNVMe Express Flash PCIe
SSD（オプション）
• 冗長電源装置（PSU）
• ホットプラグ対応の交換可能なPSU、
HDD、およびファン
• フェイルセーフな仮想化を実現するデュアル
SDカード
• ライフサイクルコントローラやOpenManag
eを搭載したiDRAC8 Expressまたは
Enterprise
• OpenManage Mobileアクセス
• 最大24台の2.5インチHDD + 2台の2.5インチ（
背面）または16台の3.5インチHDD + 2台の2.5
インチ（背面）または12台の3.5インチまたは1
6台の3.5インチ（4台内蔵） + 2台の2.5インチ
または18台の1.8インチ + 8台の3.5インチ
• Dell Fluid Cache for SANと今後提供予定のDAS
キャッシュソリューション
（製品名TBD）をサポート
• デュアルPERCを含む複数のRAIDオプション
• PCIe Gen3拡張スロット x 6とRAID
専用のPCIeレーン x 1
• SNA: 1 GbE x 4、10 GbE x 2

62. Driving Open
Networking

63. Dell offers Choice of Software Defined Networking
Open Standards + Open Protocols + Open Source = Open IT with Choices
63
Vmware, Microsoft, Open Stack
TCL, Perl Python scripting
REST-API, XML, OMI, Puppet, Chef
Programmable
Solutions
Overlay /Hypervisor
Solutions
SDN Controllers
Open Standards, Open Source
Software-Defined
Networks
Controller
Solutions
Open
Networking

64. Compute paradigm shift
The disaggregated server model changed the landscape
Mainframe/Proprietary model X86 servers model Today
64
Proprietary architectures
mgmt tools
Limited apps
Proprietary OS
(e.g., Solaris, HP-UX, Ultrix)
Proprietary CPUs
(e.g., SPARC, PA-RISC, Alpha)
Orchestration/automation for
distributed computing
Application ecosystem
Standard OS—hypervisors
Industry standard (X86 CPU)
Dell
HP
Others
VMware | Windows Server System | RedHat Linux
| Suse
Intel | AMD

65. Now: Networking paradigm shift
65
Traditional networking Future of networking
Proprietary architectures
mgmt tools
Hundreds of protocols
Proprietary networking
OS
Proprietary ASICs
Standard orchestration automation tools
Optional 3rd party SDN/NVO controller
Any networking OS
Open standard hardware
Merchant silicon

66. New S-Series open networking models
66
Dell S4810-ON
Dell S6000-ON
Dell’s first disaggregated open
networking switches
• Designed for flexibility, performance and
support of 3rd party OS
• 1RU high-density 10/40Gbps TOR
switches
– S4810-ON with 48 ports 10GbE and 4 ports
40GbE
– S6000-ON with 32 ports of 40GbE or 96
ports of 10GbE + 8 ports of 40GbE
• Supports the open source Open Network
Install Environment (ONIE)
• Dell global ProSupport Services

67. Imagine - “Androidification” of networking
67
Standard orchestration
and automation tools
Optional 3rd party SDN /
NVO controller
Any networking OS
Open standard hardware
Merchant silicon
+
Open Source Apps
+
Independent
Software Vendor
Apps
Standard orchestration
and automation tools
Optional 3rd party SDN /
NVO controller
Open network platform OS
Open standard hardware
Merchant silicon
Virtual
services
Power and
traffic
optimization
app
Performance
monitoring
opt app
Security
app
Our focus is on Apps

68. Best of breed Network Operating Systems
68
Dell Networking Operating Systems
• Feature rich, mission critical, line rate performance
Cumulus Linux
• Linux expertise and Linux standardized environments that value
common Linux tools for server and network management
Big Switch Networks Switch Light OS
• Network tapping and monitoring for customers interested in adopting
SDN

69. Open Networking Ecosystem with Cumulus Linux
69
Routing Network
NSX
Automation Orchestration Network
Virtualization Monitoring Storage Security Others
Cumulus Linux
Industry Standard Hardware

70. Configuration Management
70
• Converged administration
– Same automation tools for managing servers now available for the network
Layer 3 Fabric
Servers
Switches

71. This is exactly what dell + big switch bring to market
Big Switch SDN
software...
SDN Controller – single, centralized,
command control
Sits in customer Virtual Machine
(VM) environment / appliance
71
S4810-ON
…Dell open network switch
hardware…
Same high-density, high-quality Dell hardware
used in production ENT, SP and PS hyper-scale
datacenters
1G, 10G, 40G ports for maximum flexibility
BIG TAP
CONTROLLER
SWITCH LIGHT™ OS
ONIE BOOT LOADER
…deliver
monitoring fabrics
Scalable, multi-tenant
network monitoring
solution
Open-networking enables rapid innovation and customer choice through hardware and software disaggregation

72. 72
Thank you