calyptos Documentation

Transcription

1 calyptos Documentation Release Eucalyptus Quality Team Nov 08, 2017

2

3 Contents 1 Contents Quick Start Pre-requisites Installation Creating your configuration Validating your configuration Preparing your deployment machines Bootstrapping your Eucalyptus Cloud Controller Provisioning the remaining Eucalyptus components Calyptos Configuration File Name Description Default Attributes Developing Plugins Introduction Validators Debuggers Indices and tables 13 i

4 ii

5 Warning: Calyptos is still under development for issues/feedback/improvements please go to the project s page on GitHub Calyptos is a command line tool intended to help Eucalyptus cloud administrators with the following phases of their Eucalyptus deployments: Configuration Deployment Getting Status Debugging Backup/Restore (Not yet implemented) Each of the phases is implemented as plugins using the stevedore library. This allows new validators, deployers and debuggers to be implemented with modularity in mind. For more information on how to create your own plugins head over to the plugin documentation. Currently Calyptos supports deploying the following: Object Storage Backends Walrus RiakCS Network modes EDGE VPC (Midokura) Managed No VLAN Managed Storage backends DAS Overlay Equallogic Netapp Ceph EMC VNX Contents 1

6 2 Contents

7 CHAPTER 1 Contents 1.1 Quick Start Pre-requisites Before starting the installation process you should have: # Hosts provisioned with CentOS or RHEL 6 # SSH access to the machines you will deploy on (password or key based) # At least 16 network addresses carved out from your network Installation In order to install Calyptos you should run the following commands on a CentOS 6 host: # yum install -y python-devel gcc git python-setuptools python-virtualenv # easy_install fabric PyYAML # curl -L sudo bash -s -- -P chefdk # virtualenv envcalyptos # source envcalyptos/bin/activate # cd envcalyptos/ # git clone # cd calyptos # python setup.py install Creating your configuration In order to install Eucalyptus using Calyptos you will first need to create a configuration file that defines your deployment. Examples for different types of deployments can be found in the examples directory of the Calyptos repository. For details on the various sections of the config file please read the following document: Calyptos Configuration File 3

8 1.1.4 Validating your configuration Once you have a config file that describes the Eucalyptus cloud that you intend on deploying, it is best practice to run the Calyptos validators to make sure that there are no syntactical or semantic mistakes. The validators are intended to provide feedback based on known mis-configurations that the tool believes will result in either a sub-optimal or broken deployment. Any failures in this step will not block the continuation of the deployment. # calyptos validate -e my-environment.yml Preparing your deployment machines The preparation step ensures that all dependencies for the deployment are available. This can include but is not limited to: Ensuring IP connectivity Ensuring SSH access Ensuring deployment dependencies are in place (Chef, Ansible, etc) # calyptos prepare -e my-environment.yml Bootstrapping your Eucalyptus Cloud Controller The bootstrap step is used to provision your Cloud Controller (CLC). After completing this step your CLC will be up and running and have all of its dependent components registered. When this step has completed successfully we will know a few more things about our deployment: We are able to install Eucalyptus from the package repositories we listed in our environment Eucalyptus is able to bring up its database without any issues We have generated all the necessary keys in order to provision the rest of our components # calyptos bootstrap -e my-environment.yml Provisioning the remaining Eucalyptus components Once we have bootstrapped our CLC, we have all the pre-requisites we need in order to provision all the rest of the Eucalyptus components. The provision step will deploy all of these components in parallel. When all the components have been provisioned a final configuration step will be run on the CLC in order to complete the installation as specified in your environment file. # calyptos provision -e my-environment.yml 1.2 Calyptos Configuration File Name Description 4 Chapter 1. Contents

9 Default Attributes eucalyptus * topology * network * system-properties midokura RiakCS Ceph * riak_cs * riak * sysctl * haproxy * riakcs_cluster * ceph Calyptos configuration files are written in YAML syntax. Below is a guide on what can be provided and how to structure your configuration files. The a typical config file has the following structure: name: HadEupa description: This Euca install will run our Hadoop workloads! default_attributes: eucalyptus: topology: clc-1: user-facing: walrus: clusters: hadoop-a: cc-1: nodes: sc-1: network: mode: EDGE private-interface: br0 public-interface: br0 bridge-interface: br0 bridged-nic: em1 config-json: Clusters: - Name: hadoop-a PrivateIps: Subnet: Gateway: Name: Netmask: Subnet: Calyptos Configuration File 5

10 InstanceDnsServers: PublicIps: system-properties: cloudformation.url_domain_whitelist: '*s3.amazonaws.com,*qa1.eucalyptus-systems. com' Lets take a look at each section and figure out what each does Name This is a short name used to refer to your cloud. It must not contain any spaces or underscores Description This can be a sentence that further identifies your cloud and its purpose moving forward Default Attributes Default attributes are applied to all machines in your deployment. These can be seen as global configuration values. This section is broken down by subsystem. For example, there are sections for: * eucalyptus * midokura * riakcs In each of these sections we can configure and tune each set of components that make up our cloud infrastructure. Lets take a look at each section more in depth. eucalyptus The eucalyptus section is likely to be the one most heavily interacted with. This section helps to define the Eucalyptus specific configuration of your deployment. This includes but isn t limited to: * Component topology * Networking configuration * System properties topology topology: clc-1: user-facing: walrus: clusters: hadoop-a: cc-1: nodes: sc-1: This section describes not only where to connect to your hosts but also which components should be installed on each. The cloud global components are defined by the following keys in the topology section: clc-1: The primary cloud controller host user-facing: A list of user-facing service hosts 6 Chapter 1. Contents

11 walrus: The host to install the walrus on The cluster level components are defined in a dictionary where the key is the intended name of the cluster. In our example above the cluster name is hadoop-a. Inside each of the specific cluster sections the following hosts must be defined: cc-1: The primary cluster controller sc-1: The primary storage controller nodes: This is a space separated string of the node controllers in this cluster network network: mode: EDGE private-interface: br0 public-interface: br0 bridge-interface: br0 bridged-nic: em1 config-json: Clusters: - Name: hadoop-a PrivateIps: Subnet: Gateway: Name: Netmask: Subnet: InstanceDnsServers: PublicIps: The network section defines global attributes for cloud level networking as well as the networking parameters that are used on the node controllers. The mode is a string that can be one of the following: EDGE VPCMIDO MANAGED MANAGED-NOVLAN The following params are available at the global level: private-interface and public-interface keys - map to the VNET_PRIVINTERFACE and VNET_PUBINTERFACE respectively for the eucalyptus.conf on both cluster and node controllers bridge-interface - maps to the VNET_BRIDGE parameter in eucalyptus.conf for node controllers The config-json section has the same structure as defined in the Eucalyptus documentation Calyptos Configuration File 7

12 system-properties system-properties: cloudformation.url_domain_whitelist: '*s3.amazonaws.com,*qa1.eucalyptus-systems.com' This section allows the overriding of Eucalyptus system properties that would usually be set using euca-modify-property. Each key in this section is the name of a property, its corresponding value is what we will set that property to during deployment. In the case of the example above we will run the following after the cloud has been fully deployed: euca-modify-property -p cloudformation.url_domain_whitelist='*s3.amazonaws.com,*qa1. eucalyptus-systems.com' midokura midokura: bgp-peers: - local-as: peer-address: port-ip: remote-as: route: /24 router-name: eucart cassandras: initial-tenant: euca_tenant_1 midolman-host-mapping: b-19.qa1.eucalyptus-systems.com: g qa1.eucalyptus-systems.com: midonet-api-url: repo-password: 8yU8Pj6h repo-url: repo-username: eucalyptus yum-options: --nogpg zookeepers: :2181 RiakCS To deploy and use a RiakCS cluster, the configuration files need to have few sections e.g riak, riak_cs, sysctl, haproxy, riakcs_cluster. riak_cs riak_cs: (Config for RiakCS) config: riak_cs: 8 Chapter 1. Contents

13 anonymous_user_creation: true (boolean; default: true; required) fold_objects_for_list_keys: true (boolean; default: true; required) admin_key": "admin-key" (string; default: "admin-key"; required) admin_secret": "admin-secret" (string; default: "admin-secret"; required) cs_port: 8080 (int; default: 8080; required; can be any usable port) riak riak: config: riak_kv: storage_backend: "riak_cs_kv_multi_backend" (string; default: "riak_cs_kv_multi_ backend"; required; default value is required for RiakCS deployment) sysctl sysctl: params: (following params are required to avoid riak-diag warnings) net.core.wmem_default: " " net.core.rmem_default: " " net.core.wmem_max: " " net.core.rmem_max: " " net.core.netdev_max_backlog: "10000" haproxy haproxy: (required if riak_cs cluster is being placed behind load-balancer) incoming_port: 80 (int; default: 80; required; can be any usable port) members: - "server <host-01> <ip_address_of_riakcs_host-01>:<cs_port value from riak_cs config> weight 1 maxconn check" - "server <host-02> <ip_address_of_riakcs_host-02>:<cs_port value from riak_cs config> weight 1 maxconn check" - "server <host-03> <ip_address_of_riakcs_host-03>:<cs_port value from riak_cs config> weight 1 maxconn check" riakcs_cluster riakcs_cluster: (Config for RiakCS Cluster) topology: head: (A host where calyptos bootstraps and creates necessary artifacts for the entire cluster) ipaddr: "ip_address of the head node" (string; required) 1.2. Calyptos Configuration File 9

14 fqdn: "host_name of the head node" (string; required) stanchion_ip: "ip_address for the stanchion host" (string; required) stanchion_port: 8085 (int; default: 8085; required; port for the stanchion host") load_balancer: "ip_address" (string; required; where load balancer should be installed for riak_cs cluster) nodes: - "ip_address" (string; required; ip_address for riakcs nodes) - "ip_address" (string; required; ip_address for riakcs nodes) Ceph To deploy and use a RiakCS cluster, the configuration files need to have few sections e.g riak, riak_cs, sysctl, haproxy, riakcs_cluster. ceph ceph: (Config for Ceph Cluster) config: fsid: "unique id, e.g uuid" (string; required) topology: mon_bootstrap: ipaddr: "ip address of a mon host where calyptos bootstraps" hostname: "hostname of bootstrap mon host" osds: - ipaddr: "ip address of an osd host" hostname: "hostname of an osd host" - ipaddr: "ip address of an osd host" hostname: "hostname of an osd host" drive: (if using drives for OSDs, if not present, filesystem will be used for single OSD) - "drive name if not using OS drive e.g /dev/osd1 [optional]" - "drive name if not using OS drive e.g /dev/osd2 [optional]" 1.3 Developing Plugins Introduction The plugins in Calyptos are implemented with the stevedore library. There are currently 2 different types of plugins: Validators Debuggers We will go into more detail on each type of plugin below Validators Validator plugins are meant to ensure that the configuration file provided will produce a functional Eucalyptus cloud when the deployer is run. The plugin has access to a RoleBuilder object which provides: 10 Chapter 1. Contents

15 Access to the configuration yaml Methods for relaying success and failure messages A dict that groups each machine in the deployment by their role/component This step does not block you from continuing to deploy, however it is intended to provide feedback on configurations which we know will be suboptimal or simply non-functional. The implemented plugins live in the eucadeploy/plugins/validator folder. Please add your validators there when submitting a pull request. Below is an example of a very simple validation plugin. In this example plugin we will merely be checking that we have a CLC role defined and there is not more than 1 host in that group. 1 from eucadeploy.plugins.validator.validatorplugin import ValidatorPlugin 2 3 class CLCCheck(ValidatorPlugin): 4 def validate(self): 5 if 'clc' in self.role_builder.roles: 6 self.success('found at least 1 CLC') 7 if len(self.role_builder.roles['clc']) == 1: 8 self.success('found only 1 CLC') 9 else: 10 self.failure('found more than 1 CLC') 11 else: 12 self.failure('no CLCs found') Lets break down this plugin and note the interesting/crucial bits: In lines 1 and 3, note that we must make our plugin inherit from the ValidatorPlugin base class In line 4, each validator plugin must override the validate method, this is what will be called by the CLI In line 5, we are grabbing the set of roles from the component_deployer, this is a dict of sets with each key being the name of the roles. Here we are simply checking that there exists a clc role In lines 6 and 8, we log and report the success of our validations In lines 10 and 12, we log and report the failure cases of our validations In order to add our validator to the list of default plugins to run during the validation step we need to add it to the entry points found in the setup.py file. Validators belong in the eucadeploy.validator array. If example plugin was in the eucadeploy/plugins/validator/clccheck.py file we would add the following to the entrypoints: 'clccheck = eucadeploy.plugins.validator.clccheck:clccheck' Debuggers Debuggers are used to introspect into a running system to: Retrieve relevant logs/info Check for resource contention (memory, disk, cpu) Ensure network connectivity is available between components An example plugin for looking at the state of the node-controller service would look like this: 1.3. Developing Plugins 11

16 1 from fabric.context_managers import hide 2 import re 3 from calyptos.plugins.debugger.debuggerplugin import DebuggerPlugin 4 5 class DebugNodeControllerService(DebuggerPlugin): 6 def debug(self): 7 # Get the list of node controllers 8 nodes = self.role_builder.roles['node-controller'] 9 # Collect service status using SSH to the hosts 10 nc_service_state = self.run_command_on_hosts('service eucalyptus-nc status', hosts=nodes) 11 # Iterate through the result from each node and flag it as a success or failure 12 for node in nodes: 13 if re.search('running', nc_service_state[node]): 14 self.success(node + ': NC service running') 15 else: 16 self.failure(node + ': NC service not running') 17 return self.passed, self.failed 12 Chapter 1. Contents

17 CHAPTER 2 Indices and tables genindex modindex search 13