2. Summary
  3. Files
  4. Support
  5. Report Spam
  6. Create account
  7. Log in

  1. How to Use
  2. Deployment Guide

As a provisioning system for the SLA@SOI infrastructure management Apache Tashi was adopted. You can find more about Apache Tashi on http://incubator.apache.org/tashi/. Apache Tashi manages a set of KVM and/or Xen hypervisors that run on a clustered set of physical machines. To better deliver a SLA-enabled infrastructure two modules for the Virtual Machines Management have been developed. Both have been integrated in Apache Tashi and can be further integrated in other IaaS platforms. The first module is a Scheduler that allocates the virtual machines to the physical machines. The second module is virtual machine re-provisioning functionality which provides a dynamic resource management of the virtual machines.

A short description for a Tashi is available on the official web page: The Tashi project aims to build a software infrastructure for cloud computing on massive internet-scale datasets (what we call Big Data). The idea is to build a cluster management system that enables the Big Data that are stored in a cluster/data center to be accessed, shared, manipulated, and computed on by remote users in a convenient, efficient, and safe manner.

SLA@SOI project is using a modified Apache Tashi code (for original code see http://svn.apache.org/repos/asf/incubator/tashi). In order to integrate Tashi with the SLA@SOI framework, a message sink process that receives messages from the ISM and processes them was implemented. This process or daemon runs in the background on the Cluster Manager node of a Tashi deployment. It receives provisioning requests as XMPP messages, extracts the requirements and using the Tashi client, issues requests for VM creation. Besides the provisioning requests, the daemon is also listening to the requests for reprovisioning and user registration. The daemon will not return a response immediately to the ISM but rather will notify the ISM asynchronously once the provisioning process has completed.

Some extensions were made to Tashi to meet the SLA@SOI needs. These extensions are:

  • OCCI implementation for Tashi was provided, see ISM. Part of the OCCI implemantation is also XMPP daemon which enables remote Tashi controlling.
  • Dynamic adaptation of CPU share, memory, network bandwidth and disk IO for the virtual machines have been implemented.
  • The existing scheduler was rewritten to enable other scheduler implementations. There are two scheduler implementations available now - Balanced Scheduler and Consolidated Scheduler (both includes virtual machine priorities, CPU reservation, powering on/off hosts...). Read more about schedulers here Schedulers.
  • User registration has been implemented, but it is available only for the SQL storage implementation for now. Priority value for the user is available also for the LDAP implementation.
  • Automatic host registration has been implemented. Now when installing Tashi there is no need to manually add hosts to the database. Just start the nodemanager and the host will be registered automatically if it was not already.
  • Simple image management has been implemented - VMs that require persistent disk get a new image (copied from image template), a new instance state is available (InstanceState?.PreparingDisk?).
  • XMPP publisher has been implemented - it can be used for informing external components about VM layout, about actions that were taken on the virtual machines... The consumer of these message in the SLA@SOI framework is Low Level Monitoring System, which stores the data in the historical database, checks any potential Infrastructure SLA violations and informs higher-level components about them.
  • Some fixes were applied, for example migrations state exceptions, registering VM instances with already used ID (after restarting cluster manager), getHosts method minor fix in FromConfig.py.

How to Use

  • Start cluster manager and node managers as documented on original Tashi web page.
  • Start schedulermanager.py instead of starting primitive.py (schedulermanager.py and other scheduler scripts are located in tashi/scheduler folder).
  • Configure tashi.tac file and execute from OCCI folder: 
twistd -ny tashi.tac

or to run it daemonised: 

twistd -l tashi-occi-xmpp.log -y tashi.tac
  • If you want for example remotely create ten VMs via OCCI XMPP daemon then you can write a script like: 
import xmpp

live=True
username = '' # add username here
passwd = '' # add password here
to='' # add recipient here, also configure tashi.tac file in OCCI folder

client = xmpp.Client('testbed.sla-at-soi.eu') # add server here
client.connect(server=('server',port)) # add server and port here
client.auth(username, passwd, 'test-botty')
client.sendInitPresence()
client.sendInitPresence()

for i in range(0, 10):
	msg = 'createcompute [{"class":"eu.slasoi.infrastructure.model.infrastructure.Compute","id":1,"cpu_speed":null,"boot_vol_type":null,"status":{"class":"Status","id":2},"provisionRequest":{"class":"ProvisionRequest","id":1},"imageIdentifier":"tashi","userId":1000,"memory_size":512,"hostname":"tizzy'+str(i)+'","provisioningSystemId":null,"links":null,"type":"occi_compute","memory_reliability":null,"memory_speed":null,"resourceId":"a626bbb4-6c92-4f0e-a117-ae11ec502a6e'+str(i)+'","cpu_cores":1,"categories":[{"class":"Category","id":9},{"class":"Category","id":8},{"class":"Category","id":1},{"class":"Category","id":11},{"class":"Category","id":13}],"cpu_arch":null},[{"class":"eu.slasoi.infrastructure.model.Category","id":null,"scheme":"http://purl.org/occi/kind#","term":"compute","label":"Compute Resource"},{"class":"eu.slasoi.infrastructure.model.Category","id":13,"scheme":"http://provider.com/category#templates","term":"ubuntu-9.10","label":"Ubuntu Linux 9.10"},{"class":"eu.slasoi.infrastructure.model.Category","id":null,"scheme":"http://provider.com/category#sla","term":"gold","label":"SLA@SOI Gold SLA"},{"class":"eu.slasoi.infrastructure.model.Category","id":null,"scheme":"http://provider.com/category#locations","term":"ie","label":"Ireland"}],[]]'
	#print msg
	if(live):
		message = xmpp.Message(to, msg)
		message.setAttr('type', 'chat')
		print "Sending message"
		client.send(message)

client.disconnect()

If you want remotely destroy VM via OCCI XMPP daemon then you can write something like: 

import xmpp

live = True
username = '' # add username here
passwd = '' # add password here
to='' # add recipient here, also configure tashi.tac file in OCCI folder

client = xmpp.Client('testbed.sla-at-soi.eu') # add server here
client.connect(server=('server',port)) # add server and port here
client.auth(username, passwd, 'test-botty')
client.sendInitPresence()

msg = 'deletecompute 10'
if(live):
	message = xmpp.Message(to, msg)
	message.setAttr('type', 'chat')
	client.send(message)

client.disconnect()
  • You can execute the command below to see what functionality is available via tashi-client.py: 
python bin/tashi-client.py

In addition to existing original Tashi functions there are also registerUser, unregisterUser, adaptCpuShare, adaptMemoryLimit, and unregisterHost. Also, createVm command has a new parameter (cpuShare).

  • If you want to register a new user execute the following command (only for SQL data storage): 
python bin/tashi-client.py registerUser --name mihas --passwd mihas12 --priority 12

The priority of the virtual machines is based on the priority of user.

For unregistering user execute: 

python bin/tashi-client.py unregisterUser --userId 1

If LDAP is used for data storage something similar to the following configuration is needed in Tashi configuration file: 

[LdapOverride]
baseData = tashi.clustermanager.data.Pickled
fetchThreshold = 3600.0
nameKey = uid
idKey = uidNumber
priorityKey = gidNumber
ldapCommand = ldapsearch -x -b dc=xlab,dc=si

A priorityKey was added to the original configuration and is used to retrieve the information about user priority, based on what the decision in scheduler is taken where to provision the VM. In this case the group id is also the indicator for the priority of the group.

  • When starting a new virtual machine you can specify its CPU share as follows: 
python bin/tashi-client.py createVm --name test1 --cpuShare 2048 --disks tashi.img

Default CPU share is 1024.

  • If you want to change the CPU share or memory for virtual machine execute the commands as below: 
python bin/tashi-client.py adaptCpuShare --share 1500 --instance 3
python bin/tashi-client.py adaptMemoryLimit --limit 512 --instance 3
python tashi-client.py adaptDiskBandwidth  --weight 1000 --instance 3
python tashi-client.py adaptNetworkBandwidth --downspeed 1000 --upspeed 500 --instance 3
  • Hosts are registered automatically, but if you want to unregister them execute: 
python bin/tashi-client.py unregisterHost --hostId 2
  • Hosts have to be a configured in order to enable the SLA management of the terms that have been added to the scheduler (auditability, isolation, location...). A host can be configured via setHostConfig, which has been implemented inside tashi-client.py: 
python bin/tashi-client.py setHostConfig --hostId 2 --elemName auditability --value True

Deployment Guide

Check out SLA@SOI Tashi sources and install Tashi as it is documented on http://incubator.apache.org/tashi/documentation.html.

After installation you will have to take some additional steps:

  • Install python xmpppy library to enable sending XMPP messages from the PriorityScheduler? implementations. Install python easy_install package and execute the following command: 
    easy_install xmpppy

If you want to use OCCI XMPP daemon to remotely control Tashi, you will need also twisted and wokkel libraries. Execute the following two commands: 

easy_install twisted
easy_install wokkel
  • Configure XMPP options in the Tashi configuration file. 
[XMPP]
enabled = True
jid=
pwd=
recipient=
  • Configure scheduler options in the Tashi configuration file (you can remove Primitive section, it is replaced by Scheduler section). In addition to the old Primitive section options (hook1, scheduleDelay) you can choose Primitive Scheduler or Priority Scheduler, you can set cpuSpeedOvercommit, cpuCoresOvercommit, rescheduleAfterStart, scheduler (which implementation of the scheduler) and loadExpression properties. You can read more about this here Schedulers. 
[Scheduler]
hook1 = tashi.agents.DhcpDns
scheduleDelay = 2.0
scheduler = tashi.scheduler.ConsolidatedScheduler
rescheduleAfterStart = False
autoMigrations = True
loadExpression = memUsage + coresUsage * 512 + cpuUsage
# if it is 1, the CPU cores over-provisioning is not allowed
cpuCoresOverRate = 1
# if it is 1, the CPU speed over-provisioning is not allowed
cpuSpeedOverRate = 2 
# guaranteed number of servers that are always up and running and ready for provisioning, the remaining servers can be powered on if necessary
guaranteedServers = 3
optimalConsolidation = False
minimalVmMemory = 64
autoPowering = True
  • Add Servers section to the Tashi configuration file which tells Priority Scheduler which servers are of better efficiency rating and can be used for provisioning of the virtual machines with the highest priority. You can find more about this here Schedulers. 
[Servers]
# hostId = priority
1 = 3
2 = 2
3 = 1
4 = 4
  • Be aware that SQL schema is a bit different from the original Tashi SQL schema, because some additional properties have been added (like cpuShare for instances table and cpuSpeed for hosts table). Database tables are named a bit different as in original Tashi to prevent errors if you have original Tashi and SLA@SOI Tashi installed in parallel.
  • You can use python fabric.api to simplify some tasks. You will need a fabfile.py script with methods for simplifying tasks, these methods can be then executed from inside the folder where fabfile.py is located. For example if you want to have the latest SVN version on the Tashi cluster, put the hosts on your Tashi cluster inside env.hosts list and implement updateSvn method. 
from fabric.api import run, env, sudo

env.disable_known_hosts = True
env.hosts = ['mihas@localhost', 'mihas@10.100.0.3', 'mihas@10.100.0.4']

def updateSvn():
    """ fab updateSvn command executed inside folder with fabric file will execute svn up on all Tashi
        machine specified in env.hosts
    """
    run('cd /srv/tashi-slasoi/tashi/src;svn up')

def switchTashi(which):
    """ fab switchTashi:slasoi or fab switchTashi:original command executed inside folder with fabric file 
        will switch PYTHONPATH from SLA@SOI version to the original Tashi version or the other way around
    """
    sudo('cd /usr/lib/python2.6/;sudo rm -fr tashi')
    if which == "slasoi":
        print "switching to slasoi tashi"
        sudo('cd /usr/lib/python2.6/; ln -s /srv/tashi-slasoi/tashi/src/tashi tashi')
    else:
        print "switching to original tashi"
        sudo('cd /usr/lib/python2.6/; ln -s /srv/tashi/src/tashi tashi')

To update the Tashi cluster files now just execute the following command from inside the folder where fabfile.py is: 

fab updateSvn

You will be have to enter the passwords for your machines and then the files will be updated. Something like switchTashi method can be used to quickly switch between Tashi installations, if you have more Tashi installations in parallel.

© 2012 Geeknet, Inc.   Terms of Use - Privacy Policy - Cookies/Opt Out