Install the cloud dispatcher

Note:

arvados-dispatch-cloud is only relevant for cloud installations. Skip this section if you are installing a on premise cluster that will spool jobs to Slurm.

  1. Introduction
  2. Create compute node VM image
  3. Update config.yml
  4. Install arvados-dispatch-cloud
  5. Start the service
  6. Restart the API server and controller
  7. Confirm working installation

Introduction

The cloud dispatch service is for running containers on cloud VMs. It works with Microsoft Azure and Amazon EC2; future versions will also support Google Compute Engine.

The cloud dispatch service can run on any node that can connect to the Arvados API service, the cloud provider’s API, and the SSH service on cloud VMs. It is not resource-intensive, so you can run it on the API server node.

Create compute node VM image and configure resolver

Set up a VM following the steps to set up a compute node

Compute nodes must be able to resolve the hostnames of the API server and any keepstore servers to your internal IP addresses. You can do this by running an internal DNS resolver and configuring the compute VMs to use that resolver, or by hardcoding the services in the /etc/hosts file. For example:

10.20.30.40     ClusterID.example.com
10.20.30.41     keep1.ClusterID.example.com
10.20.30.42     keep2.ClusterID.example.com

Once the VM is fully configured, create a reusable VM image from it and make note of the image id.

Update config.yml

Create a private key

Generate an SSH private key with no passphrase. Save it in the cluster configuration file (see PrivateKey in the example below).

~$ ssh-keygen -N '' -f ~/.ssh/id_dispatcher
Generating public/private rsa key pair.
Your identification has been saved in /home/user/.ssh/id_dispatcher.
Your public key has been saved in /home/user/.ssh/id_dispatcher.pub.
The key fingerprint is:
[...]
~$ cat ~/.ssh/id_dispatcher
-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEAqXoCzcOBkFQ7w4dvXf9B++1ctgZRqEbgRYL3SstuMV4oawks
ttUuxJycDdsPmeYcHsKo8vsEZpN6iYsX6ZZzhkO5nEayUTU8sBjmg1ZCTo4QqKXr
...
oFyAjVoexx0RBcH6BveTfQtJKbktP1qBO4mXo2dP0cacuZEtlAqW9Eb06Pvaw/D9
foktmqOY8MyctzFgXBpGTxPliGjqo8OkrOyQP2g+FL7v+Km31Xs61P8=
-----END RSA PRIVATE KEY-----

You can delete the key files after you have copied the private key to your configuration file.

~$ rm ~/.ssh/id_dispatcher ~/.ssh/id_dispatcher.pub

Configure CloudVMs

Add or update the following portions of your cluster configuration file, config.yml. Refer to config.defaults.yml for information about additional configuration options.

    Services:
      DispatchCloud:
        InternalURLs:
          "http://localhost:9006": {}
    Containers:
      CloudVMs:
        # BootProbeCommand is a shell command that succeeds when an instance is ready for service
        BootProbeCommand: "sudo systemctl status docker"

        # --- driver-specific configuration goes here --- see Amazon and Azure examples below ---

      DispatchPrivateKey: |
        -----BEGIN RSA PRIVATE KEY-----
        MIIEpQIBAAKCAQEAqXoCzcOBkFQ7w4dvXf9B++1ctgZRqEbgRYL3SstuMV4oawks
        ttUuxJycDdsPmeYcHsKo8vsEZpN6iYsX6ZZzhkO5nEayUTU8sBjmg1ZCTo4QqKXr
        FJ+amZ7oYMDof6QEdwl6KNDfIddL+NfBCLQTVInOAaNss7GRrxLTuTV7HcRaIUUI
        jYg0Ibg8ZZTzQxCvFXXnjseTgmOcTv7CuuGdt91OVdoq8czG/w8TwOhymEb7mQlt
        lXuucwQvYgfoUgcnTgpJr7j+hafp75g2wlPozp8gJ6WQ2yBWcfqL2aw7m7Ll88Nd
        [...]
        oFyAjVoexx0RBcH6BveTfQtJKbktP1qBO4mXo2dP0cacuZEtlAqW9Eb06Pvaw/D9
        foktmqOY8MyctzFgXBpGTxPliGjqo8OkrOyQP2g+FL7v+Km31Xs61P8=
        -----END RSA PRIVATE KEY-----
    InstanceTypes:
      x1md:
        ProviderType: x1.medium
        VCPUs: 8
        RAM: 64GiB
        IncludedScratch: 64GB
        Price: 0.62
      x1lg:
        ProviderType: x1.large
        VCPUs: 16
        RAM: 128GiB
        IncludedScratch: 128GB
        Price: 1.23

Minimal configuration example for Amazon EC2

    Containers:
      CloudVMs:
        ImageID: ami-01234567890abcdef
        Driver: ec2
        DriverParameters:
          AccessKeyID: XXXXXXXXXXXXXXXXXXXX
          SecretAccessKey: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
          SecurityGroupIDs:
          - sg-0123abcd
          SubnetID: subnet-0123abcd
          Region: us-east-1
          EBSVolumeType: gp2
          AdminUsername: arvados

Minimal configuration example for Azure

    Containers:
      CloudVMs:
        ImageID: "https://zzzzzzzz.blob.core.windows.net/system/Microsoft.Compute/Images/images/zzzzz-compute-osDisk.55555555-5555-5555-5555-555555555555.vhd"
        Driver: azure
        DriverParameters:
          SubscriptionID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
          ClientID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
          ClientSecret: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
          TenantID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
          CloudEnvironment: AzurePublicCloud
          ResourceGroup: zzzzz
          Location: centralus
          Network: zzzzz
          Subnet: zzzzz-subnet-private
          StorageAccount: example
          BlobContainer: vhds
          DeleteDanglingResourcesAfter: 20s
          AdminUsername: arvados

Get the SubscriptionID and TenantID:

$ az account list
[
  {
    "cloudName": "AzureCloud",
    "id": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX",
    "isDefault": true,
    "name": "Your Subscription",
    "state": "Enabled",
    "tenantId": "YYYYYYYY-YYYY-YYYY-YYYYYYYY",
    "user": {
      "name": "you@example.com",
      "type": "user"
    }
  }
]

You will need to create a “service principal” to use as a delegated authority for API access.

$ az ad app create --display-name "Arvados Dispatch Cloud (ClusterID)" --homepage "https://arvados.org" --identifier-uris "https://ClusterID.example.com" --end-date 2299-12-31 --password Your_Password
$ az ad sp create "appId"
(appId is part of the response of the previous command)
$ az role assignment create --assignee "objectId" --role Owner --scope /subscriptions/{subscriptionId}/
(objectId is part of the response of the previous command)

Now update your config.yml file:

ClientID is the ‘appId’ value.

ClientSecret is what was provided as Your_Password.

Test your configuration

Run the cloudtest tool to verify that your configuration works. This creates a new cloud VM, confirms that it boots correctly and accepts your configured SSH private key, and shuts it down.

~$ arvados-server cloudtest && echo "OK!"

Refer to the cloudtest tool documentation for more information.

Install arvados-dispatch-cloud

Red Hat and Centos

# yum install arvados-dispatch-cloud

Debian and Ubuntu

# apt-get install arvados-dispatch-cloud

Start the service

# systemctl enable --now arvados-dispatch-cloud
# systemctl status arvados-dispatch-cloud
[...]

If systemctl status indicates it is not running, use journalctl to check logs for errors:

# journalctl -n12 --unit arvados-dispatch-cloud

Restart the API server and controller

Make sure the cluster config file is up to date on the API server host then restart the API server and controller processes to ensure the configuration changes are visible to the whole cluster.

# systemctl restart nginx arvados-controller

Confirm working installation

On the dispatch node, start monitoring the arvados-dispatch-cloud logs:

~$ sudo journalctl -o cat -fu arvados-dispatch-cloud.service

Make sure to install the arvados/jobs image.

Submit a simple container request:

shell:~$ arv container_request create --container-request '{
  "name":            "test",
  "state":           "Committed",
  "priority":        1,
  "container_image": "arvados/jobs:latest",
  "command":         ["echo", "Hello, Crunch!"],
  "output_path":     "/out",
  "mounts": {
    "/out": {
      "kind":        "tmp",
      "capacity":    1000
    }
  },
  "runtime_constraints": {
    "vcpus": 1,
    "ram": 1048576
  }
}'

This command should return a record with a container_uuid field. Once arvados-dispatch-cloud polls the API server for new containers to run, you should see it dispatch that same container.

The arvados-dispatch-cloud API a list of queued and running jobs. For example:

~$ curl ...

When the container finishes, the dispatcher will log it.

After the container finishes, you can get the container record by UUID from a shell server to see its results:

shell:~$ arv get zzzzz-dz642-hdp2vpu9nq14tx0
{
 ...
 "exit_code":0,
 "log":"a01df2f7e5bc1c2ad59c60a837e90dc6+166",
 "output":"d41d8cd98f00b204e9800998ecf8427e+0",
 "state":"Complete",
 ...
}

You can use standard Keep tools to view the container’s output and logs from their corresponding fields. For example, to see the logs from the collection referenced in the log field:

~$ arv keep ls a01df2f7e5bc1c2ad59c60a837e90dc6+166
./crunch-run.txt
./stderr.txt
./stdout.txt
~$ arv-get a01df2f7e5bc1c2ad59c60a837e90dc6+166/stdout.txt
2016-08-05T13:53:06.201011Z Hello, Crunch!

If the container does not dispatch successfully, refer to the arvados-dispatch-cloud logs for information about why it failed.


Previous: Install arvados/jobs image Next: Install the SLURM dispatcher

The content of this documentation is licensed under the Creative Commons Attribution-Share Alike 3.0 United States licence.
Code samples in this documentation are licensed under the Apache License, Version 2.0.