1. OpenStack Infrastructure atany Scale- Simple is BEST!? -Takanori SuzukiEmail: takanori_suzuki@dell.comTwitter: @takanorisuzuki

2. Agenda OpenStack Dells PoV OpenStack DELLOpenStack Networking DELL Driving OpenNetworking2 3. Who am I? 3 4. OpenStackDells PoV 5. OpenStack is NOT a productPhysical Infrastructure Compute Storage Networking5Access controlID mgmtCloud OperatingSystemMaintenance & Support Code Hardware Help SystemsEnterpriseCloudSecurity MgmtPolicy MgmtApplicationsApp. mgmt, PaaSMonitoring &Analytics 6. What OpenStack brings 6ControlEnterpriseCloudFlexibilityVast growingeco-systemTrue choiceCatalyst forInnovationVisibilityReduced risk ofAlligatorencounters! 7. Our Focus7Enrich theOpenStack communityBridge OpenStackand the enterprise 8. Dells Commitment to OpenStack8Dell was one of the first of the hardware vendors to graspthe fact that cloud is about provisioning services,not about the hardware.Maxwell Cooter, Cloud ProProven solutions Proven components First OpenStack cloud solution provider Pioneering OpenStack partnerOnly tier 1 day 1 hardware provider Deep partner ecosystemwith single point of service and support ONLY company with automated software formulti-node OpenStack provisioning: Crowbar Dell OpenStack experts continually investin the community Gold Foundation Member with 2 board positionsSave on licensingfeesInnovateaggressivelyScale operationsefficiently 9. 9OpenStack isOpenInnovation 10. OpenStack 11. Official Document for OpenStack Networking Architecture Design Guide Chapter 5. Network focused11 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 Networking12 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 focusedContents Contents13 User requirements Technical considerations Operational considerations Architecture Prescriptive examples All OpenStack deployments are dependent, to some extent, on network communication in order to functionproperly 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 thatthe 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 webservices, High speed high volume transactional systems, High availability, Big Data, Virtual desktopinfrastructure (VDI), Voice over IP (VoIP), Video Conference or web conference, High performancecomputing (HPC) 14. Architecture Design Guide Chapter 5. Network focusedContents Contents14 User requirements Technical considerations Operational considerations Architecture Prescriptive examples All OpenStack deployments are dependent, to some extent, on network communication in order to functionproperly 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 thatthe 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 webservices, High speed high volume transactional systems, High availability, Big Data, Virtual desktopinfrastructure (VDI), Voice over IP (VoIP), Video Conference or web conference, High performancecomputing (HPC) 15. Architecture Design Guide Chapter 5. Network focusedUser Requirements User requirements15 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 cloudlocations 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 andrequirements for redundancy in the systems. Risks Netowrk misconfigurations, Capacity planning, Network tuning, Single Point Of Failure (SPOF), Complexity, Non-standardfeatures Security Security is often overlooked or added after a design has been implemented. Consider security implications andrequirements before designing the physical and logical network topologies. 16. Architecture Design Guide Chapter 5. Network focusedUser Requirements User requirements16 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 cloudlocations 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 andrequirements for redundancy in the systems. Risks Netowrk misconfigurations, Capacity planning, Network tuning, Single Point Of Failure (SPOF), Complexity, Non-standardfeatures Security Security is often overlooked or added after a design has been implemented. Consider security implications andrequirements before designing the physical and logical network topologies. 17. Architecture Design Guide Chapter 5. Network focusedTechnical Considerations Layer-2 Technical considerations17 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 wellin a data center with hundreds of physical machines, cloud data centers have the additional burden of needing to keep track of all virtual machineaddresses 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 statechanges 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 focusedTechnical Considerations Layer-2 Technical considerations18 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 wellVML2in a data center with hundreds of physical machines, cloud data centers have the additional burden of needing to keep track of all virtual machineaddresses 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 stateVLAN4096MLAGL2BUMARPARPchanges 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 focusedTechnical Considerations Layer-3 advantages Technical considerations19 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 onlyoccur 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 physicalhost. 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 theswitches 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 focusedTechnical Considerations Layer-3 advantages Technical considerations20 Layer-2 architecture limitations Layer-3 architecture advantages Network recommendations overview Additional considerations Layer-3 architecture advantagesL2PingL3 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 onlyoccur 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 limitationsIPL2L2MACIP 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 physicalhost. 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 theswitches 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 focusedTechnical Considerations Network recommendations overview Network recommendations overview21 OpenStack has complex networking requirements for several reasons. Many components interact atdifferent levels of the system stack that adds complexity. Data flows are complex. Data in an OpenStackcloud moves both between instances across the network (also known as East-West), as well as in and out ofthe system (also known as North-South). Physical server nodes have network requirements that areindependent of those used by instances which need to be isolated from the core network to account forscalability. It is also recommended to functionally separate the networks for security purposes and tuneperformance through traffic shaping. A number of important general technical and business factors need to be taken into consideration whenplanning 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 onspecific features of a vendors 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 focusedTechnical Considerations Network recommendations overview Network recommendations overview22 OpenStack has complex networking requirements for several reasons. Many components interact at differentOpenStack(East-West)(North-South)levels of the system stack that adds complexity. Data flows are complex. Data in an OpenStack cloud movesboth 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 ofthose used by instances which need to be isolated from the core network to account for scalability. It is alsorecommended to functionally separate the networks for security purposes and tune performance throughtraffic shaping. A number of important general technical and business factors need to be taken into consideration whenplanning 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 onspecific features of a vendors 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 focusedTechnical Considerations Network recommendations overview(Contd) 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 internalnetwork 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 focusedTechnical Considerations Network recommendations overview(Contd) 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 internalL3IPnetwork 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 focusedTechnical Considerations Prescriptive examples25 A large-scale web application has been designed with cloudprinciples in mind. The application is designed to scale horizontally ina bursting fashion and will generate a high instance count. Theapplication requires an SSL connection to secure data and must notlose connection state to individual servers. An example design for this workload is depicted in the figure below. Inthis example, a hardware load balancer is configured to provideSSL offload functionality and to connect to tenant networks in order toreduce address consumption. This load balancer is linked to therouting architecture as it will service the VIP for the application. Therouter and load balancer are configured with GRE tunnel ID of theapplication's tenant network and provided an IP address within thetenant subnet but outside of the address pool. This is to ensure that theload balancer can communicate with the application's HTTP serverswithout requiring the consumption of a public IP address. Because sessions persist until they are closed, the routing andswitching architecture is designed for high availability. Switches aremeshed to each hypervisor and each other, and also provide anMLAG implementation to ensure that layer-2 connectivity does notfail. Routers are configured with VRRP and fully meshed with switchesto ensure layer-3 connectivity. Since GRE is used as an overlaynetwork, Networking is installed and configured to use the OpenvSwitch agent in GRE tunnel mode. This ensures all devices can reachall other devices and that tenant networks can be created for privateaddressing links to the load balancer. 26. Architecture Design Guide Chapter 5. Network focusedTechnical Considerations Prescriptive examples26 A large-scale web application has been designed with cloudprinciples in mind. The application is designed to scale horizontally ina bursting fashion and will generate a high instance count. Theapplication requires an SSL connection to secure data and must notlose connection state to individual servers. An example design for this workload is depicted in the figure below. Inthis example, a hardware load balancer is configured to provideSSL offload functionality and to connect reduce address consumption. This load SSLto tenant networks in order tobalancer is linked to therouting architecture as it will service the VIP for the application. Therouter LBand load balancer are configured with GRE VIPtunnel application's tenant network and provided an IP address ID of thewithin thetenant subnet but outside of the address pool. This is to ensure that theload balancer can communicate with the application's HTTP serverswithout requiring the consumption of a public IP address.OVSGREMLAG Because sessions persist until they are closed, the routing andswitching architecture is designed for high availability. Switches aremeshed to each hypervisor and each other, and also provide anMLAG implementation to ensure that layer-2 connectivity does notfail. Routers are configured with VRRP and fully meshed with switchesto ensure layer-3 connectivity. Since GRE is used as an overlaynetwork, Networking is installed and configured to use the OpenvSwitch agent in GRE tunnel mode. This ensures all devices can reachall other devices and that tenant networks can be created for privateaddressing links to the load balancer. 27. DELLOpenStack Networking 28. OpenStack28Spine Switch Spine SwitchLeaf Switch Leaf Switch Leaf Switch Leaf SwitchLeaf Switch Leaf SwitchCompute NodeCompute NodeCompute NodeCompute NodeMgmt SwitchController NodeNetwork NodeManagement NodeFB/FW/RouterMgmt SwitchController NodeNetwork NodeManagement NodeLB/FW/RouterMgmt SwitchCompute Rack ManagementNetwork Rack ManagementNetwork Rack 29. Fabrics Trend: The changing data center coreModular migration to fixed-form factor29Density: Fixed vs. Chassis40GbE per RU @ Line Rate (L3)706050403020100ConventionalActCihvaes sFisa CborreicChassis Fixed2008 2010 2012 2014 2016Data Center Modular vs. Fixed Ethernet Switch50403020100Chassis Fixed2010 2012 2014 2016Source: Dell Oro, 2013Power: Fixed vs.ChassisMax Watts / 30. CloudBig Data 30PARTITIONED CAPACITYCoreDistAccessVMNetworkTopologyCapacityTopologyL2 31. CloudBig Data 31SpineUNIFORMCAPACITYLeafVMNetworkTopologyCapacityTopologyL3L2 32. Uniform fabric for CloudBig DataName Node32Database1280 Server ports(64) (16)L3L2vSwitch vSwitchVM VM VM VMJob TrackerRack1Rack2Rack3RackNNode Secondary NNNodeNodeNodeNodeClientNodeNodeNodeNodeClientNodeNodeNodeNodeNodeNodeNodeNodeNodeNodeNodeNodeNodeNodeBlock I/ONASObject 33. Uniform fabric for CloudBig DataName NodeNode Secondary NNNodeNodeNodeNode33(64) (16)L3L2Rack1Job TrackerRack2ClientNodeNodeNodeNodeClientFirewallFirewallWorldLBLBvswitchVM VM VMvswitchVM VM VMvswitchVM VM VMvswitchVM VM VMvswitchVM VM VMvswitchVM VM VMx86 Gateways 34. 10GE OpenStack Pod Overlay based3410GE Cluster InterconnectLine rate, Low LatencyVLT VLT VLT L3Open vSwitchServer cabinet 140 nodesNova Compute L2-in-L3 Overlay (GRE/VXLAN/STT) 40 Nodes per rack 4 racks, 160 nodes 2.5:1 oversubscription @ ToRServer cabinet 240 nodesCloud APIComputeSchedulerServer cabinet 440 nodesL210GEToR160GECMP160GECMP160GECMP160GECMP160GECMP160GECMPSpineLeafCorex8 Layer 3 Fabric with 2 Spine x 8 Leaf 2 switches per rack w/ VLT (S4810) Layer 3 handoff to Core via LeafNova ComputeVM VM VMOpen vSwitchVM VM VMNovaVolumeSwift /GlancevFWvLBMessageBusOVSControllerL2-in-L3Distributed Edge Overlay 35. Leaf-Switch(ToR)35 10G NIC x2Bonding Bonding mode=4(802.3ad)mode=2(balance-xor/Static LAG) 10G NIC VXLAN OverlayH/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 MLAGmsec 10G Twinax Leaf(ToR)BGP BGP ECMP16 OverSubscription1:13:1 40 40G DAC ToR3:1 LAN40G 40G10Gx8LAG10G 10GManagement 36. LAG36ISLMLAG vs Stacking Active Standby MLAGAct/Act 2 MLAGMLAGTerminology Mapping to VLT MLAG = VLT (ISL) = VLTi 37. Active Fabric solutions at any scale37Server/VM densityFabric scaleMicro Scale FabricMacro Scale FabricHyper Scale FabricPay-As-You-Go model forsmall-scale Data CentersDense, energy-efficient, lowlatency solutionsMassively scalable with 40GbEinterconnects inside fabric 38. OpenStack Neutron38 OpenStack Installation Guide for Ubuntu Basic environment configuration OpenStack Networking(neutron) Figure 2.1 Three-node architecture with OpenStackNetworking (neutron) Neutron Network Node Plug-in GRE/VXLAN Encapsulation Hyper-VisorI/O 39. Midokura MidoNet Network Virtualization PlatformLogical Switching Layer 2 over Layer 3, decoupled fromthe physical network; VXLAN L2 Gateway with S6000Logical Routing Routing between virtual networkswithout exiting the software containerDistributed Firewall Distributed Firewall, KernelIntegrated, High Performance, avoids buying hardwareDistributed Load Balancer Application Load Balancingin software, avoids expensive hardwareDistributed VPN Site-to-SiteRemote Access VPN insoftware, avoids expensive hardwareMidoNet API RESTful API for integration into any CloudManagement PlatformAny application Supports Pricing: Model based on per host per year premium support any applicationEmulates entire network topologies, with intelligence at the edgeDecentralized control plane, VXLAN, OpenFlow, OpenStack support39Any ApplicationVirtual NetworksAny Cloud Management PlatformMidoNet Virtualization PlatformLogical L2Distributed VPNExisting Network HardwareDistributedFirewall serviceDistributedLoad Balancer serServiceLogical L3KVM, ESXi, Xen LXC 40. Active Fabric Controller (AFC) for OpenStack40Simple Zero-touch provisioning Centralized control plane Built-in support for L4-L7Flexible Ready for DC and Cloud solutions Hypervisor agnostic Blades, rack servers, and VMsProgrammable Single interface for fabric-wide mgmtcontrol Language-agnostic APIs (REST) Simple/Extensible object modelHorizon UIBlade ServersOpenStackNeutronPlug-inObject ModelAPIController softwareRack ServersStorage ArraysL4-L7 ServicesControllerUISimple, FlexibleProgrammablefabric for Openstack CloudDeployments 41. OpenDaylight Helium41 42. : OpenStack Networking42Spine Switch Spine SwitchLeaf Switch Leaf Switch Leaf Switch Leaf SwitchLeaf Switch Leaf SwitchCompute NodeCompute NodeCompute NodeCompute NodeMgmt SwitchController NodeNetwork NodeManagement NodeFB/FW/RouterMgmt SwitchController NodeNetwork NodeManagement NodeLB/FW/RouterMgmt SwitchCompute Rack ManagementNetwork Rack ManagementNetwork Rack 43. : OpenStack Networking43Spine Switch Spine SwitchL3 ECMPMLAG / Over SubscriptionLeaf Switch Leaf Switch Leaf Switch Leaf SwitchLeaf Switch Leaf SwitchCompute NodeCompute NodeCompute NodeCompute NodeBondingHyper-Visor / Encapsulation NIC H/WoffloadMgmt SwitchController NodeNetwork NodeManagement NodeFB/FW/Routertolerant of rack level failureDedicated Management Mgmt SwitchNetworkController NodeNetwork NodeManagement NodeLB/FW/RouterMgmt SwitchCompute Rack ManagementNetwork Rack ManagementNetwork Rack 44. DELL Japan 45. 45OSCA IT SI ISV / OSS 46. 46OSCA 201410 47. OSCA 47Wiki OpenStack Wiki page OpenStack / Hadoop OpenStack OpenStackHadoop Wiki page OpenStack / Hadoop Apache HadoopCrowbar Wiki page OpenStack / Hadoopq 1 Red Hat OpenStack Preview Step byStep Guideq 1 OpenStack Swift Step by Step Guideq 12 Dell PowerEdge PostgreSQL q Red Hat KVM q Red Hat Storage Serverq CloudStackq VDIq Red Hat OpenStack 3.0 (VM) 48. 48OSCA /http://www.osca-jp.comE-Mail: info@osca-jp.comTEL03-6893-2307 49. 49ITDell DellIT Dell Dellhttp://www.jp.dell.com/japantechcenter/ DELLDell Inc. 50. 50DellOpenStackDell Cloud ManagerOpenStack Reference ArchitectureNeutron Plug-inOpenCrowbarActive Fabric ManagerDevOpsDell EqualLogicDell PowerEdgeDell NetworkingCinder DriverIaaS cloudAWS /Azure /Others. 51. 51Dell Red Hat Cloud SolutionsDell Red Hat EnterpriseLinux OpenStack PlatformOEMOpenStack NOW openfor businesshttp://www.dell.com/learn/us/en/uscorp1/secure/2014-04-16-dell-partner-red-hat-openstack-private-cloud 52. 52Dell Red Hat Cloud SolutionsOpenStack OpenStack 53. 53Dell Red Hat Cloud SolutionDell PowerEdgeForce10OpenStackReference ArchitectureRed Hat EnterpriseLinux OpenStackDell Red HatCloudSolutions Dell ProfessionalServicesDell ProSupport 54. Dell | Red Hat OpenStack Lighthouse ProgramOpenStackv Red Hat Enterprise Linux OpenStack Platform5460 POC Red Hat OpenStack Red Hat OpenStack Red Hat OpenStack (30)Red Hat OpenStack x 2Dell PowerEdge R720 Servers (x3) Dell Networking S55 Switch, 1GB networking (x1)E-MAIL : JP_ESG_BDM@Dell.com 55. 55OpenStack Demo/POCDell DSCDemoPOCOpenStack DemoPOCDell 28 Compelent/Equallogic OpenStack Icehouse(CentOS6.5) Redhat OpenStackPlatform 4.0(Habana) Cinder + Equallogic 56. NICT StarBED56 57. 57 OpenStackOpenStack Icehousehttp://ja.community.dell.com/techcenter/b/weblog/archive/2014/05/07/openstack-icehouse.aspxRedhat OpenStack(Packstack)http://ja.community.dell.com/techcenter/b/weblog/archive/2014/03/11/redhat-openstack-packstack.aspxOpenStack Equallogic Cinder driverhttp://ja.community.dell.com/techcenter/b/weblog/archive/2014/03/07/openstack-equallogic-cinder-driver.aspxhttp://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 R6302S/1U2 59 2S/1URAS HPCWebXaaS1.824R630 2.58R630 I/O 2SXeon E5-2600v3CPU18 DDR4 DIMM1.5 TB x 24 24GPU PSU PSUHDD SD OpenManageiDRAC8 ExpressEnterprise iDRAC QuickSync 162.5HDD83.5HDD RAID PCIe Gen3 x 7RAIDx 1 Dell Fluid Cache for SANSanDisk DAS Cache : 1 GbE x 410 GbE x 2 60. PowerEdge R7302S/2U 60 2S/2UR730WebHPC2GPUVDI WebHPCXaaSVDI VDII/O 2GPUVDI IOVDI I/O 2SXeon E5-2600v3CPU18 DDR4 DIMM1.5 TB x 24 24GPU PSU PSUHDD SD OpenManageiDRAC8 ExpressEnterprise iDRAC QuickSync 162.5HDD83.5HDD RAID PCIe Gen3 x 7RAIDx 1 Dell Fluid Cache for SANSanDisk DAS Cache : 1 GbE x 410 GbE x 2 61. PowerEdge R730xd2S/2U 61 2S/2UXaaSHadoop / Microsoft Storage Spaces WebHPCXaaSVDI VDII/O 2GPUVDI 2U / GB I/O 2SXeon E5-2600v3CPU18 DDR4 DIMM1.5 TB x 24 4NVMe Express Flash PCIeSSD PSU PSUHDD SD OpenManageiDRAC8 ExpressEnterprise OpenManage Mobile 242.5HDD + 22.5163.5HDD + 22.5123.5163.54 + 22.5181.8 + 83.5 Dell Fluid Cache for SANDASTBD PERCRAID PCIe Gen3 x 6RAIDPCIe x 1 SNA: 1 GbE x 410 GbE x 2 62. Driving OpenNetworking 63. Dell offers Choice of Software Defined NetworkingOpen Standards + Open Protocols + Open Source = Open IT with Choices63Vmware, Microsoft, Open StackTCL, PerlPython scriptingREST-API, XML, OMI, Puppet, ChefProgrammableSolutionsOverlay /HypervisorSolutionsSDN ControllersOpen Standards, Open SourceSoftware-DefinedNetworksControllerSolutionsOpenNetworking 64. Compute paradigm shiftThe disaggregated server model changed the landscapeMainframe/Proprietary model X86 servers model Today64Proprietary architectures mgmt toolsLimited appsProprietary OS(e.g., Solaris, HP-UX, Ultrix)Proprietary CPUs(e.g., SPARC, PA-RISC, Alpha)Orchestration/automation fordistributed computingApplication ecosystemStandard OShypervisorsIndustry standard (X86 CPU)DellHPOthersVMware | Windows Server System | RedHat Linux| SuseIntel | AMD 65. Now: Networking paradigm shift65Traditional networking Future of networkingProprietary architectures mgmt toolsHundreds of protocolsProprietary networkingOSProprietary ASICsStandard orchestrationautomation toolsOptional 3rd party SDN/NVO controllerAny networking OSOpen standard hardwareMerchant silicon 66. New S-Series open networking models66Dell S4810-ONDell S6000-ONDells first disaggregated opennetworking switches Designed for flexibility, performance andsupport of 3rd party OS 1RU high-density 10/40Gbps TORswitches S4810-ON with 48 ports 10GbE and 4 ports40GbE S6000-ON with 32 ports of 40GbE or 96ports of 10GbE + 8 ports of 40GbE Supports the open source Open NetworkInstall Environment (ONIE) Dell global ProSupport Services 67. Imagine - Androidification of networking67Standard orchestrationand automation toolsOptional 3rd party SDN /NVO controllerAny networking OSOpen standard hardwareMerchant silicon+Open Source Apps+IndependentSoftware VendorAppsStandard orchestrationand automation toolsOptional 3rd party SDN /NVO controllerOpen network platform OSOpen standard hardwareMerchant siliconVirtualservicesPower andtrafficoptimizationappPerformancemonitoringopt appSecurityappOur focus is on Apps 68. Best of breed Network Operating Systems68Dell Networking Operating Systems Feature rich, mission critical, line rate performanceCumulus Linux Linux expertise and Linux standardized environments that valuecommon Linux tools for server and network managementBig Switch Networks Switch Light OS Network tapping and monitoring for customers interested in adoptingSDN 69. Open Networking Ecosystem with Cumulus Linux69Routing NetworkNSXAutomation Orchestration NetworkVirtualization Monitoring Storage Security OthersCumulus LinuxIndustry Standard Hardware 70. Configuration Management70 Converged administration Same automation tools for managing servers now available for the networkLayer 3 FabricServersSwitches 71. This is exactly what dell + big switch bring to marketBig Switch SDNsoftware...SDN Controller single, centralized,command controlSits in customer Virtual Machine(VM) environment / appliance71S4810-ONDell open network switchhardwareSame high-density, high-quality Dell hardwareused in production ENT, SP and PS hyper-scaledatacenters1G, 10G, 40G ports for maximum flexibilityBIG TAPCONTROLLERSWITCH LIGHT OSONIE BOOT LOADERdelivermonitoring fabricsScalable, multi-tenantnetwork monitoringsolutionOpen-networking enables rapid innovation and customer choice through hardware and software disaggregation 72. 72Thank you