Single Node Docker Configuration Instructions
Table of Contents
- Introduction
- Global Requirements
- Installation Steps
- CentOS Installation
- Pre-Installation Steps
- Host Configuration
- Host and Container Configuration
- ECS Object Configuration
- ECS Web Environment access and object testing
- Troubleshooting
- Support
EMC's ECS Software Docker single node deployment is intended to be used by developers and has a range of deployment options for them. The most universal method for deploying ECS software is through Docker applied across whatever means are at your disposal (IaaS/PaaS/Hypervisor). In addition to this, you can leverage Vagrant for local VirtualBox instances.
In terms of cloud deployments, there are a range of options. The most compatible methods of deployment across any provider EW the CentOS and CoreOS options to run the Docker instances.
All instances currently require to have the following minimum requirements:
- Operating systems: CentOS 7
- CPU/Cores: 4 Cores
- Memory: Minimum of 16 GB RAM
- Disks: An unpartitioned/raw disk with at least 100 GB.
Installation also requires internet connectivity to recieve the requisite utility packages and Docker images.
We have performed testing against the following platform(s):
| OS Name | Version | Docker Version |
|---|---|---|
| CentOS | 7.1 | 1.8.2 (latest) |
The installation script is comprised of three main steps:
| Step | Name | Description | Execution Time |
|---|---|---|---|
| 1 | Host & ECS Container Configuration | This step controls the flow and contains the configuration changes required for the Host OS that will run the ECS Software Docker container. In addition, this step updates the ECS Docker container so it can run as a single node and with limited resources | 3-15 min |
| 2 | ECS Object Configuration | This step performs the ECS configuration so it can start serving objects. | 10-30 min |
CentOS is a well-known Linux distribution with the ability to deploy containers with Docker. Common public cloud platforms have CentOS templates ready to be used, so getting ECS Software on a Docker container up is extremely easy.
These steps are to be performed prior running the installation scripts on each of the ECS nodes:
- Attach Data Disk(s): ECS requires one or more disks to be attached to the host. The disk(s) will hold the object data store. The Disks will be formatted as XFS by the installation script.
The data disk(s) attached to each host must be unpartitioned or RAW. For example: We have a new host where we execute the command fdisk -l:
In the picture, we can see two disks: sda and sdb. A mount -l looks like this:
Now we attach a new disk to the host VM. The new disk /dev/sdc looks like this after executing fdisk -l again:
Note: Depending on the environment or the cloud provider you maybe using, the attached disk name(s) will be different. In this example, the attached disk came as /dev/sdc. The attached disk will be formatted and mounted during step 1, so do not mount the ECS data disk before executing step 1:
- Open Ports: ECS requires the following ports to be open:
| Port Number | Port Description |
|---|---|
| 22 | SSH, needed if using remote access |
| 443 | Port used for accessing the ECS management website |
| 3218 | Port used by the CAS service |
| 4443 | ECS management API port |
| 9020 | Port used for the S3 API |
| 9021 | Port used for the S3 API on HTTPS |
| 9022 | Port used for Atmos API |
| 9023 | Port used for Atmos API on HTTPS |
| 9024 | Port used for SWIFT API |
| 9025 | Port used for SWIFT API on HTTPS |
| 9100 | Port used for DT Query service |
| 9101 | ECS Diagnostic Service Index |
Note: There are the most commonly-used ports by ECS; please refer to List of Ports to be Open of the troubleshooting page. In addition, please refer to the ECS Security Configuration Guide and our the troubleshooting page if you find any issues.
‼️ WARNING: This is a destructive operation. Existing data on selected storage devices will be overwritten. Existing Docker installations AND images will be removed.
-
Perform Updates: Perform a Yum update using
sudo yum updateand download packages required for installation usingsudo yum install git tar wget -
Git Clone/Pull the repository: https://github.com/EMCECS/ECS-CommunityEdition
-
Navigate to the /ecs-single-node folder.
-
Gather the IP Address, desired hostname, ethernet adapter name (which can be obtained by executing
ifconfigon the host) and designated data disk(s). For example:
| Hostname | IP Address | Disk Name | Ethernet Adapter |
|---|---|---|---|
| ecstestnode1 | 10.0.1.10 | sdc | eth0 |
-
Run the step 1 script for single-node ECS. For our example values the command would be the one below, but your environment's specifics will differ. Be advised that the hostname can not be localhost. The execution of this script will take about 3-15 minutes depending on how many packages need to be installed or updated and the speed of certain services on the host:
# sudo python step1_ecs_singlenode_install.py --disks sdc --ethadapter eth0 --hostname ecssinglenodeFor a list of all arguments with their full descriptions and including more detailed options, use the--helpflag, e.g.python step1_ecs_singlenode_install.py --help -
At the conclusion of step 1, you may have to wait a few minutes until the administrative web UI becomes available. ECS' administrative portal can be accessed from the data node on port 443 ( https:// ). Once you see the screen bellow, you are ready to execute step 2.
The next step is the ECS Object configuration. This can be accomplished in two ways:
- ECS' Administration UI: Please follow these Instructions.
- Automated script: Follow the instructions in the section below.
Both methods provide the same results; the first walks you through ECS's administrative web interface and the second uses ECS's Management API (exposed on port 4443 and 9011)
ECS Object Configuration via an automated script
- Navigate to the /ecs-single-node folder
-
Verify that the
step2_object_provisioning.pyscript for the environment that you are in can access the 4443 and 9011 ports of the host machine, such as through the output ofnmap -sT -O localhost. Before executing thestep2_object_provisioning.py, decide upon values for the following variables:
| Variable Name | Variable Description | Example Value |
|---|---|---|
| ECSNodes | IP Address of the ECS Node. For Single-Node deployment, only one IP is necessary. | 10.0.1.10 |
| NameSpace | The objects' Namespace | ns1 |
| ObjectVArray | The objects' Virtual Array | ova1 |
| ObjectVPool | The objects' Virtual Pool | ov1 |
| UserName | The name of the initial Object User | user1 |
| DataStoreName | The name of the Data Store. | ds1 |
| VDCName | The name of the Virtual Data Center. | vdc1 |
| MethodName | The name of step to be executed. Leave blank to complete all provisioning steps. | [empty] |
Once the variables are defined, they should be placed in the script command. Using the example values, the command becomes:
sudo python step2_object_provisioning.py --ECSNodes=10.0.1.10 --Namespace=ns1 --ObjectVArray=ova1 --ObjectVPool=ovp1 --UserName=emccode --DataStoreName=ds1 --VDCName=vdc1 --MethodName=
For more granular way of executing the Object Configuration, you can follow the instructions on this document showing how to run the process step by step.
The execution of this script may take 10 to 30 minutes to complete.
After the successful execution of the ECS Object Configuration, the system is ready to begin serving objects. Object users can read and write using free tools like S3 browser
In addition, access to the ECS's administrative panel is available via the https://<ecs-node-ip-address>. The default login and password for the portal is root/ChangeMe (which you will be prompted to change when first accessing the portal)
If you have any issues with the installation, you can review this page for troubleshooting tips and/or go to the support section bellow.
Please file bugs and issues at the GitHub issues page. For more general discussions you can contact the EMC Code team at Google Groups or tagged with EMC on Stack Overflow. The code and documentation are released with no warranties or SLAs and are intended to be supported through a community-driven process.