Deploying Applications in Today s Network Infrastructure

Transcription

1

2 Deploying Applications in Today s Network Infrastructure 2

3 Abstract Why did I create this Presentation? What Network engineers need to know before deploying applications Wikipedia defines virtualization as "a broad term that refers to the abstraction of computer resources". Another definition, is "a technique for hiding the physical characteristics of computing resources from the way in which other systems, applications, or end users interact with those resources" Virtualization Management (vcenter) Networking requirements, vswitch, Disturbed Virtual Switch or N1Kv (VSM) What applications are running on these virtual machines? What resources do the applications require? Host Operating System (Hypervisor) ESX Host, vhba, vnic (VEM) Hardware (BIOS,CPU,RAM,DISK,Storage) UCSM Service Profile 3

4 How do Servers Communicate? Converged Network Adapters converge the functionality of network and storage adapters Servers have at least two adapters FC HBA (Fiber Channel Host Bus Adapter) & Ethernet NIC (Network Interface Card) to connect to the storage network (Fiber Channel) and computer network (Ethernet) Rack Server Ethernet Switch Port Computer Network Rack Server New Setup with CNA + FCOE Computer Network Ethernet Fiber Channel Ethernet + FCOE (Fiber Channel Over Ethernet) NIC FC HBA Fiber Channel Switch Port Fiber Channel (FC) Storage Area Network CNA Fiber Channel (FC) Storage Area Network (Converged Network Adapter CNA) carries both Ethernet as well as FCOE traffic in a single cable. This cable connects to one of the Ethernet ports in the converged switch that has both Ethernet and Fiber Channel ports 4

5 Future Proofing for Virtualization Building an environment which can scale Cisco UCS adds support for flexible VLAN configurations on Fabric Interconnect (FI s) uplink ports while using End Host Mode. This feature provides support to all combinations of upstream network configurations: Supporting End Host Mode and Switch Mode End Host Mode when behave is similar to the hardware implementations of VMware vswitches no spanning tree, no loops, and does not look like it is switched to the external network Switch Mode, means the FIs can act like a normal switch (use spanning tree, etc.) I most always recommend using End Host Mode (default mode) 5

6 Inter-Fabric Traffic using Cisco UCS UCS Release 2.0(2m) adds support for Nexus 2232 fabric extender In order for Cisco UCS to provide the benefits, interoperability and management simplicity it does, the networking infrastructure is handled in a unique fashion: In the diagram, both UCS rack-mount and blade servers are connected to a pair of FI s which handle the switching and management The rack-mount servers connect to Nexus 2232s which provides a localized connectivity point 10GE FCoE without expanding management Not shown in this diagram are the I/O Modules (IOM) in the back of the UCS chassis. These extend to the Fabric Interconnects without adding management or switches 6

7 Cisco UCS Logical Connectivity UCS is a Layer 2 system so any routing (L3 decisions) must occur upstream UCS hardware is designed for low latency environments, such as high performance computing, and perfect for today s applications: All switching occurs at the FI s level so all frame forwarding decisions are made on the Fabric Interconnect and no intra-chassis switching occurs The only connectivity between FI s is the cluster links. Both FI s are active from a switching perspective but management UCS Manager (UCSM) is an Active/Standby clustered application. This clustering occurs across L1 and L2 links. These links do not carry data traffic which means there is no inter-fabric communication within the UCS system and A to B traffic must be handled upstream 7

8 Bare-Metal Operating System Bare-metal Opperating Systems (Windows, Linux, etc.) Two blades which have been configured in an active/passive NIC teaming configuration uses separate fabrics (within UCS this is done within the service profile.) This means that blade 1 is using Fabric A as a primary path with B available for failover : When a CNA adapter that supports hardware failover, provide one vnic (made redundant through HW failover) and place its primary path on the fabric When a CNA adapter does not support HW failover, use active/passive NIC teaming and ensure that the active side is set to the same fabric for servers 8

9 VMware Servers When using VMware ESXi Hypervisor Connectivity is the same from a physical perspective, but using VMware as the operating system. A vswitch, vds, or Cisco Nexus 1000v will be used to connect the VMs within the Hypervisor: For half-width blades requiring 10GE or less total throughput, or full-width blades requiring 20GE or less total throughput, provide a single vnic with hardware failover if available, or use an active/passive NIC configuration for the VMware switching For blades requiring the total active/active throughput of available NICs, determine application profiles and utilize port-groups (port-profiles with Nexus 1000v) to ensure active paths are the same for application groups which communicate heavily 9

10 Server Networking with Cisco UCS Hardware The 6248 is a 1RU model that provides 48 universal ports (1G/10G Ethernet or 1/2/4/8G FC.) Additionally the 6248 is lower latency at 2.0us from 3.2us The 2208 doubles the total uplink bandwidth per I/O module providing a total of 160Gbps total throughput per 8 blade chassis The 1280 VIC provides 8x10GE ports total. It also double the VIF numbers of the previous VIC allowing for 256 (theoretical) vnics or vhbas. The new VIC also supports port-channeling to the UCS 2208 IOM and iscsi boot 10

11 Cisco UCS Server Failover Discrete Mode Failover 2/4/8 Ports In discrete mode a static pinning mechanism is used, mapping each blade to a given port dependent on the number of uplinks used Each blade will have an assigned uplink on each IOM for inbound and outbound traffic In discrete mode if a link failure occurs the blade will not re-pin on the side of the failure but instead rely on NIC- Teaming/bonding or Fabric Failover for failover to the redundant IOM Fabric 11

12 Cisco UCS Server Failover Port-Channel Mode In Port-Channel mode all available links are bonded and a port-channel hashing algorithm (TCP/UDP + Port VLAN, non-configurable) is used for loadbalancing server traffic If a port fails the IOM port-channel load-balancing algorithms handle failing the server traffic flow to another available port in the channel This failover will typically be faster than NICteaming/bonding failover. This will decrease the potential throughput for all flows on the side with a failure, but will only effect performance if the links are saturated 12

13 Cisco UCS Fabric Failover When deploying applications in the network, multipath configuration is critical Fabric Failover is a unique capability found only in Cisco UCS that allows a server to have a highly available connection to two redundant network switches without any NIC teaming drivers or any NIC failover configuration required in the OS, hypervisor, or virtual machine Fabric Failover provides the server adapter with a virtual cable that can be quickly and automatically moved from one upstream switch to another When a virtual cable moves from one physical switch to another, the virtual cable is moved to an identically configured virtual Ethernet port with the exact same numerical interface identifier and adapters network MAC address 13

14 Fabric Failover with Installed Operating Systems In Cisco UCS, the adapters network MAC address is implicitly known (meaning, it does not need to be learned) because the adapter MAC address and network port it connects to were both provisioned by UCS Manager When Fabric Failover is enabled, the implicit MAC address of the adapter is synchronized with the second fabric switch in preparation for a failure If Windows or Linux operating systems are installed on servers with Fabric Failover enabled, the OS has a redundant connection to the network 14

15 Fabric Failover with Installed Hypervisor When to use Fabric Failover VMware with a hypervisor Servers running a hypervisor may be hosting many virtual machines (VM) behind a software switch such as vswitch/ vds/ N1K The hypervisor is not aware of the Fabric Failover: it is transparent If you use VMware s virtual switch, NIC load sharing mechanisms such as IP Hash or Load Based Teaming. Best practices are to have multiple adapters provisioned to the Port Group or Port Profile which provides redundancy In a nutshell, Fabric Failover with a hypervisor switch is certainly an intriguing design choice, but it may not be a slam dunk in every situation 15

16 Fabric Failover with Hypervisor Pass through Use Pass Through when deploying high performance based applications When Cisco UCS is configured for HW VN-link it presents itself to VMware vcenter as a distributed virtual switch (DVS) much like the Nexus 1000V. VN- Link literally indicates the creation of a logical link between a vnic on a virtual machine and a Cisco UCS fabric interconnect Pass through configuration requires fewer CPU cycles than a software switch, yet the hypervisor still has visibility to network I/O and therefore vmotion works as expected Traffic Paths for VM traffic with VN-Link in Hardware 16

17 Cisco UCS vnic Failover without Fabric Failover When you create a vnic with UCS you have many options: With VMware ESXi we always create two vnics, one on Fabric A and one on Fabric B and then let vcenter handle the NIC teaming and failover With the Palo CNA adapter you we create 4 vnics (vmnic0-vmnic4), assign two for SC/vMotion in a standard vswitch and two for VM networking in a DVS or N1K 17

18 VMware ESXi 5.0 Deployment Example How to deploy multiple virtual machines on VMware Hypervisor UCS configured with five virtual NICs (vmnics) and two virtual HBAs Fabric Failover vnic 1 Eth 1/1 L A L2 L B MAC A veth 1,2.4 vnic 2 Eth 1/2 vnic 3 Eth 1/3 L1 MAC B veth 1,3.5 vnic 4 Eth 1/4 vnic 5 Eth 1/5 ESX Service Console vnics used for VMware ESX5.x auto deploy Enable fabric failover with separate mac pool based on the UCS domain size Use two separate vnics for production data traffic. You could also use separate mac pools. Enable CDP on all vnics vmnic0 vmnic1 vmnic2 vmnic3 vmnic4 Service Console PXE Autodeploy Native Vlan Production Traffic Fabric A Production Traffic Fabric B vmotion Fabric A vmotion Fabric B VMware ESXi Host 18

19 Microsoft Hyper-V on Windows Server 2008 R2 Great example for deploying multiple virtual machines on Microsoft Hypervisor Preparing the Environment 1 If the bare-metal installations of Windows Server 2008 R2 will be configured to boot from SAN, these guidelines must be followed Note: Guidance and recommendations for specific application designs are available from Cisco. 3 2 UCS firmware version 1.4 or later is required to support fabric failover of Microsoft Hyper-V virtual machine traffic. For a fabric failover to occur without interruption of traffic in a Hyper-V environment, both the implicit MAC addresses of the virtual NICs (vnics) on the blade and the learned MAC addresses of the virtual NICs of the guest machines need to be known by both fabric interconnects (FI). The replication of both the implicit and learned MAC addresses between the FIs is fully supported beginning with UCS firmware 1.4 Create two virtual HBAs (vhbas) with distinct connectivity to the SAN via the A and B fabric interconnects. For full redundancy in case of failure, each path from the fabric interconnects should connect via separate fiber channel switches to two redundant SAN controllers 19

20 Microsoft Hyper-V on Windows Server 2008 R2 4 However, a minimum recommendation of two vnics is given to separate the management traffic of the host from Hyper-V guest traffic. If failover clustering is also to be implemented to gain access to Hyper-V live migration features, then a third vnic to isolate cluster heartbeat traffic is also recommended. Ensure the vnics are all enabled for Fabric Failover vnic eth0 is being configured as a dedicated management interface on the VLAN named default, with a VLAN ID of 1. vnic eth1 is being configured for dedicated virtual guest traffic on two VLANs named finance and human-resource 5 Configure the boot order policy to include Boot From CD-ROM as an option to install the baremetal operating system From the KVM Console Launch Virtual Media to map ISO and drivers 6 The following items must be enabled via the BIOS policy for Hyper-V to function: Virtualization Technology (VT) Execute Disabled Bit Recommends enabling Hyper Threading via the BIOS policy unless the anticipated load will be too high on CPU utilization causing a danger of oversubscription of CPU resources 7 Prior to installation of Windows Server 2008 R2, gather the following software and driver components: ISO image of Windows Server 2008 R2 ISO image of B-Series UCS drivers Drivers can be obtained from the following with valid login credentials to download the software: 7 Hyper-V host configured as follows: UCS Service Profile configured with 3 vnics. vnic0, the dedicated management NIC vnic1, the dedicated guest networking vnic2, an optional dedicated NIC for iscsi The external vswitch in Hyper-V configured as a dedicated vswitch. The vswitch is bound to the physical adapter The virtual network adapter on VM1 is vlan3 The virtual network adapters on VM2 is vlan 3,5 The virtual network adapter on VM3 is vlan 5 20

21 World Wide Names (WWPN/WWNN) Cisco UCS allows the users to create custom values for World Wide Names Used to logically identify resources on a fiber channel storage Similar to MAC addresses for Ethernet 2 types: World Wide Node Name (WWNN) Identifies node World Wide Port Name (WWPN) Identifies a port on a node Visible in name server and FLOGI tables Used for fabric zoning, array LUN masking 8 bytes, representing: Format 1,2, or 5 with the first 2 bytes (ex. 20:00) AB : CD Vendor unique OUI with bytes 3 through 5 (ex. 00:25:B5) Assigned serial number with bytes 6 through 8 (ex. 00:01:02) Type Vendor ID OUI Extension ID : EF : GH : IJ : KL : MN : OP (KL:MN:OP) These last 24-bits are the vendor specific extension identifier, no restrictions

22 Suggested WWNN/WWPN Octet Values WWN: AB:CD:EF:GH:IJ:KL:MN:OP AB = 20 A must be 2 CD = Some IEEE Security requirements EF:GH:IJ = 00:25:B5 Cisco OUI KL = Data Center M = Pod Numbering N:OP = Sequential numbering UCS Pod 2 20:00:00:25:b5:10:20:00 WWPN: AB:CD:EF:GH:IJ:KL:MN:OP AB = 20 A must be 2 CD = Some IEEE Security requirements EF:GH:IJ = 00:25:B5 Cisco OUI KL = Data Center M = Pod Numbering N = Fabric OP = Sequential numbering UCS Pod 2 20:00:00:25:b5:10:2A:00 22

23 Suggested MAC Format for UCSM Cisco UCS allows the users to create custom values for MAC address MAC: 00:25:B5:GH:IJ:KL 00:25:B5 = Fixed, can t change as of 1.0.2d GH = Data Center I = Pod JKL= Sequential numbering Creating a MAC Pool for UCSM UCS Pod 2 00:25:b5:10:20:00-00:25:b5:10:2f:ff Separate MAC pool for auto deploy and PXE. One MAC address per host 23

24 DEMO using Cisco UCS Emulator MAC Pools, Creating vnic, Enabling Fabric Failover

25 Boot Process Booting is an involved, hacky, multi-stage affair fun stuff Outline of the typical boot process: Pre-Boot execution Environment (PXE) BIOS Initialization NIC Boot ROM DHCP Request Bootloader (from TFTP server) Boot Menu Kernel And FS DHCP configuration file: Once the motherboard is powered up it initializes its own firmware chipset CPU will begin the bootstrap processor (BSP) that runs all of the BIOS and kernel initialization code If something fails you might hear beeps Pre-Execution "pixie" is an environment to boot computers using a network interface independently of data storage devices (like hard disks) or installed operating systems 25

26 Unattended OS Installation and Boot Process Booting is simplified using UCS over the Network or San UCS solves the booting complexity Server Name UUID Server Name Server MAC UUID Name UUID, WWN MAC MAC,WWN Boot Boot WWN info info firmware LAN Boot Config info LAN, SAN Config Config SAN Config Firmware SAN Config 1 Create Boot Policy DHCP Server TFTP Server File Server (name vnic s vmnic0 Name must match with vnic templates) Complete control of system boot policy separate from the BIOS settings PXE, FC SAN boot today iscsi Virtual media (CDROM,.iso, USB, floppy) Complete control of how to return a server to the infrastructure when no longer required Called Scrub Policy Optionally clear BIOS settings Optionally wipe local disk boot sector and table Allows for removing the low-level configuration state on server Easier automation possible 26

27 Cisco Server Provisioner Automated System Provisioning, Recovery, and Cloning Cisco Server Provisioner automatically installs operating environments for physical virtual servers and blades, a process known as bare metal provisioning Simple product installation Easy to use & well-documented (w/ graphical tutorials) 6 different ways to provision, but a single 3-step process for all 6: 1. Prepare the ISO (Windows, Linux, ESX) media using scripts 2. Use TSP Web UI to create: Provisioning Role Templates (MAC-Spec Provisioning) MAC-Independent Provisioning menus 3. Use TEO (or TSP Web UI) to assign templates and values to systems based on requirements Tidal Enterprise Orchestrator Browser Cisco Server Provisioner PXE,TFTP,HTTP,NFS UCS Blades, Servers, VMs 27

28 Cisco Server Provisioner MAC-Independent ("Pull ) Provisioning Use Cisco Server Provisioner Web UI to Build Client-Side Screen MAC-Specific ( Push ) Provisioning: Use Cisco Server Provisioner Web UI to Build Client-Side Screen MAC address-specific push provisioning can be used in situations where users rarely touch the computer systems and rely on a provisioning dashboard to remotely provision servers and blades 28

29 Preparing Server for Applications Boot from San Tasks You don t need to be a storage guru!! UCS Manager Tasks Create a Service Profile Template with x number of vhbas Create a Boot Policy that includes SAN Boot as the first device and link it to the Template Create x number of Service Profiles from the Template Use Server Pools, or associate servers to the profiles Let all servers attempt to boot and sit at the Non-System Disk style message that UCS servers return Switch Tasks Zone the server WWPN to a zone that includes the storage array controller s WWPN Zone the second fabric switch as well. Note: For some operating systems (Windows for sure), you need to zone just a single path during OS installation so consider this step optional Array Tasks On the array, create a LUN and allow the server WWPNs to have access to the LUN Present the LUN to the host using a desired LUN number (typically zero, but this step is optional and not available on all array models) 29

30 Boot from SAN Steps required to configure boot from SAN 1 Create a boot policy - Provide name 2 Enforce vnic/vhba/iscsi and description name - select checkbox 5 SAN Boot Target - to the Primary vhba 4 Add SAN boot - Add only SAN Boot to the policy (name vhba s fc0 and fc1 or vhba-a or vhba-b. Name must match with vhba templates) 3 Add SAN boot - Add only SAN Boot to the policy 6 SAN Boot Target WWPN - Add valid WWPN as the Boot Target. Always use boot LUN id of 0 7 Add Secondary SAN Boot and Target - Follow the same process as primary 8 Add Secondary SAN Boot and Target - Follow the same process as primary Note If you are installing a new OS on the boot LUN you might need to add a CDROM drive to the Boot Policy 30

31 1 Booting from SAN Troubleshooting Booting from SAN is not necessarily the easiest configuration UCS removes the complexity of booting from SAN by using service profiles, templates and associated boot policies First connect to the VIC firmware: For example, when logging into an array which has a WWPN of 20:00:00:1F:93:00:12:9E and it s Service Profile is associated to blade 1/1 in chassis 1 slot 1 3 Successfully logged into the fabric as we ve got a successful PLOGI and report luns available 2 Now list the vnic ID s and force the VIC to log into the SAN fabric: 31

32 Preparing Server for Applications VMware vsphere 5 Auto Deploy and Cisco UCS A new stateless functionality that ships with vsphere 5 Stateless PXE boot of bare-metal hosts Assign a specific configuration to PXE-booted hosts PXE-booted hosts receive a configuration at boot time OS is not installed on disk, it runs from RAM Configuration applied through Host Profiles Connect to vcenter Auto Deploy works in tandem with a vcenter Server, a DHCP and a TFTP server DHCP and TFTP server not part of Auto Deploy. They have to be configured to point to Auto Deploy (explained in this slide deck) Auto Deploy can be installed on a Windows VM, on vcenter Server directly. It also ships with the vcenter Server appliance Auto Deploy is registered during installation with a vcenter Server instance 32

33 VMware Auto Deploy & UCS Stateless Complementary Technologies Together Auto Deploy Benefits Decouple Hypervisors from a physical machine Eliminate the need for ESXi installation or ESXi embedded technologies Network boot hypervisor OS Auto Deploy Caveats Decoupling does not account for necessary physical infrastructure requirements between physical hosts Network booting requires the correct networking infrastructure to be in place first Physical infrastructure management is still a very manual process Stateless Benefit Rapidly provision & configure physical infrastructure via service templates Migrate physical infrastructure across hardware while maintaining infrastructural requirements (network & storage configuration) Unified Benefit UCS Stateless augments the ESXi Auto Deploy value in that it handles the physical infrastructure components which are beyond the scope of Auto Deploy. End users can link a UCS Service Profile Template to an Auto Deploy Policy to provide end to end hypervisor provisioning Hypervisor migration can be accomplished by either using service templates to provision physical then Auto Deploy to move hypervisor, or use 100% UCS stateless capabilities to migrate 33

34 Auto Deploy Technical Overview: 6 step process Host PXE boots and gets an IP address from DHCP DHCP points the host to the TFTP server via option #66 TFTP server downloads a gpxe configuration file as specified in option #67 gpxe config file instructs host to make HTTP boot request to Auto Deploy Server Auto Deploy queries the rules engine for information about host An Image Profile and Host Profile is attached to the host based on a rule set ESXi is installed into host RAM, is added to vcenter and is configured in the cluster vcenter maintains Image Profile and Host Profile for each host in its database 6 PXE boot UCS blade - host is added to the root folder of the vcenter 5 Booting working 1 Installation - Install Auto Deploy 2 Installation - Install Auto Deploy 3 Verifying installation - successful installation 4 Prepare your DHCP critical to configuration DHCP Option 66 DHCP Option 67 34

35 UCS Manager Configuration Recommendations 1. If you will be installing a lot of systems, know and understand goucs, CLI scripting - It dramatically simplifies the setup of several complex objects 2. Always use Policies, Pools, and Templates - I've seen a lot of cases were manually configured settings for specific service profiles are used. Always recommend using updating templates. If you use an actual policy you can quickly see which elements are using the policy through the "show policy usage action under each policy 3. Fixing service profiles where Policies, Pools, and Templates were not used - If Service profiles were created without policies, pools, and templates you can add them later. Since often the systems being "fixed" are probably in production you have to be very careful with the process 35

36 Use Updating Templates for vnics or vhbas To update or not to update? With vnic/vhba templates is always a question When creating a vnic or vhba template always use "updating template" option unless you want to lock down changes With updating templates all virtual interfaces bound to the template will be updated immediately with any change This can be very powerful with it comes to adding new VLANs Take for instance you need to add a new VLAN to your UCS environment. If the template is updating, all you do is add the new VLAN to the global VLAN list within UCS and then update your interface template VLAN list. 36

37 UCS Manager Configuration 4. When cloning a the service profile the clone WILL NOT have the same MAC address, UUID, WWNN, and WWPN's as the original one 5. Be careful about switching or modifying vnic's and vhba's since the MAC address and WWPN's could change if you don't follow the right process. Do not Delete the current ones then re-add the templates. This is likely to change the addresses. Could possibly break Storage zoning, boot from San and PXE setup 6. Always and ONLY use vnic and vhba templates - You loose a lot of control and dramatically increase the complexity of troubleshooting and monitoring your environment 7. Always use a maintenance policy - I suggest using a user-ack policy against EVERY service profile and EVERY service profile template. Personally I only use user-ack policy 37

38 VMware BIOS Settings Here are the best practices for VMware ESXi on Cisco UCS for deploying applications in the network 38

39 VMware BIOS Settings Enhanced Intel SpeedStep cannot be disabled on the B230 and B440 blade servers Manage BIOS firmware versions and settings on a perservice basis 39

40 UCS Manager configuration Recommendations 8. Always set all blade firmware versions in the policy - I always selecting all firmware options and version even for hardware that you may not have in the environment. Sometimes it turns out you might have a component the firmware applies to and you don't want to leave it at some random firmware version. Secondly you are likely to acquire new hardware and you will have to remember to modify your firmware policy to include this new hardware. It takes a seconds to select everything compared to creating a minimal firmware policy. Note - Newest firmware version is not necessarily at the top or the bottom of the list. You will need to pay attention to the firmware version values to find the best choice 40

41 Upgrade UCS with Production Applications The firmware upgrade process is broken down into two phases - upgrading the chassis versus upgrading the blade firmware Firmware Upgrade Process - All production application must remain unaffected Preparation should prior the to the upgrade - Collect the operating equivalent of an IOS show technical support; system logs, from UCSM Two firmware binaries which can belong to either domain and so land in a no-man s land of sorts: the Adaptor software on the Converged network adaptor, and the CIMC firmware Service profile associated with a particular blade must be rebooted in order to affect a firmware upgrade on that blade 41

42 Upgrade UCS with Production Applications Direct Updates - following the steps below to upgrade the UCS infrastructure without taking affecting the application running on the blades Activating the Fabric Interconnects - This is the only step in the process where all data connections in the UCSM domain on a particular path: A or B will be affected Preparation should prior the to the upgrade - firmware upgrade where service profiles are managed by service profile templates - No Update Template Make sure multipathing is setup correctly prior to upgrade 42

43 Nexus 1000v and Nexus

44 Back Plane Back Plane Why Nexus 1000V Architecture Comparison to a Physical Switch Moving to a Virtual Environment Network Admin Network Admin Modular Switch Modular Switch Supervisor-1 Supervisor-1 Supervisor-2 Supervisor-2 Linecard-1 Linecard-1 Linecard-2 Linecard-2 Linecard-N Linecard-N Server 1 Server 2 Server 3 Server Admin Hypervisor Hypervisor Hypervisor Comparison of a standard physical switch, where network administrators manage the physical switch and the server administrators manage the servers connected to that switch Moving towards a virtualized environment, the server administrators still manage the physical ESXi servers and network administrators manage the switch 44

45 Back Plane Back Plane Why Nexus 1000 Architecture VSM: Virtual Supervisor Module Network Admin Virtual Appliance VSM Primary VSM: Virtual Supervisor Module VEM: Virtual Ethernet Module Network Admin Virtual Appliance VSM Primary Switch VSM Secondary Switch VSM Secondary Supervisor-1 Supervisor-2 Linecard-1 Linecard-2 Linecard-N Supervisor-1 Supervisor-2 Linecard-1 Linecard-2 Linecard-N Server Admin Hypervisor Hypervisor Hypervisor With the Nexus 1000V, the network administrator will still manage the VSMs of the Nexus 1000V, along with the physical switch VEM-1 VEM-2 VEM-N Hypervisor Hypervisor Hypervisor Server Admin VEMs are managed by the network administrators since the port-profiles configurations are configured on the VSM. This allows the server administrators to manage the ESXi hosts without worrying about the networking portion within the ESXi server 45

46 VSM to VEM Communication Through Layer 2 Define Control VLAN ID (VSM) VSM-S VSM-P VSM-S VSM-P Allow Control VLAN through all points of the network Configure N1KV uplink port-profile for control VLAN ID Define control vlan Management interface Through Layer 3 VEM Requires vmkernel interface managed by N1KV (potentially service console interface) L2 Network Allow control vlan on physical switch ports L3 Network Should be on same subnet as service console Communication flows through L3 vmkernel and VSM mgmt0 interface What VLANs should be System VLANs? vsphere vsphere Nexus 1000V VEM Nexus 1000V VEM Control VLAN L3 vmkernel 46

47 Nexus 1000V Port-Profiles Type Ethernet Configuration attributes created for physical Server NIC(s) (aka uplink port-profiles) Defines what VLANs are allowed to traverse the physical NIC(s) (typically trunk mode) Critical to allow control/packet VLAN for VSM to VEM communication in L2 mode Defines Port-Channel type (mac-pinning, CDP, LACP) Can define Ethernet Port-Profiles with servers that have many NICs for more granular traffic engineering? J05-VSM-01# show running-config port-profile system-uplink port-profile type ethernet system-uplink vmware port-group switchport mode trunk switchport trunk allowed vlan 50-53,100,172 channel-group auto mode on mac-pinning no shutdown system vlan 50,100,172 state enabled J05-VSM-01# show svs domain SVS domain config: Domain id: 56 Control vlan: 50 Packet vlan: 50 L2/L3 Control mode: L2 L3 control interface: NA Status: Config push to VC successful. Nexus 5548UP- 1 VLAN 50: Control VLAN VLAN 51: Vmotion VLAN 52-53: VM Data VLANs VLAN 100: NFS Storage VLAN 172: Management VLAN VM vspher e VM VM Nexus 5548UP- 2 Nexus 1000V VEM VM Type vethernet J05-VSM-01# show running-config port-profile web-server Nexus 5548UP- 1 Nexus 5548UP- 2 Default type when creating a port-profile Configuration attributes created for virtual machines (VM) typically access mode port-profile type vethernet web-server vmware port-group switchport mode access switchport access vlan 52 no shutdown state enabled Define attributes such as VLAN, ACL, PVLAN, etc. that gets inherited by the VM Once VM is powered on, a virtual ethernet (veth) interface is automatically created with the attributes defined by this type of port-profile J05-VSM-01# show running-config port-profile database-server port-profile type vethernet database-server vmware port-group switchport mode access switchport access vlan 53 no shutdown state enabled Web0 1 vspher e Web0 2 DB01 Nexus 1000V VEM DB02 veth1 veth2 veth3 veth4

48 What is the Nexus 1010? A dedicated NX-OS appliance for deploying multiple Virtual Appliances / Virtual Services It is NOT a general purpose server to deploy any VM Nexus 1010 Manager: Cisco management experience Manages a total of 5 virtual service blades (ie. 4 VSMs and 1 NAM) Each VSM can manage up to 64 VEMs (256 total VEMs) 48

49 Nexus 1010/1010-X Connectivity There are 4 options to connect the Nexus 1010/1010-X to the physical Network using the 6x 1G interfaces available Within the Nexus 1010 CLI they are called network option and will influence on which interface the different traffic will be configured on. The four type of traffic available on the system are 49

50 Application Deployment Case Studies Looking at a Virtual Desktop Infrastructure Deployment 50

51 Virtual Desktop Infrastructure (VDI) Deployment Initial 6k VDI deployment. Goals to grow to thousands of users VMware View 5.1 Deployment Design should be scalable with no significant change in performance or stability, compared to current physical workloads per pod Deploy and user will come model Knowledge Worker Profile This is a middle of the range performance profile tier Applicable to many generic types of users Suitable to run basic corporate application suites Linked cloned desktop Non-persistent type of desktop

52 Knowledge Worker Definition Knowledge Worker User has limited privileges in OS. No ability to install applications or device drivers. Session will run approved global applications such as Microsoft Office suite and a relatively limited number of use case specific applications concurrently. User is not guaranteed session persistence Connectivity Remote - User access occurs over a network link which can potentially be strained for network bandwidth or have higher latency than that of a LAN infrastructure (for example, WAN, or Internet). These type of links are typically less than 100 Mbps and/or have latency higher than 50 ms. LAN - User access over a high-speed (1GigE or higher), low latency (5ms>) network with low overall utilization which is local to the VMware View infrastructure from a physical location standpoint 52

53 View POD - Logical Architecture Design The View pod is an abstract component of View architecture. A View pod is delineated by a cluster of View Connection Servers, five VMware vcenter servers, virtual infrastructure that hosts all of the View desktop pools and View desktops Pod Diagram for 6000 View Desktops A pod is a unit of organization determined by VMware View scalability limits 53

54 View Management Block The View Management Block is an abstract component of the View Architecture that is comprised of the virtual machines that operate the View infrastructure components. These are: View Connection Server View Block vcenter Server (One per View Block) Supporting vsphere infrastructure Supporting Storage Management 54

55 View Block Example View architecture design has four View blocks. Each block is essentially the same A View block is comprised of the following mandatory and optional components vcenter Servers ESX hosts vsphere clusters View desktop pool Shared storage NFS data store that is accessible to all ESX hosts in a View block. Data stores can be shared across View blocks 55

56 View POD Logical Design Storage is broken down into two (2) NetApp array s which will each service up to 3,000 users 56

57 Thank You Mark Dittmer

58 Complete Your Online Session Evaluation Give us your feedback and you could win fabulous prizes. Winners announced daily. Receive 20 Passport points for each session evaluation you complete. Complete your session evaluation online now (open a browser through our wireless network to access our portal) or visit one of the Internet stations throughout the Convention Center. Don t forget to activate your Cisco Live Virtual account for access to all session material, communities, and on-demand and live activities throughout the year. Activate your account at the Cisco booth in the World of Solutions or visit 58

59 Final Thoughts Get hands-on experience with the Walk-in Labs located in World of Solutions, booth 1042 Come see demos of many key solutions and products in the main Cisco booth 2924 Visit after the event for updated PDFs, ondemand session videos, networking, and more! Follow Cisco Live! using social media: Facebook: Twitter: LinkedIn Group: 59

60 Presentation_ID