What is UCS Cisco’s Unified Computing System?

I will be using the acronym UCS a lot as we are implementing it at my work and thought I would share what it is…

Amplify’d from www.cisco.com

Data Center Server Platform—Cisco Unified Computing System

Cisco Unified Computing System Overview

Today, IT organizations assemble their data center environments from individual components. Their administrators spend significant amounts of time manually accomplishing basic integration tasks rather than focusing on more strategic, proactive initiatives. The industry is in a transition away from the rigid, inflexible platforms that result and moving toward more flexible, integrated, and virtualized environments.

The Cisco Unified Computing System™ is a next-generation data center platform that unites compute, network, storage access, and virtualization into a cohesive system designed to reduce total cost of ownership (TCO) and increase business agility. The system integrates a low-latency, lossless 10 Gigabit Ethernet unified network fabric with enterprise-class, x86-architecture servers. The system is an integrated, scalable, multichassis platform in which all resources participate in a unified management domain.

Managed as a single system whether it has one server or 320 servers with thousands of virtual machines, the Cisco Unified Computing System decouples scale from complexity. The Cisco Unified Computing System accelerates the delivery of new services simply, reliably, and securely through end-to-end provisioning and migration support for both virtualized and nonvirtualized systems. It provides the following benefits:

Embedded system management—Management is uniquely integrated into all the components of the system, enabling the entire solution to be managed as a single entity through Cisco UCS Manager. Cisco UCS Manager provides an intuitive GUI, a command-line interface (CLI), and a robust API to manage all system configuration and operations. Cisco UCS Manager enables IT managers of storage, networking, and servers to collaborate easily on defining service profiles for applications.

Just-in-time provisioning with service profiles—Cisco UCS Manager implements role- and policy-based management using service profiles and templates. Infrastructure policies—such as power and cooling, security, identity, hardware health, and Ethernet and storage networking—needed to deploy applications are encapsulated in the service profile. This construct improves IT productivity and business agility. Now infrastructure can be provisioned in minutes instead of days, shifting IT’s focus from maintenance to strategic initiatives.

Unified fabric—Cisco’s unified fabric technology reduces cost by eliminating the need for multiple sets of adapters, cables, and switches for LANs, SANs, and high-performance computing networks. The system’s fabric extenders pass all network traffic to parent fabric interconnects, where it can be processed and managed centrally, improving performance and reducing points of management. The unified fabric is a low-latency lossless 10-Gbps Ethernet foundation that enables a “wireonce” deployment model in which changing I/O configurations no longer means installing adapters and recabling racks and switches.

State-of-the-art performance—Intel® Xeon® 5500 series processors automatically and intelligently adjust server performance according to application needs, increasing performance when needed and achieving substantial energy savings when not.

Performance and power settings can also be manually configured.

Energy efficiency—The system is designed for energy efficiency. Power supplies are 92 percent efficient and the Intel Xeon 5500 series processors use automated low-power states to better match power consumption with workloads. The simplified design of the Cisco UCS B-Series Blade Servers improves airflow efficiency and can reduce the number of components that need to be powered and cooled by more than 50 percent compared to traditional blade server environments; similar component reduction can be achieved with the Cisco UCS C-Series Rack-Mount Servers.

Read more at www.cisco.com

What’s New in Exchange 2010

Oh how excited I am to take on this project. Working with our new Cisco UCS system which will host our new VMWare Environment and host our new Exchange 2010 implementation. I am in the early stages of gathering information for my project plan and thought this little blurp off of the Cisco site provided a great summary of a few of the components that make up the Exchange services. I really like how you can set policy from the Hub server to analyze the outgoing messages and if you are for example a health org that needs to abide by HIPPA rules for patient info the Hub will be able to determine based on policy to hold your message or let it through or encrypt it if necessary.

Amplify’d from www.cisco.com

Hub Transport Server Role

For those familiar with earlier versions of Exchange Server 2007, the Hub Transport server role replaces what was formerly known as the bridgehead server in Exchange Server 2003. The function of the Hub Transport server is to intelligently route messages within an Exchange Server 2010 environment. By default, SMTP transport is very inefficient at routing messages to multiple recipients because it takes a message and sends multiple copies throughout an organization. As an example, if a message with a 5 MB attachment is sent to 10 recipients in an SMTP network, typically at the sendmail routing server, the 10 recipients are identified from the directory and 10 individual 5 MB messages are transmitted from the sendmail server to the mail recipients, even if all of the recipients’ mailboxes reside on a single server.

The Hub Transport server takes a message destined to multiple recipients, identifies the most efficient route to send the message, and keeps the message intact for multiple recipients to the most appropriate endpoint. Hence, if all of the recipients are on a single server in a remote location, only one copy of the 5 MB message is transmitted to the remote server. At that server, the message is then broken apart with a copy of the message dropped into each of the recipient’s mailboxes at the endpoint.

The Hub Transport server in Exchange Server 2010 does more than just intelligent bridgehead routing; it also acts as the policy compliance management server. Policies can be configured in Exchange Server 2010 so that after a message is filtered for spam and viruses, the message goes to the policy server to be assessed whether the message meets or fits into any regulated message policy and appropriate actions are taken. The same is true for outbound messages; the messages go to the policy server, the content of the message is analyzed, and if the message is determined to meet specific message policy criteria, the message can be routed unchanged or the message can be held or modified based on the policy. As an example, an organization might want any communications referencing a specific product code name or a message that has content that looks like private health information, such as Social Security number, date of birth, or health records of an individual, to be held or encryption to be enforced on the message before it continues its route.

Client Access Server Role

The Client Access Server role in Exchange Server 2010 (as was also the case in Exchange Server 2007) performs many of the tasks that were formerly performed by the Exchange Server 2003 front-end server, such as providing a connecting point for client systems. A client system can be an Office Outlook client, a Windows Mobile handheld device, a connecting point for OWA, or a remote laptop user using Outlook Anywhere to perform an encrypted synchronization of their mailbox content.

Unlike a front-end server in Exchange Server 2003 that effectively just passed user communications on to the back-end Mailbox server, the CAS does intelligent assessment of where a user’s mailbox resides and then provides the appropriate access and connectivity. This is because Exchange Server 2010 now has replicated mailbox technology where a user’s mailbox can be active on a different server in the event of a primary mailbox server failure. By allowing the CAS server to redirect the user to the appropriate destination, there is more flexibility in providing redundancy and recoverability of mailbox access in the event of a system failure.

Mailbox Server Role

The Mailbox server role is merely a server that holds users’ mailbox information. It is the server that has the Exchange Server EDB databases. However, rather than just being a database server, the Exchange Server 2010 Mailbox server role can be configured to perform several functions that keep the mailbox data online and replicated. For organizations that want to create high availability for Exchange Server data, the Mailbox server role systems would likely be clustered, and not just a local cluster with a shared drive (and, thus, a single point of failure on the data), but rather one that uses the new Exchange Server 2010 Database Availability Groups. The Database Availability Group allows the Exchange Server to replicate data transactions between Mailbox servers within a single-site data center or across several data centers are multiple sites. In the event of a primary Mailbox server failure, the secondary data source can be activated on a redundant server with a second copy of the data intact. Downtime and loss of data can be drastically minimized, if not completely eliminated, with the ability to replicate mailbox data on a real-time basis.

Microsoft eliminated single copy clusters, Local Continuous Replication, Clustered Continuous Replication, and Standby Continuous Replication in Exchange 2010 and substituted in their place Database Availability Group (DAG) replication technology. The DAG is effectively CCR, but instead of a single active and single passive copy of the database, DAG provides up to 16 copies of the database and provides a staging failover of data from primary to replica copies of the mail. DAGs still use log shipping as the method of replication of information between servers. Log shipping means that the 1 MB log files that note the information written to an Exchange server are transferred to other servers and the logs are replayed on that server to build up the content of the replica system from data known to be accurate. If during a replication cycle a log file does not completely transfer to the remote system, individual log transactions are backed out of the replicated system and the information is re-sent.

Unlike bit-level transfers of data between source and destination used in Storage Area Networks (SANs) or most other Exchange Server database replication solutions, if a system fails, bits do not transfer and Exchange Server has no idea what the bits were, what to request for a resend of data, or how to notify an administrator what file or content the bits referenced. Microsoft’s implementation of log shipping provides organizations with a clean method of knowing what was replicated and what was not. In addition, log shipping is done with small 1 MB log files to reduce bandwidth consumption of Exchange Server 2010 replication traffic. Other uses of the DAG include staging the replication of data so that a third or fourth copy of the replica resides “offline” in a remote data center; instead of having the data center actively be a failover destination, the remote location can be used to simply be the point where data is backed up to tape or a location where data can be recovered if a catastrophic enterprise environment failure occurs.

A major architecture change with Exchange Server 2010 is how Outlook clients connect to Exchange Server. In previous versions of Exchange Server, even Exchange Server 2007, RPC/HTTP and RPC/HTTPS clients would initially connect to the Exchange Server front end or Client Access Server to reach the Mailbox servers while internal MAPI clients would connect directly to their Mailbox Server. With Exchange Server 2010, all communications (initial connection and ongoing MAPI communications) go s through the Client Access Server, regardless of whether the user was internal or external. Therefore, architecturally, the Client Access Server in Exchange Server 2010 needs to be close to the Mailbox server and a high-speed connection should exist between the servers for optimum performance.

Read more at www.cisco.com