Citrix CloudStack 3

Citrix® CloudStack™ is a powerful cloud orchestration platform that is purpose-built and designed from the ground up to deliver multi-tier, multi-tenant services in the simplest and most cost-effective way. It enables Service Providers and Enterprises to rapidly build, deploy and manage cloud services that are highly scalable, reliable, secure and open by design. CloudStack accelerates service delivery by combining self-service provisioning with a catalog of custom-built and pre-defined machine images, while providing real-time visibility and reporting to ensure compliance, security and comprehensive customer usage metering.

Additional information about CloudStack 3 and its features can be found at citrix.com/cloudstack. Documentation specific to this release is provided below, for additional CloudStack documentation and access to the knowledge center click here.

Whats new in Citrix CloudStack 3.0.0

CloudStack 3.0.0 is a major new release. It provides several new features compared to CloudStack 2.2.x.

Redesigned User Interface

The user interface of CloudStack has been redesigned to provide easier navigation as well as a more intuitive workflow. Graphical displays of the infrastructure topology have replaced drill-down lists as the main way to access the various CloudStack components such as zones, hosts, and networks. The main Dashboard now provides a more clear display of key information for managing the cloud. The end-user UI also benefits from this redesign, making is easier for users to manage their VMs and other resources. The new Project View lets users switch context from one set of resources to another, enabling a more efficient focus on the task at hand.

NetScaler Load Balancer

Citrix NetScaler is now supported as an external network element for load balancing. Set up an external load balancer when you want to provide load balancing through means other than CloudStack’s provided virtual router. The NetScaler can be set up in either in-line (behind the firewall) or direct (outside the firewall) mode. It must be added before any load balancing rules are deployed on guest VMs in the zone. NetScaler can not yet be used as a firewall.

Sticky Session Policies for Load Balancer Rules

Sticky sessions are used in Web-based applications to ensure continued availability of information across the multiple requests in a user’s session. For example, if a shopper is filling a cart, you need to remember what has been purchased so far. The concept of “stickiness” is also referred to as persistence, or maintaining state. Any load balancer rule defined in CloudStack can have a stickiness policy. The policy consists of a name, stickiness method, and parameters. The stickiness method could be load balancer-generated cookie, application-generated cookie, or sourcebased. In the source-based method, the source IP address is used to identify the user and locate the user’s stored data. In the other methods, cookies are used. The cookie generated by the load balancer or application is included in request and response URLs to create persistence. A variety of options are provided to control the exact behavior of cookies, such as how they are generated and whether they are cached.

Using an LDAP Server for User Authentication

In CloudStack 3.0, you can use an external LDAP server such as Microsoft Active Directory or ApacheDS for end-user authentication. Just map CloudStack accounts to the corresponding LDAP accounts using a query filter. The query filter is written using the query syntax of the particular LDAP server, and can include special wildcard characters provided by CloudStack for matching common values such as the user’s email address and name. CloudStack will search the external LDAP directory tree starting at a specified base directory and return the distinguished name (DN) and password of the matching user. This information along with the given password is used to authenticate the user.

VM Storage Migration

The CloudStack administrator can move a virtual machine’s root disk volume or any additional data disk from one storage pool to another in the same zone. You can use the storage migration feature to achieve some commonly desired administration goals, such as balancing the load on storage pools and increasing the reliability of virtual machines by moving them away from any storage pool that is experiencing issues. This functionality is supported in XenServer, KVM, and VMware.

Swift for Secondary Storage

In CloudStack 3.0, OpenStack Object Storage (Swift, http://swift.openstack.org) is supported for secondary storage. When using Swift, you configure Swift storage for the entire CloudStack, then set up NFS secondary storage for each zone. 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 object. Any secondary storage in the whole cloud can pull a container from Swift at need – no more copying templates and snapshots from one zone to another. Everything is available everywhere.

Password and Key Encryption

CloudStack stores several sensitive passwords and secret keys that are used to provide security. Starting in CloudStack 3.0, these values are always automatically encrypted. These include the database secret key, database password, SSH keys, compute node root password, VPN password, user API secret key, and VNC password.

CloudStack 3.0 uses the Java Simplified Encryption (JASYPT) library. The data values are encrypted and decrypted using a database secret key. Of course, the database secret key itself can not be stored in the open – it must be encrypted. To read it, a second secret key must be provided from an external source during Management Server startup. This key can be provided in one of two ways: loaded from a file or provided by the CloudStack administrator. The encryption type, database secret key, and Management Server secret key are set by the administrator during CloudStack installation.Security Group Egress Rules Security groups can be used to control network traffic to and from VMs. A security group is a group of VMs that filter their incoming and outgoing traffic according to a set of rules, called ingress and egress rules. These rules filter network traffic according to the IP address that is attempting to communicate with the VM. In addition to ingress rules that control incoming network traffic to VMs in a given security group, starting in CloudStack 3.0 you can also define egress rules to control outgoing network traffic. If no egress rules are specified, then all traffic will be allowed out. Once egress rules are specified, the following types of traffic are allowed out: traffic specified in egress rules; queries to DNS servers; and responses to any traffic that has been allowed in through an ingress rule. An egress rule can be
specified either by CIDR to specify IP addresses, or by account to allow traffic from another security group.

Using Projects to Organize Users and Resources

In CloudStack 3.0, users can group themselves into projects so they can collaborate and share virtual resources. CloudStack tracks usage per project as well as per user, so the usage can be billed to either a user account or a project. For example, a private cloud within a software company might have all members of the QA department assigned to one project, so the company can track the resources used in testing while the project members can more easily isolate their efforts from other users of the same cloud. Per-project resource limits can be set.You can configure CloudStack to allow any user to create a new project, or you can restrict that ability to just CloudStack administrators. CloudStack can be set up either so that you can add people directly to a project, or so that you have to send an invitation which the recipient must accept. A user can be a member of any number of projects and can switch to a new Project View in the CloudStack UI to show only project-related information, such as project VMs, fellow project members, project-related alerts, and so on.

Providing Network Services for Users

People using cloud infrastructure have a variety of needs and preferences when it comes to the networking services provided by the cloud. Provisioning physical and virtual networks has always been supported in CloudStack. As a CloudStack 3.0 administrator, you can do the following additional things to set up networking for your users:

Set up several different providers (also known as network elements) for the same service on a single physical network. For example, you can provide both Cisco and Juniper firewalls. You can have multiple instances of the same service provider in a network; for example, more than one Juniper SRX device.
Bundle different types of network services into network offerings. When creating a new VM, the user chooses one of the available network offerings, and that determines which network services the VM can use. A network offering is a named set of network services, such as DHCP, source NAT, load balancing, firewall, VPN, port forwarding, and specific network service providers, such as Juniper SRX for the firewall. You can add new network offerings as time goes on so end users can upgrade to a better class of service on their network.
Provide more ways for a network to be accessed by a user, such as through a project of which the user is a member.
Set up two types of virtual networks: shared and isolated. An isolated network can be accessed only by virtual machines of a single account. A shared network can be accessed by virtual machines that belong to many different accounts. Network isolation on shared networks is accomplished using techniques such as security groups.
More directly control the physical network, such as add/remove/update physical networks in a zone, configure VLANs on the physical network, specify properties like network speed, configure a name so the network can be recognized by hypervisors, configure the IP addresses trunked to a physical network, and specify what type of traffic is carried on the physical network (such as guest VM traffic vs. internal management traffic).

New Features in 3.0.0

Added nonce support in API.
Openstack Swift can now be used as an alternative to NFS storage for templates, ISO, and snapshots.
All sensitive passwords are now properly encrypted in the database and any configuration files
UUIDs are now used in place of regular DB IDs. 3.0 API will support both.
Netscaler MPX, VPX, and SDX is now supported.
Templates, ISOs, Disk, and Service offerings can now be sorted to allow admins to more easily view them in the UI.
Basic LDAP authentication is now built in as an optional AUTH adapter.
Projects feature.
User dispersing allocator has now been added as an alternative algorithm for VM placement.
Admins can now re-assign VM from one account to another.
Network throttling is now controlled via network offerings.
Redundant Router support has been added.
Users can now revert a VM to the original template it was created from.
State management now included to pod and cluster level from the original host and zone level support.
API Version annotation supported.
XenServer 6.0 is now supported.
Egress rules for security groups now supported.
Capacity now has two levels of threshold support. One threshold is used to alert. The other is to disable resource allocation.
Added ability for admins to set ingress rules that cannot be removed by user.
Sticky session now supported for load balancers.
Added support in login API call to take in a map of parameters that can be passed into the authenticators.
VPN usage is now added as a new usage record
MTU for secondary storage is now configurable via Global configuration.
Templates now have a SSH enabled flag similar to password enabled flag.
vSphere 5.0 now has Beta support.
RHEL/Centos 6.2 (KVM) is now supported.

Source

Download Citrix CloudStack 3 here *require MyCitrix account

Download Citrix CloudStack 3 installation guide