Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OpenStack Infrastructure at any Scale - Simple is BEST!? - - OpenStack最新情報セミナー 2014年10月

6,586 views

Published on

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

Published in: Technology

OpenStack Infrastructure at any Scale - Simple is BEST!? - - OpenStack最新情報セミナー 2014年10月

  1. 1. OpenStack Infrastructure at any Scale - Simple is BEST!? - Takanori Suzuki Email: takanori_suzuki@dell.com Twitter: @takanorisuzuki
  2. 2. Agenda • OpenStack Dell’s PoV • OpenStack 公式ドキュメントのネットワーク部分抜粋 • DELLが考えるOpenStack Networkingの考慮点 • DELLジャパンの取り組み • Driving OpenNetworking 2
  3. 3. Who am I? • 名前 3 – 鈴木孝規 (すずきたかのり) • 職歴 – 日本企業でインフラエンジニア – 外資でネットワークエンジニア – デルでネットワークが関係すること全般 • 趣味 – 乗馬、子育て
  4. 4. OpenStack Dell’s PoV
  5. 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. 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. 7. Our Focus 7 Enrich the OpenStack community Bridge OpenStack and the enterprise
  8. 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. 9 OpenStack is Open Innovation
  10. 10. OpenStack 公式ドキュメントの ネットワーク部分抜粋
  11. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 27. DELLが考える OpenStack Networkingの 考慮点
  28. 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. 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. 30. Cloud Big Data 従来のアプローチ 30 PARTITIONED CAPACIT Y Core Dist Access VM Network Topology Capacity Topology L2
  31. 31. Cloud Big Data 適切なアプローチ 31 Spine UNIFORM CAPACITY Leaf VM Network Topology Capacity Topology L3 L2
  32. 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. 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. 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. 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の要件が多い – アップリンクは40Gを使う – コストダウンするなら40G DACを利用、相性問題注意 • ToRのオーバーサブスクリプションは3:1を目安に • 何かあったとき用に管理LANは独立させてください 40G 40G 10Gx8 LA G 10G 10G Management
  36. 36. スタッキングとマルチシャーシLAG 36 ISL MLAG vs Stacking Active Standby • 䝇䝍䝑䜻䞁䜾䛿䝁䞁䝖䝻䞊䝹䝥䝺䞊䞁䛜୍䛴 • MLAG䛿䝁䞁䝖䝻䞊䝹䝥䝺䞊䞁䛜Act/Act 䛷2䛴 • 䝇䝍䝑䜻䞁䜾䛿෕㛗໬ᢏ⾡䛷䛿䛺䛟ᣑᙇᢏ⾡ • MLAG䛿ᣑᙇᢏ⾡䛷䛿䛺䛟෕㛗໬ᢏ⾡㻌 MLAG Terminology Mapping to VLT • MLAG = VLT • 䝇䜲䝑䝏㛫䝸䞁䜽(ISL) = VLTi
  37. 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. 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. 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. 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. 41. OpenDaylight “Helium” 41
  42. 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. 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. 44. DELL Japanの取り組み
  45. 45. 45 OSCA™ 概要 ⽬目的 効率率率的でセキュアなコスト効果の⾼高い、オ ープンで標準化されたクラウド環境の提⾔言 および、参加メンバーの クラウド関連ビジネスの活性化 Ø 柔軟な拡張性と省省電⼒力力を追求した クラウドインフラの提供 Ø 共同検証やサービス開発による技術の向上 Ø 動作確認のとれたベスト・プラク ティ ス・ソリューションを提供 参加対象 ⽬目標 • IT分野における共同検証やサービス開発に よる技 術の向上 • データセンターやクラウド市場開拓拓を⽬目指してお客 様にご安⼼心してお使いいただける サービスやソ リューション、インフラを提供 • クラウドサービスを展開しているSI • クラウドを導⼊入しているお客様 • ISV / OSS
  46. 46. 46 OSCA™ 参加メンバー 2014年年10⽉月現在 五⼗十⾳音順
  47. 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. 48 OSCA™ に関する情報/お問い合わせ http://www.osca-jp.com E-Mail: info@osca-jp.com TEL:03-6893-2307
  49. 49. 49 ITエンジニアのためのコミュニティー Dell テックセンター テックセンターとは • Dellが提供するITエンジニアのための情報共有サイトです。 • Dellの技術エキスパートによるブログで最新技術トレンドをレポートいたします。 • ハードウェアやソフトウェアのセットアップをビデオで紹介しております。 • 構成ガイド、最適化ガイドなど技術ドキュメントも満載です。 • フォーラムを提供:ユーザー間でのベストプラクティスの共有が可能です。 Dellのテクノロジーに関する最新情報と情報交換 http://www.jp.dell.com/japantechcenter/ • サイトに登録いただければフォーラムに参加し、 技術ディスカッションにも参加することができ ます。 ●DELLロゴは、⽶米国Dell Inc.の登録商標です。
  50. 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. 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. 52 Dell Red Hat Cloud Solutions OpenStackでエンタープライズ環境に適した標準的なオープンクラウ ドソリューションを実現する • OpenStackをエンタープライズ環境で安⼼心して利利⽤用 して頂く為にデルとレッドハットは共同開発を推進 • エンタープライズグレードの検証認定済みで、⾼高度度な スケーラビリティ、セキュリティおよびサポート付の クラウド基盤ソリューション • 導⼊入⽀支援から保守サービスを提供 • 特定のエンタープライズユースケースを想定したアプ リケーションの展開を⽀支援
  53. 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. 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. 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. 56. 【ご参考】NICT – 北陸StarBED技術センター 56
  57. 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. 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. 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. 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. 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. 62. Driving Open Networking
  63. 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. 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. 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. 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. 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. 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. 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. 70. Configuration Management 70 • Converged administration – Same automation tools for managing servers now available for the network Layer 3 Fabric Servers Switches
  71. 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. 72 Thank you

×