Eucalyptus 安装指南


3.1 Installation Guide 2012-07-11 Eucalyptus Systems Contents Welcome............................................................................................................................................6 How to Read this Guide........................................................................................................................................6 Introduction to Eucalyptus....................................................................................................................................6 Eucalyptus Overview.................................................................................................................................7 Eucalyptus Components............................................................................................................................7 System Requirements................................................................................................................................8 Planning Your Installation............................................................................................................10 Understanding the Eucalyptus Architecture........................................................................................................10 Planning for Your Hardware................................................................................................................................11 Understanding Component Placement....................................................................................................11 Verifying Component Disk Space...........................................................................................................13 Planning Networking Modes...............................................................................................................................14 Managed Mode........................................................................................................................................16 Managed (No VLAN) Mode...................................................................................................................17 System Mode...........................................................................................................................................17 Static Mode..............................................................................................................................................18 Planning for Eucalyptus Features........................................................................................................................18 Windows Host Support............................................................................................................................18 VMware Support.....................................................................................................................................18 SAN Support...........................................................................................................................................19 Availability Zone Support.......................................................................................................................20 High Availability Support........................................................................................................................21 Preparing the Network.........................................................................................................................................24 Prepare Internal Firewalls........................................................................................................................24 Verify TCP/IP Connectivity....................................................................................................................24 Prepare VLAN.........................................................................................................................................24 Con®guring Dependencies............................................................................................................26 Install Hypervisors..............................................................................................................................................26 CentOS 5.................................................................................................................................................26 CentOS 6.................................................................................................................................................27 RHEL 5....................................................................................................................................................27 RHEL 6....................................................................................................................................................27 Ubuntu 10.04 LTS...................................................................................................................................27 Ubuntu 12.04 LTS...................................................................................................................................27 Con®gure Bridges...............................................................................................................................................27 CentOS 5.................................................................................................................................................28 Centos 6...................................................................................................................................................28 RHEL 5....................................................................................................................................................29 RHEL 6....................................................................................................................................................30 Ubuntu 10.04 LTS and Ubuntu 12.04 LTS..............................................................................................31 Eucalyptus | Contents | 2 Con®guring VMware..........................................................................................................................................32 Create New User......................................................................................................................................33 Set Up a Datastore...................................................................................................................................34 Create a Network.....................................................................................................................................34 Enable EBS Support................................................................................................................................34 Install VMware Tools..............................................................................................................................35 Con®gure the Firewall.........................................................................................................................................35 Con®gure SELinux..............................................................................................................................................35 Con®gure NTP....................................................................................................................................................36 Con®gure an MTA..............................................................................................................................................36 Installing Eucalyptus.....................................................................................................................37 Install on CentOS 5.............................................................................................................................................37 Install on CentOS 6.............................................................................................................................................38 Install on RHEL 5................................................................................................................................................40 Install on RHEL 6................................................................................................................................................42 Install on Ubuntu 10.04 LTS...............................................................................................................................44 Install on Ubuntu 12.04 LTS...............................................................................................................................45 Installing Eucalyptus Nightlies...........................................................................................................................47 Installing Eucalyptus Nightly Packages on CentOS 5............................................................................47 Installing Eucalyptus Nightly Packages on CentOS 6............................................................................48 Installing Eucalyptus Nightly Packages on RHEL 5...............................................................................49 Installing Eucalyptus Nightly Packages on RHEL 6...............................................................................51 Install Eucalyptus Nightly Packages on Ubuntu 10.04 LTS...................................................................52 Install Eucalyptus Nightly Packages on Ubuntu 12.04 LTS...................................................................53 Con®guring Eucalyptus................................................................................................................56 Con®gure Network Modes..................................................................................................................................56 Managed Mode........................................................................................................................................58 Managed (No-VLAN) Mode...................................................................................................................59 System Mode...........................................................................................................................................60 Static Mode..............................................................................................................................................60 Con®gure Hypervisors........................................................................................................................................61 CentOS 5.................................................................................................................................................61 CentOS 6.................................................................................................................................................63 RHEL 5....................................................................................................................................................63 RHEL 6....................................................................................................................................................63 Ubuntu 10.04 LTS...................................................................................................................................64 Ubuntu 12.04 LTS...................................................................................................................................64 Con®gure Loop Devices.....................................................................................................................................64 CentOS 5.................................................................................................................................................64 CentOS 6.................................................................................................................................................64 RHEL 5....................................................................................................................................................65 RHEL 6....................................................................................................................................................65 Ubuntu 10.04 LTS...................................................................................................................................65 Ubuntu 12.04 LTS...................................................................................................................................66 Eucalyptus | Contents | 3 Con®gure Multi-Cluster Networking..................................................................................................................66 Manage IP Tables Rules......................................................................................................................................67 Starting Eucalyptus.......................................................................................................................68 Start the CLC.......................................................................................................................................................68 Start Walrus.........................................................................................................................................................68 Start the CC.........................................................................................................................................................68 Start the VMware Broker....................................................................................................................................69 Start the SC..........................................................................................................................................................69 Start the NCs.......................................................................................................................................................69 Verify the Startup.................................................................................................................................................69 Registering Eucalyptus..................................................................................................................71 Register the Secondary Cloud Controller............................................................................................................71 Register Walrus....................................................................................................................................................71 Register the CC...................................................................................................................................................72 Register the VMware Broker...............................................................................................................................72 Register the SC....................................................................................................................................................72 Register the NCs..................................................................................................................................................73 Register Arbitrators.............................................................................................................................................73 Con®guring the Runtime Environment.......................................................................................76 Generate Administrator Credentials....................................................................................................................76 Con®gure SAN Support......................................................................................................................................76 Enable Dell Equallogic SANs.................................................................................................................76 Enable NetApp SANs..............................................................................................................................77 Enable Direct Attached Storage (JBOD) SANs......................................................................................77 Enable SANManager...............................................................................................................................77 Con®gure DNS....................................................................................................................................................78 Con®gure the Subdomain........................................................................................................................78 Turn on IP Mapping................................................................................................................................78 Enable DNS Delegation..........................................................................................................................79 Con®gure the Master DNS Server..........................................................................................................79 Set NC Concurrency Level..................................................................................................................................80 Increase Walrus Disk Space................................................................................................................................80 Con®gure DRBD.................................................................................................................................................81 Con®gure VMware Support................................................................................................................................83 Minimal VMware Broker con®guration..................................................................................................83 Re-generating VMware Broker con®guration.........................................................................................84 Full-featured VMware Broker con®guration..........................................................................................85 Set Up Security Groups.......................................................................................................................................87 Finding More Information............................................................................................................89 Appendix A: Upgrading Eucalyptus............................................................................................90 CentOS 5.............................................................................................................................................................90 Prepare the Con®guration File................................................................................................................90 Shutdown Components............................................................................................................................91 Upgrade Eucalyptus Packages.................................................................................................................92 Eucalyptus | Contents | 4 Start Eucalyptus.......................................................................................................................................93 Verify the Components............................................................................................................................94 Upgrade Credentials................................................................................................................................95 RHEL 5................................................................................................................................................................96 Prepare the Con®guration File................................................................................................................96 Shutdown Components............................................................................................................................96 Upgrade Eucalyptus Packages.................................................................................................................97 Start Eucalyptus.......................................................................................................................................98 Verify the Components............................................................................................................................99 RHEL 6..............................................................................................................................................................100 Prepare the Con®guration File..............................................................................................................101 Shutdown Components..........................................................................................................................101 Upgrade Eucalyptus Packages...............................................................................................................102 Start Eucalyptus.....................................................................................................................................103 Verify the Components..........................................................................................................................105 Ubuntu 10.04 LTS.............................................................................................................................................106 Prepare the Con®guration File..............................................................................................................106 Shutdown Components..........................................................................................................................106 Upgrade Eucalyptus Packages...............................................................................................................107 Start Eucalyptus.....................................................................................................................................108 Verify the Components..........................................................................................................................109 Appendix B: Creating a Local Eucalyptus Package Repository.............................................111 CentOS 5 Local Installation..............................................................................................................................111 CentOS 6 Local Installation..............................................................................................................................111 RHEL 5 Local Installation................................................................................................................................112 RHEL 6 Local Installation................................................................................................................................113 Ubuntu Local Installation..................................................................................................................................113 Eucalyptus | Contents | 5 Welcome Welcome to the Eucalyptus Installation Guide. This guide will help you understand, plan for, and install Eucalyptus. If you follow the recommendations and instructions in this guide, you will have a working version of Eucalyptus customized for your speci®c needs and requirements. How to Read this Guide We recommend that you read this guide in the order presented. There are no shortcuts for installing a customized installation of Eucalyptus. You have to understand what Eucalyptus is, what the installation requirements are, what your network con®guration and restrictions are, and what Eucalyptus components and features are available based on your needs and requirements. Important: If you are upgrading from a previous version of Eucalyptus, see Appendix A: Upgrading Eucalyptus. How to Read this Guide We recommend that you read this guide in the order presented. There are no shortcuts for installing a customized installation of Eucalyptus. You have to understand what Eucalyptus is, what the installation requirements are, what your network con®guration and restrictions are, and what Eucalyptus components and features are available based on your needs and requirements. Relevent topicHow do I? Introduction to EucalyptusUnderstand what Eucalyptus is and does Planning Your InstallationDecide how the installation will be done on your system Con®guring DependenciesCon®gure Eucalyptus dependencies Installing EucalyptusInstall Eucalyptus packages Con®guring EucalyptusCon®gure Eucalyptus for your system Starting EucalyptusStart Eucalyptus Registering EucalyptusRegister Eucalyptus components Con®guring the Runtime EnvironmentCon®gure Eucalyptus runtime environment Finding More InformationFind out more information about Eucalyptus Introduction to Eucalyptus Eucalyptus is a Linux-based software architecture that implements scalable private and hybrid clouds within your existing IT infrastructure. Eucalyptus allows you to provision your own collections of resources (hardware, storage, and network) using a self-service interface on an as-needed basis. You deploy a Eucalyptus cloud across your enterprise's on-premise data center. Users access Eucalyptus over your enterprise©s intranet. This allows sensitive data to remain secure from external intrusion behind the enterprise ®rewall. You can install Eucalyptus on the following Linux distributions: · Red Hat Enterprise Linux 5 (5.6 and above) · CentOS 5 (5.6 and above) · Red Hat Enterprise Linux 6 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Welcome | 6 · CentOS 6 · Ubuntu 10.04 LTS · Ubuntu 12.04 LTS Eucalyptus Overview Eucalyptus was designed to be easy to install and as non-intrusive as possible. The software framework is modular, with industry-standard, language-agnostic communication. Eucalyptus provides a virtual network overlay that both isolates network traf®c of different users and allows two or more clusters to appear to belong to the same Local Area Network (LAN). Also, Eucalyptus offers API compatability with Amazon's EC2, S3, and IAM services. This offers you the capability of a hybrid cloud. Eucalyptus Components Eucalyptus is comprised of six components: Cloud Controller (CLC), Walrus, Cluster Controller (CC), Storage Controller (SC), Node Controller (NC) and an optional VMware Broker (Broker or VB). Other than the VMware Broker, each component is a stand-alone web service. This architecture allows Eucalyptus both to expose each web service as a well-de®ned, language-agnostic API, and to support existing web service standards for secure communication between its components. A detailed description of each Eucalyptus component follows. Cloud Controller The Cloud Controller (CLC) is the entry-point into the cloud for administrators, developers, project managers, and end-users. The CLC queries other components for information about resources, makes high-level scheduling decisions, and makes requests to the Cluster Controllers (CCs). As the interface to the management platform, the CLC is responsible for exposing and managing the underlying virtualized resources (servers, network, and storage). You can access the CLC through command line tools that are compatible with Amazon's Elastic Compute Cloud (EC2) and through a web-based Dashboard. Walrus Walrus allows users to store persistent data, organized as buckets and objects. You can use Walrus to create, delete, and list buckets, or to put, get, and delete objects, or to set access control policies. Walrus is interface compatible with Amazon's Simple Storage Service (S3), providing a mechanism for storing and accessing virtual machine images and user data. Walrus can be accessed by end-users, whether the user is running a client from outside the cloud or from a virtual machine instance running inside the cloud. Cluster Controller The Cluster Controller (CC) generally executes on a machine that has network connectivity to both the machines running the Node Controllers (NCs) and to the machine running the CLC. CCs gather information about a set of NCs and schedules virtual machine (VM) execution on speci®c NCs. The CC also manages the virtual machine networks. All NCs associated with a single CC must be in the same subnet. Storage Controller The Storage Controller (SC) provides functionality similar to the Amazon Elastic Block Store (Amazon EBS). The SC is capable of interfacing with various storage systems (NFS, iSCSI, SAN devices, etc.). Elastic block storage exports storage volumes that can be attached by a VM and mounted or accessed as a raw block device. EBS volumes persist past VM termination and are commonly used to store persistent data. An EBS volume cannot be shared between VMs and can only be accessed within the same availability zone in which the VM is running. Users can create snapshots from EBS volumes. Snapshots are stored in Walrus and made available across availability zones. Eucalyptus with SAN support lets you use your enterprise-grade SAN devices to host EBS storage within a Eucalyptus cloud. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Welcome | 7 Node Controller The Node Controller (NC) executes on any machine that hosts VM instances. The NC controls VM activities, including the execution, inspection, and termination of VM instances. It also fetches and maintains a local cache of instance images, and it queries and controls the system software (host OS and the hypervisor) in response to queries and control requests from the CC. The NC is also responsible for the management of the virtual network endpoint. VMware Broker VMware Broker (Broker or VB) is an optional Eucalyptus component, which is available if you are a Eucalyptus subscriber. VMware Broker enables Eucalyptus to deploy virtual machines (VMs) on VMware infrastructure elements. VMware Broker mediates all interactions between the CC and VMware hypervisors (ESX/ESXi) either directly or through VMware vCenter. System Requirements To install Eucalyptus, your system must meet the following baseline requirements. Note: The speci®c requirements of your Eucalyptus deployment, including the number of physical machines, structure of the physical network, storage requirements, and access to software are ultimately determined by the features you choose for your cloud and the availability of infrastructure required to support those features. Compute Requirements · Physical Machines: All Eucalyptus components must be installed on physical machines, not virtual machines. · Central Processing Units (CPUs): We recommend that each machine in your Eucalyptus cloud contain either an Intel or AMD processor with a minimum of two, 2GHz cores. · Operating Systems: Eucalyptus supports the following Linux distributions: CentOS 5 (5.6 and above), CentOS 6, RHEL 5 (5.6 above), RHEL 6, Ubuntu 10.04 LTS, and Ubuntu 12.04 LTS. · Machine Clocks: Each Eucalyptus component machine and any client machine clocks must be synchronized (for example, using NTP). These clocks must be synchronized all the time, not just at installation. · Hypervisor: CentOS 5 and RHEL 5 installations must have Xen installed and con®gured on NC host machines. CentOS 6, RHEL 6, Ubuntu 10.04 LTS, and Ubuntu 12.04 LTS installations must have KVM installed and con®gured on NC host machines. VMware-based installations do not include NCs, but must have a VMware hypervisor pool installed and con®gured (VMware versions 4.0, 4.1 and 5.0). · Machine Access: Verify that all machines in your network allow SSH login, and that root or sudo access is available on each of them. Storage and Memory Requirements · Each machine in your network needs a minimum of 30 GB of storage. · We recommend at least 100GB for Walrus and SC hosts running Linux VMs. We recommend at least 250GB for Walrus and SC hosts running Windows VMs. · We recommend a range of 50-100GB per NC host running Linux VMs, and at least 250GB per NC host for running Windows VMs. Note that larger available disk space enables greater number of VMs. · Each machine in your network needs a minimum of 4 GB RAM. However, we recommend more RAM for improved caching. Network Requirements · All NCs must have access to a minimum of 1Gb Ethernet network connectivity. · All Eucalyptus components must have at least one Network Interface Card (NIC) for a base-line deployment. For better network isolation and scale, the CC should have two NICS (one facing the CLC/user network and one facing the NC/VM network). For HA con®gurations that include network failure resilience, each machine should have one extra NIC for each functional NIC (they will be bonded and connected to separate physical network hardware components). CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Welcome | 8 · Some con®gurations require that machines hosting a CC have two network interfaces, each with a minimum of 1Gb Ethernet. · Depending on the feature set that is to be deployed, the network ports connecting the Ethernet interfaces may need to allow VLAN trunking. · Depending on some con®gurations, Eucalyptus requires that you make available two sets of IP addresses. The ®rst range is private, to be used only within the Eucalyptus system itself. The second range is public, to be routable to and from end-users and VM instances. Both sets must be unique to Eucalyptus, not in use by other components or applications within your network. · The network interconnecting physical servers hosting Eucalyptus components (except the CC and NC) must support UDP multicast for IP address 228.7.7.3. Note that UDP multicast is not used over the network that interconnects the CC to the NCs. Once you are satis®ed that your systems requirements are met, you are ready to plan your Eucalyptus installation. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Welcome | 9 Planning Your Installation In order to get the most out of a Eucalyptus deployment, we recommend that you create a plan that provides a complete set of features, performance, scaling, and resilience characteristics you want in your deployment. Attention: If you are upgrading from an existing Eucalyptus release, see Appendix A: Upgrading Eucalyptus. To successfully plan for your Eucalyptus installation, you must determine two things: · The infrastructure you plan to install Eucalyptus on: Think about the application workload performance and resource utilization tuning. Think about how many machines you want on your system. · The amount of control you plan to give Eucalyptus on your network: Use your existing architecture and policies to determine the Eucalyptus networking features you want to enable: elastic IPs, security groups, DHCP server, and Layer 2 VM isolation. This section describes how to evaluate each tradeoff to determine the best choice to make, and how to verify that the resource environment can support the features that are enabled as a consequence of making a choice. By the end of this section, you should be able to specify how you will deploy Eucalyptus in your environment, any tradeoffs between feature set and ¯exibility, and where your deployment will integrate with existing infrastructure systems. Understanding the Eucalyptus Architecture The following image depicts the logical relationship between Eucalyptus components in a generalized deployment. The cloud components, Cloud Controller (CLC) and Walrus, communicate with cluster components, the Cluster Controllers (CCs) and Storage Controllers (SCs). The CCs and SCs, in turn, communicate with the Node Controllers (NCs). The networks between machines hosting these components must be able to allow TCP connections between them. However, if the CCs are on separate network interfaces (one for the network on which the cloud components are hosted and another for the network that NCs use) the CCs will act as software routers between these networks in some networking con®gurations. So each cluster can use an internal private network for its NCs and the CCs will route traf®c from that network to a network shared by the cloud components. Virtual machines (VMs) run on the machines that host NCs. You can use the CCs as software routers for traf®c between clients outside Eucalyptus and VMs. Or the VMs can use the routing framework already in place without CC software routers. However, depending on the layer-2 isolation characteristics of your existing network, you might not be able to implement all of the security features supported by Eucalyptus. Eucalyptus HA If you con®gure Eucalyptus for high availability (HA), the you will have primary and secondary cloud and cluster components. In the event of a failure, the secondary component becomes the primary component. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 10 Eucalyptus HA uses a service called Arbitrator that monitors connectivity between a user and a user-facing component (CLC, Walrus, and CC). An Arbitrator approximates reachability to a user. Each Arbitrator uses ICMP messages to periodically test reachability to an external entity (for example, a network gateway or border router) or to an external site (for example, google.com). An Arbitrator is not required in HA. However, it is nice to have in order to test connectivity with a user. If all Arbitrators fail to reach its monitored entity, Eucalyptus assumes there is a loss of connectivity between a user and the component. At that point a failover occurs. To allow for normal outages and maintenance, we recommend that you register more than one Arbitrator for each user-facing component. Planning for Your Hardware You can install Eucalyptus in various ways. You can install the CLC, Walrus, CC, and SC on one machine, and an NC on one or more machines. Or you can install each component on an independent physical server. This gives each component maximal local resource usage. Often your decision about how to distribute Eucalyptus components across an installation must trade deployment simplicity for performance or high-availability. For example, placing all cloud and cluster components on a single machine can simplify administration because there is only one machine to monitor and control for the Eucalyptus control services. However, each of the components deploys as an independent web service. If these components must share a single physical server, the physical resources that can be given to each service may become a performance bottleneck. In general, the Eucalyptus components are designed to be run in any combination on the various physical servers in a data center. However, the majority of use cases can be satis®ed by the below descriptions of deployment models. Understanding Component Placement A Eucalyptus deployment is a set of cloud services (CLC and Walrus) and one or more clusters, each of which contains a CC, an SC, an optional VMware Broker (located with the CC), and one or more NCs. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 11 Cloud Components The main decision for cloud components is whether to install the CLC and Walrus on the same server. If they are on the same server, they operate as separate web services within a single Java environment, and they use a fast-path for inter-service communication. If they are not on the same server, then they use SOAP and REST to work together. However, when installed on the same server, the CLC and Walrus must share a common memory footprint, both managed by the Java memory manager. Walrus self-tunes its performance based on the memory pressure it perceives and runs faster with more memory. So, while separating the CLC and Walrus decreases the ef®ciency of the messaging between the two, it often increases the responsiveness of the overall Eucalyptus system when Walrus is given a large memory footprint. Sometimes the key factor for cloud components is not performance, but server cost and data center con®guration. If you only have one server available for the cloud, then you have to install the components on the same server. The CLC and Walrus components are not designed to be separated by wide-area, common carrier networks. They use aggressive time-outs to maintain system responsiveness so separating them over a long-latency, lossy network link will not work. The CLC and Walrus communicate with Eucalyptus clients independently. End-users typically interact with Eucalyptus through a client interface. They can use either our provided euca2ools Linux command line client tools, or the Eucalyptus AWS-compatible API, or a third-party client that is compatible with Eucalyptus. In all cases, the end-user client must be able to send messages via TCP/IP to the machine on which the CLC is deployed. In addition, the CLC must have TCP/IP connectivity to all other Eucalyptus components except for node controllers (NCs), which may reside on their own private networks. In addition, NC servers must be able to send messages to the Walrus server because images are downloaded by the NC using the Walrus URL. That is, the CLC does not need to be able to route network traf®c directly to the NCs but Walrus does for the purposes of image delivery. Cluster Components The Eucalyptus components deployed in the cluster level of a Eucalyptus deployment are the Cluster Controller (CC), Storage Controller (SC), and VMware Broker. Tip: The VMware Broker is available by subscription only. You do not need the VMware Broker unless you are using VMware hypervisor. You can install all cluster components on a single machine, or you can distribute them on different machines. The choice of one or multiple machines is dictated by the demands of user workload in terms of external network utilization (CC) and EBS volume access (SC). CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 12 CC Placement If you plan to use elastic IPs and security groups, the CC physical machine becomes a software IP gateway between VM instances and the public network. Because of this software routing function, the physical server on which the CC is deployed should have fast, dedicated network access to both the NC network, and the public network. If you don't plan to use elastic IPs or security groups, the CC physical machine will not act as a software gateway. Network traf®c will be limited to small control messages. In all cases, place the CC on a machine that has TCP/IP connectivity to the Eucalyptus front end servers and the NC servers in its cluster. SC Placement The machine on which the SC is deployed must always have TCP/IP connectivity to the CLC. If you are a subscriber and use one of Eucalyptus' provided SAN integration drivers, the SC must also have TCP/IP connectivity to the chosen SAN device. In this case, the SC only sends control messages to the SAN. If you do not con®gure a SAN, the SC requires only TCP/IP connectivity to the NCs in the cluster. The SC will use this TCP/IP connectivity to provide the NCs network access to the dynamic block volumes residing on the SC's storage. SC storage should consist of a fast, reliable disk pool (either local ®le-system or block-attached storage) so that the SC can create and maintain volumes for the NCs. The capacity of the disk pool should be suf®cient to provide the NCs with enough space to accommodate all dynamic block volumes requests from end-users Subscription only: VMware Broker Placement The VMware Broker resides on the CC. If you are using more than one cluster, make sure that the VMware Broker is installed on the CC in the cluster that will be using VMware components (vCenter Server or ESX/ESXi). Make sure that the VMware Broker is able to communicate with the various VMware components (vCenter Server or ESX/ESXi) in its cluster. For instance, one should be able to connect from the CC/VB host to the vSphere endpoint on ports 443, 902, and 903. Node Components The Node Controllers are the components that comprise the Eucalyptus back-end. All NCs must have network connectivity to whatever hosts their EBS volumes. This host is either a SAN or the SC. Verifying Component Disk Space Eucalyptus components need disk space for log ®les, databases, buckets, and instances. The following table details the needs of each component. Verify that the machines you plan to install the components on have adequate space. We recommend that you choose a disk for each Walrus that is large enough to hold all objects and buckets you ever expect to have, including all images that will ever be registered to your system, plus any Amazon S3 application data. For consistent performance, we recommend that you use identical disks for the primary and secondary Walrus. Tip: We recommend that you use LVM (Logical Volume Manager). Should you run out of disk space, LVM allows you to add disks and migrate the data. Minimum SizeDirectoryComponent 20GB/var/lib/eucalyptus/dbCLC CLC logging 2GB/var/log/eucalyptus 250GB/var/lib/eucalyptus/bukkitsWalrus Walrus logging 2GB/var/log/eucalyptus 250GB/var/lib/eucalyptus/volumes (EBS storage) This disk space on the SC is only required if you are not using a SAN driver. SC CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 13 Minimum SizeDirectoryComponent 5GB/var/lib/eucalyptus/CCCC CC logging 2GB/var/log/eucalyptus 250GB/var/lib/eucalyptus/instancesNC NC logging 2GB/var/log/eucalyptus If necessary, create symbolic links to larger ®lesystems from the above locations. Make sure that the eucalyptus user owns the directories. Planning Networking Modes Eucalyptus overlays a virtual network on top of your existing network. In order to do this, Eucalyptus supports four different networking modes: Managed, Managed (No VLAN), System, and Static. Each mode is designed to allow you to choose an appropriate level of security and ¯exibility. The purpose of these modes is to direct Eucalyptus to use different network features to manage the virtual networks that connect VMs to each other and to clients external to Eucalyptus. A Eucalyptus installation must be compatible with local site policies and con®gurations (e.g., ®rewall rules). Eucalyptus con®guration and deployment interfaces allow a wide range of options for specifying how it should be deployed. However, choosing between these options implies tradeoffs. Your choice of networking mode depends on the following considerations: · Do you plan to support elastic IPs and security groups? · Do you plan to provide your own network DHCP server? · Do you plan to support Layer 2 VM isolation? These networking features are described in the following table: ModeDescriptionFeature ManagedEucalyptus instances typically have two IPs associated with them: a private one and a public one. Private IPs are intended for internal communications Elastic IPs Managed (No VLAN)between instances and are usually only routable within a Eucalyptus cloud. Public IPs are used for external access and are usually routable outside of Eucalyptus cloud. How these addresses are allocated and assigned to instances is determined by a networking mode. In System and Static modes, an instance is assigned only one IP address, which will be represented as both the private and public address assigned to the instance. Whether this address is routable outside of Eucalyptus is a property of the addresses that are set by the cloud administrator during Eucalyptus con®guration. The distinction between public and private addresses becomes important in Managed and Managed (No VLAN) modes, which support elastic IPs. With elastic IPs the user gains control over a set of static IP addresses. Once allocated to the user, those same IPs can be dynamically associated to running instances, overriding pre-assigned public IPs. This allows users to run well-known services (for example, web sites) within the Eucalyptus cloud and to assign those services ®xed IPs that do not change. ManagedSecurity groups are sets of networking rules that de®ne the access rules for all VM instances associated with a group. For example, you can specify ingress Security groups Managed (No VLAN)rules, such as allowing ping (ICMP) or SSH (TCP, port 22) traf®c to reach VMs in a speci®c security group. When you create a VM instance, unless otherwise speci®ed at instance run-time, it is assigned to a default security CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 14 ModeDescriptionFeature group that denies incoming network traf®c from all sources. Thus, to allow login and usage of a new VM instance you must authorize network access to the default security group with the euca-authorize command. ManagedAlthough network traf®c between VM instances belonging to a security group is always open, Eucalyptus can enforce isolation of network traf®c between VM isolation different security groups. This isolation is enforced using a VLAN tag per security group, thus, protecting VMs from possible eavesdropping by VM instances belonging to other security groups. StaticEucalyptus assigns IP addresses to VMs in all modes except System. In System mode, you must allow a DHCP server outside of Eucalyptus to assign IPs to any VM that Eucalyptus starts. DHCP server Managed Managed (No VLAN) If Eucalyptus can control and condition the networks its components use, your deployment will support the full set of API features. However, if Eucalyptus is con®ned to using an existing network, some of the API features might be disabled. So, understanding and choosing the right networking con®guration is an important (and complex) step in deployment planning. The following image shows which networking mode you should choose, depending on what networking features you want: CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 15 Each networking mode is detailed in the following sections. Managed Mode Managed mode offers the most features of the networking modes, but also carries with it the most potential constraints on the setup of the network. In Managed mode, Eucalyptus manages the local network of VM instances and provides all networking features Eucalyptus currently supports, including VM network isolation, security groups, elastic IPs, and metadata service. In Managed mode, you de®ne a large network (usually private, unroutable) from which VM instances will draw their private IP addresses. Eucalyptus maintains a DHCP server with static mappings for each VM instance that is created. When you create a new VM instance, you can specify the name of the security group to which that VM will belong. Eucalyptus then selects a subset of the entire range of IPs, to hand out to other VMs in the same security group. You can also de®ne a number of security groups, and use those groups to apply network ingress rules to any VM that runs within that network. In this way, Eucalyptus provides functionality similar to Amazon©s security groups. In addition, the administrator can specify a pool of public IP addresses that users may allocate, then assign to VMs either at boot or dynamically at run-time. This capability is similar to Amazon©s ©elastic IPs©. Eucalyptus administrators that require security groups, elastic IPs, and VM network isolation must use this mode. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 16 Managed mode uses a Virtual LAN (VLAN) to enforce network between instances in different security groups. If your underlying physical network is also using a VLAN, there can be con¯icts that prevent instances from being network accessible. So you have to determine if your network between the CC and NCs is VLAN clean (that is, if your VLANs are usable by Eucalyptus). To test if the network is VLAN clean, see VLAN Preparation. Each VM receives two IP addresses: a public IP address and a private IP address. Eucalyptus maps public IP addresses to private IP addresses. Access control is managed through security groups. Managed Mode Requirements · There must be an available range of IP addresses for the virtual subnets. This range must not interfere with the physical network. Typically these IP addresses are selected from the private IP ranges: 192.168.x.x, 10.x.x.x, etc. · The network between the CC and NCs must be VLAN clean, meaning that all switch ports that Eucalyptus components are connected to will allow and forward VLAN tagged packets. · Any ®rewall running on the Cluster Controller must be compatible with the dynamic changes performed by Eucalyptus when working with security groups. (Note that Eucalyptus will ¯ush the ©®lter© and ©nat© tables upon boot). · Any DHCP server on the subnet must be con®gured not to serve Eucalyptus instances. Managed (No VLAN) Mode In Managed (No VLAN) mode, Eucalyptus fully manages the local VM instance network and provides all of the networking features Eucalyptus currently supports, including security groups, elastic IPs, etc. However, it does not provide VM network isolation. Without VLAN isolation at the bridge level, it is possible in Managed (No VLAN) mode for a root user on one VM to snoop and/or interfere with the ethernet traf®c of other VMs running on the same layer 2 network. Tip: In Managed (No VLAN) mode, VM isolation is provided by having different security groups on different subnetsÐthis translates into Layer-3 only VM isolation. Managed (No VLAN) Mode Requirements · There must be an available range of IP addresses for the virtual subnets. This range must not interfere with the physical network. Typically these IP addresses are selected from the private IP ranges: 192.168.x.x, 10.x.x.x, etc. · Any ®rewall running on the Cluster Controller must be compatible with the dynamic changes performed by Eucalyptus when working with security groups. (Note that Eucalyptus will ¯ush the ©®lter© and ©nat© tables upon boot). · A range of public IP addresses must be available for use by Eucalyptus. · The CC must have a DHCP server daemon installed that is compatible with ISC DHCP Daemon version 3.0.X. Managed (No VLAN) Mode Limitations · Limited (Layer-3) VM isolation. System Mode This is the simplest networking mode, but it also offers the smallest number of networking features. In this mode, Eucalyptus simply assigns a random MAC address to the VM instance before booting and attaches the VM instance©s Ethernet device to the physical ethernet through the NC©s bridge. Then, VM instances can obtain an IP address using DHCP, the same way any machine using DHCP would obtain an address. There is very little Eucalyptus con®guration required to use System mode. Eucalyptus mostly stays out of the way in terms of VM networking. This mode requires a pre-con®gured DHCP server already active on the physical subnet. This server must be reachable by the machines hosting NC components. This mode is most useful for users who want to try out a simple Eucalyptus installation. System Mode Requirements · The physical Ethernet device on each NC that communicates with the CC must be bridged. · A pre-existing DHCP server must be running and con®gured and reachable from the NCs. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 17 System Mode Limitations · No elastic IPs · No security groups · No VM isolation Static Mode Static mode is similar to System mode but offers you more control over instance IP address assignment. In Static mode, you con®gure Eucalyptus with a map of MAC address/IP Address pairs. When a VM is instantiated, Eucalyptus sets up a static entry within a Eucalyptus controlled DHCP server, takes the next free MAC/IP pair, assigns it to an instance, and attaches the instance's ethernet device to the physical ethernet through the bridge on the NCs (in a manner similar to System mode). This mode is useful for administrators who have a pool of MAC/IP addresses that they wish to always assign to their VMs. In this mode, Eucalyptus manages VM IP address assignment by maintaining its own DHCP server with one static entry per VM. Static mode requires the Eucalyptus administrator to specify the network con®guration each VM should receive from the Eucalyptus DHCP server running on the same physical server as the CC component. Static Mode Requirements · The Ethernet device on each NC that communicates with the CC must be bridged. · There must be an available range of IP addresses for the virtual subnets. This range must not interfere with the physical network. Typically these IP addresses are selected from the private IP ranges: 192.168.x.x, 10.x.x.x, etc. · Any DHCP server on the subnet must be con®gured not to serve Eucalyptus instances. Static Mode Limitations · No elastic IPs · No security groups · No VM isolation Planning for Eucalyptus Features Before you install Eucalyptus, we recommend that you think about the features you plan to implement with Eucalyptus. These features are detailed in the following sections. Windows Host Support Eucalyptus requires the following for Windows support: · A licensed installation copy (.iso image or CD/DVD disk) of a compatible Windows OS. Eucalyptus currently supports Windows virtual machines created from Windows Server 2003 R2 Enterprise (32/64 bit); Windows Server 2008 SP2, Datacenter (32/64 bit); Windows Server 2008 R2, Datacenter; and Windows 7 Professional. · A VNC client such as RealVNC or Virtual Manager/Virtual Viewer (Centos/Xen) for initial installation. Subsequent Eucalyptus-hosted Windows instances will use RDP, but the initial installation requires VNC. For additional Windows-related licensing information, see the following links: · http://technet.microsoft.com/en-us/library/dd979803.aspx · http://technet.microsoft.com/en-us/library/dd878528.aspx · http://technet.microsoft.com/en-us/library/dd772269.aspx VMware Support Eucalyptus includes an optional subscription-only component, the VMware Broker. The VMware Broker mediates all interaction between Eucalyptus and VMware infrastructure components (that is, ESX/ESXi, and vCenter). In the following CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 18 diagram VB is controlling VMware infrastructure through a vCenter server, but it can also connect to ESX/ESXi hosts directly, without vCenter server present. Eucalyptus provides: · Support for VMware vSphere infrastructure as the platform for deploying virtual machines · The ability to extend cloud-based features (for example, elastic IPs, security groups, Amazon S3, etc.) to a VMware infrastructure · Compatibility with VMware vSphere client, which can be used alongside Eucalyptus The VMware Broker can run with either an administrative account or a minimally-privileged account on the VMware host. VMware Support Prerequisites If you plan to use Eucalyptus with VMware, there are some additional prerequisites: · You must install and con®gure the VMware infrastructure software (ESX and/or ESXi hypervisors with or without vCenter server). · The CC server (that will also run the VMware Broker) must be able to route network traf®c to and from the physical servers running VMware software on ports 443, 902, and 903. If there are internal ®rewalls present, these ®rewalls must be con®gured to open these ports so that the Eucalyptus cloud components can communicate with the VMware services and hypervisors. · You must provide the VMware administrator account credentials to Eucalyptus when you con®gure VMware support, or an equivalent account with suf®cient permissions must be created on VMware vCenter or ESX hosts. See "Con®guring VMware" section for more details. For additional information on VMware support for Eucalyptus, contact Eucalyptus Systems, Inc. SAN Support Eucalyptus includes optional, subscription only support for integrating enterprise-grade SAN (Storage Area Network) hardware devices into a Eucalyptus cloud. SAN support extends the functionality of the Eucalyptus Storage Controller (SC) to provide a high performance data conduit between VMs running in Eucalyptus and attached SAN devices. Eucalyptus dynamically manages SAN storage without the need for the administrator to manually allocate and de-allocate storage, manage snapshots or set up data connections. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 19 Eucalyptus with SAN support allows you to: · Integrate Eucalyptus block storage functionality (dynamic block volumes, snapshots, creating volumes from snapshots, etc.) with existing SAN devices · Link VMs in the Eucalyptus cloud directly to SAN devices, thereby removing I/O communication bottlenecks of the physical hardware host · Incorporate enterprise-level SAN features (high-speed, large-capacity, reliability) to deliver a production-ready EBS (block storage) solution for the enterprise · Attach SAN devices to Eucalyptus deployments on Xen, KVM, and VMware hypervisors To use Eucalyptus with supported SAN storage, you must decide whether administrative access can be provided to Eucalyptus to control the SAN. If this is possible in your environment, Eucalyptus can automatically and dynamically manage SAN storage. Currently, the Dell Equallogic series of SANs (PS 4000 and PS 6000) and NetApp Filer FAS 2000 and FAS 6000 series are supported. For Dell Equallogic, Eucalyptus requires SSH access to enable automatic provisioning. Eucalyptus will manage NetApp SANs via ONTAPI (version 7.3.3 and above). SAN Support Prerequisites Eucalyptus supports the following SAN devices: · Dell EqualLogic, PS4000 series and PS6000 series (For more information about Dell EqualLogic SANs, go to http://www.dell.com) · NetApp, FAS2000 series and FAS6000 series (For more information about NetApp SANs, go to http://www.netapp.com · Direct Attached Storage (JBOD) For additional information on SAN support for Eucalyptus, contact Eucalyptus Systems, Inc. Availability Zone Support Eucalyptus offers the ability to create multiple availability zones. In Eucalyptus, an availability zone is a partition in which there is at least one available cluster. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 20 High Availability Support Eucalyptus includes the ability to run redundant, hot swappable instances for the CLC, Walrus, CC, SC, and VMware Broker components. In a high availability (HA) con®guration, a failure of any single component will not cause the system to halt. If your network con®guration includes redundant networking hardware and routing paths, HA Eucalyptus can then tolerate a network component failure (e.g. the loss of a networking switch) without halting. The deployment choices for HA Eucalyptus are similar to a regular Eucalyptus deployment, with the following additional considerations: · You must host redundant Eucalyptus software components on separate hardware components in order to be able to tolerate a hardware failure. If, for example, you install redundant CLCs on the same machine and the machine crashes, both CLCs will become inoperable. · The redundant components occur in pairs, one primary, the other secondary. These components must be able to communicate with each other through the network to which they are both attached while they are running. For example, both CLC components in an HA installation must be able to exchange messages. If you use a ®rewall to separate them, one will not detect a failure of the other and a hot failover will not occur. This ability for pairs of components to communicate is required for the CLC, Walrus, CC, SC, and the VMware Broker for HA to operate properly. The following images shows a single cluster deployment with the component pairs at the cloud and cluster level. The NCs are not redundant. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 21 Note that the same considerations for a regular Eucalyptus deployment with respect to networking mode and components placement apply to HA Eucalyptus in addition to the need for redundant component pairs to be able to communicate. Note also that the NC components are deployed redundantly in an HA Eucalyptus deployment. If a machine running an NC fails, Eucalyptus will continue to be available for user requests. However, instances running on that speci®c NC will be lost. For HA: The installation and con®guration sections will note instructions speci®c to HA deployment by the HA icon. HA Requirements HA Eucalyptus requires the same requirements as non-HA Eucalyptus. However, the infrastructure HA Eucalyptus will be deployed on must meet some additional requirements, listed in the following sections. Redundant Physical Servers for Eucalyptus Components Each cloud component (CLC and Walrus) and cluster component (CC, SC, and VMware Broker) in an HA deployment has a redundant hot backup. These redundant Eucalyptus components occur in pairs, and each member of a pair must be mapped to a separated physical server to ensure high availability. Important: HA pairs must be able to connect to each other. If the HA deployment is to be able to tolerate the failure of networking hardware, additional network interfaces are required for the physical servers that host Eucalyptus components. The physical servers hosting a CLC, Walrus, or CC and VMware Broker must each have three network interface cards (NICs). Each remaining physical server (except the NC components) requires two NICs. DNS Round-Robin Support The DNS entries for the externally visible IP addresses of the physical servers hosting CLC or Walrus components must be con®gured to change round-robin style in an HA deployment. Storage Mirroring HA Eucalyptus uses a kernel-level storage technology called DRBD for storage integrity. DRBD must be con®gured to mirror data operations between physical servers that host Walrus components. For more information about DRBD, go to What is DRBD. Storage Controllers For HA Storage Controllers, you must be using a supported SAN. Only use HA SCs with NetApp or Equallogic drivers, not with the iSCSI or JBOD SC driver. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 22 HA Planning High availability is the result of the combination of functionality provided by Eucalyptus and the environmental and operational support to maintain the systems proper operation. Eucalyptus provides functionality aimed at enabling highly available deployments: 1. Detection of hardware and network faults which impact system availability: Availability of the system is determined by its ability to properly service a user request at a given time. The system is available when there is at least a set of functioning services to perform the operations which result from a user request (i.e., system is distributed and operations require orchestration involving some, possibly all, services in the system). 2. Deployment of redundant services to accommodate host failure: A failure is the observed consequence of an underlying fault which compromises the systems function in some way (possibly compromising availability). 3. Automated recovery from individual component failure: Eucalyptus can take advantage of redundant host and network resources to accommodate singular failures while preserving the system©s overall availability. As a result, the deployment of the system plays a large role in the level of availability that can be achieved. To deliver services with high availability, Eucalyptus depends upon redundant hardware and network. Considerations A highly available deployment is able to mitigate the impact on system availability of faults from the following sources: = Machines hosting Eucalyptus services = Hardware faults on machines hosting Eucalyptus services can result in component services being unavailable for use by the system or users. The state of the hosting machine is monitored by the system and determines whether it can contribute to work done. In support of high availability, redundant component services can be con®gured. With redundant component services the system is able to isolate and mask the failure of one such service. · Inter-component networks: Faults in the networks that connect the system©s components to each other can prevent access to cloud resources and restrict the system©s ability to process user requests. First, internal resources may become unavailable. For example, a single network outage could impact access to attached volumes or prevent access to running instances. Second, the coordination of services needed to process user requests may be impeded even if the service state is otherwise healthy. · User-facing network connections: User-facing network faults can prevent access to an otherwise properly functioning system. The ability of a user to access the system is dif®cult to determine from the perspective of the system - can©t look through the users eyes. Allowing for multiple inbound paths (i.e., multiple disjoint routes) decreases the possibility of an availability-impacting outage occurring w/in the scope of the environment within which Eucalyptus is deployed. (See also: registering arbitrators) Recommendations To ensure availability in the face of any single failure, we recommend the following deployment strategy: · Host/Service Redundancy: Each component which is registered should have a complementary service registered on a redundant host. For example, the cloud and walrus services should be installed and registered on two hosts. Additionally, for example, each partition should have two cluster controllers and storage controllers (and VMware Brokers, if VMware is being used) con®gured. Each such complementary pair of services can suffer a single outage before system availability is compromised. · Inter-component Network Redundancy: Each host of a component service should have redundant and disjoint network connections to other internal component services and supporting systems (e.g., SANs, vSphere). The recommended approach is to have two ethernet devices (each connected to a disjoint layer-2 network) on each host and bonding the devices. Such a con®guration is also suggested on node controllers. Then, the outage of a either layer-2 network or ethernet device on a host does not impact service availability or access to cloud resources. · User-facing Network Redundancy: The wide area (where users are) network connection should be redundant and disjoint. Each such path should have an independent arbitrator host whose liveness (as determined by ICMP echo) is used to approximate the users© ability to access the system. Redundant network connections from the local area network to the wide area network and user reachability approximation (arbitrator) · System Reachability Approximation: The wide area (where users are) network connection(s) path should have an independent host (arbitrator) whose liveness (as determined by ICMP echo) can serve as a reasonable approximation CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 23 of users© ability to access the system. Ideally, the host ªclosestº to the user, but still within the domain of the deployment environment should be used (e.g., the border gateway of the hosting AS network). With such an arbitrator host in the network path between the user and the system, a failure by the user to reach an otherwise working service and allow the system to enable the complementary service (which should have a separate network route) restoring user access. Preparing the Network Decisions you make about the most appropriate deployment options imply different requirements that the underlying infrastructure must meet in order for Eucalyptus to deploy. Prepare Internal Firewalls Open ports 8443, 8773, 8774, and 8777 in any ®rewalls on your network to allow the various Eucalyptus components to communicate. Verify TCP/IP Connectivity Verify connectivity between the machines you'll be installing Eucalyptus on. Some Linux distributions provide default TCP/IP ®rewalling rules that limit network access to machines. Disable these default ®rewall settings before you install Eucalyptus components to ensure that the components can communicate with one another. Verify component connectivity by performing the following checks on the machines that will be running the listed Eucalyptus components. 1. Verify the connection from an end-user to the CLC on ports 8773 and 8443. 2. Verify the connection from an end-user to Walrus on port 8773. 3. Verify connection from the CLC to Walrus on ports 8773 and 8777. 4. Verify the connectiion from the CLC to the CC on port 8774. 5. Verify the connection from the CLC to the SC on ports 8773 and 8777. 6. Verify the connection from the CC to an NC on port 8775. 7. Verify the connection from an NC to Walrus on port 8773. Or, you can verify the connection from the CC to Walrus on port 8773, and from an NC to the CC on port 8776. 8. If you use VMware with Eucalyptus, verify the connection from the VMware Broker to VMware (ESX, VSphere). Prepare VLAN Tip: You only need to read this section if you are using Managed mode. If you aren't using Managed mode, skip this section. Managed networking mode requires that switches and routers be ªVLAN clean.º This means that switches and routers must allow and forward VLAN tagged packets. If you plan to use the Managed networking mode, you can verify that the network is VLAN clean between machines running Eucalyptus components by performing the following test. 1. Choose two IP addresses from the subnet you plan to use with Eucalyptus, one VLAN tag from the range of VLANs that you plan to use with Eucalyptus, and the network interface that will connect your planned CC and NC servers. The examples in this section use the IP addresses 192.168.1.1 and 192.168.1.2, VLAN tag 10, and network interface eth3, respectively. 2. On the planned CC server, choose the interface on the local Ethernet and run: vconfig add eth3 10 ifconfig eth3.10 192.168.1.1 up CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 24 3. On a planned NC server, choose the interface on the local network and run: vconfig add eth3 10 ifconfig eth3.10 192.168.1.2 up 4. On the NC, ping the CC: ping 192.168.1.1 5. On the CC, ping the NC: ping 192.168.1.2 · If this VLAN clean test fails, con®gure your switch to forward VLAN tagged packets. If it is a managed switch, see your switch©s documentation to determine how to do this. · If the VLAN clean test passes, continue with the following steps to remove the test interfaces. 6. On the CC, remove the test interface by running: vconfig rem eth3.10 7. On the planned NC, run: vconfig rem eth3.10 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Planning Your Installation | 25 Configuring Dependencies Before you install Eucalyptus, make sure you have the following dependencies installed and con®gured. Install Hypervisors Eucalyptus deploys VM instances on a hypervisor. A hypervisor is a software abstraction of a physical hardware platform that enables multiple guest operating systems to run concurrently on a single physical machine. Eucalyptus is directly compatible with both Xen and KVM hypervisors. To interact with these hypervisors, Eucalyptus uses the libvirt virtualization API. Alternatively, you can con®gure Eucalyptus to use VMware virtualization technologies with which it communicates using web services. While it is usually possible to use Xen and KVM with any of the supported distributions, the level of effort necessary, and the quality of the resulting platform for different distribution-hypervisor combinations varies. Before choosing an open source hypervisor and a Linux distribution, we recommend that you consider the level of support that the community reports for a speci®c combination. Eucalyptus supports the Xen hypervisor for CentOS 5 and RHEL 5, and KVM for CentOS 6, RHEL 6 and Ubuntu. Important: Be sure to set the ulimit parameter to an appropriately large value if you expect to launch a large number of instances on the Node Controller. For example: ulimit -u 63652 CentOS 5 Tip: Skip this section if you selected Virtualization as an option when you installed the kernel. Before installing Eucalyptus, make sure that each NC server has a kernel with Xen support, and that this is the default kernel loaded at boot time. To determine the current kernel, enter the following command on an NC server: uname -r | grep xen | wc -l If the command returns a zero, the Xen kernel is either not installed or not setup correctly. You must install a Xen kernel. To install a Xen kernel: 1. Log in to a host you plan to use as an NC. 2. Con®rm that YUM is working. 3. Install the Xen kernel package. yum install kernel-xen 4. Ensure that grub is set up to boot the Xen kernel by default. For example, edit /boot/grub/menu.lst and change: default 1 to: default 0 5. Repeat on each planned NC in your system. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Dependencies | 26 CentOS 6 When you install Eucalyptus from packages, KVM will be installed on all NCs. For more information about using KVM on CentOS 6, go to the Virtualization page. RHEL 5 Tip: Skip this section if you selected Virtualization as an option when you installed the kernel. Before installing Eucalyptus, make sure that each NC server has a kernel with Xen support, and that this is the default kernel loaded at boot time. To determine the current kernel, enter the following command on an NC server: uname -r | grep xen | wc -l If the command returns a zero, the Xen kernel is either not installed or not setup correctly. You must install a Xen kernel. To install a Xen kernel: 1. Log in to a host you plan to use as an NC. 2. Con®rm that YUM is working. 3. Make sure that you have set up the required entitlements for RHN access. 4. Install the Xen kernel package. yum install kernel-xen 5. Repeat on each planned NC in your system. RHEL 6 When you install Eucalyptus from packages, KVM will be installed on all NCs. For more information about using KVM on RHEL 6, go to the Virtualization page in the Red Hat documentation. Ubuntu 10.04 LTS When you install Eucalyptus from packages, KVM will be installed on all NCs. For more information about installing and using KVM on Ubuntu, go to the KVM page in the Ubuntu documentation. Ubuntu 12.04 LTS When you install Eucalyptus from packages, KVM will be installed on all NCs. For more information about installing and using KVM on Ubuntu, go to the KVM page in the Ubuntu documentation. Configure Bridges For Managed (No VLAN), Static, and System modes, you must con®gure a Linux ethernet bridge on all NC machines. This bridge connects your local ethernet adapter to the cluster network. Under normal operation, NCs will attach virtual machine instances to this bridge when the instances are booted. The process for setting up a Linux ethernet bridge differs depending on Linux distribution, but the result is always the same. If you use Xen, the distros typically set up a bridge for you, and you©ll simply have to ®nd its name. For Xen versions 3.0 or earlier the bridge name is typically xenbr0 If you use Xen 3.2 the bridge name is typically eth0 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Dependencies | 27 If you use KVM, or if you want to con®gure a bridge manually, the following sections describe how to set up a bridge on various distributions. In this section we show examples for con®guring bridge devices that either obtain IP addresses using DHCP or statically. Important: Before you con®gure a bridge, you must install the bridge-utils package. CentOS 5 To con®gure a bridge in CentOS: 1. Install the bridge-utils package. yum install bridge-utils 2. Create a new ethernet bridge con®guration ®le /etc/sysconfig/network-scripts/ifcfg-br0 and enter the following: DEVICE=br0 BOOTPROTO=dhcp ONBOOT=yes TYPE=Bridge 3. Add your physical ethernet device to the bridge by editing your physical ethernet device con®guration ®le (/etc/sysconfig/network-scripts/ifcfg-eth0). · If you are using DHCP, the con®guration will look similar to the following example: DEVICE=eth0 TYPE=Ethernet BRIDGE=br0 · If you are using a static IP address, the con®guration will look similar to the following example: DEVICE=br0 TYPE=Bridge BOOTPROTO=static IPADDR= NETMASK= GATEWAY= ONBOOT=yes 4. Enter the following command: service network restart Centos 6 To con®gure a bridge in RHEL6.x, you need to create a ®le with bridge con®guration (for example, ifcfg-brX) and modify the ®le for the physical interface (for example, ifcfg-ethX). 1. Install the bridge-utils package. yum install bridge-utils CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Dependencies | 28 2. Go to the /etc/sysconfig/network-scripts directory: cd /etc/sysconfig/network-scripts 3. Open the network script for the device you are adding to the bridge and add your bridge device to it. The edited ®le should look similar to the following: DEVICE=eth0 # change the hardware address to match the hardware address your NIC uses HWADDR=00:16:76:D6:C9:45 ONBOOT=yes BRIDGE=br0 NM_CONTROLLED=no 4. Create a new network script in the /etc/sysconfig/network-scripts directory called ifcfg-br0 or something similar. The br0 is the name of the bridge, but this can be anything as long as the name of the ®le is the same as the DEVICE parameter, and the name is speci®ed correctly in the previously created physical interface con®guration (ifcfg-ethX). · If you are using DHCP, the con®guration will look similar to: DEVICE=br0 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes DELAY=0 · If you are using a static IP address, the con®guration will look similar to: DEVICE=br0 TYPE=Bridge BOOTPROTO=static IPADDR= NETMASK= GATEWAY= ONBOOT=yes 5. Enter the following command: service network restart RHEL 5 To con®gure a bridge in RHEL5.x, you need to create a ®le with bridge con®guration (for example, ifcfg-brX) and modify the ®le for the physical interface (for example, ifcfg-ethX). 1. Install the bridge-utils package. yum install bridge-utils 2. Go to the /etc/sysconfig/network-scripts directory: cd /etc/sysconfig/network-scripts CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Dependencies | 29 3. Open the network script for the device you are adding to the bridge and add your bridge device to it. The edited ®le should look similar to the following: DEVICE=eth0 # change the hardware address to match the hardware address your NIC uses HWADDR=00:16:76:D6:C9:45 ONBOOT=yes BRIDGE=br0 NM_CONTROLLED=no 4. Create a new network script in the /etc/sysconfig/network-scripts directory called ifcfg-br0 or something similar. The br0 is the name of the bridge, but this can be anything as long as the name of the ®le is the same as the DEVICE parameter, and the name is speci®ed correctly in the previously created physical interface con®guration (ifcfg-ethX). · If you are using DHCP, the con®guration will look similar to: DEVICE=br0 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes DELAY=0 · If you are using a static IP address, the con®guration will look similar to: DEVICE=br0 TYPE=Bridge BOOTPROTO=static IPADDR= NETMASK= GATEWAY= ONBOOT=yes 5. Enter the following command: service network restart RHEL 6 To con®gure a bridge in RHEL6.x, you need to create a ®le with bridge con®guration (for example, ifcfg-brX) and modify the ®le for the physical interface (for example, ifcfg-ethX). 1. Install the bridge-utils package. yum install bridge-utils 2. Go to the /etc/sysconfig/network-scripts directory: cd /etc/sysconfig/network-scripts 3. Open the network script for the device you are adding to the bridge and add your bridge device to it. The edited ®le should look similar to the following: DEVICE=eth0 # change the hardware address to match the hardware address your NIC uses HWADDR=00:16:76:D6:C9:45 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Dependencies | 30 ONBOOT=yes BRIDGE=br0 NM_CONTROLLED=no 4. Create a new network script in the /etc/sysconfig/network-scripts directory called ifcfg-br0 or something similar. The br0 is the name of the bridge, but this can be anything as long as the name of the ®le is the same as the DEVICE parameter, and the name is speci®ed correctly in the previously created physical interface con®guration (ifcfg-ethX). · If you are using DHCP, the con®guration will look similar to: DEVICE=br0 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes DELAY=0 · If you are using a static IP address, the con®guration will look similar to: DEVICE=br0 TYPE=Bridge BOOTPROTO=static IPADDR= NETMASK= GATEWAY= ONBOOT=yes 5. Enter the following command: service network restart Ubuntu 10.04 LTS and Ubuntu 12.04 LTS To con®gure a bridge on Ubuntu Lucid: 1. Install the bridge-utils package. apt-get install bridge-utils 2. Modify the /etc/network/interfaces ®le. · If you are using DHCP, the con®guration will look similar to the following example: auto lo iface lo inet loopback auto br0 iface br0 inet dhcp bridge_ports eth0 · If you are using a static IP address, the con®guration will look similar to the following example: auto lo iface lo inet loopback auto br0 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Dependencies | 31 iface br0 inet static address network netmask broadcast gateway bridge_ports eth0 bridge_stp off 3. Enter the following command: /etc/init.d/networking restart Configuring VMware Tip: VMware support is available by subscription only. If you are not using VMware, skip this section. The easiest way to con®gure vSphere for Eucalyptus is to give Eucalyptus unrestricted access to all vSphere endpoint(s). This way does not require complex modi®cations to local access permission settings. You can grant this access to Eucalyptus by using an existing administrative account and password or by creating a new account for Eucalyptus and associating it with vSphere's standard Administrator role at the top level of the vSphere hierarchy as seen in the vSphere client. To give a more limited amount of control to Eucalyptus over your vSphere infrastructure managed by a vCenter server, create one new user and two new roles as described next. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Dependencies | 32 Create New User To give the minimal required amount of control to Eucalyptus over your vSphere infrastructure managed on vCenter, create one new user and two new roles. The new user and its password will be used for granting Eucalyptus access to the infrastructure. 1. Create a user (e.g., named eucalyptus) on the system where vCenter server is running. 2. Create a role (e.g., named Eucalyptus vSphere), for use at the top level of the vSphere hierarchy, with the following privileges: · Global · Licenses 3. Create a role (e.g., named Eucalyptus), for use with vSphere resources to be used by Eucalyptus, with the following privileges: · Datastore · Allocate Space · Browser Datastore · Low level ®le operations · Folder · Create folder · Host · Con®guration · Network Con®guration · Storage partition con®guration · Network · Assign network · Remove · Resource · Assign Virtual Machine to Resource Pool · Virtual Machine · (all Virtual Machine permissions) 4. Associate the user with the top-level role a) Right-click on the top-level resource, named after vCenter, and select Add Permission... b) In Users and groups section click Add... c) Add user eucalyptus with assigned role Eucalyptus vSphere and Propagate to Child Objects set to No 5. Associate the user with the resource-level role For each resource or collection of resources that you want Eucalyptus to use, the eucalyptus user must be given suf®cient privileges by using the Eucalyptus role. For example, you can create a new virtual datacenter for Eucalyptus to use, add to it the relevant hosts or clusters, and assign the eucalyptus user Eucalyptus role just for that datacenter. a) Right-click on each of the resources to be used by Eucalyptus and select Add Permission... b) In Users and groups section click Add... c) Add user eucalyptus with assigned role Eucalyptus and Propagate to Child Objects set to Yes CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Dependencies | 33 You©re now ready to set up a datastore. Set Up a Datastore Each node requires at least one datastore (either local or one shared by multiple nodes). If more than one datastore is available to a node, Eucalyptus will choose the datastore arbitrarily. If Eucalyptus is to be restricted in its use of available datastores, specify a datastore in Eucalyptus's con®guration for VMware. To determine the datastores that are available on a host, perform the following steps with vSphere client referencing either at vCenter Server or at a speci®c ESX/ESXi node: 1. Choose a host in left-hand-side panel. 2. Click the Con®guration tab. 3. Click Storage in the secondary left-hand side panel. 4. Click View: Datastores at the top of the panel. You©re now ready to create a network. Create a Network Each node must have a network reachable by the node running the Eucalyptus VMware Broker. Tip: If more than one network is available, specify the network name in Eucalyptus con®guration explicitly. Eucalyptus assumes that this network resides on the switch named "vSwitch0". To check the network settings and create a network (if necessary) perform the following steps with vSphere client pointed either at vCenter Server or at a particular ESX/ESXi node: 1. Click a host in left-hand side panel. 2. Click the Con®guration tab. 3. Click Networking in the secondary left-hand-side panel. 4. If there is no VM Network in the list, add it by performing these steps: a) Click Add Networking... in the upper-right corner. b) Click Virtual Machine and click Next. c) Click a switch (e.g., Use vSwitch0) and click Next. d) Enter VM Network for Network Label, leave VLAN ID blank, and click Next. e) Check the summary and click Finish. Enable EBS Support To enable VMware support for dynamic block volume support (like Amazon's Elastic Block Store) in Eucalyptus, con®gure each of the ESX/ESXi nodes in your infrastructure to support iSCSI. Given a node that is licensed for iSCSI support, this amounts to enabling and con®guring the gateway for the VMkernel network. To accomplish that, perform the following steps with vSphere client pointed either at vCenter or at a particular ESX/ESXi node: 1. Click a host in left-hand-side panel. 2. Click the Con®guration tab. 3. Select Networking in the secondary left-hand-side panel. 4. If there is no VMkernel network listed, add it by performing the following tasks: a) Click Add Networking... in the upper-right corner. b) Click VMkernel and click Next. c) Click a switch (e.g., Use vSwitch0) and click Next. d) Click the label VLAN ID and make sure that None(0) is selected, then click Next. e) Choose either dynamic network con®g or static IP assignment, depending on your environment. When your are done, click Next. f) Click Finish. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Dependencies | 34 5. Click DNS and Routing in the secondary left-hand-side panel. 6. If VMkernel does not have a gateway, add it by performing these steps: a) Click Properties... in upper-right corner. b) Click the Routing tab, enter the gateway©s IP, and click OK. For more information about con®guring vSphere, go to the VMware website at http://www.vmware.com/support/pubs/vs_pubs.html. Install VMware Tools Ensure that VMware Tools are installed in the images that will be installed and run within the Eucalyptus cloud. These tools allow Eucalyptus to discover an instance's IP address in System networking mode. They also are required for using the euca-bundle-instance command when running Windows VMs in Eucalyptus, since VMware Tools enable clean shutdown of VMs from outside the instance. For information about installing VMware Tools, go to the VMware documentation at http://www.vmware.com. Configure the Firewall If you have existing ®rewall rules on your hosts, you must allow Eucalyptus access. Note: This section only applies to RHEL 5, Centos 5, and RHEL 6. Tip: If you are installing on Ubuntu 10.04 LTS, you can skip this section. To enable your ®rewall: 1. To con®gure your ®rewall for RHEL5 and Centos 5: a) UDP multicast to the hosts that will run the CLC, Walrus, SC, and VMwareBroker. -A RH-Firewall-1-INPUT -p udp -d -j ACCEPT b) Allow UDP between these hosts by, for example, adding the following rule to /etc/sysconfig/iptables. -A RH-Firewall-1-INPUT -p udp -s -j ACCEPT 2. To con®gure your ®rewall (RHEL 6 only): a) Run the command system-config-firewall-tui b) Turn off the Enabled check box. 3. Repeat on each host that will run a Eucalyptus component: CLC, Walrus, CC, SC, and NC. Configure SELinux Security-enabled Linux (SELinux) is security feature for Linux that lets you to set access control through policies. Eucalyptus is not compatible with SELinux. Tip: If you are installing on Ubuntu 10.04 LTS, you can skip this section. To con®gure SELinux to allow Eucalyptus access: 1. Open /etc/selinux/con®g and edit the line SELINUX=enforcing to SELINUX=permissive. 2. Save the ®le. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Dependencies | 35 3. Run the following command: setenforce 0 Configure NTP Eucalyptus requires that each machine have the Network Time Protocol (NTP) daemon started and con®gured to run automatically on reboot. To use NTP: 1. Install NTP on the machines that will host Eucalyptus components. · For CentOS 5, RHEL 5, and RHEL 6, run yum install ntp · For Ubuntu 10.04 LTS and Ubuntu 12.04 LTS, run apt-get install openntpd 2. Open the /etc/ntp.conf ®le (/etc/openntpd/ntpd.conf in Ubuntu) and add NTP servers, as in the following example. server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org 3. Save and close the ®le. 4. Con®gure NTP to run at reboot. (In Ubuntu, NTP is con®gured after you install it.) chkconfig ntpd on 5. Start NTP. (In Ubuntu, NTP starts after you install it.) service ntpd start 6. Synchronize your server. ntpdate -u 7. Synchronize your system clock, so that when your system is rebooted, it does not get out of sync. hwclock --systohc 8. Repeat on each host that will run a Eucalyptus component. Configure an MTA All hosts running the CLC must run a mail transport agent server (MTA) on port 25. Eucalyptus uses the MTA to deliver or relay email messages to cloud users© email addresses. You can use Sendmail, Exim, post®x, or something simpler. The MTA server does not have to be able to receive incoming mail. Many Linux distributions satisfy this requirement with their default MTA. For details about con®guring your MTA, go to the documentation for your speci®c product. To test your mail relay for localhost, send email to yourself from the terminal using mail. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Dependencies | 36 Installing Eucalyptus Eucalyptus installation packages are available for CentOS 5, CentOS 6, RHEL 5, RHEL 6, Ubuntu 10.04 LTS, and Ubuntu 12.04 LTS. The following sections show installation steps on each supported Linux distribution. Eucalyptus Subscription allows you access to additional software modules. If you are a subscriber, you will receive an entitlement certi®cate and a private key that allow you to download Eucalyptus subscription modules. You will also receive a GPG public key to be used to verify the Eucalyptus software©s integrity. The ®les will come in the form of a platform speci®c package. For HA: If you are installing Eucalyptus HA, pay attention to the extra steps noted in the instructions. Install on CentOS 5 If you plan to install Eucalyptus HA, we recommend that you install each Eucalyptus component on a separate host. For example, if you are installing CLC, Walrus, CC, and SC, you will install each of these components on a separate host. You will also install each secondary component (the secondary CLC, Walrus, CC, and SC) on a separate host. In this case, you will need eight machines. Each additional cluster needs four more machines for its CCs and SCs. This does not account for NCs, which are not redundant. To install Eucalyptus on servers running CentOS 5: 1. Con®gure the Euca2ools package repository on each host that will run a Eucalyptus component or Euca2ools: rpm -Uvh http://downloads.eucalyptus.com/software/euca2ools/2.1/centos/5/x86_64/euca2ools-release-2.1.noarch.rpm 2. Con®gure the Eucalyptus package repository on each host that will run a Eucalyptus component: rpm -Uvh http://downloads.eucalyptus.com/software/eucalyptus/3.1/centos/5/x86_64/eucalyptus-release-3.1.noarch.rpm 3. Con®gure the EPEL package repository on each host that will run a Eucalyptus component or Euca2ools: rpm -Uvh http://downloads.eucalyptus.com/software/eucalyptus/3.1/centos/5/x86_64/epel-release-5.noarch.rpm 4. If you have a Eucalyptus subscription, you will have received a package that grants you access to VMware and SAN components. If you wish to use either of these components, install this package on each host that will run a Eucalyptus component using the following command. Otherwise, skip this step. rpm -Uvh eucalyptus-enterprise-release-3.1*.noarch.rpm 5. If your planned Walrus host runs a Xen kernel, install the kmod-drbd83-xen package on that host. Otherwise, skip this step. yum install kmod-drbd83-xen 6. Install the Eucalyptus cloud controller software on each planned CLC host: yum groupinstall eucalyptus-cloud-controller CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 37 7. Install the Eucalyptus node controller software on each planned NC host. Clouds that use the VMware hypervisor do not have NCs; if you plan to use VMware then skip this step. yum install eucalyptus-nc 8. Install the software for the remaining Eucalyptus components. The following example shows most components being installed on the same host. We recommend using different hosts for each component. yum install eucalyptus-cc eucalyptus-sc eucalyptus-walrus 9. If you have a Eucalyptus subscription and plan to use the VMware hypervisor, install the Eucalyptus VMware broker software on each CC host: yum install eucalyptus-enterprise-vmware-broker 10. If you have a Eucalyptus subscription and plan to use Eucalyptus©s SAN capabilities, install the Eucalyptus SAN adapter software on each SC host: yum install eucalyptus-enterprise-storage-san 11. After you have installed Eucalyptus, test multicast connectivity between each CLC and Walrus, SC, and VMware broker host. a) Run the following receiver command on the CLC: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555 b) Run the following sender command on each Walrus host: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555 c) Repeat the previous step on each SC host and VMware broker host. d) If you are installing an HA environment, repeat these tasks with the second CLC. Your installation is complete. You are now ready to Con®gure Eucalyptus. Install on CentOS 6 If you plan to install Eucalyptus HA, we recommend that you install each Eucalyptus component on a separate host. For example, if you are installing CLC, Walrus, CC, and SC, you will install each of these components on a separate host. You will also install each secondary component (the secondary CLC, Walrus, CC, and SC) on a separate host. In this case, you will need eight machines. Each additional cluster needs four more machines for its CCs and SCs. This does not account for NCs, which are not redundant. To install Eucalyptus on servers running CentOS 6: 1. Con®gure the Eucalyptus package repository on each host that will run a Eucalyptus component: yum install http://downloads.eucalyptus.com/software/eucalyptus/3.1/centos/6/x86_64/eucalyptus-release-3.1.noarch.rpm CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 38 2. Con®gure the Euca2ools package repository on each host that will run a Eucalyptus component or Euca2ools: yum install http://downloads.eucalyptus.com/software/euca2ools/2.1/centos/6/x86_64/euca2ools-release-2.1.noarch.rpm 3. Con®gure the EPEL package repository on each host that will run a Eucalyptus component or Euca2ools: yum install http://downloads.eucalyptus.com/software/eucalyptus/3.1/centos/6/x86_64/epel-release-6.noarch.rpm 4. Con®gure the ELRepo repository on each host that will run Walrus: yum install http://downloads.eucalyptus.com/software/eucalyptus/3.1/centos/6/x86_64/elrepo-release-6.noarch.rpm 5. Tip: If you are a Eucalyptus subscriber, you should have received an rpm package ®le that you will need to install. If you are not a Eucalyptus subscriber, skip this step. Install the Eucalyptus subscription package on each host that will run a Eucalyptus component: yum install eucalyptus-enterprise-release-3.1*.noarch.rpm 6. Install the Eucalyptus cloud controller software on each planned CLC host: yum groupinstall eucalyptus-cloud-controller 7. Note: Clouds that use the VMware hypervisor do not have NCs; if you plan to use VMware then skip this step. a) Install the KVM driver appropriate to your hardware. For systems with Intel processors: modprobe kvm_intel modprobe vhost_net For systems with AMD processors: modprobe kvm_amd modprobe vhost_net b) Install the Eucalyptus node controller software on each planned NC host: yum install eucalyptus-nc 8. Install the software for the remaining Eucalyptus components. The following example shows most components being installed on the same host. We recommend that you use different hosts for each component: yum install eucalyptus-cc eucalyptus-sc eucalyptus-walrus 9. Tip: If you do not have a Eucalyptus subscription and don©t plan to use Eucalyptus©s SAN capabilities, skip this step. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 39 Install the Eucalyptus SAN adapter software on each SC host: yum install eucalyptus-enterprise-storage-san 10. After you have installed Eucalyptus, test multicast connectivity between each CLC and Walrus, SC, and VMware broker host. a) Run the following receiver command on the CLC: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555 b) Run the following sender command on each Walrus host: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555 c) Repeat the previous step on each SC host and VMware broker host d) If you are installing an HA environment, repeat these tasks with the second CLC. Your installation is complete. You are now ready to Con®gure Eucalyptus. Install on RHEL 5 If you plan to install Eucalyptus HA, we recommend that you install each Eucalyptus component on a separate host. For example, if you are installing CLC, Walrus, CC, and SC, you will install each of these components on a separate host. You will also install each secondary component (the secondary CLC, Walrus, CC, and SC) on a separate host. In this case, you will need eight machines. Each additional cluster needs four more machines for its CCs and SCs. This does not account for NCs, which are not redundant. To install Eucalyptus on servers running RHEL 5: 1. Enable the Cluster-Storage repository in Red Hat Network for each planned SC: a) Go to https://rhn.redhat.com/rhn/systems/SystemList.do b) Navigate to the system that will run the SC. c) Click the Alter Channel Subscriptions link. d) Ensure that the RHEL Cluster-Storage checkbox is checked. e) Click Change Subscriptions. 2. Enable the Virtualization repository in Red Hat Network for each planned NC: a) Go to https://rhn.redhat.com/rhn/systems/SystemList.do b) Navigate to the system that will run the NC. c) Click the Alter Channel Subscriptions link. d) Ensure that the RHEL Virtualization checkbox is checked. e) Click Change Subscriptions. 3. On each planned Walrus server, create a ®le in /etc/yum.repos.d called centos-extras.repo with the following content: [centos-extras] name=CentOS 5 - Extras mirrorlist=http://mirrorlist.centos.org/?release=5&arch= $basearch&repo=extras gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 gpgcheck=1 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 40 4. Download the key that CentOS uses to sign their packages: curl http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5 > /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 5. Con®gure the Euca2ools package repository on each host that will run a Eucalyptus component or Euca2ools: rpm -Uvh http://downloads.eucalyptus.com/software/euca2ools/2.1/rhel/5/x86_64/euca2ools-release-2.1.noarch.rpm 6. Con®gure the Eucalyptus package repository on each host that will run a Eucalyptus component: rpm -Uvh http://downloads.eucalyptus.com/software/eucalyptus/3.1/rhel/5/x86_64/eucalyptus-release-3.1.noarch.rpm 7. Con®gure the EPEL package repository on each host that will run a Eucalyptus component or Euca2ools: rpm -Uvh http://downloads.eucalyptus.com/software/eucalyptus/3.1/rhel/5/x86_64/epel-release-5.noarch.rpm 8. If you have a Eucalyptus subscription, you will have received a package that grants you access to VMware and SAN components. If you wish to use either of these components, install this package on each host that will run a Eucalyptus component using the following command. Otherwise, skip this step. rpm -Uvh yum install eucalyptus-enterprise-release-3.1*.noarch.rpm 9. If your planned Walrus host runs a Xen kernel, install the kmod-drbd83-xen package on that host. Otherwise, skip this step. yum install kmod-drbd83-xen 10. Install the Eucalyptus cloud controller software on each planned CLC host: yum groupinstall eucalyptus-cloud-controller 11. Install the Eucalyptus node controller software on each planned NC host. Clouds that use the VMware hypervisor do not have NCs; if you plan to use VMware then skip this step. yum install eucalyptus-nc 12. Install the software for the remaining Eucalyptus components. The following example shows most components being installed on the same host. We recommend using different hosts for each component. yum install eucalyptus-cc eucalyptus-sc eucalyptus-walrus 13. If you have a Eucalyptus subscription and plan to use the VMware hypervisor, install the Eucalyptus VMware broker software on each CC host: yum install eucalyptus-enterprise-vmware-broker CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 41 14. If you have a Eucalyptus subscription and plan to use Eucalyptus©s SAN capabilities, install the Eucalyptus SAN adapter software on each SC host: yum install eucalyptus-enterprise-storage-san 15. After you have installed Eucalyptus, test multicast connectivity between each CLC and Walrus, SC, and VMware broker host. a) Run the following receiver command on the CLC: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555 b) Run the following sender command on each Walrus host: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555 c) Repeat the previous step on each SC host and VMware broker host. d) If you are installing an HA environment, repeat these tasks with the second CLC. Your installation is complete. You are now ready to Con®gure Eucalyptus. Install on RHEL 6 If you plan to install Eucalyptus HA, we recommend that you install each Eucalyptus component on a separate host. For example, if you are installing CLC, Walrus, CC, and SC, you will install each of these components on a separate host. You will also install each secondary component (the secondary CLC, Walrus, CC, and SC) on a separate host. In this case, you will need eight machines. Each additional cluster needs four more machines for its CCs and SCs. This does not account for NCs, which are not redundant. To install Eucalyptus on servers running RHEL 6: 1. Con®gure the Eucalyptus package repository on each host that will run a Eucalyptus component: yum install http://downloads.eucalyptus.com/software/eucalyptus/3.1/rhel/6/x86_64/eucalyptus-release-3.1.noarch.rpm 2. Con®gure the Euca2ools package repository on each host that will run a Eucalyptus component or Euca2ools: yum install http://downloads.eucalyptus.com/software/euca2ools/2.1/rhel/6/x86_64/euca2ools-release-2.1.noarch.rpm 3. Con®gure the EPEL package repository on each host that will run a Eucalyptus component or Euca2ools: yum install http://downloads.eucalyptus.com/software/eucalyptus/3.1/rhel/6/x86_64/epel-release-6.noarch.rpm 4. Con®gure the ELRepo repository on each host that will run Walrus: yum install http://downloads.eucalyptus.com/software/eucalyptus/3.1/rhel/6/x86_64/elrepo-release-6.noarch.rpm CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 42 5. Tip: If you are a Eucalyptus subscriber, you should have received an rpm package ®le that you will need to install. If you are not a Eucalyptus subscriber, skip this step. Install the Eucalyptus subscription package on each host that will run a Eucalyptus component: yum install eucalyptus-enterprise-release-3.1*.noarch.rpm 6. Install the Eucalyptus cloud controller software on each planned CLC host: yum groupinstall eucalyptus-cloud-controller 7. Note: Clouds that use the VMware hypervisor do not have NCs; if you plan to use VMware then skip this step. a) Install the KVM driver appropriate to your hardware. For systems with Intel processors: modprobe kvm_intel modprobe vhost_net For systems with AMD processors: modprobe kvm_amd modprobe vhost_net b) Restart libvirtd by running service libvirtd restart c) Install the Eucalyptus node controller software on each planned NC host: yum install eucalyptus-nc 8. Install the software for the remaining Eucalyptus components. The following example shows most components being installed on the same host. We recommend that you use different hosts for each component: yum install eucalyptus-cc eucalyptus-sc eucalyptus-walrus 9. Tip: If you do not have a Eucalyptus subscription and don©t plan to use Eucalyptus©s SAN capabilities, skip this step. Install the Eucalyptus SAN adapter software on each SC host: yum install eucalyptus-enterprise-storage-san 10. After you have installed Eucalyptus, test multicast connectivity between each CLC and Walrus, SC, and VMware broker host. a) Run the following receiver command on the CLC: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555 b) Run the following sender command on each Walrus host: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 43 c) Repeat the previous step on each SC host and VMware broker host d) If you are installing an HA environment, repeat these tasks with the second CLC. Your installation is complete. You are now ready to Con®gure Eucalyptus. Install on Ubuntu 10.04 LTS If you plan to install Eucalyptus HA, we recommend that you install each Eucalyptus component on a separate host. For example, if you are installing CLC, Walrus, CC, and SC, you will install each of these components on a separate host. You will also install each secondary component (the secondary CLC, Walrus, CC, and SC) on a separate host. In this case, you will need eight machines. Each additional cluster needs four more machines for its CCs and SCs. This does not account for NCs, which are not redundant. To install Eucalyptus on servers running Ubuntu 10.04 LTS: 1. Tip: If you are a Eucalyptus subscriber, you should have received a deb package ®le that you will need to install. If you are not a Eucalyptus subscriber, skip this step. On all servers, copy over your deb package ®le and run the following command: dpkg -i eucalyptus-enterprise-release_3.1-*lucid_all.deb 2. Download the Eucalyptus release key from http://www.eucalyptus.com/eucalyptus-cloud/security/keys 3. Add the public key to the list of trusted keys. apt-key add c1240596-eucalyptus-release-key.pub 4. Create a ®le in /etc/apt/sources.list.d called eucalyptus.list with the following content: deb http://downloads.eucalyptus.com/software/eucalyptus/3.1/ubuntu lucid main 5. On all machines that will run either Eucalyptus or Euca2ools, create a ®le in /etc/apt/sources.list.d called euca2ools.list with the following content: deb http://downloads.eucalyptus.com/software/euca2ools/2.1/ubuntu lucid main 6. Enter the following command on all machines: apt-get update 7. Install Eucalyptus packages and dependencies. The following example shows a package install all on the same server. You can install each component on a different server. apt-get install eucalyptus-cloud eucalyptus-cc eucalyptus-sc eucalyptus-walrus For HA: If you are deploying HA, you must install these packages on pairs of systems. For instance, ªeucalyptus-cloudº is installed on the primary CLC and the secondary CLC. 8. On each planned NC server, install the NC package: apt-get install eucalyptus-nc CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 44 Important: If you are using VMware, you can skip this step. Eucalyptus software is not installed on these machines. They are running VMware. 9. Important: This step is only required the ®rst time libvirt is installed on a system. The ®rst time libvirt is installed on a system, you must initialize libvirt before it will function properly. To initialize libvirt, run the following command: virsh capabilities 10. If you are a Eucalyptus subscriber and plan to use VMware, install the subscription-only VMware Broker package on each CC server: apt-get install eucalyptus-enterprise-vmware-broker 11. If you are a Eucalyptus subscriber and plan to use SAN support, install the subscription-only SAN package on each SC. Otherwise, skip this step. apt-get install eucalyptus-enterprise-storage-san 12. After you have installed Eucalyptus, test multicast connectivity between the CLC and Walrus, SC, and the VMware Broker. a) Run the following receiver command on the CLC: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555 b) Run the following sender command on Walrus: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555 c) Repeat the previous step on the SC and then on the VMware Broker. For HA: If you are installing an HA environment, repeat these tasks on secondary CLC, Walrus, SC, and VMware Broker. Your installation is complete. You are now ready to Con®gure Eucalyptus. Install on Ubuntu 12.04 LTS If you plan to install Eucalyptus HA, we recommend that you install each Eucalyptus component on a separate host. For example, if you are installing CLC, Walrus, CC, and SC, you will install each of these components on a separate host. You will also install each secondary component (the secondary CLC, Walrus, CC, and SC) on a separate host. In this case, you will need eight machines. Each additional cluster needs four more machines for its CCs and SCs. This does not account for NCs, which are not redundant. To install Eucalyptus on servers running Ubuntu 12.04 LTS: 1. Tip: If you are a Eucalyptus subscriber, you should have received a deb package ®le that you will need to install. If you are not a Eucalyptus subscriber, skip this step. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 45 On all servers, copy over your deb package ®le and run the following command: dpkg -i eucalyptus-enterprise-release_3.1-*precise_all.deb 2. Download the Eucalyptus release key from http://www.eucalyptus.com/eucalyptus-cloud/security/keys 3. Add the public key to the list of trusted keys. apt-key add c1240596-eucalyptus-release-key.pub 4. Create a ®le in /etc/apt/sources.list.d called eucalyptus.list with the following content: deb http://downloads.eucalyptus.com/software/eucalyptus/3.1/ubuntu precise main 5. On all machines that will run either Eucalyptus or Euca2ools, create a ®le in /etc/apt/sources.list.d called euca2ools.list with the following content: deb http://downloads.eucalyptus.com/software/euca2ools/2.1/ubuntu precise main 6. Enter the following command on all machines: apt-get update 7. Install Eucalyptus packages and dependencies. The following example shows a package install all on the same server. You can install each component on a different server. apt-get install eucalyptus-cloud eucalyptus-cc eucalyptus-sc eucalyptus-walrus For HA: If you are deploying HA, you must install these packages on pairs of systems. For instance, ªeucalyptus-cloudº is installed on the primary CLC and the secondary CLC. 8. On each planned NC server, install the NC package: apt-get install eucalyptus-nc Important: If you are using VMware, you can skip this step. Eucalyptus software is not installed on these machines. They are running VMware. 9. If you are a Eucalyptus subscriber and plan to use VMware, install the subscription-only VMware Broker package on each CC server: apt-get install eucalyptus-enterprise-vmware-broker 10. If you are a Eucalyptus subscriber and plan to use SAN support, install the subscription-only SAN package on each SC. Otherwise, skip this step. apt-get install eucalyptus-enterprise-storage-san 11. After you have installed Eucalyptus, test multicast connectivity between the CLC and Walrus, SC, and the VMware Broker. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 46 a) Run the following receiver command on the CLC: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555 b) Run the following sender command on Walrus: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555 c) Repeat the previous step on the SC and then on the VMware Broker. For HA: If you are installing an HA environment, repeat these tasks on secondary CLC, Walrus, SC, and VMware Broker. Your installation is complete. You are now ready to Con®gure Eucalyptus. Installing Eucalyptus Nightlies Important: Eucalyptus nightly packages are latest Eucalyptus builds. They should be considered unstable/"bleeding edge" software and should not be installed in production. In addition, upgrades from nightlies to released software are not supported. Installing Eucalyptus Nightly Packages on CentOS 5 To install Eucalyptus nightly builds on servers running CentOS 5: 1. On all servers, run the following commands: yum --nogpg install -y http://downloads.eucalyptus.com/ software/eucalyptus/nightly/3.1/centos/5/x86_64/eucalyptus-release-nightly-3.1.noarch.rpm 2. On all systems that will run either Eucalyptus or Euca2ools, run the following commands: yum install -y http://downloads.eucalyptus.com/software/ euca2ools/nightly/2.1/centos/5/x86_64/euca2ools-release-2.1.noarch.rpm 3. Con®gure the EPEL repository: a) Go to http://fedoraproject.org/wiki/EPEL b) Navigate to How can I use these extra packages? and select the newest version for EPEL5. c) Click the package link to download the RPM. d) Install the resultant RPM package with the following command, as root: rpm -Uvh epel-release-X-Y.noarch.rpm 4. On all servers, enter: yum update CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 47 5. If your planned Walrus server is running Xen (possible, but not recommended), install kmod-drbd83-xen package. Otherwise, skip this step. yum install kmod-drbd83-xen 6. Install Eucalyptus packages. The following example shows most components being installed all on the same server. You can use different servers for each component. yum install eucalyptus-cloud eucalyptus-cc eucalyptus-sc eucalyptus-walrus For HA: If you are deploying HA, you must install these packages on pairs of systems. For instance, ªeucalyptus-cloudº is installed on the primary CLC and the secondary CLC. 7. On each planned NC server, install the NC package: yum install eucalyptus-nc Important: If you are using VMware, you can skip this step. Eucalyptus software is not installed on these machines. They are running VMware. 8. After you have installed Eucalyptus, test multicast connectivity between the CLC and Walrus, SC, and the VMware Broker. a) Run the following receiver command on the CLC: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555 b) Run the following sender command on Walrus: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555 c) Repeat the previous step on the SC and then on the VMware Broker. For HA: If you are installing an HA environment, repeat these tasks on secondary CLC, Walrus, SC, and VMware Broker. Your installation is complete. You are now ready to Con®gure Eucalyptus. Installing Eucalyptus Nightly Packages on CentOS 6 To install Eucalyptus nightly builds on servers running CentOS 6 1. On all servers, run the following commands: yum --nogpg install -y http://downloads.eucalyptus.com/ software/eucalyptus/nightly/3.1/centos/6/x86_64/eucalyptus-release-nightly-3.1.noarch.rpm 2. On all systems that will run either Eucalyptus or Euca2ools, run the following commands: yum install -y http://downloads.eucalyptus.com/software/ euca2ools/nightly/2.1/centos/6/x86_64/euca2ools-release-2.1.noarch.rpm CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 48 3. Install the ELRepo repository on the machine that will run Walrus: yum --nogpg install http://downloads.eucalyptus.com/ software/eucalyptus/nightly/3.1/centos/6/x86_64/elrepo-release-6.noarch.rpm 4. Con®gure the EPEL repository: a) Go to http://fedoraproject.org/wiki/EPEL b) Navigate to How can I use these extra packages? and select the newest version for EPEL6. c) Click the package link to download the RPM. d) Install the resultant RPM package with the following command, as root: rpm -Uvh epel-release-X-Y.noarch.rpm 5. On all servers, enter: yum update 6. Install Eucalyptus packages. The following example shows most components being installed all on the same server. You can use different servers for each component. yum groupinstall eucalyptus-cloud-controller yum install eucalyptus-cc eucalyptus-sc eucalyptus-walrus For HA: If you are deploying HA, you must install these packages on pairs of systems. For instance, ªeucalyptus-cloudº is installed on the primary CLC and the secondary CLC. 7. On each planned NC server, install the NC package: yum install eucalyptus-nc Important: If you are using VMware, you can skip this step. Eucalyptus software is not installed on these machines. They are running VMware. Your installation is complete. You are now ready to Con®gure Eucalyptus. Installing Eucalyptus Nightly Packages on RHEL 5 To install Eucalyptus nightly builds on servers running RHEL 5 1. Run the following command on all servers: wget http://downloads.eucalyptus.com/software/eucalyptus/ nightly/3.1/rhel/5/x86_64/eucalyptus-release-nightly-3.1.noarch.rpm rpm -Uvh eucalyptus-release-3.1.noarch.rpm 2. On all systems that will run either Eucalyptus or Euca2ools, run the following command: wget http://downloads.eucalyptus.com/software/euca2ools/ nightly/2.1/rhel/5/x86_64/euca2ools-release-2.1.noarch.rpm rpm -Uvh euca2ools-release-2.1.noarch.rpm 3. Enable the Cluster-Storage repository in Red Hat Network for each SC: CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 49 a) Go to https://rhn.redhat.com b) Navigate to the system that will run the SC. c) Click Alter Channel Subscriptions. d) Make sure the RHEL Cluster Storage checkbox is checked. e) Click Change Subscriptions. 4. Enable the Virtualization repository in Red Hat Network for each NC: a) On http://rhn.redhat.com, navigate to the system that will run the NC. b) Click Alter Channel Subscriptions. c) Make sure the RHEL Virtualization checkbox is checked. d) Click Change Subscriptions. 5. On the machine(s) that will run Walrus, create a ®le in /etc/yum.repos.d called centos-extras.repo with the following content: [centos-extras] name=CentOS 5 - Extras mirrorlist=http://mirrorlist.centos.org/?release=5&arch=$basearch&repo=extras gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 gpgcheck=1 6. Download the key that CentOS uses to sign their packages: wget http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5 7. Copy the resulting ®le to /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5: mv RPM-GPG-KEY-CentOS-5 /etc/pki/rpm-gpg 8. Con®gure the EPEL repository: a) Go to http://fedoraproject.org/wiki/EPEL b) Navigate to How can I use these extra packages? and select the newest version for EPEL5. c) Click the package link to download the RPM. d) Install the resultant RPM package with the following command, as root: rpm -Uvh epel-release-X-Y.noarch.rpm 9. On all servers, enter: yum update 10. If your planned Walrus server is running Xen (possible, but not recommended), install kmod-drbd83-xen package. Otherwise, skip this step. yum install kmod-drbd83-xen 11. Install Eucalyptus packages. The following example shows most components being installed all on the same server. You can use different servers for each component. yum install eucalyptus-cloud eucalyptus-cc eucalyptus-sc eucalyptus-walrus For HA: If you are deploying HA, you must install these packages on pairs of systems. For instance, ªeucalyptus-cloudº is installed on the primary CLC and the secondary CLC. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 50 12. On each planned NC server, install the NC package: yum install eucalyptus-nc Important: If you are using VMware, you can skip this step. Eucalyptus software is not installed on these machines. They are running VMware. 13. After you have installed Eucalyptus, test multicast connectivity between the CLC and Walrus, SC, and the VMware Broker. a) Run the following receiver command on the CLC: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555 b) Run the following sender command on Walrus: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555 c) Repeat the previous step on the SC and then on the VMware Broker. For HA: If you are installing an HA environment, repeat these tasks on secondary CLC, Walrus, SC, and VMware Broker. Your installation is complete. You are now ready to Con®gure Eucalyptus. Installing Eucalyptus Nightly Packages on RHEL 6 To install Eucalyptus nightly builds on servers running RHEL 6 1. Run the following command on all servers: yum --nogpg install -y http://downloads.eucalyptus.com/software/eucalyptus/ nightly/3.1/rhel/6/x86_64/eucalyptus-release-nightly-3.1.noarch.rpm 2. On all systems that will run either Eucalyptus or Euca2ools, run the following command: yum install -y http://downloads.eucalyptus.com/software/ nightly/euca2ools/2.1/rhel/6/x86_64/euca2ools-release-2.1.noarch.rpm 3. Install the ELRepo repository on the machine that will run Walrus: yum --nogpg install http://downloads.eucalyptus.com/software/eucalyptus/ nightly/3.1/rhel/6/x86_64/elrepo-release-6.noarch.rpm 4. Con®gure the EPEL repository: a) Go to http://fedoraproject.org/wiki/EPEL b) Navigate to How can I use these extra packages? and select the newest version for EPEL6. c) Click the package link to download the RPM. d) Install the resultant RPM package with the following command, as root: rpm -Uvh epel-release-X-Y.noarch.rpm CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 51 5. On all servers, enter: yum update 6. Install Eucalyptus packages. The following example shows most components being installed all on the same server. You can use different servers for each component. yum groupinstall eucalyptus-cloud-controller yum install eucalyptus-cc eucalyptus-sc eucalyptus-walrus For HA: If you are deploying HA, you must install these packages on pairs of systems. For instance, ªeucalyptus-cloudº is installed on the primary CLC and the secondary CLC. 7. On each planned NC server, install the NC package: yum install eucalyptus-nc Important: If you are using VMware, you can skip this step. Eucalyptus software is not installed on these machines. They are running VMware. Your installation is complete. You are now ready to Con®gure Eucalyptus. Install Eucalyptus Nightly Packages on Ubuntu 10.04 LTS If you plan to install Eucalyptus HA, we recommend that you install each Eucalyptus component on a separate host. For example, if you are installing CLC, Walrus, CC, and SC, you will install each of these components on a separate host. You will also install each secondary component (the secondary CLC, Walrus, CC, and SC) on a separate host. In this case, you will need eight machines. Each additional cluster needs four more machines for its CCs and SCs. This does not account for NCs, which are not redundant. To install Eucalyptus nightlies on servers running Ubuntu 10.04 LTS: 1. Create a ®le in /etc/apt/sources.list.d called eucalyptus.list with the following content: deb http://downloads.eucalyptus.com/software/eucalyptus/nightly/3.1/ubuntu lucid main 2. Download the Eucalyptus nightly release key from: http://www.eucalyptus.com/eucalyptus-cloud/security/keys 3. Add the public key to the list of trusted keys. apt-key add 9d7b073c-eucalyptus-nightly-release-key.pub 4. On all machines that will run either Eucalyptus or Euca2ools, create a ®le in /etc/apt/sources.list.d called euca2ools.list with the following content: deb http://downloads.eucalyptus.com/software/euca2ools/nightly/2.1/ubuntu lucid main 5. Enter the following command on all machines: apt-get update CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 52 6. Install Eucalyptus packages and dependencies. The following example shows a package install all on the same server. You can install each component on a different server. apt-get install eucalyptus-cloud eucalyptus-cc eucalyptus-sc eucalyptus-walrus For HA: If you are deploying HA, you must install these packages on pairs of systems. For instance, ªeucalyptus-cloudº is installed on the primary CLC and the secondary CLC. 7. On each planned NC server, install the NC package: apt-get install eucalyptus-nc Important: If you are using VMware, you can skip this step. Eucalyptus software is not installed on these machines. They are running VMware. 8. Important: This step is only required the ®rst time libvirt is installed on a system. The ®rst time libvirt is installed on a system, you must initialize libvirt before it will function properly. To initialize libvirt, run the following command: virsh capabilities 9. After you have installed Eucalyptus, test multicast connectivity between the CLC and Walrus, SC, and the VMware Broker. a) Run the following receiver command on the CLC: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555 b) Run the following sender command on Walrus: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555 c) Repeat the previous step on the SC and then on the VMware Broker. For HA: If you are installing an HA environment, repeat these tasks on secondary CLC, Walrus, SC, and VMware Broker. Your installation is complete. You are now ready to Con®gure Eucalyptus. Install Eucalyptus Nightly Packages on Ubuntu 12.04 LTS If you plan to install Eucalyptus HA, we recommend that you install each Eucalyptus component on a separate host. For example, if you are installing CLC, Walrus, CC, and SC, you will install each of these components on a separate host. You will also install each secondary component (the secondary CLC, Walrus, CC, and SC) on a separate host. In this case, you will need eight machines. Each additional cluster needs four more machines for its CCs and SCs. This does not account for NCs, which are not redundant. To install Eucalyptus nightlies on servers running Ubuntu 12.04 LTS: CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 53 1. Create a ®le in /etc/apt/sources.list.d called eucalyptus.list with the following content: deb http://downloads.eucalyptus.com/software/eucalyptus/nightly/3.1/ubuntu precise main 2. Download the Eucalyptus nightly release key from: http://www.eucalyptus.com/eucalyptus-cloud/security/keys 3. Add the public key to the list of trusted keys. apt-key add 9d7b073c-eucalyptus-nightly-release-key.pub 4. On all machines that will run either Eucalyptus or Euca2ools, create a ®le in /etc/apt/sources.list.d called euca2ools.list with the following content: deb http://downloads.eucalyptus.com/software/euca2ools/nightly/2.1/ubuntu precise main 5. Enter the following command on all machines: apt-get update 6. Install Eucalyptus packages and dependencies. The following example shows a package install all on the same server. You can install each component on a different server. apt-get install eucalyptus-cloud eucalyptus-cc eucalyptus-sc eucalyptus-walrus For HA: If you are deploying HA, you must install these packages on pairs of systems. For instance, ªeucalyptus-cloudº is installed on the primary CLC and the secondary CLC. 7. On each planned NC server, install the NC package: apt-get install eucalyptus-nc Important: If you are using VMware, you can skip this step. Eucalyptus software is not installed on these machines. They are running VMware. 8. After you have installed Eucalyptus, test multicast connectivity between the CLC and Walrus, SC, and the VMware Broker. a) Run the following receiver command on the CLC: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555 b) Run the following sender command on Walrus: java -classpath /usr/share/eucalyptus/jgroups-2.11.1.Final.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555 c) Repeat the previous step on the SC and then on the VMware Broker. For HA: If you are installing an HA environment, repeat these tasks on secondary CLC, Walrus, SC, and VMware Broker. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 54 Your installation is complete. You are now ready to Con®gure Eucalyptus. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Installing Eucalyptus | 55 Configuring Eucalyptus This section describes the parameters that need to be set in order to launch Eucalyptus for the ®rst time. The ®rst launch of Eucalyptus is different than a restart of a previously running Eucalyptus deployment in that it sets up the security mechanisms that will be used by the installation to ensure system integrity. Eucalyptus con®guration is stored in a text ®le, /etc/eucalyptus/eucalyptus.conf, that contains key-value pairs specifying various con®guration parameters. Eucalyptus reads this ®le when it launches and when various forms of reset commands are sent it the Eucalyptus components. Important: Perform the following tasks after you install Eucalyptus software, but before you start the Eucalyptus services. Configure Network Modes This section provides detailed con®guration instructions for each of the four Eucalyptus networking modes. Eucalyptus requires network connectivity between its clients (end-users) and the cloud components (CC, CLC, and Walrus). In Managed and Managed (No VLAN) modes, traf®c to instances pass through the CC. So, in these two modes clients must be able to connect to the CC. In System and Static modes, clients need to connect directly to the NC. The CC does not act as a router in these two modes. The /etc/eucalyptus/eucalyptus.conf ®le contains all network-related options in in the ªNetworking Con®gurationº section. These options use the pre®x VNET_. The most commonly used VNET options are described in the following table. The set of networking settings that apply to a cloud varies based on its networking mode. Each setting in this section lists the modes in which it applies. Unless otherwise noted, all of these settings apply only to CCs. The /etc/eucalyptus/eucalyptus.conf ®le contains all network-related options in in the Networking Con®guration section. These options use the pre®x VNET_. The most commonly used VNET options are described in the following table. ModesDescriptionOption AllThe networking mode in which to run. The same mode must be speci®ed on all CCs and NCs in the entire cloud. Valid values: STATIC, SYSTEM, MANAGED, MANAGED-NOVLAN, VNET_MODE Default: SYSTEM StaticThe name of the network interface that is on the same network as the NCs. In Managed and Managed (No VLAN) modes this must be a VNET_PRIVINTERFACE Managedbridge for instances in different clusters but in the same security group to be able to reach one another with their private addresses. Default: eth0 Managed (No VLAN) ManagedOn a CC, this is the name of the network interface that is connected to the ªpublicº network. On an NC, this is the name of the network interface that is connected to the same network as the CC. Depending on the hypervisor©s VNET_PUBINTERFACE con®guration this may be a bridge or a physical interface that is attached to the bridge. Default: eth0 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Eucalyptus | 56 ModesDescriptionOption StaticOn an NC, this is the name of the bridge interface to which instances© network interfaces should attach. A physical interface that can reach VNET_BRIDGE Systemthe CC must be attached to this bridge. Common settings include xenbr0 for older Xen versions, eth0 for newer Xen versions, and br0 for KVM. Managed (No VLAN) StaticA map of MAC addresses to IP addresses that Eucalyptus should allocate to instances when running in Static mode. Separate MAC addresses and IP addresses with = characters. Separate pairs with spaces. Example: VNET_MACMAP="00:01:02:03:04:05=192.168.1.1 A1:A2:A3:A4:A5:A6=192.168.1.2" VNET_MACMAP ManagedA space-separated list of individual and/or hyphenated ranges of public IP addresses to assign to instances. If this is unde®ned then instances will receive only private IP addresses. For example: VNET_PUBLICIPS="173.205.188.140-173.205.188.254" VNET_PUBLICIPS Managed (No-VLAN) StaticThe address and network mask of the network the cloud should use for instances© private IP addresses. VNET_SUBNET, VNET_NETMASK Managed Managed (No VLAN) ManagedEucalyptus assigns a distinct subnet of private IP addresses to each security group. This setting dictates how many addresses each of these VNET_ADDRSPERNET , Managed (No VLAN) subnets should contain. Specify a power of 2 between 16 and 2048. This is directly related, though not equal, to the number of instances that may reside in each security group. StaticThe address of the DNS server to supply to instances in DHCP responses. VNET_DNS Managed Managed (No VLAN) StaticThe network broadcast and default gateway to supply to instances in DHCP responses. VNET_BROADCAST, VNET_ROUTER ManagedBy default the CC automatically determines which IP address to use when setting up tunnels to other CCs. Set this to the IP address that other CCs can use to reach this CC if tunneling does not work. VNET_LOCALIP Managed (No-VLAN) StaticThe ISC DHCP executable to use. This is set to a distro-dependent value by packaging. The internal default is /usr/sbin/dhcpd3. VNET_DHCPDAEMON Managed Managed (No VLAN) StaticThe user the DHCP daemon runs as on your distribution. For CentOS 5, RHEL5, and RHEL 6 this is typically root. In Ubuntu 10.04 LTS, this is typically dhcpd. Default: dhcpd VNET_DHCPUSER Managed Managed (No VLAN) CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Eucalyptus | 57 Managed Mode In Managed mode, Eucalyptus manages the local network of VM instances and provides all networking features Eucalyptus currently supports, including VM network isolation, security groups, elastic IPs, and metadata service. Con®gure each CC to use an Ethernet device that lies within the same broadcast domain as all of its NCs. Important: In Managed mode, each security group requires a separate subnet and a separate VLAN that Eucalyptus controls and maintains. So the underlying physical network must be ªVLAN clean.º For more information about VLAN clean, see Prepare VLAN. To con®gure for Managed mode: CLC Configuration No network con®guration required. CC Configuration Important: You must set VNET_PUBLICIPS identically on all CCs in a multi-cluster con®guration. 1. Log in to the CC and open the /etc/eucalyptus/eucalyptus.conf ®le. 2. Go to the Network Con®guration section, uncomment and set the following: VNET_MODE="MANAGED" VNET_SUBNET="" VNET_NETMASK="" VNET_DNS="º VNET_ADDRSPERNET="<# of simultaneous instances per security group>" VNET_PUBLICIPS="" VNET_LOCALIP="" VNET_DHCPDAEMON="" VNET_DHCPUSER="" 3. If your NCs are not reachable from end-users directly and the CC has two (or more) Ethernet devices of which one connects to the client/public network and one connects to the NC network, or the single Ethernet device that the CC uses to connect to both clients and NCs is NOT `eth0', then you must also uncomment and set: VNET_PRIVINTERFACE="" VNET_PUBINTERFACE="" 4. Save the ®le. 5. Repeat on each CC in your system. Important: Each CC must have the same con®guration with the exception of the VNET_LOCALIP value, which should be machine-speci®c. NC Configuration 1. Log into an NC machine and open the /etc/eucalyptus/eucalyptus.conf ®le. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Eucalyptus | 58 2. Go to the Network Con®guration section, uncomment and set the following: VNET_MODE="MANAGED" VNET_PUBINTERFACE="" 3. Save the ®le. 4. Repeat on each NC. Managed (No-VLAN) Mode In Managed (No-VLAN) mode, Eucalyptus does not use VLANs to isolate the network bridges attached to VMs from each other. Con®gure each CC to use an Ethernet device that lies within the same broadcast domain as all of its NCs. To con®gure for Managed (No VLAN) mode: CLC Configuration No network con®guration required. CC Configuration Important: You must set VNET_PUBLICIPS identically on all CCs in a multi-cluster con®guration. 1. Log in to the CC and open the /etc/eucalyptus/eucalyptus.conf ®le. 2. Go to the Network Con®guration section, uncomment and set the following: VNET_MODE="MANAGED-NOVLAN" VNET_SUBNET="" VNET_NETMASK="" VNET_DNS="º VNET_ADDRSPERNET="<# of simultaneous instances per security group>" VNET_PUBLICIPS="" VNET_LOCALIP="" VNET_DHCPDAEMON="" VNET_DHCPUSER=©" 3. If your NCs are not reachable from end-users directly and the CC has two (or more) Ethernet devices of which one connects to the client/public network and one connects to the NC network, or the single Ethernet device that the CC uses to connect to both clients and NCs is NOT `eth0', then you must also uncomment and set: VNET_PRIVINTERFACE="" VNET_PUBINTERFACE="" 4. Save the ®le. 5. Repeat on each CC in your system. Important: Each CC must have the same con®guration with the exception of the VNET_LOCALIP value, which should be machine-speci®c. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Eucalyptus | 59 NC Configuration 1. Log into an NC machine and open the /etc/eucalyptus/eucalyptus.conf ®le. 2. Go to the Network Con®guration section, uncomment and set the following: VNET_MODE="MANAGED-NOVLAN" VNET_BRIDGE="" 3. Save the ®le. 4. Repeat on each NC. System Mode In System mode, Eucalyptus mostly stays out of the way in terms of VM networking, relying on your local DHCP service to con®gure VM networks. The NC has to specify a bridge, and that it is the bridge that is connected to an Ethernet network that has a reachable DHCP server running elsewhere that is con®gured to hand out IP addresses dynamically. To con®gure for System mode: CLC Configuration No network con®guration required. CC Configuration 1. Log in to the CC and open the /etc/eucalyptus/eucalyptus.conf ®le. 2. Go to the Network Con®guration section, uncomment and set the following: VNET_MODE="SYSTEM" 3. Save the ®le. 4. Repeat on each CC in your system. NC Configuration 1. Log into an NC machine and open the /etc/eucalyptus/eucalyptus.conf ®le. 2. Go to the Network Con®guration section, uncomment and set the following: VNET_MODE="SYSTEM" VNET_BRIDGE="" 3. Save the ®le. 4. Repeat on each NC. Static Mode Static mode requires you to specify the network con®guration each VM should receive from the Eucalyptus DHCP server running on the same physical server as the CC component. Con®gure each CC to use an Ethernet device that lies within the same broadcast domain as all of its NCs. To con®gure for Static mode: CLC Configuration No network con®guration required. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Eucalyptus | 60 CC Configuration 1. Log in to the CC and open the /etc/eucalyptus/eucalyptus.conf ®le. 2. Go to the Network Con®guration section, uncomment and set the following: VNET_MODE="STATIC" VNET_SUBNET="" VNET_NETMASK="" VNET_BROADCAST="" VNET_ROUTER="" VNET_DNS="" VNET_MACMAP="" VNET_PRIVINTERFACE="" VNET_DHCPDAEMON="" VNET_DHCPUSER="" 3. Save the ®le. 4. Repeat on each CC in your system. NC Configuration 1. Log into an NC machine and open the /etc/eucalyptus/eucalyptus.conf ®le. 2. Go to the Network Con®guration section, uncomment and set the following: VNET_MODE="STATIC" VNET_BRIDGE="" 3. Save the ®le. 4. Repeat on each NC. Configure Hypervisors Eucalyptus interacts with both Xen and KVM hypervisors through libvirt. This section details steps to con®guring these hypervisors. Important: Make sure that you enable hardware virtualization before you start these steps. CentOS 5 The default settings that ship with CentOS 5.6 are generally appropriate. However, you must enable xend-http-server and restart the daemon to ensure the hypervisor is correctly con®gured. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Eucalyptus | 61 To make sure the Xen daemon is set up correctly: 1. Log in to an NC and open the /etc/xen/xend-config.sxp ®le. 2. Verify these Eucalyptus-recommended settings: (xend-http-server yes) (xend-unix-server yes) (xend-unix-path /var/lib/xend/xend-socket) (xend-address localhost) (network-script network-bridge) (vif-script vif-bridge) (dom0-min-mem 196) (dom0-cpus 0) (vncpasswd ©©) 3. Restart the network: service network restart 4. If any changes are necessary, save the ®le and restart xend by running service xend restart 5. If you are running Xen on your NC, the euca-get-console-output command will not work, unless you do the following: a) On the NC, open the /etc/sysconfig/xend. b) Uncomment the following line: XENCONSOLED_LOG_GUESTS=yes c) Save the ®le and restart xend. 6. Open the /etc/libvirt/libvirtd.conf ®le. 7. Uncomment the following lines and change the value for unix_sock_group from libvirt to eucalyptus: unix_sock_group = "eucalyptus" unix_sock_ro_perms = "0777" unix_sock_rw_perms = "0770" 8. Save the ®le and restart the libvirtd daemon. 9. Use the virsh list command to con®rm that the eucalyptus user can communicate with libvirt. su -c "virsh list" eucalyptus Id Name State -------------------------------- 0 Domain-0 The command returns a Domain-0 for user eucalyptus. If the command doesn't succeed, double-check the steps and setting. 10. Use the virsh command to switch off virbr0. virsh net-destroy virbr0 virsh net-undefine virbr0 11. Repeat for each NC server in your system. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Eucalyptus | 62 CentOS 6 No additional con®guration is required for KVM or libvirt on CentOS 6. RHEL 5 To make sure the Xen daemon is set up correctly: 1. Log in to an NC and open the /etc/xen/xend-config.sxp ®le. 2. Verify these Eucalyptus-recommended settings: (xend-http-server yes) (xend-unix-server yes) (xend-unix-path /var/lib/xend/xend-socket) (xend-address localhost) (network-script network-bridge) (vif-script vif-bridge) (dom0-min-mem 196) (dom0-cpus 0) (vncpasswd ©©) 3. Restart the network: service network restart 4. If any changes are necessary, save the ®le and restart xend by running service xend restart 5. Open the /etc/libvirt/libvirtd.conf ®le. 6. Uncomment the following lines and change the value for unix_sock_group from libvirt to eucalyptus: unix_sock_group = "eucalyptus" unix_sock_ro_perms = "0777" unix_sock_rw_perms = "0770" 7. Save the ®le and restart the libvirtd daemon. 8. Use the virsh list command to con®rm that the eucalyptus user can communicate with libvirt. su -c "virsh list" eucalyptus Id Name State -------------------------------- 0 Domain-0 The command returns a Domain-0 for user eucalyptus. If the command doesn't succeed, double-check the steps and setting. 9. If you are running Xen on your NC, the euca-get-console-output command will not work, unless you do the following: a) On the NC, open the /etc/sysconfig/xend. b) Uncomment the following line: XENCONSOLED_LOG_GUESTS=yes c) Save the ®le and restart xend. 10. Repeat for each NC server in your system. RHEL 6 No additional con®guration is required for KVM or libvirt on RHEL 6. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Eucalyptus | 63 Ubuntu 10.04 LTS No additional con®guration is required for KVM or libvirt on Ubuntu 10.04 LTS. Ubuntu 12.04 LTS No additional con®guration is required for KVM or libvirt on Ubuntu 12.04 LTS. Configure Loop Devices To ensure that Eucalyptus starts new instances, you must con®gure the number of loop devices you expect to use for SC and NC components. An SC with insuf®cient loop devices fails to create new EBS volumes. An NC with insuf®cient loop devices fails to start new instances. This section tells you how to con®gure loop devices for your distribution. We recommend that you err on the side of con®guring too many loop devices. Too many loop devices result in a minor amount of memory tie-up and some clutter added to the system©s /dev directory. Too few loop devices make Eucalyptus unable to use all of a system©s resources. Eucalyptus installs with a default loop device amount of 256. However, Eucalyptus cannot control the number of loop devices on either CentOS 5 or RHEL 5. These systems default to eight loop devices, so you must supply a option to the loop driver by writing a con®guration ®le. For more information, see the instructions for either CentOS 5 or RHEL 5. If you want to change the default loop device number in CentOS 6, RHEL 6 Ubuntu 10.04 LTS, or Ubuntu 12.04 LTS, see the instructions for either CentOS 6, RHEL 6, Ubuntu 12.04 LTS, or Ubuntu 12.04 LTS. Tip: We recommend a minimum of 50 loop devices. If you have fewer than 50, the startup script will complain. CentOS 5 1. Log in to the SC server. 2. Create and open a ®le, /etc/modprobe.d/eucalyptus-loop. 3. Enter the following line: options loop max_loop=N where N is an integer from 1 to 256 4. Reload the loop driver if it is already loaded. rmmod loop modprobe loop 5. Repeat for each SC and NC server. CentOS 6 You don't need to make a con®guration change for CentOS 6 machines unless you want to change the default loop device value of 256. To change the default value, perform the tasks that follow. 1. Log in to the SC server and open the /etc/eucalyptus/eucalyptus.conf ®le. 2. Uncomment the following line: # CREATE_SC_LOOP_DEVICES=256 3. Replace 256 with the number of loop devices. 4. Repeat for each SC on your system. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Eucalyptus | 64 5. Log in to an NC server and open the /etc/eucalyptus/eucalyptus.conf ®le. 6. Uncomment the following line: # CREATE_NC_LOOP_DEVICES=256 7. Replace 256 with the number of loop devices. 8. Repeat for each NC on your system. RHEL 5 1. Log in to the SC server. 2. Create and open a ®le, /etc/modprobe.d/eucalyptus-loop. 3. Enter the following line: options loop max_loop=N where N is an integer from 1 to 256 4. Reload the loop driver if it is already loaded. rmmod loop modprobe loop 5. Repeat for each SC and NC server. RHEL 6 You don't need to make a con®guration change for RHEL 6 machines unless you want to change the default loop device value of 256. To change the default value, perform the tasks that follow. 1. Log in to the SC server and open the /etc/eucalyptus/eucalyptus.conf ®le. 2. Uncomment the following line: # CREATE_SC_LOOP_DEVICES=256 3. Replace 256 with the number of loop devices. 4. Repeat for each SC on your system. 5. Log in to an NC server and open the /etc/eucalyptus/eucalyptus.conf ®le. 6. Uncomment the following line: # CREATE_NC_LOOP_DEVICES=256 7. Replace 256 with the number of loop devices. 8. Repeat for each NC on your system. Ubuntu 10.04 LTS You don't need to make a con®guration change for Ubuntu 10.04 machines unless you want to change the default loop device value of 256. To change the default value, perform the tasks that follow. 1. Log in to the SC server and open the /etc/eucalyptus/eucalyptus.conf ®le. 2. Uncomment the following line: # CREATE_SC_LOOP_DEVICES=256 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Eucalyptus | 65 3. Replace 256 with the number of loop devices. 4. Repeat for each SC on your system. 5. Log in to an NC server and open the /etc/eucalyptus/eucalyptus.conf ®le. 6. Uncomment the following line: # CREATE_NC_LOOP_DEVICES=256 7. Replace 256 with the number of loop devices. 8. Repeat for each NC on your system. Ubuntu 12.04 LTS You don't need to make a con®guration change for Ubuntu 12.04 6 machines unless you want to change the default loop device value of 256. To change the default value, perform the tasks that follow. 1. Log in to the SC server and open the /etc/eucalyptus/eucalyptus.conf ®le. 2. Uncomment the following line: # CREATE_SC_LOOP_DEVICES=256 3. Replace 256 with the number of loop devices. 4. Repeat for each SC on your system. 5. Log in to an NC server and open the /etc/eucalyptus/eucalyptus.conf ®le. 6. Uncomment the following line: # CREATE_NC_LOOP_DEVICES=256 7. Replace 256 with the number of loop devices. 8. Repeat for each NC on your system. Configure Multi-Cluster Networking Eucalyptus supports multiple clusters within a single Eucalyptus cloud. This section brie¯y describes how Eucalyptus manages the networking aspect of a multi-cluster setup. In System or Static networking modes, Eucalyptus does not perform any special con®guration for a multi-cluster setup. In Managed and Managed (No VLAN) modes, Eucalyptus sets up Layer 2 Tunneling Protocol (L2TP) between your clusters. This means that virtual machines in the same security group, but distributed across clusters (potentially each in their own broadcast domain), can communicate with one another. Eucalyptus uses the VTun package to handle all L2TP tunnels between clusters. If VTun is installed on each of your CCs, multi-cluster tunneling is automatically handled by each CC. Depending on the networking mode and network topology, keep the following network con®guration considerations in mind. During normal operation, you will see many tunnel interfaces being created and destroyed as virtual networks are constructed and torn down. Managed Mode: In order for VTun tunneling to work in this mode, you must con®gure each CC with a bridge as its primary, public interface (VNET_PUBINTERFACE). Managed (No VLAN) Mode: The CC attempts to auto-discover its list of local IP addresses upon startup, but if the IP that was used to register the CC is not locally available, you can override the CC©s Managed Mode and Managed (No VLAN) Mode: notion of ©self© by setting the VNET_LOCALIP variable in the eucalyptus.conf ®le. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Eucalyptus | 66 Do not run two CCs in the same broadcast domain with tunneling enabled, as this will potentially lead to a broadcast storm as tunnels start forwarding packets in a loop on your local network. If you want to disable tunneling altogether, set DISABLE_TUNNELING=y in eucalyptus.conf. Manage IP Tables Rules In Managed and Managed (No VLAN) modes, Eucalyptus ¯ushes the CC©s iptables rules for both filter and nat, then it sets the default policy for the FORWARD chain in filter to DROP. At run time, the CC adds and removes rules from FORWARD as users add and remove ingress rules from their active security groups. In addition, the nat table is con®gured to allow VMs access to the external network using IP masquerading, and dynamically adds/removes rules in the nat table as users assign and unassign public IPs to VMs at instance boot or run-time. If you have rules you want to apply on the CC, make the following edit on the CC before you start Eucalyptus or while Eucalyptus is stopped: iptables-save > /var/run/eucalyptus/net/iptables-preload Caution: Performing this operation to de®ne special iptables rules that are loaded when Eucalyptus starts could cause Eucalyptus VM networking to fail. We recommend that you only do this if you are completely sure that it will not interfere with the operation of Eucalyptus. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring Eucalyptus | 67 Starting Eucalyptus Make sure that each host you installed a Eucalyptus component on resolves to an IP address. Edit the /etc/hosts ®le if necessary. Start the Eucalyptus components in the order presented in this guide. Start the CLC 1. Log in to the CLC. 2. Enter the following command to initialize the CLC: /usr/sbin/euca_conf --initialize Note: This command might take a minute or more to ®nish. 3. Enter the following command to start the CLC: service eucalyptus-cloud start For HA: For an HA environment, start the secondary CLC. Do not initialize the secondary CLC. Just start it. Start Walrus Important: If you installed Walrus on the same host as the CLC, skip this step. To start Walrus: Log in to the Walrus server and enter the following command: service eucalyptus-cloud start For HA: For an HA environment, repeat this task on the secondary Walrus. Start the CC To start the CC: 1. Log in to the CC server and enter the following: service eucalyptus-cc start 2. If you have a multi-cluster setup, repeat this step on the CC in each cluster. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Starting Eucalyptus | 68 For HA: For an HA environment, repeat this task on the secondary CC in each cluster. Start the VMware Broker Tip: If you aren't using the subscription-only VMware Broker module, skip this section. If you are using Eucalyptus with VMware support, perform the following tasks. 1. Log in to the CC server and enter the following: service eucalyptus-cloud start 2. If you have a multi-cluster setup, repeat this step on the CC in each cluster. For HA: For an HA environment, repeat this task on the secondary CC in each cluster. Start the SC Important: If you installed SC on the same host as the CLC, skip this step. To start the SC: 1. Log in to the SC server and enter the following command: service eucalyptus-cloud start Important: If you are re-installing the SC, please restart the tgt (iSCSI open source target) daemon. 2. If you have a multi-cluster setup, repeat this step on the SC in each cluster. For HA: For an HA environment, repeat this task on the secondary SC in each cluster. Start the NCs 1. Log in to an NC server and enter the following command: service eucalyptus-nc start 2. Repeat for each NC server. Verify the Startup At this point, all Eucalyptus components are enabled and starting up. Some of these services perform intensive initialization at start-up, particularly the ®rst time they are started. You might have to wait a few minutes until they are fully operational. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Starting Eucalyptus | 69 One quick way to determine if the components are running is to run netstat on the various hosts and look to see when the service ports are allocated to a process. Speci®cally, the CLC, Walrus, the SC, and the VMware Broker allocate ports 8773. The CC listens to port 8774, and the NC uses port 8775. Verify that everything has started without error. Expected outcomes include: · The CLC is listening on ports 8443 and 8773 · Walrus is listening on port 8773 · The SC is listening on port 8773 · If you are using the subscription only VMware Broker, it is listening on port 8773 · The CC is listening on port 8774 · The NCs are listening on port 8775 · Log ®les are being written to /var/log/eucalyptus/ CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Starting Eucalyptus | 70 Registering Eucalyptus Eucalyptus implements a secure protocol for registering separate components so that the overall system can't be tricked into including a component run by an unauthorized administrator or user. You only need to register components the ®rst time Eucalyptus is started after it was installed. Most registration commands run on the CLC server. NCs, however, are registered on each CC. You must register each NC on every CC for the cluster on which the NC participates. Note that each registration command will attempt an SSH as root to the remote physical host where the registering component is assumed to be running. The registration command also contacts the component so it must be running at the time of the command is issued. If a password is required to allow SSH access, the command will prompt the user for it. Except for NCs, each registration command requires four pieces of information: · The component (--register-XYZ) you are registering, because this affects where the commands must be executed. · The partition (--partition) the component will belong to. The partition is the same thing as availability zone in AWS. · The name (--component) ascribed to the component. This is the name used to identify the component in a human-friendly way. This name is also used when reporting system state changes which require administrator attention. This name must be globally-unique with respect to other component registrations. To ensure this uniqueness, we recommend using a combination of the component type (CLC, SC, CC, etc) and system hostname or IP address when you choose your component names. For example: clc-eucahost15 or clc-192.168.0.15. · The IP address (--host) of the service being registered. NCs only have two pieces of information: component name and IP address. Register the Secondary Cloud Controller For HA: If you installed HA, register the secondary CLC. Otherwise, skip this section. Log in to the primary CLC and enter the following command to register the secondary CLC: /usr/sbin/euca_conf --register-cloud --partition eucalyptus --host --component The partition name for the CLC has to be eucalyptus. The component name is a unique name for this particular component: we recommend a format such as clc-. Register Walrus To register Walrus: On the CLC server, enter the following command: /usr/sbin/euca_conf --register-walrus --partition walrus --host --component The component name for Walrus has to be walrus. Like the CLC, the component name is a unique name for this particular component: we recommend a format such as walrus-. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Registering Eucalyptus | 71 For HA: For HA, register the secondary Walrus the same way, using the secondary Walrus IP address and secondary Walrus name. Use the same partition name as the primary Walrus. Register the CC To register the CC: 1. On the CLC, enter the following command: /usr/sbin/euca_conf --register-cluster --partition --host --component We recommend that you set the partition name to a descriptive name for the availability zone controlled by the CC. For example: cluster01. The component is a unique name. We recommend that you use a short-hand name of the hostname or IP address of the machine, like cc- or cc-. 2. Repeat for each cluster, replacing the CC name, partition name, CC IP address, and CC name. For HA: For HA, register the secondary CC the same way, replacing the CC IP address and CC name, but using the same partition name as the primary CC. Register the VMware Broker Tip: If you aren't using the subscription-only VMware Broker module, skip this section. To register the VMware Broker 1. On the CLC, enter the following command: /usr/sbin/euca_conf --register-vmwarebroker --partition --host --component The VMware Broker must have the same partition name as the CC in the same cluster. Like the other components, the component is a unique name for this particular component: we recommend a format such as broker-. Important: Register the VMware Broker component using the CC IP address, not the CLC IP address. 2. Repeat for each cluster, replacing the VMware Broker name, partition name, CC IP address, and CC name. For HA: For HA, register the secondary VMware Broker the same way, using the secondary CC IP address and CC name, but using the same partition name as the primary CC. Register the SC To register the SC: CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Registering Eucalyptus | 72 1. On the CLC, enter the following command: /usr/sbin/euca_conf --register-sc --partition --host --component An SC must have the same partition name as the CC in the same cluster. Like the other components, the component is a unique name for this particular component: we recommend a format such as sc-. 2. Repeat for each cluster, replacing the SC name, partition name, SC IP address, and SC name. For HA: For HA, register the secondary SC the same way, using the secondary SC IP address and SC name, but using the same partition name as the primary SC. Register the NCs Important: If you are using the subscription only VMware Broker module, you can skip this task. Eucalyptus software is not installed on machines that are running VMware. You do not have to register the NCs. Instead, you have to con®gure the VMware Broker, as described in the Con®gure VMware Support section. 1. On a CC, register all NCs using the following command with the IP address of each NC server: /usr/sbin/euca_conf --register-nodes " ... " 2. Repeat each cluster in your cloud. The IP addresses of the NCs are space delimited, as in the following example: /usr/sbin/euca_conf --register-nodes "192.168.71.154 192.168.71.155 192.168.71.159" For HA: For HA, you must also register the NCs with the secondary CC. Register Arbitrators Eucalyptus uses a periodic ICMP echo test to an Arbitrator. This test approximates an end user©s ability to access the system. If Eucalyptus determines that it cannot reach the host associated with a registered Arbitrator, all Eucalyptus services operating on that host attempt to failover to the alternate hosts running those services. For HA: In HA, you can register each Arbitrator service on the primary and secondary CLC and Walrus. If you are using either Managed or Managed (No VLAN) mode, you can also register Arbitrator services on both the primary CC and the secondary CC. We recommend that you register more than one Arbitrator for each Eucalyptus component. This will allow for normal outages and maintenance. There is no limit on the number of Arbitrators on a CLC and a Walrus. You can only register up to three on a CC. Register an Arbitrator service on each host that has a cloud component (CLC or Walrus) installed. An Arbitrator is a host-wide component: when an Arbitrator is registered on a host, it is registered with all cloud components enabled on that host. A separate arbitrator has to be registered per each network entity that needs to be monitored from the host. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Registering Eucalyptus | 73 To register an Arbitrator: 1. Log in to the primary CLC. 2. Enter the following command to register an arbitrator: /usr/sbin/euca_conf --register-arbitrator --partition --component --host where: · is a globally unique ID that identi®es an Arbitrator. Note that you must use the same as both a partition and component ID. · is the IP or hostname running the Eucalyptus component that will run the Arbitrator. For example: euca_conf --register-arbitrator --partition EXAMPLE_ARB --component EXAMPLE_ARB --host 192.168.1.10 3. Repeat for the secondary CLC and for both Walrus servers. 4. De®ne the gateway for each Arbitrator: /usr/sbin/euca-modify-property -p .arbitrator.gatewayhost= where: · is the globally unique ID of the registered Arbitrator. · is an external hostname or IP address used to approximate connectivity to the end user. For example: euca-modify-property -p EXAMPLE_ARB.arbitrator.gatewayhost=192.168.1.1 5. Repeat for each registered Arbitrator. 6. To register on each CC, log in to the primary CC, and open the /etc/eucalyptus/eucalyptus.conf ®le. 7. Provide a list of Arbitrators (up to three) as values for the CC_ARBITRATORS property. For example: CC_ARBITRATORS="192.168.48.11 192.168.48.12" 8. Save the ®le and restart the CC. service eucalyptus-cc restart 9. Repeat on the secondary CC. In the following example, the primary CLC is on , the secondary CLC is on , the primary Walrus is on , and the secondary Walrus is on . /usr/sbin/euca_conf --register-arbitrator --host --component ARB00 --partition ARB00 /usr/sbin/euca_conf --register-arbitrator --host --component ARB01 --partition ARB01 /usr/sbin/euca_conf --register-arbitrator --host --component ARB02 --partition ARB02 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Registering Eucalyptus | 74 /usr/sbin/euca_conf --register-arbitrator --host --component ARB03 --partition ARB03 /usr/sbin/euca_conf --register-arbitrator --host --component ARB04 --partition ARB04 /usr/sbin/euca_conf --register-arbitrator --host --component ARB05 --partition ARB05 /usr/sbin/euca_conf --register-arbitrator --host --component ARB06 --partition ARB06 /usr/sbin/euca_conf --register-arbitrator --host --component ARB07 --partition ARB07 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Registering Eucalyptus | 75 Configuring the Runtime Environment After Eucalyptus is installed and registered, perform the tasks in this section to con®gure the runtime environment. Generate Administrator Credentials Now that you have installed and con®gured Eucalyptus, you©re ready to start using it. To do so, you must generate credentials. Important: When you run the euca_conf --get-credentials command, you are requesting the access and secret keys and an X.509 certi®cate and key. You cannot retrieve an existing X.509 certi®cate and key. You can only generate a new pair. To generate a set of credentials: 1. Generate administrator credentials. /usr/sbin/euca_conf --get-credentials admin.zip unzip admin.zip 2. Source the eucarc ®le. source eucarc You are now able to run Eucalyptus commands. Configure SAN Support Tip: If you aren't using the subscription-only SAN support module, skip this section. To use the SAN integration feature that Eucalyptus provides, con®gure supported SAN devices to allow Eucalyptus to manage the SAN. Eucalyptus automatically creates and tears down volumes, snapshots, and data connections from guest instances. The administrator does not need to pre-allocate volumes or LUNs for Eucalyptus. Eucalyptus offers SAN support for EBS. The SANManager module directs the Storage Controller (SC) to manage supported SAN devices. Enabling the SANManager requires that you con®gure the CLOUD_OPTS variable in eucalyptus.conf so that Eucalyptus loads the SANManager module and selects your SAN device at start time. To con®gure SAN support: 1. Enable SAN access on Eucalyptus 2. Enable the speci®c SAN device (Dell, Netapp, or JBOD) Enable Dell Equallogic SANs 1. On the SC, open the /etc/eucalyptus/eucalyptus.conf ®le and make the following con®guration: CLOUD_OPTS="-Debs.storage.manager=SANManager -Debs.san.provider=EquallogicProvider" CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring the Runtime Environment | 76 2. Restart the SC. If the SC is not installed separately, restart the CLC. service eucalyptus-cloud restart Enable NetApp SANs NetApp Filer devices (FAS 2000 and FAS 6000 series) are managed by Eucalyptus using NetApp ONTAPI (version 7.3.3 or above). Enable ONTAPI and provide administrative Eucalyptus with access to OTAPI. To con®gure NetApp Filer and enable NetApp SANs: 1. Enable and verify API access to NetApp Filer. 2. Verify that an aggregate with suf®cient spare capacity exists. · If you have SSH access to the NetApp Filer, enter aggr show_space. · If an aggregate with spare capacity does not exist, create one using the aggr create command. 3. Verify that you have a license for FlexClone installed. At the shell prompt, enter license to see the list of all installed licenses. 4. Write down the administrator credentials (or create an administrator account for Eucalyptus). You will need to con®gure Eucalyptus with these credentials later. 5. On the SC, open the /etc/eucalyptus/eucalyptus.conf ®le and make the following con®guration: CLOUD_OPTS="-Debs.storage.manager=SANManager -Debs.san.provider=NetappProvider" 6. Restart the SC. If the SC is not installed separately, restart the CLC. service eucalyptus-cloud restart Enable Direct Attached Storage (JBOD) SANs 1. On the SC, open the /etc/eucalyptus/eucalyptus.conf ®le and make the following con®guration: CLOUD_OPTS="-Debs.storage.manager=DASManager" 2. Restart the SC. If the SC is not installed separately, restart the CLC. service eucalyptus-cloud restart 3. On the CLC, set the DAS device name property. The device name can be either a raw device (/dev/sdX, for example), or the name of an existing Linux LVM volume group. euca-modify-property -p .storage.dasdevice= For example: euca-modify-property -p cluster0.storage.dasdevice=/dev/sdb Enable SANManager To enable the Eucalyptus SANManager: CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring the Runtime Environment | 77 Enter the following commands: euca-modify-property -p .storage.sanhost= euca-modify-property -p .storage.sanuser= euca-modify-property -p .storage.sanpassword= Configure DNS Eucalyptus provides a DNS service that you can con®gure to: · Map instance IPs and Walrus bucket names to DNS host names · Enable DNS delegation to support transparent failover in HA mode The DNS service will automatically try to bind to port 53. If port 53 cannot be used, DNS will be disabled. Typically, other system services like dnsmasq are con®gured to run on port 53. To use the Eucalyptus DNS service, you will need to disable these services. Configure the Subdomain Before using the DNS service, con®gure the DNS sub domain name that you want Eucalyptus to handle as follows after the Eucalyptus Cloud Controller (CLC) has been started. Log in to the CLC (the primary CLC in an HA setup) and enter the following: euca-modify-property -p system.dns.dnsdomain= Turn on IP Mapping To turn on mapping of instance IPs to DNS host names: 1. Enter the following command: euca-modify-property -p bootstrap.webservices.use_instance_dns=true When this option is enabled, public and private DNS entries are set up for each instance that is launched in Eucalyptus. This also enables virtual hosting for Walrus. Buckets created in Walrus can be accessed as hosts. For example, the bucket mybucket is accessible as mybucket.walrus.eucadomain.yourdomain. Instance IP addresses will be mapped as euca-A.B.C.D.eucalyptus., where A.B.C.D is the IP address (or addresses) assigned to your instance. 2. If you wish to modify the subdomain that is reported as part of the instance DNS name, please enter the following command: euca-modify-property -p cloud.vmstate.instance_subdomain= When this value is modi®ed, the public and private DNS names reported for each instance will contain the speci®ed custom DNS subdomain name, instead of the default value, which is eucalyptus. For example, if this value is set to foobar, the instance DNS names will appear as euca-A.B.C.D.foobar.. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring the Runtime Environment | 78 Enable DNS Delegation For HA: If you are not using HA, you can skip this task. DNS delegation allows you to forward DNS traf®c for the Eucalyptus subdomain to the Eucalyptus CLC hosts. These hosts act as name servers. This allows interruption-free access to Eucalyptus cloud services in the event of a failure. Both primary and secondary CLC hosts are capable of mapping cloud host names to IP addresses of the primary CLC and Walrus hosts. For example, if the IP address of the primary and secondary CLC are 192.168.5.1 and 192.168.5.2, and the IP addresses of primary and secondary Walruses are 192.168.6.1 and 192.168.6.2, the host eucalyptus.eucadomain.yourdomain will resolve to 192.168.6.1 and walrus.eucadomain.yourdomain will resolve to 192.168.6.1. If the primary CLC fails, the secondary CLC will become the primary and eucalyptus.eucadomain.yourdomain will resolve to 192.168.5.2. If the primary Walrus fails, the secondary Walrus will be promoted and walrus.eucadomain.yourdomain will resolve to 192.168.6.2. To enable DNS delegation: 1. On the primary CLC, enter the following command: euca-modify-property -p bootstrap.webservices.use_dns_delegation=true 2. Because the credentials are now slightly changed, you must generate the administrative credentials and source the eucarc ®le again. For more information, see Generate Administrator Credentials. Configure the Master DNS Server Set up your master DNS server to forward the Eucalyptus subdomain to the primary and secondary CLC servers, which act as name servers. The following example shows how the Linux name server bind is set up to forward the Eucalyptus subdomain. 1. Open /etc/named.conf and set up the eucadomain.yourdomain zone. For example, your /etc/named.conf may look like the following: zone "yourdomain" { type master; file "/etc/bind/db.yourdomain"; }; #Forward eucadomain.yourdomain zone "eucadomain.yourdomain" { type forward; forward only; forwarders { ; ; }; }; where is the IP address of your primary CLC and is the IP address of your secondary CLC. 2. Create /etc/bind/db.yourdomain if it does not exist. If your master DNS is already set up for yourdomain, you will need to add name server entries for and . For example: $TTL 604800 @ IN SOA yourdomain. root.yourdomain. ( 2 ; Serial 604800 ; Refresh CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring the Runtime Environment | 79 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns.yourdomain. @ IN A ns.yourdomain. IN A ;Add entries for primary and secondary CLCs eucadomain.yourdomain. IN NS clc0.eucadomain.yourdomain. eucadomain.yourdomain. IN NS clc1.eucadomain.yourdomain. clc0.eucadomain.yourdomain. IN A clc1.eucadomain.yourdomain. IN A where clc0.eucadomain.yourdomain and clc1.eucadomain.yourdomain are the host names of your primary and secondary CLC servers. 3. Restart the bind nameserver (/etc/init.d/bind9 restart or /etc/init.d/named restart, depending on your Linux distribution). 4. Test your setup by pointing /etc/resolv.conf on your client to your primary DNS server and attempt to resolve eucalyptus.eucadomain.yourdomain using ping or nslookup. It should return the IP address of the primary CLC server. Set NC Concurrency Level On some Linux installations, a suf®ciently large amount of local disk activity can slow down process scheduling. This can cause other operations (e.g., network communication and instance provisioning) appear to stall. To alleviate this potential problem, we recommend performing the following steps on each NC: 1. Log in to an NC server and open the /etc/eucalyptus/eucalyptus.conf ®le. 2. Change the CONCURRENT_DISK_OPS parameter to the number of disk-intensive operations you want the NC to perform at once. Examples of disk-intensive operations include preparing disk images for launch and creating ephemeral storage. Set this value to 1 to serialize all disk-intensive operations. Set to a higher number to increase the amount of disk-intensive operations the NC will perform in parallel. Increase Walrus Disk Space The size of Walrus storage must be larger than the sum of all the uploaded images. Each uploaded image requires additional space to accommodate image decryption and the creation of temporary working ®les. We recommend that the Walrus storage size be three times the size of all uploaded images. For example, you might have a total of three images: two 10GB images and one 30 GB image. In order to ensure that all three images are cached and ready to run in Eucalyptus, you will need to set the ªSpace reserved for unbundling imagesº in Walrus to 50 GB or larger. To increase the image cache size in Walrus: 1. Log in to the Dashboard (https://:8443). 2. Click Service Components in the Quick Links section. The Service Components page displays. 3. Click walrus. The Properties section displays. 4. Enter the new size (in MB) in the Space reserved for unbundling images ®eld. 5. Click Save. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring the Runtime Environment | 80 Configure DRBD For HA: This section is for Eucalyptus HA. If you are not using HA, skip this section. Before you begin, ensure that you have the following information: · The IP address and hostname of each Walrus · The DRBD block device name of each Walrus. In the following examples, we assume that DRBD block device name is /dev/drbd1. · The DRBD backing disk partition names on each Walrus. A partition (either on a new disk or an existing disk) should be dedicated to Walrus. The partition sizes should be identical. Tip: Consider backing the DRBD resource with a logical volume using LVM, this will make growing the backing store easier in the future if you are running low on disk space. Con®guring DRBD requires that you complete edit the Eucalyptus DRBD ®le to include your Walrus information, and edit the master DRBD ®le to tell it to look for the Eucalyptus DRBD ®le. To con®gure DRBD: 1. Log in to the primary Walrus. 2. Load the DRBD module modprobe drbd There is no output from this command. 3. Copy the example Eucalyptus DRBD ®le (/etc/eucalyptus/drbd.conf.example) to /etc/eucalyptus/drbd.conf. 4. Open the /etc/eucalyptus/drbd.conf ®le and make the following edits: · Change the value of to the hostname (output of Áuname -nÁ) of the primary Walrus. · Change the value of to /dev/drbd1 · Change the value of to /dev/sdb1 · Change the value of to the IP address of the primary Walrus. · Change the value of to the hostname (output of Áuname -nÁ) of the secondary Walrus. · Change the value of to /dev/drbd1 · Change the value of to /dev/sdb1 · Change the value of to the IP address of the secondary Walrus. The ®le should look like the following example: common { protocol C; } resource r0 { on walrus00.eucalyptus.com { device /dev/drbd1; disk /dev/sdb1; address 192.168.58.1:7789; meta-disk internal; } on walrus01.eucalyptus.com { device /dev/drbd1; CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring the Runtime Environment | 81 disk /dev/sdb1; address 192.168.58.2:7789; meta-disk internal; } syncer { rate 40M; } net { after-sb-0pri discard-zero-changes; after-sb-1pri discard-secondary; } } Important: On RHEL 6, remove the common section (common { protocol C; }). The default con®guration in RHEL 6 already includes a common section. 5. Save and close the ®le. 6. Open the master DRBD ®le (/etc/drbd.conf) and append the following line: include "/etc/eucalyptus/drbd.conf"; 7. Save and close the ®le. 8. Open the /etc/eucalyptus/eucalyptus.conf ®le and make the following con®guration: CLOUD_OPTS="-Dwalrus.storage.manager=DRBDStorageManager" 9. Restart Walrus. service eucalyptus-cloud restart 10. Copy the /etc/drbd.conf, the /etc/eucalyptus/drbd.conf, and the /etc/eucalyptus/eucalyptus.conf ®les to the secondary Walrus server. 11. On the primary Walrus, associate the DRBD block device (/dev/drbd1) with the disk partition allocated for Walrus (/dev/sdb1). drbdmeta --force /dev/drbd1 v08 /dev/sdb1 internal create-md drbdadm attach r0 drbdadm connect r0 Important: Repeat this step on the secondary Walrus. 12. Set up the DRBD block device on the primary Walrus: drbdsetup /dev/drbd1 syncer -r 110M drbdadm -- --overwrite-data-of-peer primary r0 13. On the primary Walrus only, run the following command to indicate whether the data on the DRBD primary and secondary is consistent: drbdadm dstate r0 Wait for the output to display UpToDate/UpToDate, then continue to the next step. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring the Runtime Environment | 82 Tip: To view the synchronization process in near-realtime, run watch -n 2 cat /proc/drbd. 14. On the primary Walrus, create a ®lesystem on /dev/drbd1. Eucalyptus supports ext3 or ext4. For example: mkfs.ext3 /dev/drbd1 15. On the primary CLC, tell Eucalyptus to use DRBD parameters con®gured in the DRBD con®g ®le so Walrus can write to the correct device: euca-modify-property -p walrus.blockdevice=/dev/drbd1 euca-modify-property -p walrus.resource=r0 Configure VMware Support After registering the VMware Broker, as described above, the Broker component will be activated, but will not be usable (i.e., listed as ENABLED) until it is con®gured with information about your VMware infrastructure. An uncon®gured Broker is as good as a Cluster Controller with no Node Controllers to deploy virtual machines on. Until the Broker is properly con®gured, its logs (e.g., cloud-output.log) will contain a reminder of the fact: VMware Broker has not been configured (see euca-configure-vmware) Con®guration for the VMware Broker is described by an XML document. A minimal con®guration, which would supply just enough information for the Broker to become usable, can be generated automatically, by answering a set of questions about your VMware endpoints. All further con®guration must be done by editing the XML document manually, though with help from a validation mechanism. We recommend starting with a minimal con®guration and editing the generated document to further expand it. The steps for creating minimal and full-featured con®gurations, as well as for validating them, are described next. All these steps involve euca-configure-vmware command, which must be executed on the CC/Broker host. For authorization, the same type of credentials that other administrative euca- commands require must be supplied (e.g., via eucarc). If CLC and CC/Broker run on different hosts, the credentials may have to be copied from the CLC host to the CC/Broker host. Minimal VMware Broker configuration At the very least, a VMware Broker needs the IP addresses and access credentials of each VMware endpoint (either vCenter or ESX/ESXi host). To create a minimal con®guration automatically, this information must be entered, for each endpoint, when prompted by euca-configure-vmware command. If the Broker has never been con®gured, the command will detect that and will ask for information upon invocation without any ¯ags. 1. On the CC/Broker host, enter the following command: euca-configure-vmware The output of the above command prompts for the same parameters that the vSphere Client application, distribued by VMware, requests at startup. 2. Enter the requested parameters, making sure to specify just the IP addresses of VMware endpoints and not URLs. If you want to use vCenter, then enter the IP address of the vCenter server. If you do not want to use vCenter, then enter IP addresses of each ESX/ESXi host. We recommend using vCenter because it is easier to con®gure and can be more ef®cient. Please, supply vSphere endpoint IP: 192.168.51.77 Please, supply vSphere username: root Please, supply vSphere password: CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring the Runtime Environment | 83 Do you want to enter another endpoint? [N]: y Please, supply vSphere endpoint IP: 192.168.51.78 Please, supply vSphere username [root]: Please, supply vSphere password [*****]: Do you want to enter another endpoint? [N]: N After entering all vSphere endpoint information, if the access credentials are correct, you should see output similar to the following: discovered 2 host(s) 192.168.51.78 login=root datastoreName=datastore1 (7) uploadViaHost=true network=VM Network 192.168.51.77 login=root datastoreName=datastore1 (6) uploadViaHost=true network=VM Network If vCenter endpoint is entered, the output may list multiple ESX(i) hosts that were discovered by querying vCenter: Please, supply vSphere endpoint IP: 192.168.51.48 Please, supply vSphere username: Administrator Please, supply vSphere password: Do you want to enter another endpoint? [N]: discovered 7 host(s) 192.168.51.175 login=Administrator datastoreName=datastore1 uploadViaHost=null network=VM Network 192.168.51.24 login=Administrator datastoreName=datastore1 (3) uploadViaHost=null network=VM Network 192.168.51.22 login=Administrator datastoreName=datastore1 (5) uploadViaHost=null network=VM Network 192.168.51.78 login=Administrator datastoreName=datastore1 (7) uploadViaHost=null network=VM Network 192.168.51.18 login=Administrator datastoreName=datastore1 (4) uploadViaHost=null network=VM Network 192.168.51.77 login=Administrator datastoreName=datastore1 (6) uploadViaHost=null network=VM Network 192.168.51.116 login=Administrator datastoreName=datastore1 (1) uploadViaHost=null network=VM Network This process both generates the XML con®guration and con®gures the Broker. From this point onward, invoking euca-configure-vmware with no parameters will cause the current con®guration of the Broker to be validated. To make the new con®guration active, the Broker must be restarted. 3. Restart the VMware Broker. service eucalyptus-cloud restart Re-generating VMware Broker configuration After the Broker has been con®gured, to generate a con®guration again, one must use a two-step process: 1. On the CC/Broker host, use the --generate ¯ag to create another con®guration, which is saved in an XML ®le in the /tmp directory. euca-configure-vmware --generate Note the path to the newly generated XML con®guration that is printed by the command. Please, supply vSphere endpoint IP: 192.168.51.116 Please, supply vSphere username: root Please, supply vSphere password: CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring the Runtime Environment | 84 Do you want to enter another endpoint? [N]: discovered 1 host(s) 192.168.51.116 login=root datastoreName=datastore1 (1) uploadViaHost=true network=VM Network New config file was saved to /tmp/euca_vmwarexsiVPj.xml 2. Modify the con®guration in Broker©s database by providing that ®le to euca-configure-vmware: euca-configure-vmware /tmp/euca_vmwarexsiVPj.xml The XML document is validated by contacting the vSphere endpoints and some diagnostic information is reported. Network mode: MANAGED discovered 1 host(s) 192.168.51.116 login=root datastoreName=datastore1 (1) uploadViaHost=true network=VM Network 3. Restart the VMware Broker. service eucalyptus-cloud restart Full-featured VMware Broker configuration This section may be skipped if the minimal con®guration produced automatically was suf®cient to access all hypervisor nodes and the default names chosen for networks and datastores were adequate. If that is not the case, the con®guration, in the form of an XML document, will have to be edited manually. 1. There are two ways to edit the XML document: · By invoking euca-configure-vmware with --edit ¯ag, which invokes an editor (as speci®ed by the $EDITOR environment variable, which must be set for the ¯ag to work), with current con®guration loaded in it, and updates the con®guration when the editor terminates successfully. euca-configure-vmware --edit · By editing an XML ®le out of band and providing euca-configure-vmware with the path to the ®le, which is then used to update the con®guration of the Broker. euca-configure-vmware /path/to/file.xml In both cases, before the con®guration is updated, the XML document is validated for correctness, both in terms of XML syntax and in the validity of information provided therein with respect to the VMware infrastructure (i.e., endpoints, access credentials, and any named resources, such as networks and datastores, are veri®ed by requests to VMware). Network mode: MANAGED discovered 1 host(s) 192.168.51.116 login=root datastoreName=datastore1 (1) uploadViaHost=true network=VM Network 2. Restart the VMware Broker. service eucalyptus-cloud restart CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring the Runtime Environment | 85 XML configuration structure The part of the document that describes vSphere endpoints can be hierarchical, re¯ecting the hierarchy of abstractions de®ned within vSphere: endpoints may contain datacenters, datacenters may contain clusters, and clusters may contain hosts. However, just as parts of the hierarchy are optional in vSphere (e.g., there may be one default datacenter and no clusters) the hierarchy is optional in the VMware Broker con®guration. The only required element is , which must be enclosed by the element, which in turn must be enclosed by the element. These requirements are satisifed by any minimal con®guration, as generated by the steps described above. Minimal con®gurations typically look as follows: When other elements are present, however, they must be arranged relative to each other in a hierarchy. This hierarchy is shown in the following template, which describes all valid elements in a VMware Broker con®guration and their attributes (some attributes are grouped into categories, namely CREDENTIALS and EXTRAS). For example, if a is speci®ed, it must be contained by the to which it belongs. Likewise, any must be contained within an , if any. And so on. All endpoints must be contained by the single element. These elements and attributes will be discussed below. XML configuration attributes Each , , and element requires the ©name© attribute, which must match the name of that abstraction in vSphere; whereas requires the ©url© attribute, which is normally the IP of a vSphere endpoint pre®xed by https://. CREDENTIALS and EXTRAS are categories of attributes. These attributes can be speci®ed for any vSphere-related element with values propagating from higher-level elements to lower-level elements, where the values can be overridden selectively. For example, if one were to specify maxCores="4" in the element, then all hosts belonging to that endpoint would advertise 4 cores instead of their actual number of physical cores. However, the lower-level parameter always overrides the higher-level parameter. So, if a speci®es maxCores="8", that will override maxCores="4" speci®ed in the or that contains it. This kind of inheritance of values with possibility of overriding applies to all attributes in CREDENTIALS and EXTRAS categories. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring the Runtime Environment | 86 · CREDENTIALS consist of ©login© and ©password© attributes, the latter of which can be speci®ed in plaintext or encrypted (as produced by euca-configure-vmware). At the very least they must be speci®ed either for each or once in the enclosing element, in which case they will be used for all endpoints without explicitly speci®ed credentials. If credentials are speci®ed for any elements contained by , they will be used for the optional data transfer connections to individual ESX/ESXi hosts (see uploadViaHost attribute below). Thus, if login or password on ESX/ESXi hosts are different from login and password on vCenter, the values for ESX/ESXi must be speci®ed separately. · EXTRAS attributes allow one to restrict Eucalyptus©s behavior in several ways. By default, Eucalyptus will attempt to use all resources that it discovers, such as memory, cores, and storage space on a datastore. Furthermore, when multiple options are available, e.g., for a datastore or a network, it will make an arbitrary choice. With the following attributes, one can make the exact choices when desired: · ©datastore© - name of the vSphere datastore to use (®rst one found by default). · ©network© - name of the vSphere network to use (®rst one found by default). · ©maxCores© - number of virtual cores to use on an ESX(i) host for Eucalyptus instances (same as physical cores by default). · ©maxMemMB© - memory, in MB, to use on an ESX(i) host for Eucalyptus instances (same as physical RAM by default). · ©maxDiskMB© - disk size, in MB, to use on a datastore for Eucalyptus instances (free space on the datastore by default). · ©uploadViaHost© - upload VM disk contents directly to the ESX(i) host rather than through vCenter ("false" by default). This option is ignored when the endpoint is an ESX(i) host. The default behavior is to upload VM©s disk ®les through vCenter. To avoid overloading the vCenter with I/O traf®c, however, Eucalyptus can perform the upload directly to an individual host. In this case, if the credentials (login or password) for the host are different from vCenter credentials, they must be speci®ed explicitly in one or more elements contained by the (e.g., in each or each or each element). Three elements, , , and , may specify the boolean attribute ©discover© (with "true" and "false" as the only allowed values). Setting it to "true" implies that VMware Broker is allowed to add to its inventory any elements (clusters or hosts) contained therein even if they are not speci®ed explicitly. Conversely, setting it to "false" implies that VMware Broker may not add to its inventory any containing elements that are not speci®ed explicitly with or tags. If a host is not added to the inventory because discovery is forbidden and the host is not speci®ed explicitly with a element, that incident will be reported as: DISALLOWED BY CONFIGURATION Storage attributes You can change disk locations and the size limits used by VMware Broker for constructing and caching of disk images. · cacheLimitMb, the only attribute unique to the element, speci®es how much space Eucalyptus is allowed to use on vSphere, cumulatively across all datastores, for caching VM templates. The default value is 50GB. · scratchDirectory and scratchDirectoryLimitMb attributes of the optional element de®ne where on the ®le system and how much space the VMware Broker may use for non-cacheable work. Default values are /var/lib/eucalyptus/vmware/tmp and 50GB, respectively. · cacheDirectory and cacheDirectoryLimitMb attributes of the optional element de®ne where on the ®le system and how much space the VMware Broker may use for cacheable work. Default values are /var/lib/eucalyptus/vmware/cache and 50GB, respectively. Set Up Security Groups In Managed and Managed (No VLAN) networking modes, you must con®gure the system with parameters that de®ne how Eucalyptus will allocate and manage virtual machine networks. These virtual machine networks are known as security groups. The relevant parameters are set in the eucalyptus.conf on all machines running a CC. These parameters are: CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring the Runtime Environment | 87 · VNET_SUBNET · VNET_NETMASK · VNET_ADDRSPERNET The CC will read VNET_SUBNET and VNET_NETMASK to construct a range of IP addresses that are available to all security groups. This range will then be further divided into smaller networks of the size speci®ed in VNET_ADDRSPERNET. The ®rst time an instance runs in a given security group, Eucalyptus chooses an unused range of IPs of size speci®ed in VNET_ADDRSPERNET. Eucalyptus then implements this network across all CCs. All instances that run within this given security group obtain a speci®c IP from this range. Tip: Ten of the IP addresses within each security group network are reserved for Eucalyptus to use as gateway addresses, broadcast address, etc. For example, if you set VNET_ADDRSPERNET to 32, there will be 22 free IPs that are available for instances running in that security group. In Managed mode, each security group network is assigned an additional parameter that is used as the VLAN tag. This parameter is added to all virtual machine traf®c running within the security group. By default, Eucalyptus uses VLAN tags starting at 2, going to a maximum of 4094. The maximum is dependent on how many security group networks of the size speci®ed in VNET_ADDRSPERNET ®t in the network de®ned by VNET_SUBNET and VNET_NETMASK. If your networking environment is already using VLANs for other reasons, Eucalyptus supports the de®nition of a smaller range of VLANs that are available to Eucalyptus. To set this range with a running and con®gured Eucalyptus installation: 1. Determine the range that your cluster controllers are con®gured to support. euca-describe-properties | grep cluster.maxnetworktag euca-describe-properties | grep cluster.minnetworktag 2. De®ne a range that is a proper subset of the above bounds. euca-modify-property -p cloud.network.global_max_network_tag= euca-modify-property -p cloud.network.global_min_network_tag= CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Con®guring the Runtime Environment | 88 Finding More Information Read More Eucalyptus has the following guides to help you with more information: · The Administration Guide details ways to manage your Eucalyptus deployment. Refer to this guide to learn more about managing your Eucalyptus components, managing access to Eucalyptus, and managing Eucalyptus resources, like instances and images. · The User Guide details ways to use Eucalyptus for your computing and storage needs. Refer to this guide to learn more about getting and using euca2ools, creating images, running instances, and using dynamic block storage devices. · The CLI Reference Guide describes the Euca2ools commands. Refer to this guide for more information about required and optional parameters for each command. Get Involved The following resources can help you to learn more, connect with other Eucalyptus users, or get actively involved with Eucalyptus development. · The Eucalyptus IRC channel is #eucalyptus on Freenode. This channel is used for real-time communication among users and developers. Information on how to use the network is available from Freenode. · The Eucalyptus community mailing list is community@lists.eucalyptus.com. This list is used for user discussions, problem reports, and other communications. Information on how to subscribe is available at http://lists.eucalyptus.com/cgi-bin/mailman/listinfo/community CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Finding More Information | 89 Appendix A: Upgrading Eucalyptus If you are upgrading from a previous version of Eucalyptus, follow the directions detailed in this section. Migrating Users There are two considerations for migrating users during the upgrade process: · In Eucalyptus 3.1.0 the concept of user has changed. What used to be a user is now an account, and the user is an identity within the account. In the upgrade process to Eucalyptus 3.1.0, users are converted to accounts. · Eucalyptus 3.1.0 enforces case insensitivity. So a user labeled john and another user labeled JOHN will collide during the upgrade process. You must either relabel con¯icting accounts or be aware that Eucalyptus will relabel these accounts. For example, the upgrade process will maintain the john label but will relabel the other one as john-. Migrating VLAN Range In Eucalyptus 2.x, there were per-cluster settings in the web user interface for Min VLANs and Max VLANs. These values de®ned the range of numeric VLAN tags allowed for that cluster. In some cases, this was necessary due to limitations of the network switches being used. Failing to preserve these values might break your cloud©s network con®guration. In Eucalyptus 3.1.0, the VLAN tag range is a global setting. The safest thing is to choose a range that is the intersection of the user©s per-cluster settings from 2.x. However, this will not always be the preferred con®guration for each user. Use the euca-describe-properties command to display the new settings: PROPERTY cloud.network.global_max_network_tag 1000 PROPERTY cloud.network.global_min_network_tag 2 Finding Backup Files The upgrade process creates a backup to /var/lib/eucalyptus/upgrade/eucalyptus.backup.. For example: /var/lib/eucalyptus/upgrade/eucalyptus.backup.1326905212 If the upgrade fails and needs to be reverted to your earlier version, you can ®nd your preserved data in this directory. CentOS 5 This section explains tasks to perform in order to upgrade to Eucalyptus 3.1.0 on CentOS 5 machines. Notice: The steps in this section work for both Eucalyptus 2.03 open source and Eucalyptus 3.0 upgrades. Prepare the Configuration File To upgrade to Eucalyptus 3.1.0 on CentOS: Important: The steps in this section should be performed on all machines with Eucalyptus installed. 1. Remove any hand-written repository ®les for earlier versions of Eucalyptus and Euca2ools from /etc/yum.repos.d. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 90 2. Con®gure the Euca2ools package repository on each host that will run a Eucalyptus component or Euca2ools: rpm -Uvh http://downloads.eucalyptus.com/software/euca2ools/2.1/rhel/5/x86_64/euca2ools-release-2.1.noarch.rpm 3. Con®gure the Eucalyptus package repository on each host that will run a Eucalyptus component: rpm -Uvh http://downloads.eucalyptus.com/software/eucalyptus/3.1/rhel/5/x86_64/eucalyptus-release-3.1.noarch.rpm 4. Con®gure the EPEL package repository on each host that will run a Eucalyptus component or Euca2ools: rpm -Uvh http://downloads.eucalyptus.com/software/eucalyptus/3.1/rhel/5/x86_64/epel-release-5.noarch.rpm 5. Note: If upgrading from Eucalyptus 2.0, you can skip this step. This step is only necessary if you are upgrading from Eucalyptus 3.0. If you have a Eucalyptus subscription, you will have received a package that grants you access to VMware and SAN components. If you wish to use either of these components, install this package on each host that will run a Eucalyptus component using the following command. Otherwise, skip this step. rpm -Uvh eucalyptus-enterprise-release-3.1-1.noarch.rpm Shutdown Components To shut down Eucalyptus components: 1. Terminate any running instances, as in the following example: euca-terminate-instances 2. Tip: The following is an example that scripts the individual steps to shut down Eucalyptus components noted in this section. for x in $( euca_conf --list-nodes | tail -n +2 | awk ©{ print $1 }©); do ssh root@$x "service eucalyptus-nc stop"; done for x in $( euca_conf --list-clusters | tail -n +2 | awk ©{ print $2 }©); do ssh root@$x "service eucalyptus-cc stop"; done for x in $( euca_conf --list-scs | tail -n +2 | awk ©{ print $2 }©); do ssh root@$x "service eucalyptus-cloud stop"; done for x in $( euca_conf --list-walruses | tail -n +2 | awk ©{ print $2 }©); do ssh root@$x "service eucalyptus-cloud stop"; done service eucalyptus-cloud stop If you don©t have ssh keys set up, you©ll have to type a lot of passwords during this. Log in to an NC host and shut down the NC service. service eucalyptus-nc stop Repeat for each machine hosting an NC. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 91 3. Log in to a CC host and shut down the CC service. service eucalyptus-cc cleanstop Repeat for each machine hosting a CC. 4. Shut down the VMware Broker service on the CC host. service eucalyptus-cloud stop Tip: This command also shuts down a CLC, Walrus, and SC components co-located with the CC and VMware Broker to stop at the same time, in the correct order. Repeat for each machine hosting the VMware Broker. 5. Log in to an SC host and shut down the SC service. service eucalyptus-cloud stop Repeat for any other machine hosting an SC. 6. Log in to the Walrus host and shut down the Walrus service. service eucalyptus-cloud stop 7. Log in to the CLC host and shut down the CLC service. service eucalyptus-cloud stop Upgrade Eucalyptus Packages To upgrade Eucalyptus packages: 1. Enter the following command on each machine running a Eucalyptus component: yum clean expire-cach 2. Enter the following command on each machine running a Eucalyptus component: yum update If you have previously customized your con®guration ®les, yum returns a warning, and installs the new con®guration ®les with a different name. This preserves your customizations. Before you continue, customize and rename the new con®guration ®les. Tip: For larger deployments, use a script to upgrade the component host machines. For example: for host in 28 29 32 33 35 39 40; do echo 192.168.51.$host; ssh 192.168.51.$host ©yum update -y $( rpm -qa | grep euca )© ; done 3. On the CLC, run the following command: yum groupinstall -y eucalyptus-cloud-controller CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 92 4. If you are a subscriber and use SAN, run the following command on the SC: yum install eucalyptus-enterprise-storage-san Start Eucalyptus 1. In the CLC, enter the following command. service eucalyptus-cloud start The process starts the database upgrade. Eucalyptus returns output similar to the following example. Starting Eucalyptus services: Attempting database upgrade from 3.0.1 at /var/lib/eucalyptus/upgrade/eucalyptus.backup.1326904600... # UPGRADE INFORMATION #================================================================================ # Old Version: 3.0.1 # New Version: 3.1.0 # Upgrade keys: false using: # Upgrade configuration: false using: # Upgrade database: true using: upgrade_db # Same version: false using: # Start upgrading: db Upgrading your database... . . . # Done upgrading: db done. [debug:0387] redirecting stdout to //var/log/eucalyptus/startup.log and stderr to //var/log/eucalyptus/startup.log done. Note: You might see some warnings in the output. These are a known issue. 2. Log in to the Walrus server and enter the following command: service eucalyptus-cloud start Eucalyptus returns output similar to the following example. Starting Eucalyptus services: Attempting database upgrade from 3.0.1 at /var/lib/eucalyptus/upgrade/eucalyptus.backup.1326905005... # UPGRADE INFORMATION #================================================================================ # Old Version: 3.0.1 # New Version: 3.1.0 # Upgrade keys: false using: # Upgrade configuration: false using: # Upgrade database: true using: upgrade_db # Same version: false using: # Start upgrading: db CLC is disabled. Skipping DB upgrade. # Done upgrading: db done. [debug:0387] redirecting stdout to //var/log/eucalyptus/startup.log and stderr to //var/log/eucalyptus/startup.log done. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 93 3. If you are using Eucalyptus with VMware support, start the VMware Broker. On the CC server, and enter the following: service eucalyptus-cloud start 4. Log in to the CC server and enter the following: service eucalyptus-cc start 5. If you have a multi-cluster setup, repeat the previous step for each cluster. 6. Repeat for each CC server. 7. Log in to the SC server and enter the following command: service eucalyptus-cloud start Eucalyptus returns output similar to the following example> Starting Eucalyptus services: Attempting database upgrade from 3.0.1 at /var/lib/eucalyptus/upgrade/eucalyptus.backup.1326905005... # UPGRADE INFORMATION #================================================================================ # Old Version: 3.0.1 # New Version: 3.1.0 # Upgrade keys: false using: # Upgrade configuration: false using: # Upgrade database: true using: upgrade_db # Same version: false using: # Start upgrading: db CLC is disabled. Skipping DB upgrade. # Done upgrading: db done. [debug:0387] redirecting stdout to //var/log/eucalyptus/startup.log and stderr to //var/log/eucalyptus/startup.log done. 8. Log in to an NC server and enter the following command: service eucalyptus-nc start 9. Repeat for each NC server. Verify the Components Verify that all Eucalyptus components are running and properly connected to one another. Check to make sure that the status of each component is enabled. To verify that all services are enabled: 1. Verify your Walruses: euca_conf --list-walruses Eucalyptus returns a list, as in the following example. WALRUS walrus walrus 192.168.51.28 ENABLED {} CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 94 2. Verify your CCs: euca_conf --list-clusters Eucalyptus returns a list, as in the following example. CLUSTER test00 test00_cc 192.168.51.29 ENABLED {} CLUSTER test01 test01_cc 192.168.51.35 ENABLED {} 3. Verify your SCs: euca_conf --list-scs Eucalyptus returns a list, as in the following example. STORAGECONTROLLER test01 test01_sc 192.168.51.39 ENABLED {} STORAGECONTROLLER test00 test00_sc 192.168.51.32 ENABLED {} 4. Make sure that NCs are presenting available resources to the CC. euca-describe-availability-zones verbose The returned output should a non-zero number in the free and max columns, as in the following example. AVAILABILITYZONE test00 192.168.51.29 arn:euca:eucalyptus:test00:cluster:test00_cc/ AVAILABILITYZONE |- vm types free / max cpu ram disk AVAILABILITYZONE |- m1.small 0004 / 0004 1 128 2 AVAILABILITYZONE |- c1.medium 0004 / 0004 1 256 5 AVAILABILITYZONE |- m1.large 0002 / 0002 2 512 10 AVAILABILITYZONE |- m1.xlarge 0002 / 0002 2 1024 20 AVAILABILITYZONE |- c1.xlarge 0001 / 0001 4 2048 20 AVAILABILITYZONE test01 192.168.51.35 arn:euca:eucalyptus:test01:cluster:test01_cc/ AVAILABILITYZONE |- vm types free / max cpu ram disk AVAILABILITYZONE |- m1.small 0004 / 0004 1 128 2 AVAILABILITYZONE |- c1.medium 0004 / 0004 1 256 5 AVAILABILITYZONE |- m1.large 0002 / 0002 2 512 10 AVAILABILITYZONE |- m1.xlarge 0002 / 0002 2 1024 20 AVAILABILITYZONE |- c1.xlarge 0001 / 0001 4 2048 20 Upgrade Credentials All users© credentials will still work after the upgrade. However the new Eucalyptus access control commands will not work until you upgrade your credentials. Other users must updates theirs as well. To update your credentials: 1. Enter the following command: euca_conf --get-credentials 2. Unzip the ®le unzip -o CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 95 RHEL 5 This section explains tasks to perform in order to upgrade to Eucalyptus 3.1.0 on RHEL 5 machines. Prepare the Configuration File To update the distro in RHEL 5: Important: The steps in this section should be performed on all machines with Eucalyptus installed. 1. Remove any hand-written repository ®les for earlier versions of Eucalyptus and Euca2ools from /etc/yum.repos.d. 2. Con®gure the Euca2ools package repository on each host that will run a Eucalyptus component or Euca2ools: rpm -Uvh http://downloads.eucalyptus.com/software/euca2ools/2.1/rhel/5/x86_64/euca2ools-release-2.1.noarch.rpm 3. Con®gure the Eucalyptus package repository on each host that will run a Eucalyptus component: rpm -Uvh http://downloads.eucalyptus.com/software/eucalyptus/3.1/rhel/5/x86_64/eucalyptus-release-3.1.noarch.rpm 4. Con®gure the EPEL package repository on each host that will run a Eucalyptus component or Euca2ools: rpm -Uvh http://downloads.eucalyptus.com/software/eucalyptus/3.1/rhel/5/x86_64/epel-release-5.noarch.rpm 5. Note: If upgrading from Eucalyptus 2.0, you can skip this step. This step is only necessary if you are upgrading from Eucalyptus 3.0. If you have a Eucalyptus subscription, you will have received a package that grants you access to VMware and SAN components. If you wish to use either of these components, install this package on each host that will run a Eucalyptus component using the following command. Otherwise, skip this step. rpm -Uvh eucalyptus-enterprise-release-3.1-1.noarch.rpm Shutdown Components To shut down Eucalyptus components: 1. Terminate any running instances, as in the following example: euca-terminate-instances 2. Tip: The following is an example that scripts the individual steps to shut down Eucalyptus components noted in this section. for x in $( euca_conf --list-nodes | tail -n +2 | awk ©{ print $1 }©); do ssh root@$x "service eucalyptus-nc stop"; done for x in $( euca_conf --list-clusters | tail -n +2 | awk ©{ print $2 }©); do ssh root@$x "service eucalyptus-cc stop"; done for x in $( euca_conf --list-scs | tail -n +2 | awk ©{ print $2 }©); do ssh root@$x "service eucalyptus-cloud stop"; done CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 96 for x in $( euca_conf --list-walruses | tail -n +2 | awk ©{ print $2 }©); do ssh root@$x "service eucalyptus-cloud stop"; done service eucalyptus-cloud stop If you don©t have ssh keys set up, you©ll have to type a lot of passwords during this. Log in to an NC host and shut down the NC service. service eucalyptus-nc stop Repeat for each machine hosting an NC. 3. Log in to a CC host and shut down the CC service. service eucalyptus-cc cleanstop Repeat for each machine hosting a CC. 4. Shut down the VMware Broker service on the CC host. service eucalyptus-cloud stop Tip: This command also shuts down a CLC, Walrus, and SC components co-located with the CC and VMware Broker to stop at the same time, in the correct order. Repeat for each machine hosting the VMware Broker. 5. Log in to an SC host and shut down the SC service. service eucalyptus-cloud stop Repeat for any other machine hosting an SC. 6. Log in to the Walrus host and shut down the Walrus service. service eucalyptus-cloud stop 7. Log in to the CLC host and shut down the CLC service. service eucalyptus-cloud stop Upgrade Eucalyptus Packages To upgrade Eucalyptus packages: 1. Enter the following command on each machine running a Eucalyptus component: yum clean expire-cach 2. Enter the following command on each machine running a Eucalyptus component: yum update If you have previously customized your con®guration ®les, yum returns a warning, and installs the new con®guration ®les with a different name. This preserves your customizations. Before you continue, customize and rename the new con®guration ®les. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 97 Tip: For larger deployments, use a script to upgrade the component host machines. For example: for host in 28 29 32 33 35 39 40; do echo 192.168.51.$host; ssh 192.168.51.$host ©yum update -y $( rpm -qa | grep euca )© ; done 3. On the CLC, run the following command: yum groupinstall -y eucalyptus-cloud-controller 4. If you are a subscriber and use SAN, run the following command on the SC: yum install eucalyptus-enterprise-storage-san Start Eucalyptus 1. In the CLC, enter the following command. service eucalyptus-cloud start The process starts the database upgrade. Eucalyptus returns output similar to the following example. Starting Eucalyptus services: Attempting database upgrade from 3.0.1 at /var/lib/eucalyptus/upgrade/eucalyptus.backup.1326904600... # UPGRADE INFORMATION #================================================================================ # Old Version: 3.0.1 # New Version: 3.1.0 # Upgrade keys: false using: # Upgrade configuration: false using: # Upgrade database: true using: upgrade_db # Same version: false using: # Start upgrading: db Upgrading your database... . . . # Done upgrading: db done. [debug:0387] redirecting stdout to //var/log/eucalyptus/startup.log and stderr to //var/log/eucalyptus/startup.log done. Note: You might see some warnings in the output. These are a known issue. 2. Log in to the Walrus server and enter the following command: service eucalyptus-cloud start Eucalyptus returns output similar to the following example. Starting Eucalyptus services: Attempting database upgrade from 3.0.1 at /var/lib/eucalyptus/upgrade/eucalyptus.backup.1326905005... # UPGRADE INFORMATION #================================================================================ # Old Version: 3.0.1 # New Version: 3.1.0 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 98 # Upgrade keys: false using: # Upgrade configuration: false using: # Upgrade database: true using: upgrade_db # Same version: false using: # Start upgrading: db CLC is disabled. Skipping DB upgrade. # Done upgrading: db done. [debug:0387] redirecting stdout to //var/log/eucalyptus/startup.log and stderr to //var/log/eucalyptus/startup.log done. 3. If you are using Eucalyptus with VMware support, start the VMware Broker. On the CC server, and enter the following: service eucalyptus-cloud start 4. Log in to the CC server and enter the following: service eucalyptus-cc start 5. If you have a multi-cluster setup, repeat the previous step for each cluster. 6. Repeat for each CC server. 7. Log in to the SC server and enter the following command: service eucalyptus-cloud start Eucalyptus returns output similar to the following example> Starting Eucalyptus services: Attempting database upgrade from 3.0.1 at /var/lib/eucalyptus/upgrade/eucalyptus.backup.1326905005... # UPGRADE INFORMATION #================================================================================ # Old Version: 3.0.1 # New Version: 3.1.0 # Upgrade keys: false using: # Upgrade configuration: false using: # Upgrade database: true using: upgrade_db # Same version: false using: # Start upgrading: db CLC is disabled. Skipping DB upgrade. # Done upgrading: db done. [debug:0387] redirecting stdout to //var/log/eucalyptus/startup.log and stderr to //var/log/eucalyptus/startup.log done. 8. Log in to an NC server and enter the following command: service eucalyptus-nc start 9. Repeat for each NC server. Verify the Components Verify that all Eucalyptus components are running and properly connected to one another. Check to make sure that the status of each component is enabled. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 99 To verify that all services are enabled: 1. Verify your Walruses: euca_conf --list-walruses Eucalyptus returns a list, as in the following example. WALRUS walrus walrus 192.168.51.28 ENABLED {} 2. Verify your CCs: euca_conf --list-clusters Eucalyptus returns a list, as in the following example. CLUSTER test00 test00_cc 192.168.51.29 ENABLED {} CLUSTER test01 test01_cc 192.168.51.35 ENABLED {} 3. Verify your SCs: euca_conf --list-scs Eucalyptus returns a list, as in the following example. STORAGECONTROLLER test01 test01_sc 192.168.51.39 ENABLED {} STORAGECONTROLLER test00 test00_sc 192.168.51.32 ENABLED {} 4. Make sure that NCs are presenting available resources to the CC. euca-describe-availability-zones verbose The returned output should a non-zero number in the free and max columns, as in the following example. AVAILABILITYZONE test00 192.168.51.29 arn:euca:eucalyptus:test00:cluster:test00_cc/ AVAILABILITYZONE |- vm types free / max cpu ram disk AVAILABILITYZONE |- m1.small 0004 / 0004 1 128 2 AVAILABILITYZONE |- c1.medium 0004 / 0004 1 256 5 AVAILABILITYZONE |- m1.large 0002 / 0002 2 512 10 AVAILABILITYZONE |- m1.xlarge 0002 / 0002 2 1024 20 AVAILABILITYZONE |- c1.xlarge 0001 / 0001 4 2048 20 AVAILABILITYZONE test01 192.168.51.35 arn:euca:eucalyptus:test01:cluster:test01_cc/ AVAILABILITYZONE |- vm types free / max cpu ram disk AVAILABILITYZONE |- m1.small 0004 / 0004 1 128 2 AVAILABILITYZONE |- c1.medium 0004 / 0004 1 256 5 AVAILABILITYZONE |- m1.large 0002 / 0002 2 512 10 AVAILABILITYZONE |- m1.xlarge 0002 / 0002 2 1024 20 AVAILABILITYZONE |- c1.xlarge 0001 / 0001 4 2048 20 RHEL 6 This section explains tasks to perform in order to upgrade to Eucalyptus 3.1.0 on RHEL 6 machines. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 100 Prepare the Configuration File To update the distro in RHEL 6: Important: The steps in this section should be performed on all machines with Eucalyptus installed. 1. Remove any hand-written repository ®les for earlier versions of Eucalyptus and Euca2ools from /etc/yum.repos.d. 2. Con®gure the Eucalyptus package repository on each host that will run a Eucalyptus component: yum install http://downloads.eucalyptus.com/software/eucalyptus/3.1/rhel/6/x86_64/eucalyptus-release-3.1.noarch.rpm 3. Con®gure the Euca2ools package repository on each host that will run a Eucalyptus component or Euca2ools: yum install http://downloads.eucalyptus.com/software/euca2ools/2.1/rhel/6/x86_64/euca2ools-release-2.1.noarch.rpm 4. Con®gure the EPEL package repository on each host that will run a Eucalyptus component or Euca2ools: yum install http://downloads.eucalyptus.com/software/eucalyptus/3.1/rhel/6/x86_64/epel-release-6.noarch.rpm 5. Con®gure the ELRepo repository on each host that will run Walrus: yum install http://downloads.eucalyptus.com/software/eucalyptus/3.1/rhel/6/x86_64/elrepo-release-6.noarch.rpm 6. Note: If upgrading from Eucalyptus 2.0, you can skip this step. This step is only necessary if you are upgrading from Eucalyptus 3.0. If you have a Eucalyptus subscription, you will have received a package that grants you access to VMware and SAN components. If you wish to use either of these components, install this package on each host that will run a Eucalyptus component using the following command. Otherwise, skip this step. rpm -Uvh eucalyptus-enterprise-release-3.1-1.noarch.rpm Shutdown Components To shut down Eucalyptus components: 1. Terminate any running instances, as in the following example: euca-terminate-instances 2. Tip: The following is an example that scripts the individual steps to shut down Eucalyptus components noted in this section. for x in $( euca_conf --list-nodes | tail -n +2 | awk ©{ print $1 }©); do ssh root@$x "service eucalyptus-nc stop"; done for x in $( euca_conf --list-clusters | tail -n +2 | awk ©{ print $2 }©); do ssh root@$x "service eucalyptus-cc stop"; done for x in $( euca_conf --list-scs | tail -n +2 | awk ©{ print $2 }©); CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 101 do ssh root@$x "service eucalyptus-cloud stop"; done for x in $( euca_conf --list-walruses | tail -n +2 | awk ©{ print $2 }©); do ssh root@$x "service eucalyptus-cloud stop"; done service eucalyptus-cloud stop If you don©t have ssh keys set up, you©ll have to type a lot of passwords during this. Log in to an NC host and shut down the NC service. service eucalyptus-nc stop Repeat for each machine hosting an NC. 3. Log in to a CC host and shut down the CC service. service eucalyptus-cc cleanstop Repeat for each machine hosting a CC. 4. Shut down the VMware Broker service on the CC host. service eucalyptus-cloud stop Tip: This command also shuts down a CLC, Walrus, and SC components co-located with the CC and VMware Broker to stop at the same time, in the correct order. Repeat for each machine hosting the VMware Broker. 5. Log in to an SC host and shut down the SC service. service eucalyptus-cloud stop Repeat for any other machine hosting an SC. 6. Log in to the Walrus host and shut down the Walrus service. service eucalyptus-cloud stop 7. Log in to the CLC host and shut down the CLC service. service eucalyptus-cloud stop Upgrade Eucalyptus Packages To upgrade Eucalyptus packages: 1. Enter the following command on each machine running a Eucalyptus component: yum clean expire-cach 2. Enter the following command on each machine running a Eucalyptus component: yum update CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 102 If you have previously customized your con®guration ®les, yum returns a warning, and installs the new con®guration ®les with a different name. This preserves your customizations. Before you continue, customize and rename the new con®guration ®les. Tip: For larger deployments, use a script to upgrade the component host machines. For example: for host in 28 29 32 33 35 39 40; do echo 192.168.51.$host; ssh 192.168.51.$host ©yum update -y $( rpm -qa | grep euca )© ; done 3. On the CLC, run the following command: yum groupinstall -y eucalyptus-cloud-controller 4. If you are a subscriber and use SAN, run the following command on the SC: yum install eucalyptus-enterprise-storage-san Start Eucalyptus 1. In the CLC, enter the following command. service eucalyptus-cloud start The process starts the database upgrade. Eucalyptus returns output similar to the following example. Starting Eucalyptus services: Attempting database upgrade from 3.0.1 at /var/lib/eucalyptus/upgrade/eucalyptus.backup.1326904600... # UPGRADE INFORMATION #================================================================================ # Old Version: 3.0.1 # New Version: 3.1.0 # Upgrade keys: false using: # Upgrade configuration: false using: # Upgrade database: true using: upgrade_db # Same version: false using: # Start upgrading: db Upgrading your database... . . . # Done upgrading: db done. [debug:0387] redirecting stdout to //var/log/eucalyptus/startup.log and stderr to //var/log/eucalyptus/startup.log done. Note: You might see some warnings in the output. These are a known issue. 2. Log in to the Walrus server and enter the following command: service eucalyptus-cloud start Eucalyptus returns output similar to the following example. Starting Eucalyptus services: Attempting database upgrade from 3.0.1 at /var/lib/eucalyptus/upgrade/eucalyptus.backup.1326905005... CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 103 # UPGRADE INFORMATION #================================================================================ # Old Version: 3.0.1 # New Version: 3.1.0 # Upgrade keys: false using: # Upgrade configuration: false using: # Upgrade database: true using: upgrade_db # Same version: false using: # Start upgrading: db CLC is disabled. Skipping DB upgrade. # Done upgrading: db done. [debug:0387] redirecting stdout to //var/log/eucalyptus/startup.log and stderr to //var/log/eucalyptus/startup.log done. 3. If you are using Eucalyptus with VMware support, start the VMware Broker. On the CC server, and enter the following: service eucalyptus-cloud start 4. Log in to the CC server and enter the following: service eucalyptus-cc start 5. If you have a multi-cluster setup, repeat the previous step for each cluster. 6. Repeat for each CC server. 7. Log in to the SC server and enter the following command: service eucalyptus-cloud start Eucalyptus returns output similar to the following example> Starting Eucalyptus services: Attempting database upgrade from 3.0.1 at /var/lib/eucalyptus/upgrade/eucalyptus.backup.1326905005... # UPGRADE INFORMATION #================================================================================ # Old Version: 3.0.1 # New Version: 3.1.0 # Upgrade keys: false using: # Upgrade configuration: false using: # Upgrade database: true using: upgrade_db # Same version: false using: # Start upgrading: db CLC is disabled. Skipping DB upgrade. # Done upgrading: db done. [debug:0387] redirecting stdout to //var/log/eucalyptus/startup.log and stderr to //var/log/eucalyptus/startup.log done. 8. Log in to an NC server and enter the following command: service eucalyptus-nc start 9. Repeat for each NC server. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 104 Verify the Components Verify that all Eucalyptus components are running and properly connected to one another. Check to make sure that the status of each component is enabled. To verify that all services are enabled: 1. Verify your Walruses: euca_conf --list-walruses Eucalyptus returns a list, as in the following example. WALRUS walrus walrus 192.168.51.28 ENABLED {} 2. Verify your CCs: euca_conf --list-clusters Eucalyptus returns a list, as in the following example. CLUSTER test00 test00_cc 192.168.51.29 ENABLED {} CLUSTER test01 test01_cc 192.168.51.35 ENABLED {} 3. Verify your SCs: euca_conf --list-scs Eucalyptus returns a list, as in the following example. STORAGECONTROLLER test01 test01_sc 192.168.51.39 ENABLED {} STORAGECONTROLLER test00 test00_sc 192.168.51.32 ENABLED {} 4. Make sure that NCs are presenting available resources to the CC. euca-describe-availability-zones verbose The returned output should a non-zero number in the free and max columns, as in the following example. AVAILABILITYZONE test00 192.168.51.29 arn:euca:eucalyptus:test00:cluster:test00_cc/ AVAILABILITYZONE |- vm types free / max cpu ram disk AVAILABILITYZONE |- m1.small 0004 / 0004 1 128 2 AVAILABILITYZONE |- c1.medium 0004 / 0004 1 256 5 AVAILABILITYZONE |- m1.large 0002 / 0002 2 512 10 AVAILABILITYZONE |- m1.xlarge 0002 / 0002 2 1024 20 AVAILABILITYZONE |- c1.xlarge 0001 / 0001 4 2048 20 AVAILABILITYZONE test01 192.168.51.35 arn:euca:eucalyptus:test01:cluster:test01_cc/ AVAILABILITYZONE |- vm types free / max cpu ram disk AVAILABILITYZONE |- m1.small 0004 / 0004 1 128 2 AVAILABILITYZONE |- c1.medium 0004 / 0004 1 256 5 AVAILABILITYZONE |- m1.large 0002 / 0002 2 512 10 AVAILABILITYZONE |- m1.xlarge 0002 / 0002 2 1024 20 AVAILABILITYZONE |- c1.xlarge 0001 / 0001 4 2048 20 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 105 Ubuntu 10.04 LTS This section explains tasks to perform in order to upgrade to Eucalyptus 3.1.0 on Ubuntu 10.04 LTS machines. Prepare the Configuration File To update the distro in Ubuntu 10.04 LTS: Important: The steps in this section should be performed on all machines with Eucalyptus installed. 1. Tip: If you are a Eucalyptus subscriber, you should have received a deb package ®le that you will need to install. If you are not a Eucalyptus subscriber, skip this step. On all servers, copy over your deb package ®le and run the following command: dpkg -i eucalyptus-enterprise-release_3.1-*lucid_all.deb 2. Create a ®le in /etc/apt/sources.list.d called eucalyptus.list with the following content: deb http://downloads.eucalyptus.com/software/eucalyptus/3.1/ubuntu lucid main 3. On all machines that will run either Eucalyptus or Euca2ools, create a ®le in /etc/apt/sources.list.d called euca2ools.list with the following content: deb http://downloads.eucalyptus.com/software/euca2ools/2.1/ubuntu lucid main Shutdown Components To shut down Eucalyptus components: 1. Terminate any running instances, as in the following example: euca-terminate-instances 2. Tip: The following is an example that scripts the individual steps to shut down Eucalyptus components noted in this section. for x in $( euca_conf --list-nodes | tail -n +2 | awk ©{ print $1 }©); do ssh root@$x "service eucalyptus-nc stop"; done for x in $( euca_conf --list-clusters | tail -n +2 | awk ©{ print $2 }©); do ssh root@$x "service eucalyptus-cc stop"; done for x in $( euca_conf --list-scs | tail -n +2 | awk ©{ print $2 }©); do ssh root@$x "service eucalyptus-cloud stop"; done for x in $( euca_conf --list-walruses | tail -n +2 | awk ©{ print $2 }©); do ssh root@$x "service eucalyptus-cloud stop"; done service eucalyptus-cloud stop If you don©t have ssh keys set up, you©ll have to type a lot of passwords during this. Log in to an NC host and shut down the NC service. service eucalyptus-nc stop Repeat for each machine hosting an NC. CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 106 3. Log in to a CC host and shut down the CC service. service eucalyptus-cc cleanstop Repeat for each machine hosting a CC. 4. Shut down the VMware Broker service on the CC host. service eucalyptus-cloud stop Tip: This command also shuts down a CLC, Walrus, and SC components co-located with the CC and VMware Broker to stop at the same time, in the correct order. Repeat for each machine hosting the VMware Broker. 5. Log in to an SC host and shut down the SC service. service eucalyptus-cloud stop Repeat for any other machine hosting an SC. 6. Log in to the Walrus host and shut down the Walrus service. service eucalyptus-cloud stop 7. Log in to the CLC host and shut down the CLC service. service eucalyptus-cloud stop Upgrade Eucalyptus Packages To upgrade the Eucalyptus packages, perform the following steps. 1. Enter the following command to upgrade the Eucalyptus packages: apt-get dist-upgrade If you have previously customized your con®guration ®les, apt returns a warning, and installs the new con®guration ®les with a different name. This preserves your customizations. Before you continue, customize and rename the new con®guration ®les. Tip: For larger deployments, use a script to upgrade the component host machines. For example: for host in 28 29 32 33 35 39 40; do echo 192.168.51.$host; ssh 192.168.51.$host ©apt-get dist-upgrade -y $( rpm -qa | grep euca )© ; done 2. Run the following command to install the required libraries for the upgrade to work properly: apt-get install eucalyptus-enterprise-libs CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 107 Start Eucalyptus 1. In the CLC, enter the following command. service eucalyptus-cloud start The process starts the database upgrade. Eucalyptus returns output similar to the following example. Starting Eucalyptus services: Attempting database upgrade from 3.0.1 at /var/lib/eucalyptus/upgrade/eucalyptus.backup.1326904600... # UPGRADE INFORMATION #================================================================================ # Old Version: 3.0.1 # New Version: 3.1.0 # Upgrade keys: false using: # Upgrade configuration: false using: # Upgrade database: true using: upgrade_db # Same version: false using: # Start upgrading: db Upgrading your database... . . . # Done upgrading: db done. [debug:0387] redirecting stdout to //var/log/eucalyptus/startup.log and stderr to //var/log/eucalyptus/startup.log done. Note: You might see some warnings in the output. These are a known issue. 2. Log in to the Walrus server and enter the following command: service eucalyptus-cloud start Eucalyptus returns output similar to the following example. Starting Eucalyptus services: Attempting database upgrade from 3.0.1 at /var/lib/eucalyptus/upgrade/eucalyptus.backup.1326905005... # UPGRADE INFORMATION #================================================================================ # Old Version: 3.0.1 # New Version: 3.1.0 # Upgrade keys: false using: # Upgrade configuration: false using: # Upgrade database: true using: upgrade_db # Same version: false using: # Start upgrading: db CLC is disabled. Skipping DB upgrade. # Done upgrading: db done. [debug:0387] redirecting stdout to //var/log/eucalyptus/startup.log and stderr to //var/log/eucalyptus/startup.log done. 3. If you are using Eucalyptus with VMware support, start the VMware Broker. On the CC server, and enter the following: service eucalyptus-cloud start CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 108 4. Log in to the CC server and enter the following: service eucalyptus-cc start 5. If you have a multi-cluster setup, repeat the previous step for each cluster. 6. Repeat for each CC server. 7. Log in to the SC server and enter the following command: service eucalyptus-cloud start Eucalyptus returns output similar to the following example> Starting Eucalyptus services: Attempting database upgrade from 3.0.1 at /var/lib/eucalyptus/upgrade/eucalyptus.backup.1326905005... # UPGRADE INFORMATION #================================================================================ # Old Version: 3.0.1 # New Version: 3.1.0 # Upgrade keys: false using: # Upgrade configuration: false using: # Upgrade database: true using: upgrade_db # Same version: false using: # Start upgrading: db CLC is disabled. Skipping DB upgrade. # Done upgrading: db done. [debug:0387] redirecting stdout to //var/log/eucalyptus/startup.log and stderr to //var/log/eucalyptus/startup.log done. 8. Log in to an NC server and enter the following command: service eucalyptus-nc start 9. Repeat for each NC server. Verify the Components Verify that all Eucalyptus components are running and properly connected to one another. Check to make sure that the status of each component is enabled. To verify that all services are enabled: 1. Verify your Walruses: euca_conf --list-walruses Eucalyptus returns a list, as in the following example. WALRUS walrus walrus 192.168.51.28 ENABLED {} 2. Verify your CCs: euca_conf --list-clusters CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 109 Eucalyptus returns a list, as in the following example. CLUSTER test00 test00_cc 192.168.51.29 ENABLED {} CLUSTER test01 test01_cc 192.168.51.35 ENABLED {} 3. Verify your SCs: euca_conf --list-scs Eucalyptus returns a list, as in the following example. STORAGECONTROLLER test01 test01_sc 192.168.51.39 ENABLED {} STORAGECONTROLLER test00 test00_sc 192.168.51.32 ENABLED {} 4. Make sure that NCs are presenting available resources to the CC. euca-describe-availability-zones verbose The returned output should a non-zero number in the free and max columns, as in the following example. AVAILABILITYZONE test00 192.168.51.29 arn:euca:eucalyptus:test00:cluster:test00_cc/ AVAILABILITYZONE |- vm types free / max cpu ram disk AVAILABILITYZONE |- m1.small 0004 / 0004 1 128 2 AVAILABILITYZONE |- c1.medium 0004 / 0004 1 256 5 AVAILABILITYZONE |- m1.large 0002 / 0002 2 512 10 AVAILABILITYZONE |- m1.xlarge 0002 / 0002 2 1024 20 AVAILABILITYZONE |- c1.xlarge 0001 / 0001 4 2048 20 AVAILABILITYZONE test01 192.168.51.35 arn:euca:eucalyptus:test01:cluster:test01_cc/ AVAILABILITYZONE |- vm types free / max cpu ram disk AVAILABILITYZONE |- m1.small 0004 / 0004 1 128 2 AVAILABILITYZONE |- c1.medium 0004 / 0004 1 256 5 AVAILABILITYZONE |- m1.large 0002 / 0002 2 512 10 AVAILABILITYZONE |- m1.xlarge 0002 / 0002 2 1024 20 AVAILABILITYZONE |- c1.xlarge 0001 / 0001 4 2048 20 CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix A: Upgrading Eucalyptus | 110 Appendix B: Creating a Local Eucalyptus Package Repository In certain situations (such as installing Eucalyptus from behind a ®rewall), you might need to install Eucalyptus from a local repository. This section augments the standard installation instructions with additional instructions for downloading and installing Eucalyptus from a local repository. CentOS 5 Local Installation This task augments the existing installation instructions with additional steps needed to install Eucalyptus from a local repository. This task is not standalone; it augments the existing installation instructions. To install Eucalyptus from behind a ®rewall on CentOS 5: 1. Download the Eucalyptus repository to a local directory. For example: wget -r --no-parent --certificate /etc/pki/tls/certs/eucalyptus-enterprise.crt --private-key /etc/pki/tls/private/eucalyptus-enterprise.key http://downloads.eucalyptus.com/ software/eucalyptus/3.1/centos/5/x86_64/eucalyptus-release-3.1.noarch.rpm -P /root/3.1-centos5-packages 2. In step 1 of the instructions, modify the baseurl to point to the local repository: baseurl=file:///root/3.1-centos5-packages 3. Proceed with the existing installation instructions. Install euca2ools 4. Download euca2ools: wget -r --no-parent http://downloads.eucalyptus.com/software/ euca2ools/2.1/centos/5/x86_64/euca2ools-release-2.1.noarch.rpm -P /root/local-euca2ools-repo 5. In step 2 of the installation instructions, modify the baseurl to point to the local repository: baseurl=file:///root/local-euca2ools-repo/downloads.eucalyptus.com/software/euca2ools/2.1/centos/5/x86_64 6. Run yum update. CentOS 6 Local Installation This task augments the existing installation instructions with additional steps needed to install Eucalyptus from a local repository. This task is not standalone; it augments the existing installation instructions. To install Eucalyptus from behind a ®rewall on CentOS 6: CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix B: Creating a Local Eucalyptus Package Repository | 111 1. Download the Eucalyptus repository to a local directory. For example: wget -r --no-parent --certificate /etc/pki/tls/certs/eucalyptus-enterprise.crt --private-key /etc/pki/tls/private/eucalyptus-enterprise.key http://downloads.eucalyptus.com/ software/eucalyptus/3.1/centos/6/x86_64/eucalyptus-release-3.1.noarch.rpm -P /root/3.1-centos6-packages 2. In step 1 of the instructions, modify the baseurl to point to the local repository: baseurl=file:///root/3.1-centos6-packages 3. Proceed with the existing installation instructions. Install euca2ools 4. Download euca2ools: wget -r --no-parent http://downloads.eucalyptus.com/software/ euca2ools/2.1/centos/6/x86_64/euca2ools-release-2.1.noarch.rpm -P /root/local-euca2ools-repo 5. In step 2 of the installation instructions, modify the baseurl to point to the local repository: baseurl=file:///root/local-euca2ools-repo/downloads.eucalyptus.com/software/euca2ools/2.1/centos/6/x86_64 6. Run yum update. RHEL 5 Local Installation This task augments the existing installation instructions with additional steps needed to install Eucalyptus from a local repository. This task is not standalone; it augments the existing installation instructions. To install Eucalyptus from behind a ®rewall on RHEL 5: 1. Download the Eucalyptus repository to a local directory. For example: wget -r --no-parent --certificate /etc/pki/tls/certs/eucalyptus-enterprise.crt --private-key /etc/pki/tls/private/eucalyptus-enterprise.key http://downloads.eucalyptus.com/ software/eucalyptus/3.1/rhel/5/x86_64/eucalyptus-release-3.1.noarch.rpm -P /root/3.1-rhel5-packages 2. In step 1 of the instructions, modify the baseurl to point to the local repository. For example: baseurl=file:///root/3.1/3.1-rhel5-packages 3. Proceed with the existing installation instructions. Install euca2ools 4. Download euca2ools: wget -r --no-parent http://downloads.eucalyptus.com/software/ euca2ools/2.1/rhel/5/x86_64/euca2ools-release-2.1.noarch.rpm -P /root/local-euca2ools-repo CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix B: Creating a Local Eucalyptus Package Repository | 112 5. In step 2 of the installation instructions, modify the baseurl to point to the local repository: baseurl=file:///root/local-euca2ools-repo/downloads.eucalyptus.com/software/euca2ools/2.1/rhel/5/x86_64 6. Run yum update. RHEL 6 Local Installation This task augments the existing installation instructions with additional steps needed to install Eucalyptus from a local repository. This task is not standalone; it augments the existing installation instructions. To install Eucalyptus from behind a ®rewall on RHEL 6: 1. Download the Eucalyptus repository to a local directory. For example: wget -r --no-parent --certificate /etc/pki/tls/certs/eucalyptus-enterprise.crt --private-key /etc/pki/tls/private/eucalyptus-enterprise.key http://downloads.eucalyptus.com/ software/eucalyptus/3.1/rhel/6/x86_64/eucalyptus-release-3.1.noarch.rpm -P /root/3.1-rhel6-packages 2. In step 1 of the instructions, modify the baseurl to point to the local repository: baseurl=file:///root/3.1-rhel6-packages 3. Proceed with the existing installation instructions. Install euca2ools 4. Download euca2ools: wget -r --no-parent http://downloads.eucalyptus.com/software/ euca2ools/2.1/rhel/6/x86_64/euca2ools-release-2.1.noarch.rpm -P /root/local-euca2ools-repo 5. In step 2 of the installation instructions, modify the baseurl to point to the local repository: baseurl=file:///root/local-euca2ools-repo/downloads.eucalyptus.com/software/euca2ools/2.1/rhel/6/x86_64 6. Run yum update. Ubuntu Local Installation This task augments the existing installation instructions with additional steps needed to install Eucalyptus from a local repository. This task is not standalone; it augments the existing installation instructions. To install Eucalyptus from behind a ®rewall on Ubuntu 10.04 and 12.04 LTS: 1. Download the Eucalyptus repository: wget -r --no-parent --certificate /etc/pki/tls/certs/eucalyptus-enterprise.crt --private-key /etc/pki/tls/private/eucalyptus-enterprise.key CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix B: Creating a Local Eucalyptus Package Repository | 113 http://downloads.eucalyptus.com/software/eucalyptus/3.1/ubuntu -P /root/ubuntu-packages 2. In step 5 of the instructions, modify the URL to point to the local repository: file:///root/ubuntu-packages/downloads.eucalyptus.com/software/enterprise/3.1/ubuntu 3. Proceed with the existing installation instructions. Install euca2ools 4. Download euca2ools: wget -r --no-parent http://downloads.eucalyptus.com/software/euca2ools/2.1/ubuntu -P /root/local-euca2ools-repo 5. In step 2 of the installation instructions, modify the baseurl to point to the local repository: file:///root/local-euca2ools-repo/downloads.eucalyptus.com/software/euca2ools/2.1/ubuntu 6. Run apt-get update: apt-get update CC-BY-SA, Eucalyptus Systems, Inc. Eucalyptus | Appendix B: Creating a Local Eucalyptus Package Repository | 114
还剩113页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf

pdf贡献者

hujunhu

贡献于2012-07-29

下载需要 8 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf