Apache CloudStack 4.0.2 管理员指南

需积分: 10 65 浏览量更新于2024-07-25 收藏 1.94MB PDF 举报

"Apache CloudStack 4.0.2 管理员指南" Apache CloudStack 是一个开源的云计算管理平台，用于构建、管理和提供基础设施即服务（IaaS）的私有云和公共云。该软件提供了对计算、存储、网络资源的自动化管理，并支持多种虚拟化技术，如 XenServer、KVM、VMware 和 Hyper-V。Apache CloudStack 4.0.2 版本是这个项目在 Apache 软件基金会（ASF）的一个孵化项目，它遵循严格的开源许可协议，即 Apache 2.0 许可证。管理员指南是针对那些负责部署、配置和维护 CloudStack 环境的专业人员。这份指南将涵盖以下关键知识点： 1. **安装与配置**：包括如何设置 CloudStack 环境，配置管理服务器、数据库、存储系统和网络。管理员需要理解硬件和软件的需求，以及如何准备这些基础设施以支持 CloudStack。 2. **云服务创建**：通过 CloudStack，管理员可以定义虚拟机模板、网络服务和安全策略，以满足不同用户和业务需求。这涉及到了解如何创建和管理虚拟数据中心资源。 3. **用户管理与权限**：CloudStack 提供了多租户模型，允许管理员创建用户账户、组织结构和权限策略。理解如何有效地管理用户访问和控制是至关重要的。 4. **资源调度与分配**：CloudStack 自动化了资源调度，如虚拟机的启动、停止、迁移等。管理员需要掌握如何配置这些策略，以优化资源利用率和性能。 5. **监控与日志**：CloudStack 提供了丰富的监控和报警功能，帮助管理员实时了解系统的运行状态。了解如何查看和分析日志数据，对故障排查和性能调优至关重要。 6. **高可用性与容错**：为了确保服务的持续可用性，管理员需要了解如何设置 CloudStack 的高可用性架构，包括主控服务器的冗余和存储的故障切换机制。 7. **更新与维护**：升级和维护 CloudStack 是持续的任务，管理员需要知道如何安全地进行版本更新，以及如何执行定期的维护任务，如备份和恢复。 8. **API 和集成**：CloudStack 提供了一套全面的 API，允许与其他系统（如自定义工具或第三方服务）进行集成。理解如何使用这些 API 可以扩展 CloudStack 的功能。 9. **计费与计量**：对于提供按需付费服务的云环境，了解如何设置和管理计费策略是必要的。CloudStack 支持基于资源使用的计量和计费功能。 10. **故障排查**：当遇到问题时，管理员需要能够使用 CloudStack 提供的工具和日志信息来定位并解决问题，确保服务的正常运行。 Apache CloudStack 的管理员指南将深入讲解以上各个主题，帮助管理员熟练掌握这个强大的云平台的运维技能，以构建和管理高效、可靠的云基础设施。同时，由于 CloudStack 在 ASF 的孵化器中，这意味着项目正在积极发展和完善中，管理员还需要关注项目的最新进展和更新。

Chapter 2. Cloud Infrastructure Concepts

Additional hosts can be added at any time to provide more capacity for guest VMs.

CloudStack automatically detects the amount of CPU and memory resources provided by the Hosts.

Hosts are not visible to the end user. An end user cannot determine which host their guest has been

assigned to.

For a host to function in CloudStack, you must do the following:

• Install hypervisor software on the host

• Assign an IP address to the host

• Ensure the host is connected to the CloudStack Management Server

2.5. About Primary Storage

Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on

hosts in that cluster. You can add multiple primary storage servers to a cluster. At least one is required.

It is typically located close to the hosts for increased performance.

CloudStack is designed to work with all standards-compliant iSCSI and NFS servers that are

supported by the underlying hypervisor, including, for example:

• Dell EqualLogic™ for iSCSI

• Network Appliances filers for NFS and iSCSI

• Scale Computing for NFS

If you intend to use only local disk for your installation, you can skip to Add Secondary Storage.

2.6. About Secondary Storage

Secondary storage is associated with a zone, and it stores the following:

• Templates — OS images that can be used to boot VMs and can include additional configuration

information, such as installed applications

• ISO images — disc images containing data or bootable media for operating systems

• Disk volume snapshots — saved copies of VM data which can be used for data recovery or to

create new templates

The items in zone-based NFS secondary storage are available to all hosts in the zone. CloudStack

manages the allocation of guest virtual disks to particular primary storage devices.

To make items in secondary storage available to all hosts throughout the cloud, you can add

OpenStack Object Storage (Swift, swift.openstack.org

) in addition to the zone-based NFS secondary

storage. When using Swift, you configure Swift storage for the entire CloudStack, then set up NFS

secondary storage for each zone as usual. The NFS storage in each zone acts as a staging area

through which all templates and other secondary storage data pass before being forwarded to Swift.

The Swift storage acts as a cloud-wide resource, making templates and other data available to any

zone in the cloud. There is no hierarchy in the Swift storage, just one Swift container per storage

http://swift.openstack.org

About Physical Networks

object. Any secondary storage in the whole cloud can pull a container from Swift at need. It is not

necessary to copy templates and snapshots from one zone to another, as would be required when

using zone NFS alone. Everything is available everywhere.

2.7. About Physical Networks

Part of adding a zone is setting up the physical network. One or (in an advanced zone) more physical

networks can be associated with each zone. The network corresponds to a NIC on the hypervisor

host. Each physical network can carry one or more types of network traffic. The choices of traffic

type for each network vary depending on whether you are creating a zone with basic networking or

advanced networking.

A physical network is the actual network hardware and wiring in a zone. A zone can have multiple

physical networks. An administrator can:

• Add/Remove/Update physical networks in a zone

• Configure VLANs on the physical network

• Configure a name so the network can be recognized by hypervisors

• Configure the service providers (firewalls, load balancers, etc.) available on a physical network

• Configure the IP addresses trunked to a physical network

• Specify what type of traffic is carried on the physical network, as well as other properties like

network speed

2.7.1. Configurable Characteristics of Physical Networks

CloudStack provides configuration settings you can use to set up a physical network in a zone,

including:

• What type of network traffic it carries (guest, public, management, storage)

• VLANs

• Unique name that the hypervisor can use to find that particular network

• Enabled or disabled. When a network is first set up, it is disabled – not in use yet. The administrator

sets the physical network to enabled, and it begins to be used. The administrator can later disable

the network again, which prevents any new virtual networks from being created on that physical

network; the existing network traffic continues even though the state is disabled.

• Speed

• Tags, so network offerings can be matched to physical networks

• Isolation method

2.7.2. Basic Zone Network Traffic Types

When basic networking is used, there can be only one physical network in the zone. That physical

network carries the following traffic types:

• Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with

each other over a network that can be referred to as the guest network. Each pod in a basic zone

Chapter 2. Cloud Infrastructure Concepts

is a broadcast domain, and therefore each pod has a different IP range for the guest network. The

administrator must configure the IP range for each pod.

• Management. When CloudStack’s internal resources communicate with each other, they generate

management traffic. This includes communication between hosts, system VMs (VMs used by

CloudStack to perform various tasks in the cloud), and any other component that communicates

directly with the CloudStack Management Server. You must configure the IP range for the system

VMs to use.

Note

We strongly recommend the use of separate NICs for management traffic and guest traffic.

• Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible

IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs

to implement NAT between their guest network and the public network, as described in Acquiring a

New IP Address.

• Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage

VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC)

named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high

bandwidth network allows fast template and snapshot copying. You must configure the IP range to

use for the storage network.

In a basic network, configuring the physical network is fairly straightforward. In most cases, you only

need to configure one guest network to carry traffic that is generated by guest VMs. If you use a

NetScaler load balancer and enable its elastic IP and elastic load balancing (EIP and ELB) features,

you must also configure a network to carry public traffic. CloudStack takes care of presenting the

necessary network configuration steps to you in the UI when you add a new zone.

2.7.3. Basic Zone Guest IP Addresses

When basic networking is used, CloudStack will assign IP addresses in the CIDR of the pod to the

guests in that pod. The administrator must add a Direct IP range on the pod for this purpose. These

IPs are in the same VLAN as the hosts.

2.7.4. Advanced Zone Network Traffic Types

When advanced networking is used, there can be multiple physical networks in the zone. Each

physical network can carry one or more traffic types, and you need to let CloudStack know which type

of network traffic you want each network to carry. The traffic types in an advanced zone are:

• Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with

each other over a network that can be referred to as the guest network. This network can be

isolated or shared. In an isolated guest network, the administrator needs to reserve VLAN ranges to

provide isolation for each CloudStack account’s network (potentially a large number of VLANs). In a

shared guest network, all guest VMs share a single network.

• Management. When CloudStack’s internal resources communicate with each other, they generate

management traffic. This includes communication between hosts, system VMs (VMs used by

CloudStack to perform various tasks in the cloud), and any other component that communicates

Advanced Zone Guest IP Addresses

directly with the CloudStack Management Server. You must configure the IP range for the system

VMs to use.

• Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible

IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs

to implement NAT between their guest network and the public network, as described in “Acquiring a

New IP Address” in the Administration Guide.

• Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage

VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC)

named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high

bandwidth network allows fast template and snapshot copying. You must configure the IP range to

use for the storage network.

These traffic types can each be on a separate physical network, or they can be combined with certain

restrictions. When you use the Add Zone wizard in the UI to create a new zone, you are guided into

making only valid choices.

2.7.5. Advanced Zone Guest IP Addresses

When advanced networking is used, the administrator can create additional networks for use by the

guests. These networks can span the zone and be available to all accounts, or they can be scoped

to a single account, in which case only the named account may create guests that attach to these

networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may

provision thousands of these networks if desired.

2.7.6. Advanced Zone Public IP Addresses

When advanced networking is used, the administrator can create additional networks for use by the

guests. These networks can span the zone and be available to all accounts, or they can be scoped

to a single account, in which case only the named account may create guests that attach to these

networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may

provision thousands of these networks if desired.

2.7.7. System Reserved IP Addresses

In each zone, you need to configure a range of reserved IP addresses for the management network.

This network carries communication between the CloudStack Management Server and various system

VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP.

The reserved IP addresses must be unique across the cloud. You cannot, for example, have a host in

one zone which has the same private IP address as a host in another zone.

The hosts in a pod are assigned private IP addresses. These are typically RFC1918 addresses. The

Console Proxy and Secondary Storage system VMs are also allocated private IP addresses in the

CIDR of the pod that they are created in.

Make sure computing servers and Management Servers use IP addresses outside of the System

Reserved IP range. For example, suppose the System Reserved IP range starts at 192.168.154.2 and

ends at 192.168.154.7. CloudStack can use .2 to .7 for System VMs. This leaves the rest of the pod

CIDR, from .8 to .254, for the Management Server and hypervisor hosts.

In all zones:

Provide private IPs for the system in each pod and provision them in CloudStack.

剩余177页未读，继续阅读

雁過無痕

粉丝: 0
资源: 1

Apache CloudStack 4.0.2 管理员指南

Apache_CloudStack-4.3.0-Developers_Guide-en-US

Apache_CloudStack-4.3.0-Admin_Guide-en-US

Apache_CloudStack-4.0.1-Installation_Guide

Python库 | dbaas_cloudstack-0.1.7.tar.gz

Python库 | dbaas_cloudstack-0.4.1.tar.gz

apache-cloudstack-4.4.0

apache-cloudstack-4.0.0-incubating-src.tar

apache-cloudstack-primate-1.0-src.tar.bz2

apache-cloudstack-cloudmonkey-6.1.0-src.tar.bz2

docs-cloudstack-apache-org-en-4.11.1.0.pdf

最新资源