HPL ERROR from process # 0, on line 240 of function HPL_pdtest: [1,7] Memory allocation failed for A, x and b. Skip. <<<
[912792.250504] Out of memory: Kill process 27830 (xhpl_hybrid_int) score 750 or sacrifice child [912792.252876] Killed process 27830 (xhpl_hybrid_int) total-vm:541372kB, anon-rss:480184kB, file-rss:0kB
HPL ERROR from process # 0, on line 240 of function HPL_pdtest: [1,7] Memory allocation failed for A, x and b. Skip. <<<
[912792.250504] Out of memory: Kill process 27830 (xhpl_hybrid_int) score 750 or sacrifice child [912792.252876] Killed process 27830 (xhpl_hybrid_int) total-vm:541372kB, anon-rss:480184kB, file-rss:0kB
Para executar esta tarefa é necessário realizar os seguintes passos:
- Instalar as dependências do open nebula: g++, libxmlrpc-c3-dev, scons, libsqlite3-dev, libmysqlclient-dev, libxml2-dev, libssl-dev, ruby;
- Realizar o download do pacote opennebula-3.2.1.tar.gz;
- Descompactar o pacote opennebula-3.2.1.tar.gz;
- Acessar o diretório previamente descompactado;
- executar o comando: scons sqlite=no mysql=yes parses=yes
- criar o grupo oneadmin: groupadd oneadmin
- criar o usuário oneadmin: useradd -d /var/lib/one -g oneadmin -s /bin/bash oneadmin
- criar o diretório home do usuário oneadmin: mkdir /var/lib/oneadmin
- instalar o opennebula: ./install.sh -u oneadmin -g oneadmin -c -s -o
- instalar as gems do ruby: ./share/install_gems/install_gems
- Instalar o nfs server: apt-get install nfs-kernel-server
- exportar o home do oneadmin para os nós da rede: echo "/var/lib/one 200.145.46.0/24(rw,sync,no_subtree_check,no_root_squash)" > /etc/exports
- instalar os scripts tm_clone.sh, tm_context.sh, tm_delete.sh, tm_ln.sh, tm_mkimage.sh, tm_mkswap.sh, tm_mv.sh no diretório /usr/lib/one/tm_commands/iscsi
- adicionar as seguintes linhas ao arquivo /etc/sudoers:
- oneadmin ALL=(ALL) NOPASSWD: /sbin/lvcreate
- oneadmin ALL=(ALL) NOPASSWD: /sbin/lvremove
- oneadmin ALL=(ALL) NOPASSWD: /sbin/lvs
- oneadmin ALL=(ALL) NOPASSWD: /usr/local/bin/iscsiadd
- oneadmin ALL=(ALL) NOPASSWD: /usr/local/bin/iscsirm
- criar o usuário oneadmin: useradd -d /var/lib/one -g oneadmin -s /bin/bash oneadmin
- criar o home do usuário oneadmin: mkdir /var/lib/one
- montar o home do oneadmin: mount -t nfs $SERVER:/var/lib/one /var/lib/one
- instalar as seguintes dependências: openssh-server, lvm, iscsitarget
- instalar os scripts iscsiadd e iscsirm (em anexo) no diretório /usr/local/bin
- Criar partição lvm: vgcreate osdc1 /dev/sda1
- Instalar as dependências: openssh, libvirt-bin, ruby
- criar o grupo oneadmin: groupadd oneadmin
- criar o usuário oneadmin: useradd -d /var/lib/one -g oneadmin -s /bin/bash oneadmin
- criar o home do usuário oneadmin: mkdir /var/lib/one
- montar o home do oneadmin: mount -t nfs $SERVER:/var/lib/one /var/lib/one
- instalar os pacotes de instância de iSCSI
- criar bridge LAN para a interface eth1 e configurar regras de roteamento:
- brctl addbr virbr1
- iptables -A INPUT -i virbr1 -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT
- iptables -A FORWARD -i virbr1 -o virbr1 -j ACCEPT
- iptables -t nat -A POSTROUTING -s 192.168.123.0/24 -j MASQUERADE
- onehost create osdc06 im_kvm vmm_kvm tm_iscsi
- onehost create osdc07 im_kvm vmm_kvm tm_iscsi
- onehost create osdc03 im_kvm vmm_kvm tm_iscsi
- sunstone-server -H 0.0.0.0 start
Educloud00 (LVM) keystone, glance, cinder, nova-*
Eth0 - 00:15:17:DE:B7:24 - 200.145.46.165/24 - educloud00.ncc.unesp.br CNAME cloud.ncc.unesp.br
Eth1 - 00:15:17:DE:B7:25
Educloud01 (TPM01)
Eth0 - 00:1e:67:3c:7c:df - 200.145.46.166/24 - educloud01.local
Eth1 - 00:1e:67:3c:7c:e0
Eth2 - 00:1e:67:3c:7c:e1
Eth3 - 00:1e:67:3c:7c:e2
Educloud02 (TPM02)
Eth0 - 00:1e:67:3c:89:ce - 200.145.46.167/24 - educloud02.local
Eth1 - 00:1e:67:3c:89:cf
Eth2 - 00:1e:67:3c:89:d0
Eth3 - 00:1e:67:3c:89:d1
Educloud03
Eth0 - 00:15:17:da:53:92 - 200.145.46.168/24 - educloud03.local
Eth1 - 00:15:17:da:53:93
Eth2 - 00:15:17:da:53:94
Eth3 - 00:15:17:da:53:95
Eth4 - 00:15:17:da:53:96
Educloud04
Eth0 - 00:15:17:da:55:62 - 200.145.46.169/24 - educloud04.local
Eth1 - 00:15:17:da:55:63
Eth2 - 00:15:17:da:55:64
Eth3 - 00:15:17:da:55:65
Eth4 - 00:15:17:da:55:66
Educloud05
Eth0 - 00:26:18:6d:65:a6 - 200.145.46.170/24 - educloud05.local
Eth1 - 00:26:18:6d:65:a7
Educloud06
Eth0 - 00:26:18:6d:61:64 - 200.145.46.171/24 - educloud06.local
Eth1 - 00:26:18:6d:61:65
Educloud07
Eth0 - 00:26:18:6d:67:ba - 200.145.46.172/24 - educloud07.local
Eth1 - 00:26:18:6d:67:bb
Educloud08
Eth0 - 00:26:18:6d:67:be - 200.145.46.173/24 - educloud08.local
Eth1 - 00:26:18:6d:67:bf
Educloud09
Eth0 - 00:26:18:6d:65:22 - 200.145.46.174/24 - educloud09.local
Eth1 - 00:26:18:6d:65:23
Educloud10
Eth0 - 00:26:18:6d:65:3e - 200.145.46.175/24 - educloud10.local
Eth1 - 00:26:18:6d:65:3f
This document refers to the installation manual of the main components of
OpenStack. The version of each component used can be found in the respective
sections of the components.
This document was produced by the Center for Scientific Computing, UNESP, with
funding from Intel and UNESP.
OpenStack OpenStack is a global collaboration of developers and cloud computing
technologists producing the ubiquitous open source cloud computing platform for
public and private clouds. The project aims to deliver solutions for all types
of clouds by being simple to implement, massively scalable, and feature rich.
The technology consists of a series of interrelated projects delivering various
components for a cloud infrastructure solution.
The OpenStack project is divided into sub projects that have a specific role in
the big picture.
The main components are: Cloud Compute (Nova) Cloud Storage (Swift), Image
registration and delivery (Glance), Identity (Keystone) and Dashboard
(Horizon).
Each component is independent of each other and can be installed on separate
machines, or all in one. In the environment of UNESP, OpenStack was installed in
seven machines, described in section "Environment used."
This document is modified version of OpenStack Install and Deploy Manual [1]
with minor adjustments and changes to resolve problems encountered during
installation and adjustment to the environment in which it was installed.
OpenStack is a collection of open source technology that provides massively
scalable open source cloud computing software. Currently OpenStack develops two
related projects: OpenStack Compute, which offers computing power through
virtual machine and network management, and OpenStack Object Storage which is
software for redundant, scalable object storage capacity. Closely related to the
OpenStack Compute project is the Image Service project, named Glance. OpenStack
can be used by corporations, service providers, VARS, SMBs, researchers, and
global data centers looking to deploy large-scale cloud deployments for private
or public clouds.
The main components are: Cloud Compute (Nova) Cloud Storage (Swift), Image
registration and delivery (Glance), Identity (Keystone) and Dashboard
(Horizon).
They are presented here in an order for educational purposes only to a
straightforward procedure for installation. But following a brief description of
each component.
Keystone is an OpenStack project that provides Identity, Token, Catalog and
Policy services for use specifically by projects in the OpenStack family. It
implements OpenStack’s Identity API.
Nova is the project name for OpenStack Compute, a cloud computing fabric
controller, the main part of an IaaS system. Individuals and organizations can
use Nova to host and manage their own cloud computing systems. Nova originated
as a project out of NASA Ames Research Laboratory.
OpenStack Object Storage (Swift) is a system to store objects in a massively
scalable large capacity system with built-in redundancy and failover. Object
Storage has a variety of applications, such as backing up or archiving data,
serving graphics or videos (streaming data to a user's browser), storing
secondary or tertiary static data, developing new applications with data
storage integration, storing data when predicting storage capacity is difficult,
and creating the elasticity and flexibility of cloud-based storage for your web
applications.
OpenStack Image Service (Glance) is a lookup and retrieval system for virtual
machine images. It can be configured in three ways: using OpenStack Object Store
to store images; using Amazon's Simple Storage Solution (S3) storage directly;
or using S3 storage with Object Store as the intermediate for S3 access.
This document aims to guide you in setting up a test environment or development.
The original documentation suggests many machines. To install OpenStack here,
you will need only one or two machines.
You can install all services on one machine only (all-in-one). Or you can
install OpenStack controller (all services except the nova-compute) on machine A
and a compute cloud controller on machine B.
For a production environment it is advisable to separate the elements to ensure
a high availability and redundancy.
Settings used in this document:
- Cloud Controller:- Cloud Computer Node:All machines are installed with Ubuntu Server 12.04 LTS.
Before starting the installation and configuration of each component must first
to make some adjustments.
For both conserving network resources and ensuring that network administrators
understand the needs for networks and public IP addresses for accessing the APIs
and VMs as necessary, this section offers recommendations and required minimum
sizes. Throughput of at least 1000 Mbps is suggested.
For OpenStack Compute, networking is configured on multi-node installations
between the physical machines on a single subnet. For networking between virtual
machine instances, three network options are available: flat, DHCP, and VLAN.
Two NICs (Network Interface Cards) are recommended on the server running
nova-network.
Management Network (RFC1918 IP Range, not publicly routable): This network is
utilized for all inter-server communications within the cloud infrastructure.
Recommended size: 255 IPs (CIDR /24)
Public Network (Publicly routable IP range): This network is utilized for
providing Public IP accessibility to the API endpoints within the cloud
infrastructure. Minimum size: 8 IPs (CIDR /29)
VM Network (RFC1918 IP Range, not publicly routable): This network is utilized
for providing primary IP addresses to the cloud instances. Recommended size:
1024 IPs (CIDR /22)
Floating IP network (Publicly routable IP Range): This network is utilized for
providing Public IP accessibility to selected cloud instances. Minimum size:
16 IPs (CIDR /28)
In this installation we will use eth0 to public interface and eth1 for
management interface.
To keep all the services in sync, you need to install NTP, and if you do a
multi-node configuration you will configure one server to be the reference
server.
Set up the NTP server on your controller node so that it receives data by
modifying the ntp.conf file and restarting the service. As root:
Set up the NTP client on your compute node so that the time between controller
node and compute node is synchronized. Do the following as a cron job on compute
node.
Many cloud computing use cases require persistent remote storage. Storage
solutions are often divided into three categories: object storage, block
storage, and file storage.
Here we will use a "object storage" and a "block storage".
With object storage, files are exposed through an HTTP interface, typically with
a REST API. All client data access is done at the user level: the operating
system is unaware of the presence of the remote storage system. In OpenStack,
the Object Storage service provides this type of functionality. Users access and
modify files by making HTTP requests. Because the data accesss interface provided
by an object storage system is at a low level of abstraction, people often build
on top of object storage to build file-based applications that provide a higher
level of abstraction. For example, the OpenStack Image service can be configured
to use the Object Storage service as a backend. Another use for object storage
solutions is as a content delivery network (CDN) for hosting static web content
(e.g., images, and media files), since object storage already provides an HTTP
interface.
With block storage, files are exposed through a low-level computer bus interface
such as SCSI or ATA, that is accessible over the network. Block storage is
synonymous with SAN (storage area network). Clients access data through the
operating system at the device level: users access the data by mounting the
remote device in a similar manner to how they would mount a local, physical disk
(e.g., using the "mount" command in Linux). In OpenStack, the nova-volume
service that forms part of the Compute service provides this type of
functionality, and uses iSCSI to expose remote data as a SCSI disk that is
attached to the network.
Because the data is exposed as a physical device, the end-user is responsible
for creating partitions and formatting the exposed disk device. In addition,
in OpenStack Compute a device can only be attached to one server at a time, so
block storage cannot be used for to share data across virtual machine instances
concurrently.
OpenStack Compute has a large number of configuration options. To simplify this
installation guide, we make a number of assumptions about the target
installation:
This installation process walks through installing a cloud controller node and a
compute node using a set of packages that are known to work with each other.
The cloud controller node contains all the nova- services including the API
server and the database server. The compute node needs to run only the
nova-compute service. You only need one nova-network service running in a
multi-node install.
The OpenStack Identity service manages users, tenants (accounts or projects) and
offers a common identity system for all the OpenStack components.
The Identity services has two primary functions:
1. User management: keep track of users and what they are permitted to do
2. Service catalog: Provide a catalog of what services are available and where
their API endpoints are located.The three main concepts of Identity user management are:
A user represents a human user, and has associated information such as username,
password and email.
A tenant can be thought of as a project, group, or organization. Whenever you
make requests to OpenStack services, you must specify a tenant. For example, if
you query the Compute service for a list of running instances, you will receive
a list of all of the running instances in the tenant you specified in your
query.
A role captures what operations a user is permitted to perform in a given tenant.
The two main concepts of Identity service management are:
The Identity service also maintains a user that corresponds to each service
(e.g., a user named nova, for the Compute service) and a special service tenant,
which is called service.
# apt-get install keystone
Delete the keystone.db file created in the /var/lib/keystone directory.
# rm /var/lib/keystone/keystone.db
Install mysql:
# apt-get install python-mysqldb mysql-server
Use sed to edit /etc/mysql/my.cnf to change bind-address from localhost
(127.0.0.1) to any (0.0.0.0) and restart the mysql service, as root:
# sed -i 's/127.0.0.1/0.0.0.0/g' /etc/mysql/my.cnf # service mysql restart
To configure the MySQL database, create the keystone database.
# mysql -u root -p mysql> CREATE DATABASE keystone; mysql> CREATE USER keystone; mysql> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' IDENTIFIED BY 'keystonepass'; mysql> FLUSH PRIVILEGES; mysql> quit;
Edit keystone.conf to use mysql:
[sql] connection = mysql://keystone:keystonepass@192.168.69.1/keystone
Change in keystone.conf the ADMIN_TOKEN:
admin_token = 012345SECRET99TOKEN012345
Restart the keystone service and populate with initial data:
# service keystone restart # keystone-manage db_sync
Create the file /root/openstackrc, with theses lines
export SERVICE_ENDPOINT=http://192.168.69.1:35357/v2.0/ export SERVICE_TOKEN=012345SECRET99TOKEN012345
Theses environment variables are useful to avoid execute commands with long args, like --token or --endpoint.
Reload the file:
# source /root/openstackrc
Create the tenants: openstackDemo and service:
# keystone tenant-create --name openstackDemo --description "Default Tenant" --enabled true # keystone tenant-create --name service --description "Service Tenant" --enabled true
Create the user admin, replace the tenant_id by openStackDemo tenant_id:
# keystone user-create --tenant_id 9c401c9d2b9d41bcabda6919d4aec63a --name admin --pass adminpass --enabled true
Create the roles: admin and user:
# keystone role-create --name admin # keystone role-create --name user
Grant admin role to user admin:
# keystone user-role-add --user [admin_user_id] --tenant_id [openstackDemo_tenant_id] --role [admin_role]
Create an user to each service, replace the tenant_id by the service tenant id:
# keystone user-create --tenant_id 92920816c7704a8a95c916d34dc7a05c --name glance --pass glancepass --enabled true # keystone user-create --tenant_id 92920816c7704a8a95c916d34dc7a05c --name nova --pass novapass --enabled true # keystone user-create --tenant_id 92920816c7704a8a95c916d34dc7a05c --name swift --pass swiftpass --enabled true
Add the users of each service to admin role:
# keystone user-role-add --user [glance_user_id] --tenant_id [service_tenant_id] --role [admin_role] # keystone user-role-add --user [nova_user_id] --tenant_id [service_tenant_id] --role [admin_role] # keystone user-role-add --user [swift_user_id] --tenant_id [service_tenant_id] --role [admin_role]
Until now, we just created: tenants, users and roles. The Keystone manage the services and yours endpoints too. In this way, the OpenStack components query to keystone where each service is located:
Run the follow commands, to create the services:
# keystone service-create --name keystone --type identity --description "Keystone Identity Service" # keystone service-create --name nova --type compute --description "Nova Compute Service" # keystone service-create --name volume --type volume --description "Nova Volume Service" # keystone service-create --name glance --type image --description "Glance Image Service" # keystone service-create --name swift --type object-store --description "Object Storage Service"
Run the follow commands, to create the endpoints of each service:
# keystone endpoint-create --region RegionOne --service_id [keystone_service_id] --publicurl http://192.168.69.1:5000/v2.0 --internalurl http://192.168.69.1:5000/v2.0 --adminurl http://192.168.69.1:35357/v2.0 # keystone endpoint-create --region RegionOne --service_id [compute_service_id] --publicurl 'http://192.168.69.1:8774/v2/%(tenant_id)s' --internalurl 'http://192.168.69.1:8774/v2/%(tenant_id)s' --adminurl 'http://192.168.69.1:8774/v2/%(tenant_id)s' # keystone endpoint-create --region RegionOne --service_id [volume_service_id] --publicurl 'http://192.168.69.1:8776/v1/%(tenant_id)s' --internalurl 'http://192.168.69.1:8776/v1/%(tenant_id)s' --adminurl 'http://192.168.69.1:8776/v1/%(tenant_id)s' # keystone endpoint-create --region RegionOne --service_id [glance_service_id] --publicurl http://192.168.69.1:9292/v1 --internalurl http://192.168.69.1:9292/v1 --adminurl http://192.168.69.1:9292/v1 # keystone endpoint-create --region RegionOne --service_id [swift_service_id] --publicurl 'http://192.168.69.1:8888/v1/AUTH_%(tenant_id)s' --adminurl 'http://192.168.69.1:8888/' --internalurl 'http://192.168.69.1:8888/v1/AUTH_%(tenant_id)s'
# sudo apt-get install curl openssl
Do a REST request to keystone-api using curl:
# curl -d '{"auth": {"tenantName": "openstackDemo", "passwordCredentials": {"username": "admin", "password": "adminpass"}}}' -H "Content-type: application/json" http://192.168.69.1:35357/v2.0/tokens | python -mjson.tool
The output should have the services, endpoints and a valid token for 24 hours:
{
"access": {
"serviceCatalog": [
{
"endpoints": [
{
"adminURL": "http://192.168.69.1:8776/v1/9c401c9d2b9d41bcabda6919d4aec63a",
"internalURL": "http://192.168.69.1:8776/v1/9c401c9d2b9d41bcabda6919d4aec63a",
"publicURL": "http://192.168.69.1:8776/v1/9c401c9d2b9d41bcabda6919d4aec63a",
"region": "RegionOne"
}
],
"endpoints_links": [],
"name": "volume",
"type": "volume"
},
{
"endpoints": [
{
"adminURL": "http://192.168.69.1:9292/v1",
"internalURL": "http://192.168.69.1:9292/v1",
"publicURL": "http://192.168.69.1:9292/v1",
"region": "RegionOne"
}
],
"endpoints_links": [],
"name": "glance",
"type": "image"
},
{
"endpoints": [
{
"adminURL": "http://192.168.69.1:8774/v2/9c401c9d2b9d41bcabda6919d4aec63a",
"internalURL": "http://192.168.69.1:8774/v2/9c401c9d2b9d41bcabda6919d4aec63a",
"publicURL": "http://192.168.69.1:8774/v2/9c401c9d2b9d41bcabda6919d4aec63a",
"region": "RegionOne"
}
],
"endpoints_links": [],
"name": "nova",
"type": "compute"
},
{
"endpoints": [
{
"adminURL": "http://192.168.69.1:35357/v2.0",
"internalURL": "http://192.168.69.1:5000/v2.0",
"publicURL": "http://192.168.69.1:5000/v2.0",
"region": "RegionOne"
}
],
"endpoints_links": [],
"name": "keystone",
"type": "identity"
},
{
"endpoints": [
{
"adminURL": "http://192.168.69.1:8888/",
"internalURL": "http://192.168.69.1:8888/v1/AUTH_9c401c9d2b9d41bcabda6919d4aec63a",
"publicURL": "http://192.168.69.1:8888/v1/AUTH_9c401c9d2b9d41bcabda6919d4aec63a",
"region": "RegionOne"
}
],
"endpoints_links": [],
"name": "swift",
"type": "object-store"
}
],
"token": {
"expires": "2012-06-08T15:31:46Z",
"id": "05b818ff23564d5599c97ea5e1df7bbe",
"tenant": {
"description": "Default Tenant",
"enabled": true,
"id": "9c401c9d2b9d41bcabda6919d4aec63a",
"name": "openstackDemo"
}
},
"user": {
"id": "1fcfbe778fc3428aa30db782056b34d7",
"name": "admin",
"roles": [
{
"id": "a2d6da77c0a54105aab94484e0d2088b",
"name": "admin"
}
],
"roles_links": [],
"username": "admin"
}
}
}
You can list users, roles, tenants and services:
# keystone user-list +----------------------------------+---------+-------+--------+ | id | enabled | email | name | +----------------------------------+---------+-------+--------+ | 029c5749548946f7b560b2706d31d488 | True | None | glance | | 1fcfbe778fc3428aa30db782056b34d7 | True | None | admin | | 4b75079aeb1b408ebdb286bfb85e719f | True | None | swift | | e25f81d50eb84bdb92907adbd0e41f25 | True | None | nova | +----------------------------------+---------+-------+--------+
# keystone role-list +----------------------------------+-------+ | id | name | +----------------------------------+-------+ | 845e83e4d9bf4d8d8188b1e261dfe103 | user | | a2d6da77c0a54105aab94484e0d2088b | admin | +----------------------------------+-------+
# keystone tenant-list +----------------------------------+---------------+---------+ | id | name | enabled | +----------------------------------+---------------+---------+ | 92920816c7704a8a95c916d34dc7a05c | service | True | | 9c401c9d2b9d41bcabda6919d4aec63a | openstackDemo | True | +----------------------------------+---------------+---------+
# keystone service-list +----------------------------------+----------+----------------+---------------------------+ | id | name | type | description | +----------------------------------+----------+----------------+---------------------------+ | 00486163c7c64c6a86f577627071aafc | nova | compute | Nova Compute Service | | 69d3a6b21c9348acb1042d7d9386ff81 | volume | volume | Nova Volume Service | | 7b09782f9faf448781f5a460acabe258 | swift | object-store | Object Storage Service | | d6b32583a6694e9b828b2a50037623ba | keystone | identity | Keystone Identity Service | | f7f964a71e2a45119dcaede68fafbd78 | glance | image | Glance Image Service | +----------------------------------+----------+----------------+---------------------------+
OpenStack Object Storage (Swift) is a system to store objects in a massively
scalable large capacity system with built-in redundancy and failover. Object
Storage has a variety of applications, such as backing up or archiving data,
serving graphics or videos (streaming data to a user's browser), storing
secondary or tertiary static data, developing new applications with data
storage integration, storing data when predicting storage capacity is difficult,
and creating the elasticity and flexibility of cloud-based storage for your web
applications.
In this environment we use the same controller node as storage too. So the swift and swift-proxy is installed in the controller-node.
Install the swift and dependencies:
# apt-get install swift python-xattr python-memcache rsync memcached python-netifaces
Unfortunately at the time of writing this manual swift package not automates some tasks, such as the creation of configuration files. We have to do this manually:
# mkdir /etc/swift
Create the config file /etc/swift/swift.conf:
[swift-hash] # random unique string that can never change (DO NOT LOSE) swift_hash_path_suffix = fLIbertYgibbitZ
In this case, the object-nodes (computer when data are stored) is the same cloud-controller.
# apt-get install swift-account swift-container swift-object xfsprogs
Each "Object node" can have many devices Is a requisite use xfs file system.
# fdisk /dev/sdb (set up a single partition) # mkfs.xfs -i size=1024 /dev/sdb1
This device should be mount at /srv/node/
echo "/dev/sdb1 /srv/node/sdb1 xfs noatime,nodiratime,nobarrier,logbufs=8 0 0" >> /etc/fstab mkdir -p /srv/node/sdb1 mount /srv/node/sdb1 chown -R swift:swift /srv/node
uid = swift gid = swift log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid address = 192.168.69.1 [account] max connections = 2 path = /srv/node/ read only = false lock file = /var/lock/account.lock [container] max connections = 2 path = /srv/node/ read only = false lock file = /var/lock/container.lock [object] max connections = 2 path = /srv/node/ read only = false lock file = /var/lock/object.lock
Edit the /etc/default/rsync:
RSYNC_ENABLE = true
Restart the rsync:
service rsync restart
Create the /etc/swift/account-server.conf:
[DEFAULT] bind_ip = 192.168.69.1 workers = 2 [pipeline:main] pipeline = account-server [app:account-server] use = egg:swift#account [account-replicator] [account-auditor] [account-reaper]
Create the /etc/swift/container-server.conf:
[DEFAULT] bind_ip = 192.168.69.1 workers = 2 [pipeline:main] pipeline = container-server [app:container-server] use = egg:swift#container [container-replicator] [container-updater] [container-auditor]
Create the /etc/swift/object-server.conf:
[DEFAULT] bind_ip = 192.168.69.1 workers = 2 [pipeline:main] pipeline = object-server [app:object-server] use = egg:swift#object [object-replicator] [object-updater] [object-auditor]
The swift-proxy is the component that acts like a proxy, so you can have multiple object-nodes and one swift-proxy. When an user or openStack component need get a object, its ask for swift-proxy.
Install swift-proxy:
# apt-get install swift-proxy memcached
Create a self-sign SSL certificate:
cd /etc/swift openssl req -new -x509 -nodes -out cert.crt -keyout cert.key
Change the memcached to listen in correct interface, change the /etc/memcached.conf:
-l 127.0.0.1 to -l 192.168.69.1
Restart the memcached:
service memcached restart
Create the file /etc/swift/proxy-server.conf:
[DEFAULT]
bind_port = 8888
user = swift
[pipeline:main]
pipeline = catch_errors healthcheck cache authtoken keystone proxy-server
[app:proxy-server]
use = egg:swift#proxy
account_autocreate = true
[filter:keystone]
paste.filter_factory = keystone.middleware.swift_auth:filter_factory
operator_roles = admin, swiftoperator
[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
# Delaying the auth decision is required to support token-less
# usage for anonymous referrers ('.r:*').
delay_auth_decision = 10
service_port = 5000
service_host = 192.168.69.1
auth_port = 35357
auth_host = 192.168.69.1
auth_token = 012345SECRET99TOKEN012345
admin_token = 012345SECRET99TOKEN012345
auth_protocol = http
[filter:cache]
use = egg:swift#memcache
set log_name = cache
[filter:catch_errors]
use = egg:swift#catch_errors
[filter:healthcheck]
use = egg:swift#healthcheck
Create the account, container and object rings. The builder command is basically creating a builder file with a few parameters. The parameter with the value of 18 represents 2 ^ 18th, the value that the partition will be sized to. Set this "partition power" value based on the total amount of storage you expect your entire ring to use. The value of 1 represents the number of replicas of each object, with the last value being the number of hours to restrict moving a partition more than once.
cd /etc/swift swift-ring-builder account.builder create 18 1 1 swift-ring-builder container.builder create 18 1 1 swift-ring-builder object.builder create 18 1 1
For every storage device on each node add entries to each ring:
swift-ring-builder account.builder add z<ZONE>-<STORAGE_LOCAL_NET_IP>:6002/<DEVICE> 100 swift-ring-builder container.builder add z<ZONE>-<STORAGE_LOCAL_NET_IP_1>:6001/<DEVICE> 100 swift-ring-builder object.builder add z<ZONE>-<STORAGE_LOCAL_NET_IP_1>:6000/<DEVICE> 100
In our case, we have only one zone in one storage node with one device (sdb1), so the command should be:
swift-ring-builder account.builder add z1-192.168.69.1:6002/sdb1 100 swift-ring-builder container.builder add z1-192.168.69.1:6001/sdb1 100 swift-ring-builder object.builder add z1-192.168.69.1:6000/sdb1 100
Verify the ring contents for each ring:
swift-ring-builder account.builder swift-ring-builder container.builder swift-ring-builder object.builder
Rebalance the rings:
swift-ring-builder account.builder rebalance swift-ring-builder container.builder rebalance swift-ring-builder object.builder rebalance
Change the permissions of config files:
# chown -R swift:swift /etc/swift/
Start the swift-proxy:
swift-init proxy start
Start all swift services:
swift-init main start swift-init rest start
The file /root/openstackrc will receive more environment variables:
# Used for Keystone export SERVICE_ENDPOINT=http://192.168.69.1:35357/v2.0/ export SERVICE_TOKEN=012345SECRET99TOKEN012345 # Used for swift export ST_AUTH=http://192.168.69.1:5000/v2.0 export ST_USER=openstackDemo:admin export ST_KEY=adminpass export OS_REGION_NAME=RegionOne
Reload the file:
# source /root/openstackrc
Try to get swift status, with the command:
# swift -V 2.0 stat
List the containers:
# swift -V 2.0 list
Do some upload files:
# swift -V 2.0 upload myfiles bigfile1.tgz # swift -V 2.0 upload myfiles bigfile2.tgz
Download the container "myfiles":
# cd /tmp/ # swift -V 2.0 download myfiles
OpenStack Image Service (Glance) is a lookup and retrieval system for virtual
machine images. It can be configured in three ways: using OpenStack Object Store
to store images; using Amazon's Simple Storage Solution (S3) storage directly;
or using S3 storage with Object Store as the intermediate for S3 access.
Install the glance on the controller node:
# apt-get install glance
Remove the sqlite file:
# rm /var/lib/glance/glance.sqlite
# mysql -u root -p mysql> CREATE DATABASE glance; mysql> CREATE USER glance; mysql> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' IDENTIFIED BY 'glancepass'; mysql> FLUSH PRIVILEGES; mysql> quit;
Copy the config files to /etc/glance/:
/etc/glance/glance-api.conf:
[DEFAULT] # Show more verbose log output (sets INFO log level output) verbose = True # Show debugging output in logs (sets DEBUG log level output) debug = False # Which backend store should Glance use by default is not specified # in a request to add a new image to Glance? Default: 'file' # Available choices are 'file', 'swift', and 's3' default_store = swift # Address to bind the API server bind_host = 0.0.0.0 # Port the bind the API server to bind_port = 9292 # Log to this file. Make sure you do not set the same log # file for both the API and registry servers! log_file = /var/log/glance/api.log # Backlog requests when creating socket backlog = 4096 # Number of Glance API worker processes to start. # On machines with more than one CPU increasing this value # may improve performance (especially if using SSL with # compression turned on). It is typically recommended to set # this value to the number of CPUs present on your machine. workers = 0 # Role used to identify an authenticated user as administrator #admin_role = admin # ================= Syslog Options ============================ # Send logs to syslog (/dev/log) instead of to file specified # by `log_file` use_syslog = False # Facility to use. If unset defaults to LOG_USER. # syslog_log_facility = LOG_LOCAL0 # ================= SSL Options =============================== # Certificate file to use when starting API server securely # cert_file = /path/to/certfile # Private key file to use when starting API server securely # key_file = /path/to/keyfile # ================= Security Options ========================== # AES key for encrypting store 'location' metadata, including # -- if used -- Swift or S3 credentials # Should be set to a random string of length 16, 24 or 32 bytes # metadata_encryption_key = <16, 24 or 32 char registry metadata key> # ============ Registry Options =============================== # Address to find the registry server registry_host = 0.0.0.0 # Port the registry server is listening on registry_port = 9191 # What protocol to use when connecting to the registry server? # Set to https for secure HTTP communication registry_client_protocol = http # The path to the key file to use in SSL connections to the # registry server, if any. Alternately, you may set the # GLANCE_CLIENT_KEY_FILE environ variable to a filepath of the key file # registry_client_key_file = /path/to/key/file # The path to the cert file to use in SSL connections to the # registry server, if any. Alternately, you may set the # GLANCE_CLIENT_CERT_FILE environ variable to a filepath of the cert file # registry_client_cert_file = /path/to/cert/file # The path to the certifying authority cert file to use in SSL connections # to the registry server, if any. Alternately, you may set the # GLANCE_CLIENT_CA_FILE environ variable to a filepath of the CA cert file # registry_client_ca_file = /path/to/ca/file # ============ Notification System Options ===================== # Notifications can be sent when images are create, updated or deleted. # There are three methods of sending notifications, logging (via the # log_file directive), rabbit (via a rabbitmq queue), qpid (via a Qpid # message queue), or noop (no notifications sent, the default) notifier_strategy = noop # Configuration options if sending notifications via rabbitmq (these are # the defaults) rabbit_host = localhost rabbit_port = 5672 rabbit_use_ssl = false rabbit_userid = guest rabbit_password = guest rabbit_virtual_host = / rabbit_notification_exchange = glance rabbit_notification_topic = glance_notifications # Configuration options if sending notifications via Qpid (these are # the defaults) qpid_notification_exchange = glance qpid_notification_topic = glance_notifications qpid_host = localhost qpid_port = 5672 qpid_username = qpid_password = qpid_sasl_mechanisms = qpid_reconnect_timeout = 0 qpid_reconnect_limit = 0 qpid_reconnect_interval_min = 0 qpid_reconnect_interval_max = 0 qpid_reconnect_interval = 0 qpid_heartbeat = 5 # Set to 'ssl' to enable SSL qpid_protocol = tcp qpid_tcp_nodelay = True # ============ Filesystem Store Options ======================== # Directory that the Filesystem backend store # writes image data to filesystem_store_datadir = /var/lib/glance/images/ # ============ Swift Store Options ============================= # Version of the authentication service to use # Valid versions are '2' for keystone and '1' for swauth and rackspace swift_store_auth_version = 2 # Address where the Swift authentication service lives # Valid schemes are 'http://' and 'https://' # If no scheme specified, default to 'https://' # For swauth, use something like '127.0.0.1:8080/v1.0/' swift_store_auth_address = http://192.168.69.1:35357/v2.0/ # User to authenticate against the Swift authentication service # If you use Swift authentication service, set it to 'account':'user' # where 'account' is a Swift storage account and 'user' # is a user in that account swift_store_user = service:glance # Auth key for the user authenticating against the # Swift authentication service swift_store_key = glancepass # Container within the account that the account should use # for storing images in Swift swift_store_container = glance # Do we create the container if it does not exist? swift_store_create_container_on_put = True # What size, in MB, should Glance start chunking image files # and do a large object manifest in Swift? By default, this is # the maximum object size in Swift, which is 5GB swift_store_large_object_size = 5120 # When doing a large object manifest, what size, in MB, should # Glance write chunks to Swift? This amount of data is written # to a temporary disk buffer during the process of chunking # the image file, and the default is 200MB swift_store_large_object_chunk_size = 200 # Whether to use ServiceNET to communicate with the Swift storage servers. # (If you aren't RACKSPACE, leave this False!) # # To use ServiceNET for authentication, prefix hostname of # `swift_store_auth_address` with 'snet-'. # Ex. https://example.com/v1.0/ -> https://snet-example.com/v1.0/ swift_enable_snet = False # ============ S3 Store Options ============================= # Address where the S3 authentication service lives # Valid schemes are 'http://' and 'https://' # If no scheme specified, default to 'http://' s3_store_host = 127.0.0.1:8080/v1.0/ # User to authenticate against the S3 authentication service s3_store_access_key = <20-char AWS access key> # Auth key for the user authenticating against the # S3 authentication service s3_store_secret_key = <40-char AWS secret key> # Container within the account that the account should use # for storing images in S3. Note that S3 has a flat namespace, # so you need a unique bucket name for your glance images. An # easy way to do this is append your AWS access key to "glance". # S3 buckets in AWS *must* be lowercased, so remember to lowercase # your AWS access key if you use it in your bucket name below! s3_store_bucket = <lowercased 20-char aws access key>glance # Do we create the bucket if it does not exist? s3_store_create_bucket_on_put = False # When sending images to S3, the data will first be written to a # temporary buffer on disk. By default the platform's temporary directory # will be used. If required, an alternative directory can be specified here. # s3_store_object_buffer_dir = /path/to/dir # ============ RBD Store Options ============================= # Ceph configuration file path # If using cephx authentication, this file should # include a reference to the right keyring # in a client.<USER> section rbd_store_ceph_conf = /etc/ceph/ceph.conf # RADOS user to authenticate as (only applicable if using cephx) rbd_store_user = glance # RADOS pool in which images are stored rbd_store_pool = images # Images will be chunked into objects of this size (in megabytes). # For best performance, this should be a power of two rbd_store_chunk_size = 8 # ============ Delayed Delete Options ============================= # Turn on/off delayed delete delayed_delete = False # Delayed delete time in seconds scrub_time = 43200 # Directory that the scrubber will use to remind itself of what to delete # Make sure this is also set in glance-scrubber.conf scrubber_datadir = /var/lib/glance/scrubber # =============== Image Cache Options ============================= # Base directory that the Image Cache uses image_cache_dir = /var/lib/glance/image-cache/ [paste_deploy] flavor = keystone
/etc/glance/glance-api-paste.ini:
# Default minimal pipeline [pipeline:glance-api] pipeline = versionnegotiation context apiv1app authtoken # Use the following pipeline for keystone auth # i.e. in glance-api.conf: # [paste_deploy] # flavor = keystone # [pipeline:glance-api-keystone] pipeline = versionnegotiation authtoken context apiv1app # Use the following pipeline to enable transparent caching of image files # i.e. in glance-api.conf: # [paste_deploy] # flavor = caching # [pipeline:glance-api-caching] pipeline = versionnegotiation context cache apiv1app # Use the following pipeline for keystone auth with caching # i.e. in glance-api.conf: # [paste_deploy] # flavor = keystone+caching # [pipeline:glance-api-keystone+caching] pipeline = versionnegotiation authtoken context cache apiv1app # Use the following pipeline to enable the Image Cache Management API # i.e. in glance-api.conf: # [paste_deploy] # flavor = cachemanagement # [pipeline:glance-api-cachemanagement] pipeline = versionnegotiation context cache cachemanage apiv1app # Use the following pipeline for keystone auth with cache management # i.e. in glance-api.conf: # [paste_deploy] # flavor = keystone+cachemanagement # [pipeline:glance-api-keystone+cachemanagement] pipeline = versionnegotiation authtoken context cache cachemanage apiv1app [app:apiv1app] paste.app_factory = glance.common.wsgi:app_factory glance.app_factory = glance.api.v1.router:API [filter:versionnegotiation] paste.filter_factory = glance.common.wsgi:filter_factory glance.filter_factory = glance.api.middleware.version_negotiation:VersionNegotiationFilter [filter:cache] paste.filter_factory = glance.common.wsgi:filter_factory glance.filter_factory = glance.api.middleware.cache:CacheFilter [filter:cachemanage] paste.filter_factory = glance.common.wsgi:filter_factory glance.filter_factory = glance.api.middleware.cache_manage:CacheManageFilter [filter:context] paste.filter_factory = glance.common.wsgi:filter_factory glance.filter_factory = glance.common.context:ContextMiddleware [filter:authtoken] paste.filter_factory = keystone.middleware.auth_token:filter_factory service_protocol = http service_host = 192.168.69.1 service_port = 5000 auth_host = 192.168.69.1 auth_port = 35357 auth_protocol = http auth_uri = http://192.168.69.1:5000/ admin_tenant_name = service admin_user = glance admin_password = glancepass
/etc/glance/glance-registry.conf:
[DEFAULT] # Show more verbose log output (sets INFO log level output) verbose = True # Show debugging output in logs (sets DEBUG log level output) debug = True # Address to bind the registry server bind_host = 0.0.0.0 # Port the bind the registry server to bind_port = 9191 # Log to this file. Make sure you do not set the same log # file for both the API and registry servers! log_file = /var/log/glance/registry.log # Backlog requests when creating socket backlog = 4096 # SQLAlchemy connection string for the reference implementation # registry server. Any valid SQLAlchemy connection string is fine. # See: http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/connections.html#sqlalchemy.create_engine sql_connection = mysql://glance:glancepass@192.168.69.1/glance # Period in seconds after which SQLAlchemy should reestablish its connection # to the database. # # MySQL uses a default `wait_timeout` of 8 hours, after which it will drop # idle connections. This can result in 'MySQL Gone Away' exceptions. If you # notice this, you can lower this value to ensure that SQLAlchemy reconnects # before MySQL can drop the connection. sql_idle_timeout = 3600 # Limit the api to return `param_limit_max` items in a call to a container. If # a larger `limit` query param is provided, it will be reduced to this value. api_limit_max = 1000 # If a `limit` query param is not provided in an api request, it will # default to `limit_param_default` limit_param_default = 25 # Role used to identify an authenticated user as administrator #admin_role = admin # ================= Syslog Options ============================ # Send logs to syslog (/dev/log) instead of to file specified # by `log_file` use_syslog = True # Facility to use. If unset defaults to LOG_USER. # syslog_log_facility = LOG_LOCAL1 # ================= SSL Options =============================== # Certificate file to use when starting registry server securely # cert_file = /path/to/certfile # Private key file to use when starting registry server securely # key_file = /path/to/keyfile [paste_deploy] flavor = keystone
/etc/glance/glance-registry-paste.ini:
# Default minimal pipeline [pipeline:glance-registry] pipeline = context registryapp authtoken # Use the following pipeline for keystone auth # i.e. in glance-registry.conf: # [paste_deploy] # flavor = keystone # [pipeline:glance-registry-keystone] pipeline = authtoken context registryapp [app:registryapp] paste.app_factory = glance.common.wsgi:app_factory glance.app_factory = glance.registry.api.v1:API [filter:context] context_class = glance.registry.context.RequestContext paste.filter_factory = glance.common.wsgi:filter_factory glance.filter_factory = glance.common.context:ContextMiddleware [filter:authtoken] paste.filter_factory = keystone.middleware.auth_token:filter_factory service_protocol = http service_host = 192.168.69.1 service_port = 5000 auth_host = 192.168.69.1 auth_port = 35357 auth_protocol = http auth_uri = http://192.168.69.1:5000/ admin_tenant_name = service admin_user = glance admin_password = glancepass
/etc/glance/glance-scrubber.conf:
[DEFAULT] # Show more verbose log output (sets INFO log level output) verbose = True # Show debugging output in logs (sets DEBUG log level output) debug = False # Log to this file. Make sure you do not set the same log # file for both the API and registry servers! log_file = /var/log/glance/scrubber.log # Send logs to syslog (/dev/log) instead of to file specified by `log_file` use_syslog = False # Should we run our own loop or rely on cron/scheduler to run us daemon = False # Loop time between checking for new items to schedule for delete wakeup_time = 300 sql_connection = mysql://glance:glancepass@192.168.69.1/glance # Directory that the scrubber will use to remind itself of what to delete # Make sure this is also set in glance-api.conf scrubber_datadir = /var/lib/glance/scrubber # Only one server in your deployment should be designated the cleanup host cleanup_scrubber = False # pending_delete items older than this time are candidates for cleanup cleanup_scrubber_time = 86400 # Address to find the registry server for cleanups registry_host = 0.0.0.0 # Port the registry server is listening on registry_port = 9191
# glance-manage version_control 0 # glance-manage db_sync # service glance-registry restart # service glance-api restart
Put the new env vars to /root/openstackrc:
# Used for Keystone export SERVICE_ENDPOINT=http://192.168.69.1:35357/v2.0/ export SERVICE_TOKEN=012345SECRET99TOKEN012345 # Used for swift export ST_AUTH=http://192.168.69.1:5000/v2.0 export ST_USER=openstackDemo:admin export ST_KEY=adminpass export OS_REGION_NAME=RegionOne # Used for glance export OS_USERNAME=admin export OS_TENANT_NAME=openstackDemo export OS_PASSWORD=adminpass export OS_AUTH_URL=http://192.168.69.1:5000/v2.0/ export OS_REGION_NAME=RegionOne
Download a test image:
mkdir /tmp/images cd /tmp/images/ wget http://smoser.brickies.net/ubuntu/ttylinux-uec/ttylinux-uec-amd64-12.1_2.6.35-22_1.tar.gz tar -zxvf ttylinux-uec-amd64-12.1_2.6.35-22_1.tar.gz
Upload the image:
# cd /tmp/images/ # glance add name="tty-linux-kernel" disk_format=aki container_format=aki < ttylinux-uec-amd64-12.1_2.6.35-22_1-vmlinuz # glance add name="tty-linux-ramdisk" disk_format=ari container_format=ari < ttylinux-uec-amd64-12.1_2.6.35-22_1-loader # glance add name="tty-linux" disk_format=ami container_format=ami kernel_id=[kernel_image_id] ramdisk_id=[kernel_ramdisk_image_id] < ttylinux-uec-amd64-12.1_2.6.35-22_1.img
List the images:
# glance index
Nova is the project name for OpenStack Compute, a cloud computing fabric controller, the main part of an IaaS system. Individuals and organizations can use Nova to host and manage their own cloud computing systems. Nova originated as a project out of NASA Ames Research Laboratory.
OpenStack Compute gives you a tool to orchestrate a cloud, including running instances, managing networks, and controlling access to the cloud through users and projects. The underlying open source project's name is Nova, and it provides the software that can control an Infrastructure as a Service (IaaS) cloud computing platform. It is similar in scope to Amazon EC2 and Rackspace Cloud Servers. OpenStack Compute does not include any virtualization software; rather it defines drivers that interact with underlying virtualization mechanisms that run on your host operating system, and exposes functionality over a web-based API.
AMQP is the messaging technology chosen by the OpenStack cloud. The AMQP broker, either RabbitMQ or Qpid, sits between any two Nova components and allows them to communicate in a loosely coupled fashion. More precisely, Nova components (the compute fabric of OpenStack) use Remote Procedure Calls (RPC hereinafter) to communicate to one another.
For more information about AMQP in Nova, please read the AMQP section in nova manual
For production environments the most tested hypervisors are KVM and Xen-based hypervisors. KVM runs through libvirt, Xen runs best through XenAPI calls. KVM is selected by default and requires the least additional configuration. This guide offers information on
specific walkthrough configuration options to KVM.
KVM is configured as the default hypervisor for Compute. To enable KVM explicitly, add the following configuration options /etc/nova/nova.conf:
connection_type=libvirt libvirt_type=kvm
The KVM hypervisor supports the following virtual machine image formats:
The processors of your compute host need to support virtualization technology (VT) to use KVM.
If you are running on Ubuntu, use the kvm-ok command to check if your processor has VT support, it is enabled in the BIOS, and KVM is installed properly, as root:
# kvm-ok INFO: /dev/kvm exists KVM acceleration can be used
On distributions that don't have kvm-ok, you can check if your processor has VT support by looking at the processor flags in the /proc/cpuinfo file. For Intel processors, look for the vmx flag, and for AMD processors, look for the svm flag. A simple way to check is to run the following command and see if there is any output:
$ egrep '(vmx|svm)' --color=always /proc/cpuinfo
KVM requires the kvm and either kvm-intel or kvm-amd modules to be loaded. This may have been configured automatically on your distribution when KVM is installed. You can check that they have been loaded using lsmod, as follows, with expected output for Intel-based processors:
$ lsmod | grep kvm kvm_intel 137721 9 kvm 415459 1 kvm_intel
If your compute host is Intel-based, run the following as root to load the kernel modules:
# modprobe kvm # modprobe kvm-intel
Add the following lines to /etc/modules so that these modules will load on reboot:
kvm kvm-intel
To configure the MySQL database, create the nova database on the cloud controller machine:
mysql> CREATE DATABASE nova; mysql> CREATE USER nova; mysql> GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' IDENTIFIED BY 'novapass'; mysql> quit
Install the messaging queue server, RabbitMQ. You also have the option of installing
Apache Qpid, refer to the Compute Administration Manual for instructions.
sudo apt-get install rabbitmq-server
Install the required nova- packages, and dependencies are automatically installed.
sudo apt-get install nova-volume nova-compute nova-vncproxy nova-api nova-ajax-console-proxy nova-cert nova-consoleauth nova-doc nova-scheduler nova-network
nova-manage config convert --infile=/etc/nova/nova.conf --outfile=/etc/nova/nova.conf.new mv /etc/nova/nova.conf.new /etc/nova/nova.conf
The packages automatically do these steps for a user named nova, but if you are installing
as another user you should ensure that the nova.conf file should have its owner set to
root:nova, and mode set to 0640, since the file contains your MySQL server’s username
and password. This packaged install ensures that the nova user belongs to the nova group
and that the .conf file permissions are set, but here are the manual commands, which
should be run as root:
# groupadd nova # usermod -g nova nova # chown -R root:nova /etc/nova # chmod 640 /etc/nova/nova.conf
Modify your nova.conf, nova-compute and api-paste.ini according to the following examples:
nova-compute.conf
[DEFAULT] libvirt_type=kvm
nova.conf
[DEFAULT] # LOGS/STATE verbose=True use_syslog=False debug=False #logging_default_format_string = '%(asctime)s %(levelname)s %(name)s [-] %(message)s' logging_default_format_string = '%(asctime)s %(levelname)s %(name)s [-] %(message)s' logging_context_format_string = '%(asctime)s %(levelname)s %(name)s [-] %(message)s' # AUTHENTICATION auth_strategy=keystone logdir=/var/log/nova/ state_path=/var/lib/nova lock_path=/var/run/nova bindir=/usr/bin/ force_to_raw=False # SCHEDULER compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler scheduler_default_filters=AllHostsFilter # VOLUMES volume_group=nova-volumes volume_name_template=volume-%08x iscsi_helper=tgtadm # DATABASE sql_connection=mysql://nova:novapass@192.168.69.1/nova # COMPUTE libvirt_type=kvm connection_type=libvirt instance_name_template=instance-%08x api_paste_config=/etc/nova/api-paste.ini allow_resize_to_same_host=True # APIS osapi_compute_extension=nova.api.openstack.compute.contrib.standard_extensions ec2_dmz_host=192.168.69.1 s3_host=192.168.69.1 # RABBITMQ rabbit_host=192.168.69.1 # GLANCE image_service=nova.image.glance.GlanceImageService glance_api_servers=192.168.69.1:9292 # NETWORK network_manager=nova.network.manager.FlatDHCPManager force_dhcp_release=True dhcpbridge_flagfile=/etc/nova/nova.conf firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver my_ip=192.168.69.1 public_interface=br100 vlan_interface=eth0 flat_network_bridge=br100 flat_interface=eth0 fixed_range=192.168.70.0/24 # NOVNC CONSOLE - You should change this IP to public ip of current nova-compute machine novncproxy_base_url=http://200.145.46.167:6080/vnc_auto.html vncserver_proxyclient_address=200.145.46.167 vncserver_listen=200.145.46.167 xvpvncproxy_base_url=http://200.145.46.167:6081/console
api-paste.ini
############ # Metadata # ############ [composite:metadata] use = egg:Paste#urlmap /: metaversions /latest: meta /1.0: meta /2007-01-19: meta /2007-03-01: meta /2007-08-29: meta /2007-10-10: meta /2007-12-15: meta /2008-02-01: meta /2008-09-01: meta /2009-04-04: meta [pipeline:metaversions] pipeline = ec2faultwrap logrequest metaverapp [pipeline:meta] pipeline = ec2faultwrap logrequest metaapp [app:metaverapp] paste.app_factory = nova.api.metadata.handler:Versions.factory [app:metaapp] paste.app_factory = nova.api.metadata.handler:MetadataRequestHandler.factory ####### # EC2 # ####### [composite:ec2] use = egg:Paste#urlmap /services/Cloud: ec2cloud [composite:ec2cloud] use = call:nova.api.auth:pipeline_factory noauth = ec2faultwrap logrequest ec2noauth cloudrequest validator ec2executor deprecated = ec2faultwrap logrequest authenticate cloudrequest validator ec2executor keystone = ec2faultwrap logrequest ec2keystoneauth cloudrequest validator ec2executor [filter:ec2faultwrap] paste.filter_factory = nova.api.ec2:FaultWrapper.factory [filter:logrequest] paste.filter_factory = nova.api.ec2:RequestLogging.factory [filter:ec2lockout] paste.filter_factory = nova.api.ec2:Lockout.factory [filter:totoken] paste.filter_factory = nova.api.ec2:EC2Token.factory [filter:ec2keystoneauth] paste.filter_factory = nova.api.ec2:EC2KeystoneAuth.factory [filter:ec2noauth] paste.filter_factory = nova.api.ec2:NoAuth.factory [filter:authenticate] paste.filter_factory = nova.api.ec2:Authenticate.factory [filter:cloudrequest] controller = nova.api.ec2.cloud.CloudController paste.filter_factory = nova.api.ec2:Requestify.factory [filter:authorizer] paste.filter_factory = nova.api.ec2:Authorizer.factory [filter:validator] paste.filter_factory = nova.api.ec2:Validator.factory [app:ec2executor] paste.app_factory = nova.api.ec2:Executor.factory ############# # Openstack # ############# [composite:osapi_compute] use = call:nova.api.openstack.urlmap:urlmap_factory /: oscomputeversions /v1.1: openstack_compute_api_v2 /v2: openstack_compute_api_v2 [composite:osapi_volume] use = call:nova.api.openstack.urlmap:urlmap_factory /: osvolumeversions /v1: openstack_volume_api_v1 [composite:openstack_compute_api_v2] use = call:nova.api.auth:pipeline_factory noauth = faultwrap noauth ratelimit osapi_compute_app_v2 deprecated = faultwrap auth ratelimit osapi_compute_app_v2 keystone = faultwrap authtoken keystonecontext ratelimit osapi_compute_app_v2 keystone_nolimit = faultwrap authtoken keystonecontext osapi_compute_app_v2 [composite:openstack_volume_api_v1] use = call:nova.api.auth:pipeline_factory noauth = faultwrap noauth ratelimit osapi_volume_app_v1 deprecated = faultwrap auth ratelimit osapi_volume_app_v1 keystone = faultwrap authtoken keystonecontext ratelimit osapi_volume_app_v1 keystone_nolimit = faultwrap authtoken keystonecontext osapi_volume_app_v1 [filter:faultwrap] paste.filter_factory = nova.api.openstack:FaultWrapper.factory [filter:auth] paste.filter_factory = nova.api.openstack.auth:AuthMiddleware.factory [filter:noauth] paste.filter_factory = nova.api.openstack.auth:NoAuthMiddleware.factory [filter:ratelimit] paste.filter_factory = nova.api.openstack.compute.limits:RateLimitingMiddleware.factory [app:osapi_compute_app_v2] paste.app_factory = nova.api.openstack.compute:APIRouter.factory [pipeline:oscomputeversions] pipeline = faultwrap oscomputeversionapp [app:osapi_volume_app_v1] paste.app_factory = nova.api.openstack.volume:APIRouter.factory [app:oscomputeversionapp] paste.app_factory = nova.api.openstack.compute.versions:Versions.factory [pipeline:osvolumeversions] pipeline = faultwrap osvolumeversionapp [app:osvolumeversionapp] paste.app_factory = nova.api.openstack.volume.versions:Versions.factory ########## # Shared # ########## [filter:keystonecontext] paste.filter_factory = nova.api.auth:NovaKeystoneContext.factory [filter:authtoken] paste.filter_factory = keystone.middleware.auth_token:filter_factory service_protocol = http service_host = 192.168.69.1 service_port = 5000 auth_host = 192.168.69.1 auth_port = 35357 auth_protocol = http auth_uri = http://192.168.69.1:5000/ admin_tenant_name = service admin_user = nova admin_password = novapass
Restart the nova- services prior to running db sync, by running as root:
# restart nova-api # restart nova-compute # restart nova-network # restart nova-scheduler # restart nova-vncproxy # restart nova-volume
There are many different ways to perform a multinode install of Compute in order to scale out your deployment and run more. In this case, you can install all the nova- packages and dependencies as you did for the Cloud Controller node, or just install nova-network and nova-compute. Your installation can run any nova- services anywhere, so long as the service can access nova.conf so it knows where the Rabbitmq or Qpid messaging server is installed.
The Compute Node is where you configure the Compute network, the networking between your instances. Because you may need to query the database from the Compute node and learn more information about instances, the nova client and MySQL client or PostgresSQL client
packages should be installed on any additional Compute nodes. Copy the nova.conf from your controller node to all additional compute nodes.
If you are using a network bridge configuration and the computer nodes will not have external access, no need to install the nova-network computer nodes.
# apt-get update # apt-get upgrade
# apt-get install bridge-utils
# modprobe kvm_intel echo "kvm_intel" >> /etc/modules
# apt-get install nova-compute nova-network # cd /etc/nova/ # mkdir back # mv * back/ # scp 192.168.1.100:/tmp/nova.conf.tgz . # tar zxvf nova.conf.tgz # rm nova.conf.tgz
Create the tables in your backend data store by running the following command:
sudo nova-manage db sync
Restart all the services:
# restart nova-api # restart nova-compute # restart nova-network # restart nova-scheduler # restart nova-vncproxy # restart nova-volume # restart libvirt-bin # restart nova-cert # restart nova-consoleauth # sudo /etc/init.d/rabbitmq-server restart
All nova services are now installed and started. If the "restart" command doesn't work, your services may not be running correctly (or not at all). Review the logs in /var/log/nova.
You must run the command that creates the network and the bridge using the br100 specified in the nova.conf file to create the network that the virtual machines use. This example shows the network range using 192.168.70.0/24 as the fixed range for our guest
VMs, but you can substitute the range for the network you have available. We're labeling it with "private" in this case.
nova-manage network create private --multi_host=T --fixed_range_v4=192.168.70.0/24 --bridge_interface=br100 --num_networks=1 --network_size=256
You can ensure all the Compute services are running by using the nova-manage command:
sudo nova-manage service list
In return you should see "smiley faces" rather than three X symbols. Here's an example.
Binary Host Zone Status State Updated_At nova-compute educloud01 nova disabled XXX 2012-06-03 14:23:45 nova-network educloud01 nova enabled :-) 2012-06-08 12:04:21 nova-scheduler educloud01 nova enabled :-) 2012-06-08 12:04:14 nova-volume educloud01 nova enabled :-) 2012-06-08 12:04:21 nova-cert educloud01 nova enabled :-) 2012-06-08 12:04:21 nova-consoleauth educloud01 nova enabled :-) 2012-06-08 12:04:21 nova-compute educloud02 nova enabled :-) 2012-06-08 12:04:00 nova-network educloud02 nova enabled :-) 2012-06-08 12:04:00
In order to create a multinic (multiple network interfaces) the parameter --nic specifying the id of the network created on nova by the nova-manage network create (the net-id parameter).
The user can also specify the ip of the virtual machine (the v4-fixed-ip parameter).
For instance if the user wants to create a virtual machine on two separate network with a specific ips he/she should perform the command
# nova boot --flavor 1 --nic net-id=e55b9517-83eb-4377-b7d1-6487529f30f7,v4-fixed-ip=192.168.100.109 --nic net-id=47a3cef8-b5bf-4880-b621-96d08009d57f,v4-fixed-ip=192.168.200.109
Install the packages.
$ sudo apt-get install cinder-api cinder-scheduler cinder-volume open-iscsi python-cinderclient tgt
Edit /etc/cinder/api-paste.ini (filter authtoken).
[filter:authtoken] paste.filter_factory = keystone.middleware.auth_token:filter_factory service_protocol = http service_host = educloud00.local service_port = 5000 auth_host = educloud00.local auth_port = 35357 auth_protocol = http admin_tenant_name = service admin_user = cinder admin_password = openstack
Edit /etc/cinder/cinder.conf.
[DEFAULT] rootwrap_config=/etc/cinder/rootwrap.conf sql_connection = mysql://cinder:CINDER_PASS@educloud00.local/cinder api_paste_config = /etc/cinder/api-paste.ini iscsi_helper=tgtadm volume_name_template = volume-%s volume_group = cinder-volumes verbose = True auth_strategy = keystone #osapi_volume_listen_port=5900 state_path = /var/lib/cinder lock_path = /var/lock/cinder volumes_dir = /var/lib/cinder/volumes
Verify entries in nova.conf.
volume_api_class=nova.volume.cinder.API enabled_apis=ec2,osapi_compute,metadata #MAKE SURE NO ENTRY FOR osapi_volume anywhere in nova.conf!!! #Leaving out enabled_apis altogether is NOT sufficient, as it defaults to include osapi_volume
Edit the configuration file: /etc/tgt/targets.conf in order to include the cinder_tgt.conf instead of conf.d/*.conf
include /etc/tgt/conf.d/cinder_tgt.conf
create the file include /etc/tgt/conf.d/cinder_tgt.conf with the following content:
include /var/lib/cinder/volumes/*
Restart the tgt service.
$ sudo restart tgt
Populate the database.
$ sudo cinder-manage db sync
Restart the services.
$ sudo service cinder-volume restart $ sudo service cinder-api restart $ sudo service cinder-scheduler restart
Create a 1 GB test volume.
$ cinder create --display_name test 1 $ cinder list
the result should look like this:
+--------------------------------------+-----------+--------------+------+-------------+-------------+ | ID | Status | Display Name | Size | Volume Type | Attached to | +--------------------------------------+-----------+--------------+------+-------------+-------------+ | 5bbad3f9-50ad-42c5-b58c-9b6b63ef3532 | available | test | 1 | None | | +--------------------------------------+-----------+--------------+------+-------------+-------------+
First we have to create a virtual machine instance using whatever image and flavor we want:
# nova create --image <YOUR IMAGE> --flavor 1 myinstance
Then we can use the nova volume-attach tool to attach it to the instance. We need to specify a device identifier within the instance that isn’t being used. In
our case we know that /dev/vdb is free, so we will use that:
# nova volume-attach myinstance da6ae608-4673-4b24-acd4-75e527b5969a /dev/vdb
In some cases the users of the virtual machine would like them to be persistent, so changes in kernels, initram would be kept. A solution for these cases is to
use a volume to boot the virtual machine.
After booting from a volume, the user data will be persisted at the file system attached to the virtual machine.
The user can create an image from within a running virtual machine, accessing the device created by the attach command.
Another way to do that is to create a volume from an image. Nova has an utility to do so, the --image-id parameter when using the volume-create utility e.g.:
# nova volume-create --image-id <image_id> --display-name my-bootable-vol <size>
After creating the volume the user can boot from it using the nova boot command:
# nova boot --flavor <favlor_id> --block_device_mapping <dev_name=mapping> boot-from-vol-test
where device_mapping} in the format <dev_name$>=<id>:<type>:<size(GB)>:<delete_on_terminate>, with dev_name
being the device name where the volume will be attached in the virtual machine at /dev/dev_name.
Most of the times, this value is vda. id is the id of the volume created with the cinder create command.
type is a string that describes the process used to creat the volume, e.g, it can be snap, which means that the volume was created from a snapshot.
This parameter can be left in blank.
The delete_on_terminate specifies wether the volume should be deleted after the virtual machine is terminated.
OpenStack has components that provide a view of the OpenStack installation such as a Django-built website that serves as a dashboard. You can use a dashboard interface with an OpenStack Compute installation with a web-based console provided by the Openstack-Dashboard project. It provides web-based interactions with the OpenStack Compute cloud controller through the OpenStack APIs. For more information about the Openstack-Dashboard project, please visit: https://github.com/openstack/horizon/. These instructions are for an example deployment configured with an Apache web server.
- An Image Store (Glance) endpoint.
- An Object Store (Swift) endpoint.
Install the OpenStack Dashboard, as root:
# apt-get install -y memcached libapache2-mod-wsgi openstack-dashboard
Next, modify the variable CACHE_BACKEND in /etc/openstack-dashboard/ local_settings.py to match the ones set in /etc/memcached.conf. Open /etc/openstack-dashboard/local_settings.py and look for this line:
CACHE_BACKEND = 'memcached://127.0.0.1:11211/'
To configure the MySQL database, create the dash database.
mysql> CREATE DATABASE dash; mysql> GRANT ALL ON dash.* TO 'dash'@'%' IDENTIFIED BY 'dashpass'; mysql> quit;
After configuring the local_settings.py as shown below, you can run the manage.py syncdb command to populate this newly-created database.
import os
from django.utils.translation import ugettext_lazy as _
DEBUG = False
TEMPLATE_DEBUG = DEBUG
PROD = False
USE_SSL = False
SWIFT_ENABLED = True
ENABLE_JUJU_PANEL = True
SECRET_KEY = 'elj1IWiLoWHgcyYxFVLj7cM5rGOOxWl0'
LOCAL_PATH = os.path.dirname(os.path.abspath(__file__))
CACHE_BACKEND = 'memcached://192.168.69.1:11211/'
EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'
OPENSTACK_HOST = "192.168.69.1"
OPENSTACK_KEYSTONE_URL = "http://%s:5000/v2.0" % OPENSTACK_HOST
OPENSTACK_KEYSTONE_DEFAULT_ROLE = "Member"
OPENSTACK_KEYSTONE_BACKEND = {
'name': 'native',
'can_edit_user': True
}
API_RESULT_LIMIT = 1000
LOGGING = {
'version': 1,
# When set to True this will disable all logging except
# for loggers specified in this configuration dictionary. Note that
# if nothing is specified here and disable_existing_loggers is True,
# django.db.backends will still log unless it is disabled explicitly.
'disable_existing_loggers': False,
'handlers': {
'null': {
'level': 'DEBUG',
'class': 'django.utils.log.NullHandler',
},
'console': {
# Set the level to "DEBUG" for verbose output logging.
'level': 'INFO',
'class': 'logging.StreamHandler',
},
},
'loggers': {
# Logging from django.db.backends is VERY verbose, send to null
# by default.
'django.db.backends': {
'handlers': ['null'],
'propagate': False,
},
'horizon': {
'handlers': ['console'],
'propagate': False,
},
'novaclient': {
'handlers': ['console'],
'propagate': False,
},
'keystoneclient': {
'handlers': ['console'],
'propagate': False,
},
'nose.plugins.manager': {
'handlers': ['console'],
'propagate': False,
}
}
}
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'dash',
'USER': 'dash',
'PASSWORD': 'dashpass',
'HOST': '192.168.69.1',
'default-character-set': 'utf8'
},
}
Run the manage.py syncdb command to initialize the database.
$ /usr/share/openstack-dashboard/manage.py syncdb
Restart Apache to pick up the default site and symbolic link settings.
# /etc/init.d/apache2 restart
Restart the nova-api service to ensure the API server can connect to the Dashboard and to avoid an error displayed in the Dashboard
sudo restart nova-api
OpenStack
Balanceadores
Hadoop
OCCI
Versão Final
Atualmente para propósitos de demonstração o educloud-mon está configurado com duas métricas: web-cpu-usage e web-active-users.
Estas duas métricas se referem a uma média aritimética do uso de cpu ou usuários ativos do sistema como um todo (todos os hosts web servers).
O parâmetro de configuração do educloud-mon é o bottom_threshold de cada métrica. Para saber quais valores estão configurados para bottom_treshold veja o arquivo educloud-mon.conf.
O educloud-mon libera uma máquina virtual caso nenhuma métrica atingiu o top_thresold e alguma métrica tenha atingido o bottom_thresold.
Ainda existe o parâmetro minimum_vms do arquivo de configuração educloud-mon.conf, caso esta quantidade de máquinas virtuais seja atingido, o daemon, não irá mais liberar máquinas virtuais, mesmo que as métricas retornem valores abaixo do bottom_thresold. Isso evita que a farm de servidores web, fique sem máquinas.
Atualmente para propósitos de demonstração o educloud-mon está configurado com duas métricas: web-cpu-usage e web-active-users.
Estas duas métricas se referem a uma média aritimética do uso de cpu ou usuários ativos do sistema como um todo (todos os hosts web servers).
O parâmetro de configuração do educloud-mon é o top_threshold de cada métrica. Para saber quais valores estão configurados para top_treshold veja o arquivo educloud-mon.conf.
A máquina osdc01 (200.145.46.197) é um repositório de imagens. Nele temos o seguinte layout de lvm:
--- Physical volume --- PV Name /dev/sda3 VG Name osdc1 PV Size 18.18 TiB / not usable 1.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 4765714 Free PE 254883 Allocated PE 4510831 PV UUID L4yscI-w5r3-0IVh-FtxE-oGOJ-EtTM-5nBjt2
--- Volume group --- VG Name osdc1 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 276 VG Access read/write VG Status resizable MAX LV 0 Cur LV 9 Open LV 7 Max PV 0 Cur PV 1 Act PV 1 VG Size 18.18 TiB PE Size 4.00 MiB Total PE 4765714 Alloc PE / Size 4510831 / 17.21 TiB Free PE / Size 254883 / 995.64 GiB VG UUID 3oKaJb-HYqQ-cOZK-duiF-qGVR-5P9H-HcrWaa
Cada imagem está em um volume lógico e é exportado para as máquinas nós, via iSCSI. Para isso, elas usam o transport manager iscsi desenvolvido pelo Marco.
Para ver a lista de volumes lógicos (São muitos, dependendo das máquinas virtuais que estão em execução), por favor execute:
lvdisplay
O educloud-mon inicia uma máquina virtual caso alguma métrica tenha atingido o top_thresold.
Para simular o excesso de demanda foi utilizado o comando ab do pacote apache-utils.
O ab inicia quantas threads forem necessárias e envia N requisições para um determinado host. Sua utilização é muito simples. Abaixo um exemplo do comando ab:
ab -n 2000 -c 50 http://cursos.educacao.sp.gov.br/
Abaixo temos a saída do comando acima:
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking cursos.educacao.sp.gov.br (be patient)
Completed 200 requests
Completed 400 requests
Completed 600 requests
Completed 800 requests
Completed 1000 requests
Completed 1200 requests
Completed 1400 requests
Completed 1600 requests
Completed 1800 requests
Completed 2000 requests
Finished 2000 requests
Server Software: squid/2.7.STABLE9
Server Hostname: cursos.educacao.sp.gov.br
Server Port: 80
Document Path: /
Document Length: 1321 bytes
Concurrency Level: 50
Time taken for tests: 0.641 seconds
Complete requests: 2000
Failed requests: 0
Write errors: 0
Non-2xx responses: 2000
Total transferred: 3312000 bytes
HTML transferred: 2642000 bytes
Requests per second: 3118.24 [#/sec] (mean)
Time per request: 16.035 [ms] (mean)
Time per request: 0.321 [ms] (mean, across all concurrent requests)
Transfer rate: 5042.78 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.3 0 5
Processing: 5 15 2.0 15 24
Waiting: 3 13 1.9 13 22
Total: 7 16 1.9 16 25
ERROR: The median and mean for the initial connection time are more than twice the standard
deviation apart. These results are NOT reliable.
Percentage of the requests served within a certain time (ms)
50% 16
66% 16
75% 16
80% 17
90% 18
95% 18
98% 23
99% 24
100% 25 (longest request)
# educloud-mon main config file.
# General section
[general]
# This daemon will run in background or in foreground?
background = 0
# Run daemon in debug mode will produce further information in the system
# log.
debug = 1
# Location of the log file
logfile = /var/log/educloud-mon.log
# Run daemon as the follow user
user = "oneadmin"
# Run daemon as the follow group
group = "oneadmin"
# Run in dry-run mode ?
# In this mode virtual machines are not created or deleted.
# Default is false.
dry-run = 0
# How many seconds wait after start a vm ?
# Default is 30 seconds
start_vm_wait = 60
# How many seconds wait to start new cicle of metrics checks ?
# This value determines the seconds between each cicle of N
# metrics. Default is 30 seconds
cicle_wait = 30
# Number maximum of retries to start a vm. After this, if vm state is not
# "running", a notification will be sent
# Default is 3
max_vm_retry = 3
# List of metrics to consider. This wil be converted to a dict in the python
# deamon, so please, use the same python syntax.
# Each metric must have: 'top_thresold', 'bottom_thresold' and 'script'
# Each script MUST return in stdout only the value to consult and compare with
# thresolds defined here.
# TODO: Better documentation
metrics = {
'cpu-load': {
'top_thresold': '70',
'bottom_thresold': '2',
'script': '/usr/local/bin/educloud-mon/scripts/web-cpu-usage.py',
'check_interval': '2',
'average_checks': '5',
},
'active-users': {
'top_thresold': '20',
'bottom_thresold': '5',
'script': '/usr/local/bin/educloud-mon/scripts/web-active-users.py',
'check_interval': '2',
'average_checks': '5',
},
}
# This command will be execute to get number of current http connection
# in a vm. This will be appended th vm id
get_connections_cmd = "ssh osdc07 iis_connected_users.sh"
# nginx web server cluster
[nginx]
# This command will be executed when a new vm is added to the pool
# This command will be appended with vm_id
nginx_add_cmd = "ssh osdc07 nginx_webservers.sh add"
# This command will be executed when a vm is removed from pool
# This command will be appended with vm_id
nginx_del_cmd = "ssh osdc07 nginx_webservers.sh del"
# This command will be executed after a add or del action in nginx cluster
nginx_restart_cmd = "ssh osdc07 sudo /usr/sbin/service nginx restart"
# Settings for email notification system
[notification]
# If enabled, emails will be sent to administrators when errors occur.
# Default is true.
enable_notifications = 0
# SMTP Server to use
smtp_server = 127.0.0.1
# SMTP Port
smtp_port = 25
# Use SMTP Authentication ?
# Default is true.
smtp_auth = 0
# SMTP User for authentication
smtp_user = user
# SMTP Pass for authentication
smtp_pass = password
# Mail From
mail_from = "educloud-mon <educloud-mon@ncc.unes.pbr"
# Mail to
mail_to = "admin@ncc.unesp.br"
# Options to connect with OpenNebula goes in this section
[opennebula]
# RPC OpenNebula URL. You have to specify a full URL of RCP with port and path.
# Without quotes. Example: http://localhost:2633/RPC2
rpc_url = http://200.145.46.198:2633/RPC2
# User to use in opennebula connection. Without quotes.
user = oneadmin
# Password to use in opennebula connection. Without quotes.
password = !@qazxsw
# Relative path to template to start when metrics get values >= top_thresolds
# This path is relative to the home of the user oneadmin on OpenNebula
# controller. This hardcoded path is necessary because we are using OpenNebula
# 2.2.1 version.
template = "/usr/local/bin/educloud-mon/templates/teste.template"
# Minimum amount of machine in "web cluster"
# If the cluster has this number no more virtual machines will be
# deleted. Default is 1
minimum_vms = 1
- Submeter uma nova VM webserver:
- onevm submit /path/to/Lena.template
- Após a VM estar up & running, resgatar informação do endereço ip:
- cat /var/lib/misc/dnsmasq.leases | grep $(onevm show $VM_ID | grep MAC= | cut -d "=" -f2 | cut -d "," -f1) | awk '{ print $3 }'
- Adicionar esse ip ao pool de máquinas que recebem direcionamento do nginx
Lista de atividades da Fase 3 do projeto Educloud.
Linguagem utilizada para o desenvolvimento.
Licença em que o código foi liberado. A preferência é por licenças livres, facilitando assim o estudo e desenvolvimento de aplicações ou até mesmo de correções de problemas.
Quais linguagens são suportadas na implementação de aplicações e componentes.
Quanto e que tipo de modularidade o controlador oferece.
Onde encontrar o código.
Existência de testes de unidades no codigo (scripts ou códigos), geralmente em uma pasta em separado, que validam e testam o código desenvolvido.
Disponibilidade e facilidade de instação nas distribuição GNU/Linux relevantes atuais.
Nível de documentação do controlador, incluindo tutoriais e exemplos (tanto de estruturas quanto de aplicações).
Como o ambiente estruturado se baseia no OpenStack, é interessante saber qual é o tipo de suporte oferecido a essa ferramenta.
Público do controlador
Empresas, consórcio, comunidade, universidade, ...
Uma das formas de se ter noção de quanto o desenvolvimento ainda está ativo é procurar pela data da última atualização de código no repositório.
Características que não se adequam a nenhuma das anteriores.
O escopo deste documento trata de avaliar um conjunto de soluções de storage aplicado à cloud computing, avaliando a viabilidade de uma delas atender às necessidades do projeto EduCloud, para posterior deployment. Fez parte da investigação descrita por este documento, a verificação dos passos para execução da instalação e configuração da solução de storage.
O projeto Educloud é um projeto para a implementação de uma infraestrutura de cloud computing para a secretaria da educação do estado de São Paulo, com objetivo de fornecer serviços de apoio ao ensino via nuvem, para educadores e estudantes.
O Hadoop é uma solução de sistema de arquivos distribuídos desenvolvida para manipular volumes de dados, focando na análise qualitativa dos dados armazenados através de ferramentas de data mining desenvolvidas utilizando o framework fornecido pelo Google, seu fabricante.
Desenvolvido na linguagem Java, o Hadoop oferece um sistema de arquivos paralelo e distribuído com tolerância à falha, e um framework para desenvolver aplicações de análise dos dados armazenados de forma a correlacioná-los.
Algumas tecnologias alternativas ao Hadoop são apresentadas a seguir, porém nem todas são capazes de trabalhar com grandes volumes de dados, ou até mesmo de fazer a correlação de dados.
Todas as soluções acima foram retiradas do seguinte site:
http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_parallel_fault-tolerant_file_systems
O Hadoop é licenciado sob a Apache v2.0. Nesta versão de licenciamento é possível o uso para qualquer propósito, alterar e redistribuir o código sob outro tipo de licenciamento, desde que seja incluído um changelog indicando as modificações realizadas. O texto da licença se encontra em: http://www.apache.org/licenses/LICENSE-2.0
O Hadoop tem seu uso bem vasto entre diversas companhias. Algumas delas o utilizam como parte de sua infraestrutura, onde a função do Hadoop é dar suporte ao produto ou serviço comercializado, enquanto em outras o próprio Hadoop, ou uma de suas características, é o serviço oferecido.
Dentre as empresas que usam Hadoop em sua infraestrutura, temos as seguintes:
Outras empresas que usam Hadoop em sua infraestrutura pode ser listada em: http://wiki.apache.org/hadoop/PoweredBy
A seguir algumas empresas que oferecem o Hadoop como serviço:
Outras empresas que oferecem Hadoop como um serviço/produto podem ser encontradas no seguinte link: http://wiki.apache.org/hadoop/Distributions%20and%20Commercial%20Support
Analisando os dados fornecidos acima, podemos observar que grandes empresas utilizam o Hadoop em sua infraestrutura ou como parte de seus serviços/produtos; portanto podemos afirmar que o Hadoop tem uma vasta utilização e por isso o interesse das empresas na continuidade desse projeto é latente.
Observando também o link https://issues.apache.org/jira/browse/HADOOP#selectedTab=com.atlassian.jira.plugin.system.project:roadmap-panel&allVersions=true , podemos observar a existência de um roadmap para futuras versões do Hadoop. O release atual é o 1.0, e existem trabalhos nas versões 1.1, 2.0 e 3.0. Além disso, é incluído no roadmap melhorias nas versões já lançadas, como as versões 0.21.1, 0.22.1, 0.23.2, 0.23.3 e 0.24.0. Há também planos de criação de uma versão para Windows do Hadoop.
Com essas informações é possível afirmar que o Hadoop, como projeto, não tem uma baixa expectativa de vida, garantindo sua adoção sem preocupações futuras de substituição de tecnologia por obsolescência.
O projeto EduCloud necessita uma tecnologia que possa armazenar, manipular e gerenciar grandes volumes de dados. As ferramentas que melhor atendem hoje a essa necessidade são conhecidas como sistemas de arquivos distribuídos. Estes sistemas de arquivos potencialmente atendem o requisito do EduCloud, permitindo que este seja utilizado para distribuir de conteúdo para os usuários, e correlacionar dados para detectar semelhanças entre estudos de usuários distintos.
Nesse sentido, o Hadoop atende a necessidade do EduCloud, logo que o objetivo principal do primeiro é oferecer um sistema de arquivos distribuídos, capaz de manter e manipular arquivos muito grandes (várias centenas de terabytes), e em grandes quantidades. Porém, dado que não está claro que o projeto EduCloud irá trabalhar com arquivos grandes, é provável que o Hadoop não seja a solução mais indicada para o projeto, pois todo o trabalho existente no Hadoop envolve a movimentação e disponibilidade de grandes volumes de dados. Segundo artigos, o Hadoop não possui performance ótima mexendo com pequenos volumes de dados. Os links a seguir irão aproveitar e mostrar quais situações nas quais o Hadoop apresenta desvantagem:
http://wiki.apache.org/hadoop/HadoopIsNotAlém dos itens já citados acima, a desvantagem do Hadoop é ser um sistema de arquivos baseado em write-once, ou seja, não existe operações de append de arquivos, não sendo possível modificações nestes. Outra desvantagem é o map reduce, pois trata-se de uma linguagem para criar jobs de análise de dados. É necessário um conhecimento prévio do que se deseja analisar, pois o Hadoop apenas fornece as ferramentas para análise, não as faz de forma automática. Portanto deve se levar em consideração o tempo de desenvolvimento dos jobs de map reduce ao realizar uma implementação de Hadoop.
Em contrapartida, as vantagens da tecnologia são disponibilizar o dado com redundância, tentar manter o dado próximo ao local onde ele será usado para evitar uso de rede (sobrecarga nos switches centrais) e realizar o correlacionamento de dados semelhantes.
Por outro lado, pensando nas soluções que compõem o projeto EduCloud, podemos observar ao comparar o Hadoop com outras soluções de storages disponibilizadas pelas tecnologias de cloud, que a princípio, o Hadoop oferece um serviço semelhante ao Swift do projeto OpenStack. O Swift é a solução de armazenamento e gerenciamento de dados que compõem o framework fornecido pelo OpenStack, cujo propósito é armazenar os dados que serão utilizados pelas máquinas virtuais. Logo, seu objetivo de disponibilizar o dado para a máquina virtual, vem de encontro com a solução proposta pelo Hadoop.
Considerando que o Projeto EduCloud tenha um deployment de Hadoop em sua composição, os requisitos de hardware são, no mínimo:
A documentação descrita no link http://hadoop.apache.org/common/docs/stable é indicada para fazer um deployment de uma versão single node, e outra versão, mais elaborada, de cluster setup. Com esta documentação, parece ser suficiente para realizar o deployment de hadoop em um ambiente para testes.
Além disso, consultando a wiki do projeto Hadoop (http://wiki.apache.org/hadoop/#Setting_up_a_Hadoop_Cluster), existem outros tutoriais de deployment, específicos para determinadas distribuições de linux, e determinados sistemas operacionais.
E os passos necessários para deployment são:
Os pré-requisitos para instalação são os seguintes:
Para um modo de operação single node:
Satisfeitos os requisitos acima, é necessário fazer o download e descompactar o conteúdo.
Dentro do diretório descompactado, alterar o arquivo: conf/hadoop-env.sh para setar a variável de ambiente JAVA_HOME de acordo com o java instalado na máquina.
Após isso, basta seguir os seguintes passos:
- bin/hadoop jar hadoop-examples-*.jar grep input output 'dfs[a-z.]+'
Para um modo de operação cluster, além dos passos acima, é necessário executar os seguintes passos:
Definir o seguinte grupo de máquinas:
Todas devem conter o mesmo HADOOP_HOME (path para instalação do hadoop nas máquinas)
A configuração de cada grupo de máquinas deve ser feito de acordo com o seguinte link: http://hadoop.apache.org/common/docs/stable/cluster_setup.html
Configuração de mapreduce e localizing
O map reduce do hadoop é na realidade um framework para programação de algoritmos de análise de grandes quantidades de dados. Uma analogia do map reduce para o mundo dos bancos de dados é que o map reduce se refere à query de busca do banco de dados.
A estrutura do map reduce funciona da seguinte forma:
Logo, o map reduce atua sobre a análise dos dados, não sobre o dado em si; de forma que o resultado da análise é mais compacto.
Quanto ao localizing, é inerente à arquitetura do hadoop em distribuir os dados de acordo com o fator de replicação estipulado para os dados, e para aproximar o dado dos nós que irão processá-lo.
- qemu-img convert /path/to/imagem.vmdk -O raw image.raw
- Criar uma partição lvm para cada imagem das VMs (ir ao repositorio de imagem):
- lvcreate --name $IMG_NAME --size $SIZE osdc1
- dd if=/path/to/image of=/dev/osdc1/$IMG_NAME
- onevm submit /path/to/Vaal.template
- onevm submit /path/to/Atlantico.template
- onevm submit /path/to/Lena.template
- Criar uma partição lvm com a imagem da VM (ir ao repositorio de imagem):
- lvcreate --name $IMG_NAME --size $SIZE osdc1
- dd if=/path/to/image of=/dev/osdc1/$IMG_NAME
- Submeter o arquivo vm.template para o open nebula com o seguinte comando (ir ao gerenciador do open nebula):
- onevm submit vm.template
Todos os comandos abaixo são encontrados no pacote freeipmi-tools, uma implementação do projeto GNU, para o protocolo IPMI.
Nota: Todos os commandos do freeipmi-tools aceita a seguinte syntax para múltiplos hosts: bmc[00-127].
$ ipmi-console -h bmc01 -u admin -P -W solpayloadsize
Nota: Para sair da console digite: &.
$ ipmipower -h bmc01 -u admin -P --on
$ ipmipower -h bmc01 -u admin -P --off
$ ipmipower -h bmc01 -u admin -P --reset
Nota: Nem todas as máquinas suportam este comando.
$ ipmi-chassis-config -h bmc01 -u admin -P --commit -e "Chassis_Boot_Flags:Boot_Flags_persistent=No" $ ipmi-chassis-config -h bmc01 -u admin -P --commit -e "Chassis_Boot_Flags:Boot_Device=PXE"
$ ipmi-chassis -h bmc01 -u admin -P --get-status
$ ipmi-sensors -h bmc01 -u admin -P --verbose
$ ipmi-fru -h bmc01 -u admin -P --verbose
Primeiro precisa-se obter o arquivo base de configuração para ser usado como modelo.
$ bmc-config -h bmc01 -u admin -P -o -n bmc01.conf
Nesse arquivo, procurar a seção correspondente ao usuário cuja senha precisa ser alterada e substituir o campo
## Password
por
Password senha
E subir o arquivo com as alterações
$ bmc-config -h bmc01 -u admin -P -c -n bmc01.conf
Nota_1: Ao subir, tem-se como resposta erros de "Invalid/Unsupported Config". Apenas ignore. A mudança de senha funciona.
Nota_2: Cuidado com a identação.
Para que a configuração de SOL (Serial over Lan) funcione, Na BIOS, em Server -> Remote Access Configuration, deve estar:
******************************************************* * Remote Access [Enabled] * * * * Serial port number [COM2] * * Base Address, IRQ [2F8h, 3] * * Serial Port Mode [57600 8,n,1] * * Flow Control [Hardware] * * Redirection After BIOS POST [Always] * * Terminal Type [VT-UTF8] * *******************************************************
- Descobrir o ID da VM usando o comando onevm list
- Executar o comando de shutdown da VM:
- onevm shutdown VM_ID
Blocker/Dependencia:
Blocker/Dependencia:
Blocker/Dependencia:
Blocker/Dependencia:
Blocker/Dependencia:
Executou as seguintes:
Próximos passos:
Blocker/Dependencia
Blocker/Dependencia:
Executou:
Blocker/Dependencia:
Executou:
Blocker/Dependencia:
Executou:
Blocker/Dependencia:
Nesta tarefa, foi feita uma pesquisa sobre os atuais schedulers para o Open Nebula, entre eles, foram pesquisados: SVMSched e o Haizea.
Durante a pesquisada realizada, estes schedulers não implementavam recursos necessários para o projeto EduCloud, como monitoramento constante de métricas, instanciação e liberação de máquinas virtuais, dependendo dos resultados destas métricas.
Foi decidido então, que um "monitor/daemon/balanceador" seria desenvolvido, a este chamamos de educloud-mon.
O educloud-mon é atualmente um monitor do OpenNebula, porém com possibilidade para extender-se ao OpenStack, por exemplo. Ele foi feito em Python e utiliza-se da biblioteca: python-oca, para as tarefas de comunicação com o OpenNebula.
O educloud-mon precisa ser executado como root, em qualquer máquina na mesma rede dos nós do OpenNebula. Ele foi desenvolvido de modo que permita ao administrador configurar métricas e parâmetros, tornando ele um daemon bem flexível. Seu principal arquivo de configuração é o educloud-mon.conf.
Atualmente, em nosso ambiente de testes, o educloud-mon está funcionando na máquina 200.145.146.198, e encontra-se instalado em /usr/local/bin/educloud-mon/.
Aqui você encontra um exemplo de um arquivo de configuração educloud-mon.conf.
Além do arquivo de configuração você pode passar alguns parâmetro por meio de argumentos ao daemon. Para maiores informações, execute:
./educloud-mon.py --help
O educloud-mon, quando determina que precisa instanciar uma nova máquina virtual, lê o template da máquina virtual, e envia para o OpenNebula o comando para instanciar uma nova máquina virtual. Para isso, os templates das máquinas virtuais (arquivos de configuração), precisa estar na mesma máquina que o educloud-mon, e você deve configurar o parâmetro template em seu arquivo de configuração:
# Relative path to template to start when metrics get values >= top_thresolds # This path is relative to the home of the user oneadmin on OpenNebula # controller. This hardcoded path is necessary because we are using OpenNebula # 2.2.1 version. template = "/usr/local/bin/educloud-mon/templates/teste.template"
O educloud-mon conta também com um sistema simples para envio de alertas por email. Caso alguma ação durante a sua execução falhe, um email de alerta será enviado.
Para isso configure a seção [notification] no educloud-mon.conf:
# Settings for email notification system [notification] # If enabled, emails will be sent to administrators when errors occur. # Default is true. enable_notifications = 0 # SMTP Server to use smtp_server = 127.0.0.1 # SMTP Port smtp_port = 25 # Use SMTP Authentication ? # Default is true. smtp_auth = 0 # SMTP User for authentication smtp_user = user # SMTP Pass for authentication smtp_pass = password # Mail From mail_from = "educloud-mon <educloud-mon@ncc.unes.pbr" # Mail to mail_to = "admin@ncc.unesp.br"
O educloud-mon, monitora N métricas passadas por arquivo de configuração (educloud-mon.conf). Até o momento do desenvolvimento, ele executa duas ações: criar uma nova máquina virtual e liberar uma nova máquina virtual, quando o top thresold é atingido e o bottom thresold, respectivamente.
Métricas são passadas via arquivo de configuração bem como seus valores de top e bottom. As métricas ficam em um diretório "scripts/" idependente do educloud-mon.
Exemplo de configuração de métricas e seus valores no arquivo de configuração do educloud-mon:
metrics = {
'cpu-load': {
'top_thresold': '70',
'bottom_thresold': '2',
'script': '/usr/local/bin/educloud-mon/scripts/web-cpu-usage.py',
'check_interval': '2',
'average_checks': '5',
},
'active-users': {
'top_thresold': '20',
'bottom_thresold': '0',
'script': '/usr/local/bin/educloud-mon/scripts/web-active-users.py',
'check_interval': '2',
'average_checks': '5',
},
}
No exemplo acima, o educloud-mon irá monitorar duas métricas: "cpu-load" e "active-users". O parâmtro "script" de cada métrica, informa qual o script irá ser executado para coletar esta métrica.
Cada métrica tem o seus valores de top_thresold e bottom_thresold. No exemplo acima, caso o script retorne um valor superior a 70, o top_thresold é atingido. Caso ele retorne um valor abaixo de 2, o bottom_thresold é atingido.
A eurística para determinar se uma nova máquina será instanciada ou liberada é a seguinte:
top_thresold, uma nova máquina será instanciada;top_thresold e nenhuma métrica tenha atingido o bottom_thresold, nada será feito;top_thresold e alguma métrica tenha atingido o bottom_thresold, uma máquina será liberada;Existem duas versões do NOX. A versão antiga e descontinuada foi renomeada para NOX-Classic. Porém todos os materiais que foram produzidos para essa versão tratam-na com o nome que era corrente, ou seja, apenas por NOX. Isso causa um problema sério: em qualquer conteúdo referente ao NOX não se consegue saber se é sobre a versão antiga ou a nova, a menos que seja dito explicitamente ou que o NOX seja chamado de 'new NOX'.
C++
GPLv3
OpenFlow 1.0
Quais linguagens são suportadas na implementação de aplicações e componentes.
Quanto e que tipo de modularidade o controlador oferece.
Onde encontrar o código.
Existência de testes de unidades no codigo (scripts ou códigos), geralmente em uma pasta em separado, que validam e testam o código desenvolvido.
Disponibilidade e facilidade de instação nas distribuição GNU/Linux relevantes atuais.
Nível de documentação do controlador, incluindo tutoriais e exemplos (tanto de estruturas quanto de aplicações).
Como o ambiente estruturado se baseia no OpenStack, é interessante saber qual é o tipo de suporte oferecido a essa ferramenta.
Público do controlador
Empresas, consórcio, comunidade, universidade, ...
Uma das formas de se ter noção de quanto o desenvolvimento ainda está ativo é procurar pela data da última atualização de código no repositório.
Características que não se adequam a nenhuma das anteriores.
Controlador praticamente desenvolvido em conjunto com OpenFlow.
http://www.noxrepo.org/_/nox-classic-doxygen/index.html
(gerado pelo doxygen)
https://github.com/noxrepo/nox
Dizem que apesar de ultrapassado, a documentação contida no wiki do NOX-Classic ainda pode ajudar, então:
https://github.com/noxrepo/nox-classic/wiki
O escopo deste documento trata de avaliar o uso de soluções de protocolos de comunicação para interoperabilidade entre clouds, avaliando a viabilidade de uma determinada solução para o contexto do projeto Educloud, e se o projeto dispõe de informações suficientes para realizar tal análise e um possível deployment em nosso ambiente de desenvolvimento.
O projeto Educloud é um projeto para a implementação de uma infraestrutura de cloud computing para a secretaria da educação do estao de São Paulo.
O OCCI é um protocolo para realizar interface entre o usuário e as soluções de cloud de uma forma uniforme. Com ela é possível montar um sistema centralizado de gerenciamento de diferentes soluções de cloud, oferecendo dessa forma interoperabilidade e simplicidade de uso. A especificação do OCCI é desenvolvida e mantida pelo Open Grid Forum e disponibilizada para que seja implementada nas soluções de cloud, assim como em ferramentas para realizar validações da implementação de acordo com a especificação.
O OCCI em específico apresenta-se como uma soluçao de protocolo para interoperabilidade de cloud. Até o presente momento não foram encontradas soluções que servem o mesmo propósito. Existem soluções na mesma linha, mas com propósitos diferentes, e são listadas a seguir:
Ela é uma implementação aberta, e tem seus aspectos legais de uso descritos no link a seguir:
http://occi-wg.org/about/legal
Esta tecnologia é implementada pelas principais soluções de cloud open source existentes e existem ferramentas de validação da implementação de acordo com este site: http://occi-wg.org/community/implementations
A questão da adoção varia da necessidade das empresas de possuírem soluções interoperáveis, e até o presente momento não foi encontrada uma referência que pudesse quantificar tal informação.
Dentro do site do projeto, não há uma referência explicita de roadmap para o OCCI. Porém, eles possuem uma wiki https://forge.ogf.org/sf/projects/occi-wg com informações sobre o processo de desenvolvimento, bugfixes e discussões a respeito do projeto. Acredito que por ser uma especificação, deve haver continuidade na elaboração de novas versões da especificação, porém é apenas uma suposição baseada no desenvolvimento que cloud computing está tendo no mundo.
Uso no Projeto Educloud
Os requisitos para o projeto Educloud no contexto de um protocolo de gerenciamento de cloud são:
Posto isso, o OCCI é um protocolo desenvolvido para ser interoperável, oferecer um conjunto de soluções para gerenciamento de cloud tanto em situações de IaaS, PaaS e SaaS. Além disso, ele oferece uma API com alto nível de extensibilidade.
O uso de OCCI é importante para o projeto pois irá adicionar uma camada de interoperabilidade entre as soluções de cloud existentes e com isso teremos a possiblidade de controlar diferentes tipos de soluções através de uma interface centralizada.
As vantagens para o projeto são as já citadas acima, e além disso, a possibilidade da interface poder ser extendida para adicionar funcionalidades de acordo com nossas necessidades.
Uma desvantagem é a provável variação na implementação da interface nas soluções de cloud existentes, podendo culminar em necessidade de retrabalho para nivelar as soluções de cloud em um mesmo patamar de usabilidade da interface.
O uso do OCCI conflita com as soluções de cloud disponíveis pois ela entra com o papel de substituir as interfaces de gerenciamento das soluções de cloud. Mas isso não é visto como um aspecto negativo, pois a idéia de substituir estas interfaces é justamente sua principal função para ser possível também integrar as soluções e centralizar o comando em uma única interface.
A documentação do OCCI no site do projeto é referente à especificação do mesmo. Para o contexto do projeto, a documentação procurada se refere às implementações de OCCI nas soluções de cloud. Logo, temos as seguintes documentações:
Pensando em deployment de OCCI não é efetivamente o termo correto a ser utilizado. Como nosso foco é em interoperabilidade, para esta tecnologia é necessário estudar as implementações de OCCI em cada uma das soluções de cloud que iremos utilizar para poder ser criado uma solução que consiga gerenciar as VMs de forma uniforme entre as clouds.
No opennebula, o OCCI é implementado de forma a ser um protocolo sobre HTTP operando através de operações de GET, POST, PUT e DELETE.
No openstack, o OCCI também é implementado sob HTTP, porém aparenta ser uma implementação mais completa que no opennebula, oferecendo uma gama maior de recursos para gerenciamento da VM.
No eucalyptus não foi encontrado documentação falando a respeito da implementação de OCCI.
Linguagem utilizada para o desenvolvimento.
Licença em que o código foi liberado. A preferência é por licenças livres, facilitando assim o estudo e desenvolvimento de aplicações ou até mesmo de correções de problemas.
Quais linguagens são suportadas na implementação de aplicações e componentes.
Quanto e que tipo de modularidade o controlador oferece.
Onde encontrar o código.
Existência de testes de unidades no codigo (scripts ou códigos), geralmente em uma pasta em separado, que validam e testam o código desenvolvido.
Disponibilidade e facilidade de instação nas distribuição GNU/Linux relevantes atuais.
Nível de documentação do controlador, incluindo tutoriais e exemplos (tanto de estruturas quanto de aplicações).
Como o ambiente estruturado se baseia no OpenStack, é interessante saber qual é o tipo de suporte oferecido a essa ferramenta.
Público do controlador
Empresas, consórcio, comunidade, universidade, ...
Uma das formas de se ter noção de quanto o desenvolvimento ainda está ativo é procurar pela data da última atualização de código no repositório.
Características que não se adequam a nenhuma das anteriores.
Página: http://www.opendaylight.org/
OpenDaylight Developer Wiki
https://wiki.opendaylight.org/view/Main_Page
Tem a Intel como um dos membros, além de outros peixes grandes.
A linguagem utilizada é java.
Acredito q seja baseado no floodlight.
Descrição e documentação das características a serem analisadas nos controladores.
Linguagem utilizada para o desenvolvimento.
Licença em que o código foi liberado. A preferência é por licenças livres, facilitando assim o estudo e desenvolvimento de aplicações ou até mesmo de correções de problemas.
Quais linguagens são suportadas na implementação de aplicações e componentes.
Quanto e que tipo de modularidade o controlador oferece.
Onde encontrar o código.
Existência de testes de unidades no codigo (scripts ou códigos), geralmente em uma pasta em separado, que validam e testam o código desenvolvido.
Disponibilidade e facilidade de instação nas distribuição GNU/Linux relevantes atuais.
Nível de documentação do controlador, incluindo tutoriais e exemplos (tanto de estruturas quanto de aplicações).
Como o ambiente estruturado se baseia no OpenStack, é interessante saber qual é o tipo de suporte oferecido a essa ferramenta.
Público do controlador
Empresas, consórcio, comunidade, universidade, ...
Uma das formas de se ter noção de quanto o desenvolvimento ainda está ativo é procurar pela data da última atualização de código no repositório.
Specific Protocol between the controller and the OF switches. And a set of operations/messages sent to the switches.
Características e funcionalidades
| Nome | Linguagem | Licença | Tamanho do Pacote | Features | URL | Versão do OpenFlow |
|---|---|---|---|---|---|---|
| Nox | C++ | GPL V3 | 258 Kb (Fonte) | Provides a C++ OpenFlow 1.0 API Provides fast, asynchronous IO Includes sample components for: Topology discovery Learning switch Network-wide switch |
http://www.noxrepo.org/pox/documentation/ | 1.0, 1.3 via https://github.com/CPqD/nox13oflib |
| Pox | Python | GPL V3 | 1.1 Mb (Fonte) | “Pythonic” OpenFlow interfacePOX Performance Graph Reusable sample components for path selection, topology discovery, etc. “Runs anywhere” – Can bundle with install-free PyPy runtime for easy deployment Specifically targets Linux, Mac OS, and Windows Supports the same GUI and visualization tools as NOX Performs well compared to NOX applications written in Python |
http://www.noxrepo.org/nox/documentation/ | 1.0 |
| Beacon | Java | GPL v2 | 12.2 Mb (Fonte) 17 Mb (Binários + Dependências) | Stable - Beacon has been in development since early 2010, and has been used in several research projects, networking classes, and trial deployments. Beacon currently powers a 100-vswitch, 20-physical switch experimental data center and has run for months without downtime. Cross-platform - Beacon is written in Java and runs on many platforms, from high end multi-core Linux servers to Android phones. Dynamic - Code bundles in Beacon can be started/stopped/refreshed/installed at runtime, without interrupting other non-dependent bundles (ie replace your running Learning Switch application without disconnecting switches). Rapid Development - Beacon is easy to get up and running. Java and Eclipse simplify development and debugging of your applications. Fast - Beacon is multithreaded, check out performance benchmarks. Web UI - Beacon optionally embeds the Jetty enterprise web server and a custom extensible UI framework Frameworks - Beacon builds on mature Java frameworks such as Spring and Equinox (OSGi) |
https://openflow.stanford.edu/display/Beacon/Guides | 1.0 |
| Maestro | Java | LGPL v2.1 | 117 Kb (Binários) 262 Kb (Fonte) | Developed in Java (both the platform and the components) - Highly portable to various operating systems and architectures. Multi-threaded - Takes full advantage of multi-core processors. Currently provides the control components for realizing either a learning switch network, or a routed network using OpenFlow switches. |
http://code.google.com/p/maestro-platform/wiki/MaestroTutorial | 1.0 |
| Ryu | Python | Apache V2.0 | 12.2 Mb (Fonte) | OpenStack supports Ryu. You can create tens of thousands of isolated virtual networks without using VLAN. You manage virtual networks, OpenStack notifies of Ryu and Ryu configures OpenvSwitches properly. You can try Now. Ryu's pre-configured VM image file enables you to easily set up multi-node OpenStack environment. We try Ryu with software OpenFlow Switch (OpenvSwitch) and bunch of hardware OpenFlow Switches. |
https://github.com/osrg/ryu/wiki | 1.0, 1.2, 1.3 e Nicira Extensions |
| Floodlight | Java | Apache V2.0 | 46 Mb (Fonte) | - Offers a module loading system that make it simple to extend and enhance. - Support for OpenStack cloud orchestration platform - OpenStack Quantum plugin. - It is the core of 'BigSwitch' (BigSwitch open-sourced FloodLight). - Easy to set up with minimal dependencies. - Supports a broad range of virtual- and physical- OpenFlow switches. - Can handle mixed OpenFlow and non-OpenFlow networks – it can manage multiple “islands” of OpenFlow hardware switches. - Designed to be high-performance – is the core of a commercial product from Big Switch Networks. - API REST. - Enterprise class (production). - Floodlight VM*. It includes floodlight running by default and Mininet. - Nos repositórios do Ubuntu. - *Avior (GUI open-source). |
http://www.projectfloodlight.org/documentation/ | 1.0 |
| BigSwitch | java | closed-source | -- | - OpenStack - based on Beacon - targets production networks - user-friendly cli |
http://www.bigswitch.com/ | |
| MUL | C | GPLv2 | 16.2 MB (src) | - muli-threaded infrastructure - multi-level north bound interface for hooking up applications. - designed for performance and reliability (mission-critical networks). - core of a commercial controller from Kulcloud Networks - Openstack Support through Quantum plugins |
http://sourceforge.net/projects/mul/ | 1.0, 1.1, 1.2 |
| Jaxon | java | -- | 109 KB (src) | - NOX-dependent - provides a thin interface with the NOX - possible to directly access from Java program to C native ones. |
http://jaxon.onuos.org/ | -- |
| NDDI-OESS | ?? | Apache V2.0 | ?? | -- set of programs - OESS provides sub-second circuit provisioning - automatic circuit failover - per-interface permissions - automatic per-VLAN statistics - simple and user friendly web-based user interface - web services API |
http://code.google.com/p/nddi/wiki/README | 1.0 |
| NodeFlow | javascript | MIT-License | ? | - provides an asynchronous library over JavaScript for server side programming which is perfect for writing network based applications (ones that don’t require an excessive amount of CPU). - Uses on OFLIB-NODE Library. |
http://garyberger.net/?p=537 | 1.0 |
| Helios | C | closed-source | ? | - targetting researchers - programmatic shell (integrated experiments) |
http://www.nec.com/ | 1.0 |
| SNAC | Python e C++ | GPLv3 | ? | - targets production networks - based on NOX 0.4 - flexible policy definition language - user-friendly interface (configuration + monitoring) |
http://www.openflow.org/wp/snac/ | 1.0 |
| HP VANSC | ? | closed | ? | - dinamic control plane - full support for OpenFLOW protocol - Open API enable third part application |
? | ? |
| IBM PNC | ? | closed | ? | - unlimited virtual machine mobility - enterprise class (production) - automatically and continuous discovers network topology |
? | ? |
To a controller: ordinary switch. To a switch: a controller. Must stay on top of switches and under the controller.
Trema is a full-stack, easy-to-use framework for developing OpenFlow controllers in Ruby and C.
Aqui uma lista de bugs criticos do OpenStack, que afetam a implantacao na FDE.
O time do openstack nao esta fazendo testes pesados com maquinas Windows muito menos imagens grandes.
Segundo a propria documentacao do OpenStack:
" Troubleshooting
Mainly, it wouldn't take more than 5 minutes in order to go from a "SAVING" to the "ACTIVE" state. If this takes longer than five minutes, here are several hints:
Este papel seria do balanceador de vm;
XLCloud-Networking_Needs_Quantum.pdf: continuar da página 9
Serviço OpenStack que lida com rede (OpenStack Networking)
Retirada do OpenStack Admin Guide
cloud controller host e network gateway host podem ser combinados em uma máquina, porém é recomendado que exista um network gateway host separado para evitar restrições de CPU entre os encaminhamentos realizados pelo quantum-l3-agent e outros serviços OS.
Retirada do OpenStack Guide
Retirada do OpenStack Guide
Networking oferece uma API para definir interface entre os serviços OpenStack (e.g.: vNICs de máquinas virtuais com Nova). Os recursos alocados possuem dois modos: controle e operação
Abstrações que descrevem os recursos:Agentes são softwares que devem rodar em cada nó que lida com pacotes de dados.
Neutron Plugin são pedaços de código que implementam chamadas da API Neutron.
Um plugin geralmente é formado por códigos para:
quantum-server: processo principal do Netron. Expõe Netron API e encaminha as requisições de usuário para o plugin.
Agentes enviam mensagens para o Quantum-Server via RPC (rabbitmq ou qpid) ou Netron API padrão (REST).
$ sudo ovs-vsctrl add-br br-ext $ sudo ovs-vsctrl add-port br-ext eth1
$ ip netns exec qrouter-<UUID> ping <fixed ip>
Serviço de redes virtual. Define conexões e endereços para os outros serviços.
network <-- port
| |
-------------- subnet
fixed_ips é atributo do port
port.fixed_ips = {<IP1>:<subnet1>, <IP2>:<subnet2>, ...}
Projeto original assume um modelo muito básico para realizar isolamento através de Linux VLANs e tabelas IP. Netron introduz o conceito de plugin, que é a
implementação de requisições lógicas de API em forma de um back-end acoplável. Padrão: Open vSwitch e Linux Bridge. Plugin deve estar em cada nó que usa
pacotes de dados.
Os plugins devem processar chamadas de API e gerenciar vSwitches.
OpenVSwitch: open vswitch, quantum-plugin-openvswitch-agent
$ sudo ovs-vsctrl add-br br-int
Requer: python-pyparsing, python-cliff, python-quantumclient
Interagem com Netron através da API. Comunica com Netron API para connectar cada vNIC da VM em uma rede em particular.
agent-*
dhcp-agent-*
ext-* (extensões)
floatingip-*
l3-agent-*
lb-* (loading balance)
lb-pool-*
lb-healthmonitor-*
lb-member-*
lb-vip-*
net-*
queue-*
router-*
security-*
subnet-*
quota-*
security-group-*
$ quantum net-create net1 $ quantum net-create net2 --provider:network_type local $ quantum net-create --tenant-id=<id> net1 $ quantum subnet-create net1 192.168.0.2/22 --name subnet1 $ quantum port-create net1 --fixed-ip ip_addr=192.168.2.40 $ quantum port-create net1 $ quantum port-list --fixed-ips $ quantum port-list --tenant-id=<tenant id> $ quantum port-list --device-id=<vm id>
$ nova boot --image=<img id> --flavor=<fl id> --nic net_id=<net id> <vm name>
$ nova boot --image=<img id> --flavor=<fl id> --nic port_id=<net id> <vm name>
1) eth0 (VM)
2) TAP VNET0 (hypervisor network interface card, VIF, vNIC)
3) LINUX BRIDGE qbrXXX (hub, multi NIC, virtual ou físico)
4) veth pair {qcbXXX, qvoXXX} (entra de um lado e sai do outro)
5) open switch bridge br-int (virtual switch, integration bridge,todos as VM estão conectadas a ele)
6) veth pair (int-br-eth1, phy-br-eth1)
7) physical network interface card eth1
$ sudo pip install ryu $ sudo apt-get install quantum-plugin-ryu-agent openvswitch-switch python-openvswitch openvswitch-datapath-dkms
Floodlight pode ser utilizado como o backend para o OpenStack Network utilizando um Plug-in para Neutron. O Neutron expõe um modelo de networking-as-a-service via API REST implementada no Floodlight. Dois componentes principais são utilizados para essa integração: um aplicativo Virtual Switch do Floodlight que implementa a Neutron API e o o RestProxy plugin que conecta o Neutron com o Floodlight.
Conexão entre FloodLight e Neutron em dois passos:
- Descobrir o ID da VM usando o comando onevm list
- Executar o comando de pausa da VM:
- onevm suspend VM_ID
Controlador derivado do NOX.
http://www.noxrepo.org/pox/about-pox/
Python 2.7
GPLv3
Somente python
https://github.com/noxrepo/pox
???
https://github.com/noxrepo/pox/tree/betta/tests
Precisa ser clonado com git.
Branch 'carp' com atividades recentes.
Nenhum, aparentemente
Voltado para pesquisadores.
Nicira
pox.py recebe uma lista de módulos na linha de comando e chama a função 'launch()' deles caso ela exista e depois muda para estado 'up'.
Os módulos podem estar nos diretórios 'pox' e 'ext', além dos diretórios normalmente vigiados pela instalação do python.
Opções (--) podem ser acrescidas após o nome do módulo e serão passadas como parâmetro para o chamado da função 'launch()'.
Algumas referências sobre integração LDAP + Keystone
Material da Folsom
http://docs.openstack.org/folsom/openstack-compute/admin/content/configuring-keystone-for-ldap-backend.html
Keystone com open LDAP e horizon (grizzly)
https://ask.openstack.org/en/question/1350/how-to-configure-keystone-with-open-ldap-horizon-on-grizzly/
Change I672b90e6: Read-only default domain for LDAP (bug 1168726)
https://review.openstack.org/#/c/28197
Openstack Keystone LDAP Redux
http://adam.younglogic.com/2012/02/openstack-keystone-ldap-redux/
Re: New schema for LDAP + Keystone Grizzly?
https://lists.launchpad.net/openstack/msg22556.html
How to configure Keystone with open LDAP + horizon on grizzly
https://lists.launchpad.net/openstack/msg23814.html
Enable the Keystone LDAP back end in OpenStack
http://www.ibm.com/developerworks/cloud/library/cl-ldap-keystone/
Lista de Referências sobre SDN, Openflow e Controladores
What Is SDN All About, Then?
http://www.noxrepo.org/2012/03/sdn/
Com a aplicação da virtualização de hardware, mostrou-se necessário haver alguma forma de comparação entre o desempenho dessas máquinas com aquelas que não utilizam esse recurso. Isso é importante pois dessa forma pode-se mensurar qual é a sobrecarga que o sistema de virtualização provoca em condições correlatas e também para mensurar o desempenho de máquinas que só se tornaram possíveis com a virtualização.
Existem tipos diferentes de benchmark como o usado no TOP500 (top500.org) e no Graph500 (graph500.org). Cada um mensura características diferentes do computador.
Benchmark é a normalização de determinados procedimentos de forma a tornar possível a comparação entre eles.
LINPACK Benchmark é um sistema de avaliação do poder computacional de computadores, utilizando ponto flutuante. Para isso, mede-se a velocidade de resolução de um sistema linear de equações n x n do tipo ''Ax = b''.
Será utilzado o HPLinpack que possibilita o teste da paralelização de computadores, em que o tamanho do problema pode ser definido de acordo com a disponibilidade de recursos de forma a fazer uso da plena capacidade das máquinas.
Os seguintes resultados são mostrados para cada teste:
R_max: a performance em Gflops/s para o maior problema executado
N_max: o tamanho do maior problema executado
N_{1/2}: o tamanho do problema para quando metade da R_max foi atingida.
R_peak: o pico teórico de performance.
Após realizar os testes com os valores escolhidos anteriormente, obtém-se:
Cada teste é armazenado na máquina 00 em /opt/hpl/ utilizando um diretório cujo nome indica a qual teste pertence. Esse nome é composto por abreviações seguidas por valores:
~$ mkdir <nome> ~$ cd <nome>
~$ cp -r /opt/hpl/* .
~$ vim hpl-files/HPL.template
~$ vim hpl-files/generateFile.pl
$ perl hpl-files/genereteFile.pl
~$ vim hpl/runme-single.sh
~$ hpl/runme-single.sh
Testes:
4 Máquinas Reais Vs 4 Máquinas Virtuais
1 Máquina Real Vs 1 Máquina Virtual
Máquina Real com HT Vs Máquina Real sem HT
Matriz QxP quadrada vs Matriz QxP Linear
Busca pelo maior número de operações por segundo em 4 máquinas sem HT - Variação do uso de memória
Busca pelo maior número de operações por segundo em 4 máquinas virtuais - Variação do uso de memória
Testes Fase 2:
2 máquinas virtuais em uma máquina real - Variação do uso de memória
4 máquinas virtuais em uma máquina real - Variação do uso de memória
8 máquinas virtuais em uma máquina real - Variação do uso de memória
4 máquinas virtuais em duas máquinas reais - Variação do uso de memória
8 máquinas virtuais em duas máquinas reais - Variação do uso de memória
16 máquinas virtuais em duas máquinas reais - Variação do uso de memória
- Descobrir o ID da VM usando o comando onevm list
- Executar o comando de resumo da VM:
- onevm resume VM_ID
Python 2.7
Apache 2.0 license
Comunicação por mensagens, então, pode conversar com qualquer aplicativo que implemente essas mensagens.
???
git://github.com/osrg/ryu.git
https://github.com/osrg/ryu/tree/master/ryu/app
https://github.com/osrg/ryu/tree/master/ryu/tests
Pode ser instalado com o gerenciador 'pip'.
http://ryu.readthedocs.org/en/latest/index.html
https://github.com/osrg/ryu/wiki/OpenFlow_Tutorial
Quantum Ryu plugin. VM pré-configurada para testar OpenStack + Ryu.
https://github.com/osrg/ryu/wiki/OpenStack
'nova requests quantum-server for network configuragion'
OVS <--> Ryu: openflow
Ryu agent <--> Ryu: REST API
Quantum server <--> Ryu: REST API
Ryu agent <--> Quantum db: db access
VIF driver <--> quantum: Quantum API
linux_net driver <--> server: Quantum API
???
NTT Lab
Blocker/Dependencia:
Próximos Passos:
Blocker/Dependencia:
Próximos Passos:
Blocker/Dependencia:
Próximos Passos:
Blocker/Dependencia:
Próximos Passos:
Blocker/Dependencia:
Próximos Passos:
Blocker/Dependencia:
Próximos Passos:
Blocker/Dependencia:
Próximos Passos:
Blocker/Dependencia:
Próximos Passos:
Blocker/Dependencia:
Próximos Passos:
Blocker/Dependencia:
Próximos Passos:
Blocker/Dependencia:
Próximos Passos:
Blocker/Dependencia:
Próximos Passos:
Blocker/Dependencia:
Executou:
Próximos Passos:
Blocker/Dependencia:
Executou:
Próximos Passos:
Blocker/Dependencia:
Executou:
Próximos Passos:
Blocker/Dependencia:
Executou:
Próximos Passos:
Blocker/Dependencia:
Executou:
Próximos Passos:
Blocker/Dependencia:
Executou:
Próximos Passos:
Blocker/Dependencia:
Executou:
Próximos Passos:
Blocker/Dependencia:
Executou:
Próximos Passos:
Blocker/Dependencia:
What Is SDN All About, Then?
http://www.noxrepo.org/2012/03/sdn/
LINPACK was designed to run on the then-modern vector computers with shared memory. LAPACK, in contrast, was designed to effectively exploit the caches on modern cache-based architectures, and thus can run orders of magnitude faster than LINPACK on such machines, given a well-tuned BLAS implementation.
Linguagem utilizada para o desenvolvimento.
Licença em que o código foi liberado. A preferência é por licenças livres, facilitando assim o estudo e desenvolvimento de aplicações ou até mesmo de correções de problemas.
Quais linguagens são suportadas na implementação de aplicações e componentes.
Quanto e que tipo de modularidade o controlador oferece.
Onde encontrar o código.
Existência de testes de unidades no codigo (scripts ou códigos), geralmente em uma pasta em separado, que validam e testam o código desenvolvido.
Disponibilidade e facilidade de instação nas distribuição GNU/Linux relevantes atuais.
Nível de documentação do controlador, incluindo tutoriais e exemplos (tanto de estruturas quanto de aplicações).
Como o ambiente estruturado se baseia no OpenStack, é interessante saber qual é o tipo de suporte oferecido a essa ferramenta.
Público do controlador
Empresas, consórcio, comunidade, universidade, ...
Uma das formas de se ter noção de quanto o desenvolvimento ainda está ativo é procurar pela data da última atualização de código no repositório.
Características que não se adequam a nenhuma das anteriores.
O conceito de computação em nuvem (em inglês, cloud computing) refere-se à utilização da memória, capacidade de armazenamento e poder computacional dos computadores interligados por meio da Internet, seguindo o princípio da computação em grade. Com a subutilização destes recursos computacionais em equipamentos modernos, surgiu a necessidade de compartilhar recursos de forma isolada, tornando assim uma máquina física em várias máquinas virtuais, cada uma servindo para um determinado propósito e com seus recursos bem definidos, tentando obter o máximo de aproveitamento dos recursos computacionais.
Prover uma infraestrutura de máquinas virtuais para clientes de forma escalável é hoje uma necessidade mundial e um desafio tecnológico. Este relatório tem por objetivo exibir as características e requisitos necessários para instalar e configurar uma infraestrutura de Cloud para prover máquinas virtuais aos usuários do projeto EduCloud.
O projeto EduCloud é uma iniciativa da Universidade Estadual Paulista - UNESP, em parceria com a Secretaria de Educação do estado de São Paulo, Intel e ACCEPT. Esta iniciativa visa fornecer uma infraestrutura de computação em nuvem para hospedar sistemas de apoio ao ensino para as escolas da rede pública do estado de São Paulo.
Uma das grandes vantagens da computação em nuvem é a possibilidade de utilizar softwares remotamente, oferecidos na forma de serviços, mais comumente chamado de: Software as a Service (SaaS), sem a necessidade de que esses estejam instalados no disco local do computador do usuário. Todavia o leque de vantagens trazidos pelo SaaS é mais amplo, não limitando-se unicamente à economia do recurso de disco do usuário1:
Para implementar uma infraestrutura de nuvem, o Núcleo de Computação Ciêntifica - NCC, da UNESP pesquisou as principais ferramentas livres2 do mercado para que juntas, executem esta tarefa.
Para prover uma infraestrutura de nuvem, faz-se atender as seguintes necessidades:
Alguns softwares existem para suprir estas necessidades. No capítulo 1 falaremos sobre o projeto OpenStack[3], responsável por disponibilizar uma infraestrutura de máquinas virtuais e unidades de armazenamento para as máquinas virtuais. No capítulo 2 falaremos sobre o projeto Hadoop[4], responsável por gerenciamento e manipulação de grandes volumes de dados em ambientes largamente distribuídos. No capítulo 5, falaremos sobre os balanceadores de conexões e de máquinas virtuais, fundamental para balancear a carga da nuvem entre os nós "workers", no capítulo 6 falaremos sobre o OCCI[5], uma interface de comunicação entre os serviços de cloud.
O OpenStack consiste em uma coleção de projetos open source criada para fornecer uma infraestrutura de computação em nuvem e armazenamento distribuído. A empresa Rackspace6 e a NASA7 são os principais contribuidores do conjunto de projetos. Hoje o consórcio possui mais de 100 membros, dentre as principais temos: Rackspace, AT&T, NASA, DreamHost, Safew Labs, Citrix, Dell, AMD, Intel, Canonical, Yahoo e HP. O projeto mantém uma página8 com uma lista dos principais contribuidores do projeto.
No OpenStack, existem 3 principais componentes:
Nova é um controlador de poder computacional para o OpenStack. Todas as atividades necessárias durante o ciclo de vida de uma instância (uma máquina virtual sendo executada) com o OpenStack são gerenciadas pelo Nova. Isto faz dele uma plataforma de gerenciamento que manipula recursos computacionais (e.g. rede), além de manter o controle de acesso sobre os recursos, e zelar pela escabilidade da infraestrutura de máquinas virtuais. O Nova não provê nenhuma funcionalidade de virtualização por si só; ele usa a interface libvirt9 para interagir com os hypervisors10 suportados.
O Swift provê um armazenamento para os objetos (dados) de forma distribuída. Ele é análogo ao serviço da Amazon: Simple Storage Service, ou S313. O Swift é capaz de armazenar bilhões de objetos distribuindos entre os nós. Ele possui um mecanismo de redundância e failover e é capaz de armazenar e transmitir os dados. Além disso o Swift é capaz de escalar arquivos considerados muito grandes (petabytes), mesmo que estes sejam em grande quantidade (número de objetos).
O Glance é um sistema de busca e recuperação de imagens de máquinas virtuais. Ele é responsável por gerenciar as imagens das máquinas virtuais, armazenando-as no sistema de arquivos local ou via o OpenStack Object Store - Swift.
Outros componentes, como um front end web (Horizon) e um serviço de autenticação (keystone), também fazem parte do projeto. O OpenStack está disponível no site do projeto10 e está dispobilizado sobre a licença Apache11.
O OpenStack atende as necessidades do projeto EduCloud por se tratar de um conjunto de ferramentas que permitem montar uma infra estrutura de cloud utilizando ferramentas livres. Cada subprojeto do OpenStack tem suas próprias características, mas de modo geral as principais vantagens do OpenStack são:
As principais desvantagens são:
O OpenStack é uma infraestrutura complexa que exige um conjunto mínimo de algumas máquinas. Embora uma única máquina pode ser utilizada para fins de desenvolvimento, os requisitos mínimos para um ambiente de produção exige uma quantidade maior de máquinas.
A arquitetura mínima é suficiente para testes de staging. Uma vez que o EduCloud tenha passado por essa fase, faz-se necessário a adoção do cenário médio para que sejam tratadas as requisições do treinamento remoto oferecido pela FDE hoje. O cenário mínimo é utilizado apenas fins de desenvolvimento. O cenário médio é robusto o suficiente para substituir a atual arquitetura sobre o qual roda o treinamento hoje. Por fim, quando chegar o momento de se oferecer serviços adicionais através da infraestrutura do projeto EduCloud, tais como ferramentas de ensino à distância, será necessário expandir o cenário médio até que atinja-se o porte do cenário grande. Dessa forma a infraestrutura será suficiente para, além de oferecer o treinamento remoto já disponibilizado, suportar novos serviços educacionais a serem oferecidos a educadores e estudantes da rede pública de ensino do estado de São Paulo.
As recomendações de hardware foram retiradas do site do projeto OpenStack11. Abaixo temos 3 propostas de arquiteturas para o projeto EduCloud, com suas respectivas configurações:
Nesta arquitetura proposta, temos as seguintes máquinas:
Com as seguintes configurações:
Nesta arquitetura proposta, temos as seguintes máquinas:
Com as seguintes configurações:
Nesta arquitetura proposta, temos as seguintes máquinas:
Com as seguintes configurações:
Várias tecnologias podem ser utilizadas para provêr uma infraestrutura de máquinas virtuais. Algumas delas na forma de solução livre, podendo ser instalada em infraestrutura própria, e outras na forma de serviço web, sendo executada na infraestrutura da empresa que a provê.
Entre as tecnologias livres mais conhecidas, temos:
Entre as tecnologias funcionando como serviço web, temos:
Estas são apenas as principais alternativas que atendem os requisitos do projeto, levando em consideração popularidade, quantidade de downloads/mês e nível de maturidade do projeto.
Um balanceador de conexões é o elemento responsável por redirecionar o fluxo de pacotes de redes vindo da Internet para os worker nodes na rede interna, dividindo as conexões de forma mais justa possível para evitar sobre carga em um nó específico. Desta forma, se temos 10 servidores web, o balanceador recebe as conexões e encaminha para os 10 balanceadores dependendo do algoritmo por ele suportado.
Como as conexões HTTP são stateless, é fundamental que o balanceador tenha a capacidade de enviar sempre para o mesmo servidor conexões vindas de um mesmo cliente. O balanceador também é responsável por adicionar ou remover worker nodes da fila de máquinas sempre que necessário.
Durante esta etapa foi feita uma pesquisa inicial sobre os projetos Nginx14 e HAProxy15. Todas as duas tecnologias se encaixam, com vantagens e desvantagens no projeto EduCloud.
O Nginx (pronuncia-se em inglês: Engine X) é um servidor HTTP + proxy reverso e está disponibilizado pela licença BSD. Ele funciona no modo de load balance via um módulo externo.
Já o HAProxy nao é um servidor HTTP (ele não serve páginas estáticas), foi feito exclusivamente para ser um proxy e load balance não só HTTP mas para qualquer protocolo TCP. Seu código está licenciado sob a GPL.
Nenhuma das tecnologias conflita com demais componentes do projeto EduCloud, porém o Nginx possui algumas limitações.
Nginx é um servidor e proxy reverso HTTP de alta performance, gratuito e livre, bem como um servidor proxy para IMAP/POP3.
Foi criado pelo programador russo Igor Sysoev em 2005. Segundo pesquisa da Alexa, reportada pela W3Techs. Em presquisa realizada pela Netcraft em Julho de 201016, o Nginx é usado em 5.21% dos domínios, tornando-se o quarto servidor web mais popular do mundo.
E funciona em UNIX, Linux, BSD, Mac OS, Solaris, e Microsoft Windows.
Todas as duas tecnologias possui um desenvolvimento ativo.
O HAProxy é usado por empresas como Twitter, Farmville, Fedora, github, Reddit, Stack Overflow, Tumblr, entre outras empresas.
Todos os dois projetos existem uma boa documentação, embora elas estejam espalhadas.
Durante a pesquisa inicial a única desvantagem encontrada no HAProxy é que nativamente ele não suporta HTTPS. Porém alguns módulos extras permitem adicionar esta funcionalidade.