How to deploy a Gridseed site

1.  Introduction

In order to have a minimal (and working) gridseed site you have to download the virtualization server (VirtualBox) and the following gridseed virtual machines:

• One user interface (milu-32 or milu-64 as you prefer)
• Three central services virtual machines (master, central-1 and wms)
• One Gridseed site, normally composed of at least 3 VMs; one Computing Element (CE), one Worker Node and one Storage Element.

1.1  Hardware requirements

The requirements to install GRIDSEED are the same as using general virtual machines, you need a modern machine (around 2 GHZ of clock), with enough RAM (1 GB or more). Beware to don't run too many virtual machines on the same physical machine, a machine as described above can handle 2-3 virtual machines without problem. For 64 bit and multicore support you NEED the VM hardware extensions enabled on your CPU. If you are running a Linux operating system run this command to check if the extensions are enabled:

[root@neon ~]# egrep -c '(vmx|svm)' /proc/cpuinfo
2

If the result is > 0 the extensions are present and the OS supports it. However it's possible that that extensions are not enabled, check in your system BIOS if it is possible to enable it.

1.2  Gridseed network overview

All the gridseed virtual machines belongs to 10.10.0.0/16 network. In order to communicate the VMs have to be or all on one physical machine or in a couple of physical machines that are all on the same local network. If there are incompatibility with the gridseed network and the real one you have to reconfigure the whole gridseed environment.

2.  Virtualbox Installation

Download the latest version of virtualbox and install it on your computers. The default installation in enough for running GRIDSEED.

3.  Gridseed Virtual machines

Download the Virtual Machines that you need from here (The downloaded VM.is a tar archive). Extract the VM from the archive, locate the ovf file and import it in VirtualBox. To import you have to (with Virtualbox GUI running):

File -> Import Appliance -> Choose -> path to the extracted VMs

And click next until finish the installation. Note: the procedure will copy the virtual hard disk in a default location (typically in your home dir), if you want to change the destination you have to change the path of Virtual Disk Image in Appliance Import Settings section.

Once the VM is imported check if the Network of the VM is on Bridged Adapter and the Adapter (the NIC) is the right one. To to this, go to:

select the VM -> right click on it -> Settings -> Network

Note: the master VM has two Network Adapters, one in bridged mode and the another in NAT mode, because master acts as gateway for the gridseed network and with NAT you haven't to configure nothing on the physical machine to go on internet (if the physical machine can access internet).

3.1  Virtual Machines boot order

The boot order is important, due to service dependencies. The first machine to boot must be master. This machine has all the central services (like dns, dhcp, ntp, http, gateway).

1. master.grid.seed
2. central-1.grid.seed
3. wms.grid.seed
4. User Interface (milu-32 or milu-64)
5. Storage Element
6. Computing Element
7. Worker Nodes
8. Other VMs like globus, arc...

The Worker Nodes VMs are dhcp based machines. They are configured to query for addresses the master VM on different port as usual, so you shouldn'have any problem with your "real" dhcp server (if you have one).

3.2  GRIDSEED-2 boot order

The GRIDSEED-2 site, has more strict boot procedure.

1. Central services as above
2. ce-2.grid.seed
3. ce-2wnX.grid.seed (wait until the ce-2 is fully operational)
4. globus.grid.seed (wait until the ce-2 is fully operational) - OPTIONAL
5. arc-ce.grid.seed (wait until the ce-2 is fully operational) - OPTIONAL

The ce-2.grid.seed VM exports the /home directory and some other directories to the other VMs of the site.

4.  Start Virtual Machines

To start the VMs you can:

• Start the VM via the Virtualbox GUI. This is the simplest way, but you have to leave open the VM's window, otherwise the VM will be powered off.
• Start in Headless Mode. This is more complicated, you don't have any console (unless you use a remote desktop program see below), but your VM will remain running.On a linux machine you can start the VM with the following command:

nohup VBoxHeadless --vrdpport 3389-3400 --startvm <VIRTUAL_MACHINE_NAME> &

This command allows you to run the VM in background and assign a port where you can connect with a remote-desktop client (at least in 3.5+ version of Virtualbox)

5.  Connect to the Gridseed machines/network

If your VMs are started with the Virtualbox GUI you have to only login (username root, password gridseed) and you are on GRIDSEED network. If you are using the headless mode you can also access the VM's console with a remote desktop client like rdesktop-vrdp (distributed with virtualbox rpm)

  rdesktop-vrdp <HOST>:<PORT>

• <HOST> Is the physical machine where the VM is running
• <PORT> Is the TCP port where the VM is listening for remote desktop commands. To know what port is using one VM use:

  # VBoxManage showvminfo <VM_NAME> | grep VRDP
  VRDP:            enabled (Address 0.0.0.0, Ports 3389, MultiConn: off, ReuseSingleConn: off,
 Authentication type: null)
  VRDP port:       3389
  VRDP Connection:    not active

To connect to GRIDSEED network directly with your PC you can use a ssh client, but you have to:

• Configure a interface of a real computer as member of the GRIDSEED network (for example assign the ip 10.10.0.254/16)
• Enter on the gateway through the external interface of master.grid.seed. This solution works only on vmware, because virtualbox doesn't create a virtual interface on the host machine.
• Configure a second network interface on the user interface with a ip that belongs to one of your lan.

6.  Configure the Central Services

From the version 1.5 of GRIDSEED all the central services are configured out of the box (the external interface of master will be configured by dhcp and the dns forwarder are set to google ones).

Take attention that on master VM is running a dhcp server that is used to assign IP addresses to worker nodes, so if the WNs lost (or never had) their IP addresses is probably due to a communication problem between them and the master VM.