添加主机¶

添加主机能为来宾VMs提供更多的性能。更多需求与说明请参阅 “添加主机”。

主机的维护计划与维护模式¶

你可以使一台主机进入维护模式。当激活维护模式时，这台主机将不会接纳新的来宾VMs，同时上面的VMs会无缝地迁移到其他非维护模式的主机上。这个迁移使用在线迁移技术并且不会中断用户的操作。

禁用和启用Zones，Pods和Clusters¶

你可以启用或禁用一个zone，pod或者cluster而不用永久的从云中移除他们。这对于维护或者当云中一部分架构的可靠性有问题的时候很有用。禁用状态下的zone，pod或cluster不会接受新的分配，除非其状态变为启用。当一个zone，pod或cluster是初次添加到云中的，默认的情况下它是禁用的。

要禁用和启用一个zone，pod或者cluster：

1. 使用管理员权限的账号登录到CloudStack
2. 在左侧导航栏中，点击基础架构
3. 点击区域中的查看更多。
4. 如果你要禁用或启用一个zone，请在列表里找到zone的名称，然后点击启用/禁用按钮。
5. 如果你要禁用或启用一个pod或者cluster，点击包含该pod或cluster的zone名称。
6. 点击计算这个标签。
7. 在示意图中的Pods或者Clusters节点，点击查看所有。
8. 点击列表中的pod或者cluster名称。
9. 点击启用/禁用按钮。

移除主机¶

主机在需要的时候可以被移除。这个过程取决于主机所使用的hypervisor类型。

重新安装主机¶

你可以在将主机进入维护模式并移除它之后重新安装系统。如果主机是宕机状态而不能进入维护模式，在重装它之前仍然能被移除。

在主机上维护Hypervisors¶

当主机上运行了hypervisor软件，请确保安装了供应商提供的所有修补程序。请通过供应商跟踪虚拟化平台的补丁发布情况，一旦发布，请尽快打上补丁。CloudStack不会跟踪或通知您所需要的虚拟化平台补丁。您的主机及时打上最新虚拟化平台补丁是非常重要的。虚拟化平台厂商很可能会拒绝支持未打最新补丁的系统。

（XenServer）更多信息，请参考`CloudStack知识库中高度推荐的XenServer修补程序 <http://docs.cloudstack.org/Knowledge_Base/Possible_VM_corruption_if_XenServer_Hotfix_is_not_Applied/Highly_Recommended_Hotfixes_for_XenServer_5.6_SP2>`_.

更改主机密码¶

数据库中的XenServer主机，KVM主机或者vShpere主机密码可能会被变更。注意群集中的所有节点密码必须一致。

用户名和密码要更改一台主机的密码：

1. 让群集中所有的主机状态保持一致。

2. 更改群集中所有主机的密码。此刻主机上的密码与CloudStack已知的密码不一致。两个密码不一致的话会导致群集上的操作失败。

3. if the password in the database is encrypted, it is (likely) necessary to encrypt the new password using the database key before adding it to the database.

   java -classpath /usr/share/cloudstack-common/lib/jasypt-1.9.0.jar \
   org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI \
   encrypt.sh input="newrootpassword" \
   password="databasekey" \
   verbose=false
   

4. 获取群集中你更改了密码的主机ID列表。你必须访问数据库来获取这些ID。为每个你要更改密码的主机名（或者vSphere群集） “h”，执行：

   mysql> SELECT id FROM cloud.host WHERE name like '%h%';
   

5. This should return a single ID. Record the set of such IDs for these hosts. Now retrieve the host_details row id for the host

   mysql> SELECT * FROM cloud.host_details WHERE name='password' AND host_id={previous step ID};
   

6. Update the passwords for the host in the database. In this example, we change the passwords for hosts with host IDs 5 and 12 and host_details IDs 8 and 22 to “password”.

   mysql> UPDATE cloud.host_details SET value='password' WHERE id=8 OR id=22;
   

超配和服务方案限制¶

（支持XenServer、KVM和VMware）

CPU和内存（RAM）超配直接影响每个群集中主机上可以运行的VMs数量。这样可以帮助优化资源的使用。依靠增加超配比率，能使使资源更充分的被利用。如果比率设为1，那么表示没有使用超配。

管理员也可以在cpu.overprovisioning.factor和mem.overprovisioning.factor这两个全局配置变量中设置全局默认超配比率。默认的值是1：默认情况下超配是关闭的。

超配比率是由CloudStack的容量计算器动态调整的。比如：

容量=2GB 超配系数=2 超配后容量=4GB

按照这个配置，假设你部署了3个VMs，每个VM 1GB：

已使用=3GB 空闲=1GB

管理员可以在每个群集中指定一个内存超配比率，也可以同时指定CPU和内存超配比率。

在任何已有的云中，hypervisor、存储和硬件配置影响每个主机上VMs最佳数量。同一个云中的每个群集的这些配置可能都不同。单一的全局超配设置不能为云中所有的群集提供最佳效果。它只能作为一个基线。无论CloudStack使用哪种算法来放置一个VM，每个群集都提供了细颗粒度的设置以提供更好的资源效果。

超配设置和专用资源（对一个账号分配一个特定的群集）一起使用时能对不同用户有效的提供的不同服务级别。比如，一个账号购买了比较高级别的服务，那么分配给他一个超配比率为1的专用群集，购买低级别服务的账号分配一个比率为2的群集。

当一个新主机被添加到群集中，CloudStack假设配置了超配的群集中的主机能够提供CPU和RAM的超配能力。这个要靠管理员来决定主机是否真的能够提供设置的超配级别。

VLAN供应¶

CloudStack能在主机上自动创建和销毁桥接至VLAN的网络接口。一般来说，管理员不需要介入此处理过程。

CloudStack根据hypervisor类型的不同，管理VLANs的方式也不同。对于XenServer或者KVM来说，只在使用VLANs的主机上创建VLANs，并且当所有使用VLANs的来宾虚机被销毁或者移动至其他主机的时候，这些VLANs就会被销毁。

vSphere上的VLANs是在群集中的所有主机上配置的，不管主机上有没有使用VLAN的来宾虚机在运行。这样允许管理员在vCenter中不需在目标主机上创建VLAN就可以执行在线迁移和其他功能。此外，当主机不再需要的时候VLANs也不会被移除。

你能够使用由不同的拥有二层网络结构的物理网络提供同样的VLANs，比如交换机。比如，在对高级zone中部署物理网络A和B的时候，你可以指定VLAN范围为500-1000。如果你的VLANs用尽了，这个功能允许你在不同的物理网卡上设置追加一个二层物理网络并且使用同样的VLANs设置。另一个优点是你可以在不同的物理网卡上为不同的客户使用同样的IPs设置，每个都有自己的路由器和来宾网络。

Out-of-band Management¶

CloudStack provides Root admins the ability to configure and use supported out-of-band management interface (e.g. IPMI, iLO, DRAC, etc.) on a physical host to manage host power operations such as on, off, reset etc. By default, IPMI 2.0 baseboard controller are supported out of the box with IPMITOOL out-of-band management driver in CloudStack that uses ipmitool for performing IPMI 2.0 management operations.

Following are some global settings that control various aspects of this feature.

A change in outofbandmanagement.sync.poolsize settings requires restarting of management server(s) as the thread pool and a background (power state) sync thread are configured during load time when CloudStack management server starts. Rest of the global settings can be changed without requiring restarting of management server(s).

The outofbandmanagement.sync.poolsize is the maximum number of ipmitool background power state scanners that can run at a time. Based on the maximum number of hosts you’ve, you can increase/decrease the value depending on how much stress your management server host can endure. It will take atmost number of total out-of-band-management enabled hosts in a round * outofbandmanagement.action.timeout / outofbandmanagement.sync.poolsize seconds to complete a background power-state sync scan in a single round.

In order to use this feature, the Root admin needs to first configure out-of-band management for a host using either the UI or the configureOutOfBandManagement API. Next, the Root admin needs to enable it. The feature can be enabled or disabled across a zone or a cluster or a host,

Once out-of-band management is configured and enabled for a host (and provided not disabled at zone or cluster level), Root admins would be able to issue power management actions such as on, off, reset, cycle, soft and status.

If a host is in maintenance mode, Root admins are still allowed to perform power management actions but in the UI a warning is displayed.

Server Address Usage¶

Historically, when multiple management servers are used a tcp-LB is used on port 8250 (default) of the management servers and the VIP/LB-IP is used as the host setting to be used by various CloudStack agents such as the KVM, CPVM, SSVM agents, who connect to the host on port 8250. However, starting CloudStack 4.11+ the host setting can accept comma separated list of management server IPs to which new CloudStack hosts/agents will get a shuffled list of the same to which they can cycle reconnections in a round-robin way.

Securing Process¶

Agents while making connections/reconnections to management server will only validate server certificate and be able to present client certificate (issued to them) when cloud.jks is accessible to them. On older hosts that are setup prior to this feature the keystore won’t be available, however, they can still connect to management server(s) if ca.plugin.root.auth.strictness is set to false. Management server(s) will check and setup their own cloud.jks keystore on startup, this keystore will be used for connecting to peer management server(s).

When a new host is being setup, such as adding a KVM host or starting a systemvm host, the CA framework kicks in and uses ssh to execute keystore-setup to generate a new keystore file cloud.jks.new, save a random passphrase of the keystore in the agent’s properties file and a CSR cloud.csr file. The CSR is then used to issue certificate for that agent/host and ssh is used to execute keystore-cert-import to import the issued certificate along with the CA certificate(s), the keystore is that renamed as cloud.jks replacing an previous keystore in-use. During this process, keys and certificates files are also stored in cloud.key, cloud.crt, cloud.ca.crt in the agent’s configuration directory.

When hosts are added out-of-band, for example a KVM host that is setup first outside of CloudStack and added to a cluster, the keystore file will not be available however the keystore and security could be setup by using keystore utility scripts manually. The keystore-setup can be ran first to generate a keystore and a CSR, then CloudStack CA can be used to issue certificate by providing the CSR to the issueCertificate API, and finally issued certificate and CA certificate(s) can be imported to the keystore using keystore-cert-import script.

Following lists the usage of these scripts, when using these script use full paths, use the final keystore filename as cloud.jks, and the certificate/key content need to be encoded and provided such that newlines are replace with ^ and space are replaced with ~:

keystore-setup <properties file> <keystore file> <passphrase> <validity> <csr file>

keystore-cert-import <properties file> <keystore file> <mode: ssh|agent> <cert file> <cert content> <ca-cert file> <ca-cert content> <private-key file> <private key content:optional>

Starting 4.11.1, a KVM host is considered secured when it has its keystore and certificates setup for both the agent and libvirtd process. A secured host will only allow and initiate TLS enabled live VM migration. This requires libvirtd to listen on default port 16514, and the port to be allowed in the firewall rules. Certificate renewal (using the provisionCertificate API) will restart both the libvirtd process and agent after deploying new certificates.