Data Center Network Trends - Lin Nease

What’s driving data center transformation? Business pressures • New Apps & Services – growth • Integrate acquisitions • Support business innovation • Compliance • Reduce costs and risks Customer • Mission critical priorities and Data center constraints expected • Communications cost structure • Power and cooling outcomes • Facilities • Personnel • Relocations • Legacy infrastructure • Workflow HP ProCurve Data Center Solutions 2008 HP ProCurve Confidential 2

Tools to address data center challenges Legacy Data Center Next Generation Data Center Heterogeneous environment Pods – Ruthless Standards Application-specific clusters Shared, flexible resources Manual element configuration Fast, reliable deployments Standardization Virtualization Automation Reduced maintenance costs, better asset utilization, lower power consumption, and higher system uptime – resulting in better business outcomes 3

Types of DC Networks “Back Office”: • typical 3-tier business applications • diverse application requirements • these customers buy tools from vendors High-performance clustering • east-west performance with line rate • in some cases, reliable multicast is very important • Infiniband is prevalent today Each Imposes Different Priorities And Demands “Front Office”: • big on-line web presence • lots of server load balancing & application acceleration “Cloud”: • huge web-based service infrastructure • think Google, MSN • totally self-sufficient, cost-driven customers

10Gb growth at the edge brings new topology approaches • 10G low-cost connectivity will evolve repeatedly for the next 3 years • 10GbaseT not practical yet – power & latency excessive, non-standard cables • Home-runs directly to core switches carry huge optics cost with 10G • Fiber & transceiver costs • core switches – higher $ per port – many more ports • choice between lack of flexibility or low capacity utilization • Using TOR/Pod-based switches greatly reduces 10G costs • CX-4 today, SFP+ direct connect next year – 7M practical, 10M theoretical passive limit • Oversubscribe in the pod – reduce costs of more complex infrastructure = cheap copper cabling = expensive fiber cabling 10G Pod-based approach 10G Home run approach (up to $4k more per server!) Lower cost Ports, Expensive Flexible Ports, fixed growth capacity Cheap Copper in Expensive pods fiber

Pod-based design – split the network into separate lifecycles • Network access & aggregation components on same lifecycle as servers • De-couple IT processes • More network bandwidth and energy contained lower in the network • “Crop rotation” used to replace old with new technologies over time • power/cooling contained in pods, allowing adoption of future efficiencies “Pod 6” “Pod 7” “Pod 8” “Pod 9”

Coupled with Facilities Design: Configure Once, Allocate on Demand – Division of Labor - De-couple IT processes (PS – we still need silos ;-) - Minimize change - Standardize & automate to the maximum possible extent The “DNA” approach: POD Types: -Standard VLANs, Addressing, ACLs at every port -Server admins assign and manage server context 1. Server -Assigned context “activates” network personality 1. Normal Power 2. High Power Network substrate configured the same regardless of future 2. Storage (3B) pod usage. 1. SAN 2. Tape/Backup/Archive 3. Network Services 4. Utility (Floor Mount Computing) 5. Legacy 6. Vacant 7. Development/Test

Very-Large Layer 2 domains VLL2 network Value propositions: • Allow very flexible mapping of virtual LANs • Allow dynamic plumbing of applications • Multipathing at L2 • Scalability versus spanning tree • Simpler configuration and troubleshooting than spanning tree Potential futures: • Trill • Shortest-Path Bridging • Extended Meshing approaches

Fibre Channel / Ethernet Convergence? FC / Ethernet converged network FCoE Value Propositions: -Replace current NICs and HBAs in servers with fewer consolidated, specialized NICs (logic goes that 10G has plenty of headroom for consolidation – at least for now) -Homogenize server I/O to enable more standard server configurations -Allow for greater flexibility to “match make” any LUN to any server -Solve interoperability problems with Fibre Channel via the Ethernet ecosystem Problems: 1) T11 standards are not finalized, issues remain 2) A “new Ethernet” will be required for storage; convergence will not be as easy as VOIP 3) Network complexity will increase significantly 4) No new entrants are likely to emerge for FC director products 5) Interoperability problems will probably get worse, not better

Possible Convergence Stages – Today = tcp/ip links = FC native links SLB IP Data Center Data Network Distribution Firewall E-net switches server farm FC switches FC SAN LUN farm

Step 1? – Standardize NIC types (still dedicated SANs, but using Ethernet) = tcp/ip links = FC native links SLB = FCoE SAN links IP Data Center Data Network Distribution Firewall Value Proposition 1) Homogenize Server I/O 2) Homogenize Switch Types E-net switches server farm FCoE switches (This is likely how FCoE will FC end up, as this is exactly how iSCSI is deployed today) SAN LUN farm

Step 2? – homogenize server I/O – Universal NICs with TOR splitting = tcp/ip links SLB = FCoE SAN links IP = FC native links = Converged Server NICs Data Network Firewall Value Prop (beyond step 1) 1) Consolidate Server I/O 2) Reduce number of NICs/HBAs converged 3) Aggregate server cabling Ethernet 4) Homogenize Server Types switches N_ports Issues: server farm • complex switch management • standards not complete • all NICs must be 10Gb for benefit • it’s still Fibre Channel! F_ports FC • ‘010 or later for volume • 10Gb won’t be overkill by then SAN (once you need 4 NICs per server, why do it this way?) LUN farm

Step 3? – Ethernet enhances SAN flexibility – Managed Virtual HBAs “on-a-rope” = tcp/ip links SLB = FCoE SAN links IP = FC native links = Converged Server NICs Data Network Firewall Value Prop (beyond step 2) • Virtualize any server to any LUN converged • …while preserving FC SANs Ethernet switches Ethernet/FC N_ports N_ports switches FC N_ports FC N_ports SAN SAN LUN farm

Step 4? – Fully Converged Network? 2015? FC  Ethernet, or Ethernet  FC? = tcp/ip links = FCoE SAN links = FC native links SLB = Converged Server NICs Converged Issues: Network Firewall • It’s still Fibre Channel • Fibre Channel is not growing • Different security model VF_ports • Different flow model • Different mgmt model • Higher cost structure • Same 2 director vendors • More interoperability problems • Complexity of merged networks VN_ports VE_ports E_ports Legacy FC E_ports SAN LUN farm

Meanwhile – iSCSI is real and growing fast today • iSCSI growing 30-40% YOY, FC is flat • HP just acquired Left-Hand Networks • turns a general-purpose server or virtual machine into an iSCSI storage system • offers compelling feature set in very low-cost solution • Very recent growth is driven by VMware • Use case is “vanilla storage for vmotion-able servers” • Ethernet switch requirements • good buffering • flow control capability • jumbo frames • (emerging) 10G density • Typically customers separate iSCSI switches from data TCP/IP

Virtualization – where is the network going? Data Campus Center VM soft switches: “Access Points?” Virtual Virtual Servers Servers • Both ends of the network are starting to look alike! • virtual switches are much like access points • Port-centric edge management model is challenged • constraining • labor-intensive • static • costly infrastructure

Virtualization & Agility – HP Strategy -Make forwarding decisions in the network Server -Use simple mechanisms to make sure all traffic can be classified farms -Leverage the “Lite AP” architectural framework -Allow real switches to do ACLs, lookups, QOS, classification -Don’t force NICs to be bridges -Allows the NICs to focus on the host/IO membrane Virtual -Use standards-based mechanisms to track VM’s connections Machines -Use MAC addresses and 802.1X tokens -Out-of-band service, authentication, tracking, and automation approaches -Actively drive new standards that help solve the problem -ProCurve vice chairs, participates in multiple standards bodies

DC Network Switch Thermal Design: Side-to-side cooling  Front-to-back cooling Side-to-side Cooled Switches Front-to-Back Cooled Switches Extra heat is leakage No extra heat is built that must be moved up inside the rack Side-cooled switch draws re-circulated hot F2B cooled switch air from inside rack exhausts air directly Into hot aisle Hot air exhausted Hot Aisle inside rack Hot Aisle F2B cooled switch draws air directly from the cool aisle Side-cooled switch draws rising warm air from inside rack Cool Aisle Cool Aisle

Common Network Automation use cases today Catalog & Deploying Maintaining Process-powered Diagramming Large Scale Changes Compliance Network Automation Auto-discover the Automate changes Enforce, audit and Integrated process network and across thousands report on automation to capture detailed of devices compliance automate network audit trail of all operations device changes  Snapshot and store  Mass configuration  Out of the box  Automate multi-step device configuration changes reports on ITIL, PCI, processes across information HIPAA & more disparate systems  Software updates  Real-time change  Enforce best  Automate validation of detection for all  Bare-metal practices and complex network activities provisioning security standards changes  Keystroke level audit  ACL deployments  Easily remediate  Ensure best practices trail violations are followed

Network complexity in data centers is exploding… • many functional types of networks Where does the “server” end • virtual servers and the “network” begin? • application acceleration • multiple firewall/NAT layers • HA / load balancing • multi-tier applications • explosion of VLANs • workload mobility • compliance • change management • high availability VMs Data Center Network …which intertwines too deeply with server provisioning…

Also, Physical Issues Exist with Virtual Networking: 1) Unlike discrete items like CPU cycles or LUNs, the network is a single shared resource. 2) The network cannot be fully virtualized, due to laws of physics and the fact that it’s shared. (i.e. bandwidth & connectivity cannot be created out of thin air, and a network that offers infinite configurable bandwidth between all endpoints is not cost-effective) Intelligent Switches Intelligent Intelligent Switches Switches Data Center Network

However… - we can “carve up” the network into pre-allocated virtual connections, and allocate them as if they were discrete items like servers and LUNs. - by choosing how many virtual connections to offer where, we can virtualize the network while still obeying laws of physics; Intelligent Switches Pre-allocated virtual chunks Intelligent Intelligent Switches Switches Data Center Network

What if the network was presented as an inventory of virtual connections – that abstract the network complexities? Demarcation between “Network” and “Server” Intelligent Switches Inventories of Virtual connections Intelligent Intelligent Switches Switches Data Center Network

…and the network access was securely automated & configured one server at a time, as a service? Blade Blade Servers Servers Intelligent Switches Intelligent Intelligent Switches Switches Server Pod Data Center Network VMs

Policy-Based Provisioning, Automation & Accounting for Virtual Data Centers Virtual Network Edge Connection Configuration Server Configuration -VLAN -ACL -QoS -Rate-limit -IP Address / Subnet -Gateway -DNS Servers Network Core Configuration -Load-balancer -Firewall -Router

Datacenter Connection Management Network Server Admin Admin 4) Configure Server 1) Set up policies according to subscription policies Place new connections in the inventory 2) Select an available 3) Subscribe to new server or VM connection the connection UCMDB federate 5) Register Server @ L2 Connection Inventory 6) Enforce L3 Compliance info registration Checking info Policy enforcement Fault info responses Network Management Subscription, Infrastructure (dynamically deployed for Registration or Capacity each connection) IP allocation Management event Policies for Router, Firewall, Load Balancer, DLP, IDS, etc 7) Automate other Network Policies via events 26 12/11/2008

Example: 3-tier data center network is represented as… Organization “a” Organization “b” Internet VLANs Web/App VLANs App/DB VLANs Serial SCSI VLAN (iSCSI or FCoE)

Example: 3-tier data center network is represented as pools of connections Organization “a” Organization “b” Internet VLAN 1 Internet VLAN 2 Internet VLAN 3 Zone 1 Internet VLAN 4 Web/App VLAN 1 Web/App VLAN 2 Web/App VLAN 3 Web/App VLAN 4 App/DB VLANs Deployed Servers Future Servers Deployed Servers Future Servers -org_a.webserver1 -org_a.webserver6 -org_b.webserver1 -org_b.webserver7 -org_a.webserver2 -org_a.webserver7 -org_b.webserver2 -org_b.webserver8 -org_a.webserver3 -org_a.webserver8 -org_b.webserver3 -org_a.webserver4 -org_b.webserver4 -org_a.webserver5 (iSCSI or FCoE) Serial SCSI VLAN -org_b.webserver5 -org_b.webserver6

Pools of connections - example inventory status Organization “a” Organization “b” Internet VLAN 1 Internet VLAN 2 Internet VLAN 3 (dmz) Zone 1 Internet VLAN 4 Web/App VLAN 1 (app) Web/App VLAN 2 Pod 1 Connection Status Server ID VLAN IP MAC Policy Forms org_a.webserver.dmz.1 In Use org_a.webserver1 Internet VLAN 3 org_a.webserver.app.1 In Use org_a.webserver1 Web/App VLAN 1 org_a.webserver.dmz.2 In Use org_a.webserver2 Internet VLAN 3 org_a.webserver.app.2 In Use org_a.webserver2 Web/App VLAN 1 org_a.webserver.dmz.3 In Use org_a.webserver3 Internet VLAN 3 org_a.webserver.app.3 In Use org_a.webserver3 Web/App VLAN 1 . org_a.webserver.dmz.4 In Use org_a.webserver4 Internet VLAN 3 . org_a.webserver.app.4 In Use org_a.webserver4 Web/App VLAN 1 org_a.webserver.dmz.5 In Use org_a.webserver5 Internet VLAN 3 org_a.webserver.app.5 In Use org_a.webserver5 Web/App VLAN 1 org_a.webserver.dmz.6 AVAILABLE org_a.webserver.app.6 AVAILABLE org_a.webserver.dmz.7 AVAILABLE org_a.webserver.app.7 AVAILABLE org_a.webserver.dmz.8 AVAILABLE org_a.webserver.app.8 AVAILABLE org_b.webserver.dmz.1 In Use org_b.webserver1 Internet VLAN 4 org_b.webserver.app.1 In Use org_b.webserver1 Web/App VLAN 2 . . . . . .

Long-term Vision – Virtualize SANs also • Physical servers are exposed to resources only upon subscription • Inventories are adjusted per capacity management • Physical servers are not confined to any particular SANs • SANs can be smaller, more specialized, more manageable, with faster & simpler recovery Server Farm g r i n ve nd er b i /s N LU Ethernet Test/dev Production VMware Virtual Oracle DB Exchange LUNs for J2EE/SAP LUNs “C: drives” VMFS LUNs Tape devices LUNs LUNs NAS heads LUNs iSCSI FC SAN SAN iSCSI FC LUN LUN farm farm

Evolution to Virtualization Design-to-Order Configure-to-Order Infrastructure Infrastructure Application Silos Application Stacks Configured one App at a Time Virtual Virtual Virtual Virtual Resource Resource Resource Resource Dedicated Infrastructure – Designed, Procured, & Built Separately for each Application Shared Infrastructure

Evolution to Infrastructure Clouds Configure-to-Order Allocate-to-Order Infrastructure Infrastructure Application Stacks Application Stacks Configured one App at a Time Virtual Virtual Virtual Virtual Resource Resource Resource Resource Pools of Pre-Configured Shared Infrastructure Standard Resources

Each Silo provides a portfolio of well-known “products” that are standard in that IT shop: Infrastructure Standards Menu Storage Menu: Server Menu: - “small VMFS LUN” - “small web server” - “High-perf DB LUN” - “medium web server” - “J2EE LUN” - “standard exchange server” - “small Windows C: clone” - “small J2EE server” - “small NAS LUN” - “large ESX server” Network Menu: - “test/dev LUN” - “NFS cluster node” - “DMZ connection” - “Exchange LUN” - “standard .Net app server” - “App-to-DB” connection” - “SAP financials container” - “Backup network connection” - “large database node” - “Mgmt network connection” - “Vmotion network connection”

Infrastructure Standards are Layered Small .web Server VM container Type 2 Large ESX Server VMFS LUN BL585 Server Blade w/Flex10 NIC Vmotion iSCSI Archive DMZ AppServer Network Network Network Network Network connection Connection Connection Connection Connection Pods of blade chassis, servers, storage, and networking

HP Vision – Adaptive Infrastructure Clouds Applications Demand Server Inventory Small Web J2EE J2EE Server 1 Server 2 Server 1 Inventory Supply Managed by Server Team Virtual Connect provides a Firewall between change domains Virtual Connect Domain Network Connection Inventory Inventory Inventory LUN Inventory Managed by Managed by Storage Team, Network Team

Infrastructure Service Lifecycle Applications Forecast Demand Provision or Server Change Servers – 1. Inventory “Subscribe” Small Web J2EE J2EE Server 1 Server 2 Server 1 3. 4. 2. Virtual Connect Allocate & Domain Activate Thin-Provision Subscriptions Subscriptions – On-Demand Pre-approve “Standard” Network Connection Changes Inventory LUN Inventory

Domains are Separated & Simplified Applications Server Inventory Small Web J2EE J2EE Server 1 Server 2 Server 1 Server Change & Configuration Firewall Domain between Virtual Connect Domains Domain Network Storage Change & Network Connection Change & Configuration Inventory Configuration LUN Inventory Domain Domain

Lifecycle of an Application Requirements Optimize Design Operate Build Deploy

Lifecycle of Applications Using Infrastructure Clouds (Standard Menus) Requirements Browse Menu vs. Requirements Optimize Remediate Design As Select best Necessary Fit standard elements Infrastructure Connection Standards Inventory Menu Subscribe to Monitor & infrastructure Maintain Operate from Build Configure specifics inventory on top of standard infrastructure Deploy

Data Center Network Trends - Lin Nease

0 comments

Notes on slide 1

5 Favorites