Booting over a network (LAN or SAN) is a mature technology and an important step in moving toward stateless computing, which eliminates the static binding between a physical server and the OS and applications it is supposed to run.
The OS and applications are decoupled from the physical hardware and reside on the network.
The mapping between the physical server and the OS on the network is performed on demand when the server is deployed. Some of the benefits of booting from a network are:
• Reduced server footprint because fewer components (no disk) and resources are needed
• Simplified disaster and server failure recovery
• Higher availability because of the absence of failure-prone local hard drives
• Centralized image management
• Rapid redeployment With SAN booting, the image resides on the SAN, and the server communicates with the SAN through an HBA . The HBA’s BIOS contains the instructions that enable the server to find the boot disk. A common practice is to have the boot disk exposed to the server as LUN ID 0.
The Cisco UCS M71KR-E Emulex CNA, Cisco UCS M71KR-Q QLogic CNA, and Cisco UCS M81KR Virtual Interface Card (VIC) are all capable of booting from a SAN.
Management of Virtual Servers in the SAN Typically, virtual servers do not have an identity in the SAN: they do not log in to the SAN like physical servers do. However, if controlling and monitoring of the virtual servers is required, N-port ID virtualization (NPIV) can be used.
This approach requires you to:
• Have a Fibre Channel adapter and SAN switch that support NPIV
• Enable NPIV on the virtual infrastructure, such as by using VMware ESX Raw Device Mode (RDM)
• Assign virtual port worldwide names (pWWNs) to the virtual servers
• Provision the SAN switches and storage to allow access By zoning the virtual pWWNs in the SAN to permit access, you can control virtual server SAN access just as with physical servers. In addition, you can monitor virtual servers and provide service levels just as with any physical server.