Support a New Class of Applications with Cisco UCS M-Series Modular Servers

Transcription

1 Solution Brief December 2014 Highlights Support a New Class of Applications Cisco UCS M-Series Modular Servers are designed to support cloud-scale workloads In which a distributed application must run on a large number of bare-metal servers. Reduce Expenses Get the most from your investment with better performance per watt and per dollar and reduced space, power, and cooling requirements. The modular design lets you rapidly refresh your CPU and memory elements while retaining your power, cooling, I/O, and management infrastructure, reducing costly waste. Reduce Time to Value Integrated management lets you use a GUI, command-line interface (CLI), or open programmatic XML API to deploy up to 320 servers per Cisco UCS domain. Right size your infrastructure by creating server definitions that exactly match your workload requirements. Meet Service-Level Agreements (SLAs) with Ease Policy-based server definitions allow consistent assignment of quality-ofservice (QoS) settings across the infrastructure. Mix and match value and performance variables to optimize infrastructure according to your needs. A new class of applications is moving into your data center. We have created a new class of server to help you support them. A Challenge to Traditional Servers You ve become experienced at supporting enterprise applications in your data center, and you ve been getting increasingly efficient at doing so. You run many applications on a pool of servers comprising a virtualization cluster. You ve distributed application components among multiple powerful systems, with many virtual machines per server (Figure 1). You ve raised utilization levels as you ve increased availability through this common model. Single Server Hypervisor Virtual Machines Figure 1. Enterprise Applications Typically Hosted Are with Multiple Applications or Application Components per Server New Class of Applications A new class of applications is challenging this common model by demanding completely the opposite: the same workload running on many bare-metal servers 2014 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.

2 (Figure 2). We call this trend cloudscale computing. Applications needing this model manage their own performance with more servers, load balancing, and availability. They are multiserver aware, and they are already highly resilient after faults. Suddenly your high-end servers and virtualized environments are big, but your clients need small. You are already familiar with applications that need cloud-scale computing. They include the back-end operations that support mobile devices, mobile workers, business transactions, and highly parallelized functions, including: Online content delivery including web presentation layers, media streaming, and caching Mobile applications such as backend servers for delivering map data and other time-sensitive interactions Cloud and Internet hosting in which you offer true, dedicated hosting Agile development environments for which software developers need bare-metal servers Gaming applications that sort out which players are allocated to which game room that is hosted on a more powerful server A Gap in the Market Our customers have found that they need a new class of server product to support cloud-scale applications. They want inexpensive, low-end servers in large quantities for baremetal applications that don t need all of the memory capacity; virtualization support; and reliability, availability, and serviceability (RAS) features found in typical enterprise-class servers (Table 1). Customers want these servers to be quick and easy to deploy, and they want the cost model to support a much more frequent server refresh cycle (18 months) than with traditional servers (3 to 5 years). Current offerings that attempt to meet the needs of cloud-scale applications don t fully address the needs of these customers because: Single Application Many Servers Figure 2. Cloud-Scale Applications Host the Same Application on Many Servers Dedicated power, coolng, I/O, and management infrastructure that must be replaced with Management RAID SCSI Vendors have focused on miniaturizing traditional server packaging with no attempt to simplify the computing model. Every component is scaled down, with lower-performing CPUs, with less memory capacity, and lowerperforming on-board I/O subsystems and disk drives. This approach results in significant waste when servers are refreshed (Figure 3). As with traditional blade servers, power supplies and cooling fans are shared, but that s about all that s shared. Packaging has been improved, but the end result Dedicated CPU and memory that are the only components that need to be replaced in Figure 3. With Traditional Servers, One Third of the Cost and Two Thirds of the Volume Is Consumed by I/O, Power, and Cooling Infrastructure That Is Wasted When Servers Are Refreshed 2014 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information. Page 2 of 6

3 presents the same challenges as rack-in-a-box blade chassis: the same amount of complexity in a smaller space. Table 1. Typical Enterprise and Cloud-Scale Application Requirements Typical Traditional Enterprise Application Characteristics Typical Cloud-Scale Application Characteristics Replacing a failed system means pulling the server out of a chassis, copying data or swapping disk drives into a new server, and configuring I/O and BIOS settings just as with traditional servers. Processes are manual, complex, and time consuming when the application really just needs a new computing module plugged in. Miniaturized packaging results in a cabling challenge: separate cables for each network, fixed partitioning of capacity between cables, and limited I/O (typically 1 Gbps per server). The management model fails to adequately address the need to manage hundreds or thousands of servers. Servers cost more because components that could be preserved across CPU generations I/O and storage devices must be paid for in each and every server that is replaced with a newer generation. Application Mapping Deployment Model Server Refresh Cycle Server Availability Requirements CPU Demands Memory Demands I/O Demands Many applications run on one server Virtualized One application runs on many servers Bare metal 3 to 5 years 18 months High: Availability is supported externally for applications through distributed, highavailability servers. High: CPUs with a large number of cores to support virtualization density are essential. High: Massive amounts of memory enable a greater number of virtual machines per server. High: Virtualized environments can impose high-i/o workloads. Low: Applications are multiserver aware and handle server failures themselves. High: High clock rate per core and the number of cores per rack are more important than the number of cores per processor. Low: Each distributed application component has low memory demands; however, the aggregate demand is high. High: Information Is consumed by a large number of mobile devices. Introducing Cisco UCS M-Series Modular Servers When we designed the Cisco Unified Computing System (Cisco UCS ), we changed the way the industry views computing. Instead of the fixedconfiguration servers that have been common in the industry, we now offer a flexible pool of resources that can be configured on demand to support the intended workload. We achieved this flexibility by extracting server identity, configuration, and connectivity characteristics so that servers become stateless. With server state extracted into a software model, you can create policies to configure servers automatically through the system s embedded management system. With more than 100 state variables stored in a Cisco UCS service profile or Cisco UCS service profile template, you can automatically assign a state to any server, making it as easy to configure 100 servers as It is to configure just one Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information. Page 3 of 6

4 take this approach a step further by disaggregating server components. CPU, memory, I/O devices, and onboard disk capacity are components that you can integrate following policies defined in Cisco UCS service profiles. You now have an automated, policybased way to deploy cloud-scale servers with finely detailed control over the way that resources are used to create a server. You implement this new approach through the familiar Cisco UCS Manager GUI, XML API, and CLI and through Python and Microsoft Windows PowerShell scripting. We make this possible through: A new Cisco UCS chassis that supports up to 16 servers in only 2 rack units (2RU) with dual 40- Shared power, cooling, I/O, and management infrastructure that does not have to be replaced with 4 internal SSDs in configurable RAID groups RAID 1 Gbps unified fabric connections; the chassis midplane supports 32 lanes of Generation 3 (Gen3) PCI Express (PCIe) connectivity that is distributed across the cartridges. A single shared infrastructure per chassis, not per server, that includes power, cooling, management, and I/O infrastructure that supports network interface cards (NICs), local disks, and connectivity to external shared networked storage (see the gray area in Figure 4) Integrated, unified management that allows you to program the number and type of I/O devices on demand; through Cisco UCS service profiles you can program even the size of direct-attached storage and the RAID group from which it is allocated Logical volumes allocated from RAID groups appear as logical volumes simplified servers with only CPU, memory, and PCIe bus 16 servers share common infrastructure Dedicated CPU and memory are the only components to replace in A dramatically simplified server that provides the CPU and memory with Gen3 PCIe connectivity to the chassis midplane (see the yellow area in Figure 4) This shift in server definition further optimizes our cloud-scale computing solution. The server components that you want to change most often the CPU and memory are separate from the I/O infrastructure, which can remain constant across CPU generations. Now, rather than managing server lifecycles, you manage component lifecyles, with more freedom to change components with less cost because you aren t replacing an entire server and its power, cooling, management, and I/O infrastructure every refresh cycle. Servers Become Computing Nodes In the Cisco UCS M-Series, a server is a simplified computing node: it is just one or more CPUs, memory, and, for the first generation of cartridges, two lanes of Gen3 PCIe connectivity for Gbps of I/O bandwidth. Management RAID 0 2 x 40-Gbps unified fabric connections to Cisco UCS fabric interconnects Cisco System Link technology uses Cisco VIC silicon to provide programmable, dedicated I/O devices to each server s PCIe bus Figure 4. The Cisco UCS M-Series Shares I/O, Power, and Cooling Components, Enabling Faster and Lower-Cost CPU Refresh Cycles This approach simplifies server design, allowing us to quickly and easily create new computing modules. Now we can quickly change computing power: the number of sockets per node, the type of CPU, the clock rate, and number of cores. The design that fixes the amount of memory per CPU socket can be changed depending on the balance of resources that your workload needs Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information. Page 4 of 6

5 Today we package two nodes in a single Cisco UCS M142 Compute Cartridge. Today, eight cartridges fit into a chassis, for 16 computing nodes per chassis (Figure 5). As with the Cisco UCS 5108 Blade Server Chassis, flexibility is built in to support potential future products. The Cisco UCS M4308 Modular Chassis has flexible cartridge slots that can support single-0 and double-width cartridges, creating flexibility for the design space. What does this all mean for you? Lower cost per server: I/O, power, cooling, and management is shared and reused across CPU generations. Cisco UCS M4308 Modular Chassis (8 Compute Cartridges, 16 Servers) Cisco UCS M142 Compute Cartridge Chassis Rear View: Shared Power, Cooling, I/O, and Disk Resources Figure 5. Cisco UCS M-Series Modular Chassis and Compute Cartridge Less cost to refresh more frequently: Your I/O infrastructure doesn t get thrown out every time you need a more powerful (or different) CPU. A better match between workloads and processing power: Do you need fewer cores at a faster clock rate? More cores at a slower clock rate? Our solution is designed so that it can evolve quickly and support many different application resource needs. I/O and Storage Disaggregation Cisco System Link technology disaggregates I/O interfaces and storage from computing nodes. The I/O configuration, including the number and type of I/O devices, quality of service, local storage, and storage redundancy characteristics (such as RAID level) are configured through CIsco UCS Manager service profiles and new storage profiles. Cisco System Link technology uses Cisco UCS virtual interface card (VIC) silicon. Third-generation Cisco VIC silicon connects a total of 32 PCIe lanes from the server cartridges to the chip s programmable devices. Bus connectivity is flexible. For example, the four lanes of connectivity per slot could be allocated to up to four servers in a cartridge, or for greater I/O bandwidth only a single server per cartridge could access four PCIe lanes. Similarly, double-width cartridges could be designed to connect to up to 8 PCIe lanes. Logical volumes are carved out of the four solid-state drives (SSDs) inserted in the rear of the chassis and presented to computing cartridges as local disks. Now you can define each server s local disks through Cisco UCS storage profiles and swap or upgrade computing cartridges without having to copy boot drives or physically move disks from the old server to a new server. Traditional scale-out servers typically use dual Gigabit Ethernet interfaces. In the new Cisco model, a total of 80 Gbps of network bandwidth is shared among the chassis 16 servers, for an average of 5 Gbps of bandwidth per server. And because this bandwidth is shared, the servers, unlike discrete servers, can accommodate spikes in bandwidth. What does this mean for you? Easier, faster, and less expensive server refresh cycles because the shared storage infrastructure can be inherited from one computing cartridge to the next Dramatically greater bandwidth for network and shared storage access than with traditional 1RU servers Flexibility to reconfigure server I/O characteristics dynamically as workload needs change Completely programmable I/O infrastructure, including local disk drives a feature that only Cisco and Cisco System Link technology can deliver 2014 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information. Page 5 of 6

6 Centralized Management and Automation We have disaggregated the traditional components of a server. Cisco UCS Manager reintegrates those components into the servers that you design to best fit your workload. From a resource pool, you select the computing cartridges with the CPU and memory characteristics most appropriate for your workload. You create the number and type of I/O devices that the workload needs to access the network and shared storage devices. You create disk groups to support the reliability characteristics that are important to your business. From those disk groups you provision logical boot drives and local storage volumes to suit your workload, both of which appear to the BIOS as local Small Computer System Interface (SCSI) targets. After you have created policies to define servers, you can define up to 320 servers in a single Cisco UCS domain, and up to 10,000 through an upcoming release of Cisco UCS Central Software. Cisco UCS Manager is embedded in the system s fabric interconnects, making it self-aware and selfintegrating. Zero-touch management helps you automate your IT processes so that you have no tedious, manual, error-prone server configuration to perform between the time a server arrives at the loading dock and the time it is put to use in your data center. What does this mean for you? Lower operating costs through policy-based automation Elimination of configuration errors that can cause downtime Faster time to value through programmatic deployment of servers Flexibility to tailor every detail of server configuration to meet the needs of your workloads Capability to easily match performance characteristics with workloads to meet service-level agreements (SLAs) Conclusion Cisco has a reputation for innovating to fill gaps in the market. We see a gap in the products offered for cloud-scale computing workloads, and we believe that this market should be addressed with visionary leadership. With Cisco UCS M-Series Servers, we deliver a new set of products to support the new class of applications appearing in your data center. These products give you: Reduced capital and operating expenses with 16 percent less initial solution cost and 38 percent lower cost after two hardware refresh cycles (based on an 80-server comparison with traditional 1RU servers based on retail prices on August 29, 2014) Faster time to value with easier deployment and an exceptional capability to optimize your computing environment to match your workload needs Simplified SLA support with a common management framework and a greater capability to align infrastructure to optimize your own cost and value model Unlike any other platform, Cisco UCS enables you to run scale-up and scaleout workloads in the same unified system, with the same management model. Now you can run your lightweight presentation applications on Cisco UCS M-Series Servers, and your heavyweight, data-centric applications on scale-up servers all managed under the same system and connected with the same high-bandwidth, lowlatency unified fabric that is one of the hallmarks of Cisco innovation. For More Information For more information about Cisco UCS, visit Americas Headquarters Cisco Systems, Inc. San Jose, CA Asia Pacific Headquarters Cisco Systems (USA) Pte. Ltd. Singapore Europe Headquarters Cisco Systems International BV Amsterdam, The Netherlands Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) LE /14