Categories
Community General OpenSource

OpenNebula User Group en Barcelona


 
Como sabéis, la comunidad de OpenNebula es un pilar muy importante para el proyecto. Comunidad que mediante un sistema de peticiones, listas de distribución y ahora foros, pueden expresar sus dudas, peticiones, o aportar ideas que para los desarrolladores es una información muy útil, además, puede contribuir ayudando a otros usuarios o desarrollando nuevas funcionalidades.
Para eso OpenNebula ha pensado en los User Groups. Los User Groups de Opennebula son comunidades a nivel local, donde los usuarios pueden discutir o compartir información y experiencias de una forma más directa en su misma ciudad. De esta forma también se consigue hacer una difusión más cercana, y encontrar gente que quiera colaborar con el proyecto.
También añadir que este 2015 la conferencia anual de OpenNebula viaja de Berlín a Barcelona, ciudad que será el punto de encuentro dónde desarrolladores, usuarios, administradores, investigadores,… podrán compartir experiencias, casos de estudio y lo que “proceda”.
ONE 2015 Conference
Por todo lo anterior algunos partícipes de este blog nos hemos puesto en contacto con OpenNebula y con otros usuarios del área de Barcelona y hemos decidido crear el OpenNebula User Group de Barcelona. Este grupo pretende ser una comunidad a pequeña escala donde podamos discutir y encontrar objetivos comunes en los que colaborar con el proyecto. Hemos creado un grupo de Google donde iremos informando de los pasos que se van dando y empezaremos a fijar objetivos.
Además, también participaremos en la charla de sudoers, un grupo que se reúne periódicamente en el Campus Nord de la UPC, dónde hablaremos sobre la OpenNebula y expondremos los objetivos del User Group de Barcelona.
Es un grupo totalmente abierto así que estáis invitados!. Primeros integrantes del Grupo:








Xavi Peralta
Colaborador www.cloudadmins.org
 
Algunos enlaces de interés:
OpenNebulaconf 2015 (Barcelona) http://2015.opennebulaconf.com/
OneBCN Google Group – https://groups.google.com/forum/embed/?place=forum%2Fopennebula-barcelona-usergroup
Sudoers Barcelona – http://sudoers-barcelona.wikia.com/wiki/Sudoers_Barcelona_Wiki

Categories
General In detail

Cloud Simulators.. ¿Por qué y para qué?

cloud simulator

¿Desarrollo de aplicaciones sobre la nube o incluso optimización de esta sin un proceso de “testing” a la altura? La utilización de bancos de pruebas reales sin duda limita los experimentos y hace que la reproducción de resultados sea para este tipo de entornos un tanto difícil.

Una alternativa adecuada es usar herramientas de simulación, ya que abren la posibilidad de evaluar la hipótesis antes del desarrollo de software en un entorno donde se pueden reproducir tests sin impacto en el bolsillo. Como bien conocemos en la computación en la nube, el acceso a la infraestructura incurre en pagos a golpe de tarjeta, los enfoques basados ​​en la simulación ofrecen beneficios significativos, ya que permite a los clientes probar sus servicios/aplicaciones en un entorno repetible y controlable cerca de un coste que tiende a 0. Es decir, que si buscamos ajustar aspectos de rendimiento y evitar futuros cuellos de botella antes de implementarlos en nubes públicas reales nos pueden ser de mucha utilidad.

Por la parte del proveedor, los entornos de simulación permiten la evaluación de diferentes tipos de escenarios de “alquiler” de recursos con diversas configuraciones de cargas de trabajo y a partir de aquí llegar incluso a ajustar o establecer sus tarifas. En ausencia de este tipo de plataformas de simulación, los clientes y los proveedores cloud tienen que confiar en suposiciones teóricas, dónde los enfoques de prueba/error pueden conducir a la prestación de un servicio ineficiente y en consecuencia impacto sobre la propia generación de ingresos.

Resumiendo, tests de integración parecidos al entorno productivo permiten:

  1. Validar rápidamente suposiciones.
  2. Trabajar con volumenes de recursos que no podemos conseguir.
  3. Ahorrar tiempo.
  4. [alguna más que seguro estás pensando..]

Algunos ejemplos de “frameworks” disponibles:
cloudbuslogo-v5aCloudSim http://www.cloudbus.org/cloudsim/  – Univ. of Melbourne

  • Dedicado a entornos cloud (IaaS & PaaS)
  • Java
  • Se está situando como estándar en su campo



simgrid_logo_2011
SimGrid http://simgrid.gforge.inria.fr/ –  Inria / Univ. Lorraine

  • Establecido en al comunidad científica (muy versátil)
  • C y varios bindings (Java incluido)
  • Reorientado hacia cloud por la ANR via el proyecto Songs





greencloud
GreenCloud http://greencloud.gforge.uni.lu/ – Univ. Luxembourg

  • Orientado a la mejora de la eficiencia energética.
  • Simulación de entornos de virtualización y clouds privados.
  • Altamente enfocado a networking.

Y hasta aquí el repaso del ecosistema de herramientas de referencia, como es habitual cada opción con sus ventajas e inconvenientes dónde su aplicación vendrá determinada por cada caso.
A modo de conclusiones:

  • Los simuladores sin duda son de mucha utilidad frente a la validación y testeo de algoritmos de  optimización/automatización de procesos y del manejo del ciclo de vida de recursos en cloud. Un verdadero reto dónde las aplicaciones (lo de arriba) y la infraestructura (lo de abajo) aumentaran su eficiencia debido a alinearse con los primeros y en consecuencia hacer un mejor uso de los segundos.
  • El uso de simuladores permite a investigadores y desarrolladores de la industria concentrarse en cuestiones de diseño de sistemas específicos que quieren investigar, sin estar preocupados por los detalles relacionados con la infraestructura y servicios base que ofrece la nube.

Para finalizar y como recomendación no olvides que en ocasiones la simulación se puede alejar de la realidad si no se contemplan los tiempos,  (provisonar 50k MV’s via simulador (10 seg) sobre tu cloud provider favorito un poco más… 😉

Categories
General Monitoring

Battle Cloud Providers

microsoft-azure-logo
Almacenamiento y computación son los recursos que más consumimos habitualmente en nuestros proveedores IaaS. Otros servicios como balanceo de carga, servicio de colas, monitorización de rendimiento de los recursos, etc son considerados en el momento de escoger pero son secundarios en el grueso de la factura final. Estos servicios compiten en costes, rendimiento y disponibilidad. Es sorprendente como recientemente hemos visto anuncios de distintas compañías anunciando reducciones de precios en servicios clave.

A raíz de estos movimientos es fácil no saber hacía que proveedor dirigirse o que criterio debe prevalecer a la hora de utilizar los distintos servicios que nos proporcionan. Han surgido herramientas como PlanForCloud que pueden ayudarnos en esta tarea. También le debemos dar importancia a las SLA’s que nos ofrecen y al rendimiento de las plataformas que desplegamos en servicios IaaS/PaaS, para ello contamos con aplicaciones como de CloudSleuth, nos permite ver de forma detallada varias métricas que nos ayudan elegir que proveedor es el adecuado para nuestros requerimientos.

Cloud Pricing Trends
Ante tanta variedad se nos puede hacer complicado la gestión de tantos servicios, más aún si contamos con varios proveedores, se encuentran en crecimiento plataformas como ECmanaged o eNovance, que nos permiten llevar una administración centralizada de ellos. También herramientas de código abierto como Hydra que nos permiten una mayor flexibilidad y menor coste para llevar a cabo estas tareas. Hemos encontrado este post muy interesante para valorar los distintos proveedores existentes actualmente. A día de hoy AWS sigue siendo la referencia a seguir, veremos como evolucionan las grandes compañías ante tanta competitividad.
Top Public Clouds Used

Categories
OpenSource

OpenvSwitch y OpenNebula – 2a entrega

openvswitch
opennebula_logo
Siguiendo con la serie de posts sobre OpenvSwitch y OpenNebula en los que vamos viendo la integración de OpenNebula con Open vSwitch a través del driver, vamos a ver en esta entrega cómo poder aplicar firewalling con OpenNebula al driver de OpenvSwitch.
Para empezar, vamos a ver como se configura el firewalling en general con OpenNebula, en este enlace podemos ver mas detalles. OpenNebula tiene cinco campos especiales a la hora de crear una màquina/template que són:

  • WHITE_PORTS_TCP: Se filtran todos los puertos tcp menos los especificados por el parámetro, para especificarlo se hace con “:” para rangos de puertos y con “,” para puertos especificos. Así pues si queremos filtrar todos los puertos menos el 22, el 80 i del 2000 al 3000  se pasaria la variable de la siguiente forma: WHITE_PORTS_TCP = 22,80,2000:3000  
  • BLACK_PORTS_TCP: Se filtran sólo los puertos tcp especificados, para especificar los puertos a filtrar se hace de la misma forma que con el WHITE_PORTS_TCP, però en este caso el funcionamiento es el inverso, és decir se filtran todos los puertos especificados y el resto se dejan abiertos. En caso de especificar tanto el WHITE_PORTS_TCP cómo el BLACK_PORTS_TCP, entonces se aplican sólo los WHITE_PORTS_TCP. Si quisieramos filtrar todos los puertos menos el 22, 80 i del 2000 al 3000, en este caso se especificaria de la siguiente forma:  BLACK_PORTS_UDP = 1:21,23:79,81:1999,3001:65535
  • WHITE_PORTS_UDP: En este caso el funcionamiento és idéntico al TCP pero con tráfico UDP.
  • BLACK_PORTS_UDP: También este caso es idéntico al TCP pero con UDP.
  • ICMP: En el caso de ICMP podemos optar por filtrar todo el tráfico o no, si queremos filtrarlo, lo especificaremos de la siguiente forma: ICMP = drop

Para la implementación de esta funcionalidad con Open vSwitch, en el driver actual de OpenNebula no se pueden especificar rangos de puertos, se tienen que hacer uno a uno. Se ha provado i si se crean máquinas virtuales con muchos puertos filtrados, tarda muchas horas en crear la máquina virtual y añade mucha carga adicional al nodo físico. Para solventarlo tendremos que actualizar la versión de open vSwitch a la 1.6 o superior, ya que a partir de esta se pueden especificar los puertos con mascaras. Con las mascaras podemos especificar un puerto y la mascara asociada, la cual cosa nos permitirá filtrar todo el rango de puertos a los que se llegue con esta. Si por ejemplo quisieramos filtrar del puerto 32768 al 65535, podriamos hacerlo especificanod el puerto y la mascara de la siguiente forma (en hexadecimal): 0x8000/0x8000. Aqui podemos ver como el numero 32768 equivale a 0x8000 (el primero) y el rango de puertos que estaremos filtrando irá del 0x8000 (1000 0000 0000 0000) al 0xFFFF (1111 1111 1111 1111)  és decir el 65535 después de aplicarle la mascara.
Vemos pero que si queremos aplicar un filtro que vaya del puerto 32769 al 65535 la cosa no es tan evidente, ya que tenemos que hacer un filtro que para el 32769/0xFFFF, otro para el 32770/0xFFFE, otro para el 32772/0xFFFC y asi sucesivamente.
Así pues el algoritmo para el filtrado con rangos de puertos será:
Para todos los puertos p:

  1. Calculamos la máscara máxima para no filtrar algun puerto ya filtrado o que no se tenga que filtrar
  2. Calculamos la máscara máxima para los puertos que se tendrán que filtrar a continuación, hasta encontrar alguno que no sea consecutivo
  3. Aplicamos la mascara más pequeña entre 1 y 2.
  4. Aplicamos el filtro con la máscara escogida
  5. p= maximo puerto filtrado en 4 (aplicando mascara) + 1

En el ejemplo de que quisieramos filtrar todos los puertos menos el 22,80 y del 2000 al 3000, las reglas correspondientes quedarian de la siguiente forma:

0x1/0xffff, 0x2/0xfffe, 0x4/0xfffc, 0x8/0xfff8, 0x10/0xfffc, 0x14/0xfffe,
0x17/0xffff, 0x18/0xfff8, 0x20/0xffe0, 0x40/0xfff0, 0x51/0xffff, 0x52/0xfffe,
0x54/0xfffc, 0x58/0xfff8, 0x60/0xffe0, 0x80/0xff80, 0x100/0xff00, 0x200/0xfe00,
 0x400/0xfe00, 0x600/0xff00, 0x700/0xff80, 0x780/0xffc0, 0x7c0/0xfff0,
0x7d1/0xffff, 0x7d2/0xfffe, 0x7d4/0xfffc, 0x7d8/0xfff8, 0x7e0/0xffe0,
0x800/0xfe00, 0xa00/0xff00, 0xb00/0xff80, 0xb80/0xffe0, 0xba0/0xfff0,
0xbb0/0xfff8, 0xbb9/0xffff, 0xbba/0xfffe, 0xbbc/0xfffc, 0xbc0/0xffc0,
0xc00/0xfc00, 0x1000/0xf000, 0x2000/0xe000, 0x4000/0xc000, 0x8000/0x8000

Así pues, vemos que con este ejemplo pasariamos de 64532 reglas para aplicar a 43 gracias a las mascaras.

Actualización del driver de OpenNebula

Una vez visto que es lo que tenemos que hacer para que nos funcionen los drivers para OpenvSwitch con mascaras vamos a ver las modificaciones que se tienen que hacer en el driver de OpenNebula para Open vSwitch. El fichero en cuestión se encuentra en /var/lib/one/remotes/vnm/ovswitch/OpenvSwitch.rb. Aqui podeis encontrar el fichero con las modificaciones que se han explicado en el post.
Para modificar el driver, lo único que tenemos que hacer és sobreescribir el fichero y ejecutar:

onehost sync

Una vez ejecutado el comando ya podremos crear máquinas virtuales pasandoles los parametros de filtraje como con el driver por defecto.
Oriol Marti
www.cloudadmins.org

Categories
General Social

Chef, devops… future of system administration

Some thoughts for the holidays… Best Regards!  Cloudadmins team.
by Julian Dunn, 2012

Opscode Chef logoLast night, at a meeting of NYLUG, the New York City Linux Users’ Group, I watched Sean O’Meara whip through a presentation about Chef, the system configuration management (CM) tool. I was impressed. The last time(s) I tried to play with automation tools like cfengine and Puppet I got very frustrated at their complexity. The folks at Opscode have definitely succeeded at bringing simplicity (as much as can be had) to the CM space.
But what struck me after hearing Sean had nothing to do with Chef. Instead, I came to the conclusion that pure systems administration is eventually going to die out as a profession. The developer is now king (or queen), and that’s not a bad thing.
Let’s step back for a minute and talk about CM tools in general. Traditional CM tools — to the extent that they existed before cfengine et. al. – know nothing about the underlying semantics of what you ask them to do. At CBC, we had a set of elaborate shell and Perl scripts that were written in-house, collectively known as ASC, Application Server Control, to do so-called configuration management of the origin infrastructure. ASC’s sole job was to revision control configurations, perform deploy and rollback operations, and perhaps do some auditing. But it was prescriptive, not descriptive. Most of the time I spent monkeying with ASC was debugging how it was doing things.
Enter Chef (or Puppet, LCFG, cfengine, BCFG2; pick your poison). These are all configuration management tools that allow you to describe your infrastructure  in a fourth-generation language (4GL) way. You describe the features that certain hosts should have, and the tools, using canned recipes, makes it happen. (“Make me a MySQL server,” for instance.) Another advantage of these tools is that they (can) keep track of the state of your infrastructure, and you can query that database to make decisions about new deployments. “How many MySQL servers do I have?” for example. Or even “Which node is the MySQL master?” and then kicking off another job on a new MySQL slave to automatically start replicating from the right server.
Had it not been for the development of IaaS — infrastructure as a service — everything that I’ve told you would not be particularly noteworthy. But IaaS, or “cloud computing”, now allows anyone to provision new (virtual) servers inexpensively. No more waiting around for the system administrator to order a couple servers from Dell, wait a few weeks for them to arrive, rack them up, configure them, etc. Developers, armed with a tool like Chef and its huge cookbook of canned recipes for making many standard infrastructure components, can fire up everything they need to support their application themselves. Therein lies the demise of system administration as a standalone profession and the rise of “devops”.
I admit that when I first heard the concept of “devops”, I snickered. “Give developers the keys to the infrastructure and they’ll surely break it beyond repair and expect the sysadmins to fix it,” I thought. But it’s finally dawned on me that “devops” isn’t just some buzzword concept that someone has thought up to make sysadmins’ lives hell. It’s the natural evolution of both professions. By bringing development and system administration closer together, it does two things. First, it makes developers operationally accountable for their code, because they are the ones that get paged in the middle of the night, not some “operations team” upon whom they can offload that responsibility. And secondly, it makes those on the systems side of the house better at their jobs, because they can use newly-acquired programming skills to manage infrastructure resources in a more natural way.
So will IaaS and sophisticated configuration management tools kill the system administrator? I believe so — but that’s not a bad thing. System administrators have got to stop thinking of servers/disk/memory/whatever as “their resources” that “they manage”. Cloud computing has shown us that all of that stuff is just a service, dedicated to nothing more than serving up an application, which is what really matters. If sysadmins want to remain relevant, they’ll get on board and start learning a bit more about programming.
Source: http://www.juliandunn.net/2012/01/13/chef-devops-and-the-death-of-system-administration/
 

Categories
Social

Chef or Puppet + IaaS = No More Sysadmins?

The DevOps Zone is presented by DZone with partners including ThoughtWorks Studios and UrbanCode to bring you the most interesting and relevant content on the DevOps movement.  See today’s top DevOps content and be sure to check out ThoughtWorks Studio’s Continuous Delivery Whitepapers and UrbanCode’s Webinars.

The end of days is nigh for the profession of systems administration according to Julian Dunn, a digital media systems designer and architect.  At a recent meeting of the New York City Linux Users’ Group, a presentation using the configuration management tool, Chef, led him to the conclusion that

IaaS, or “cloud computing”, now allows anyone to provision new (virtual) servers inexpensively. No more waiting around for the system administrator to order a couple servers from Dell, wait a few weeks for them to arrive, rack them up, configure them, etc. Developers, armed with a tool like Chef and its huge cookbook of canned recipes for making many standard infrastructure components, can fire up everything they need to support their application themselves. Therein lies the demise of system administration as a standalone profession and the rise of “devops”. —Julian Dunn

Traditional CM tools have been composed of elaborate prescriptive, rather than descriptive, scripts that are unaware of the underlying semantic meaning of user requests, according to Dunn.  The tools that we’re now associating with DevOps (Puppet, Chef, etc.) allow you to describe your infrastructure in what Dunn refers to as a ‘4th Generation Language’ way.  That simplified process for creating reusable, canned recipies for configuration, paired with IaaS (where you don’t need to worry about the physical setup and configuration), is what could make the Sysadmin, as we know it, obsolete.  This is Dunn’s theory.
With these new opportunities in cloud computing, Dunn sees the benefits of bringing development and system administration together, and suggests that “if sysadmins want to remain relevant, they’ll get on board and start learning a bit more about programming.”  Good point, Dunn, but let’s not forget that, even with cloud services, code ultimately runs on servers/disk/memory. The hardware is never truly “virtual”.
Source:  http://server.dzone.com/articles/cm-tools-and-end-systems
Memfis (Cloud Admin)

Categories
General

EEDC Seminars- Iaas and Mobile Apps

One week after the first seminar, we attended to the second day of the EEDC Seminars, the second day was focused in Iaas and Mobile Apps.
In this second day, they should talk about Iaas, Saas and Mobile Apps, but finally the seminar about Saas was cancelled. So, the presentations were two:

Xavier Guarda and Joaquin Custodio have developed different iPhone applications, like Mountain Angel, that is a GPS tracking, heart rate monitor, and it sends a SMS to the person you want if you fall down with your bike.
He talked about Parse, it is a backend to create projects for mobile apps, it’s a very good choice to start a mobile app and easy, you can make prototypes without deploy anything on servers.

 

  • Infraestructure as a Service by David Suárez (Nexica)

Nexica offers Iaas and hosting services and they have two datacenters, one in Barcelona and another one in Madrid, member of Catnix and Espanix, the Catalan and Spanish Neutral Internet Exchange points. Nexica has a PUE of 1,4 in their datacenters.
David Suárez started talking about cloud categories, if you see cloud by deployment categories it can be Public, Private or Hybrid and if you see by service type it can be Iaas, Saas and Paas.
Iaas, Saas, Paas and visibility
He talked about community cloud, that are services with specific requirements, restricted to a group of organizations.
David ended his seminar talking the next step in this evolution: infrastructure as code, Iac is an abstraction of infrastructure into configuration files and code. Management and automation soft is needed (puppet, chef, juju). In many cases this evolution is changing the system administrators and devops tasks.

 
This was the last EEDC seminars. Here you can find all the slides of the EEDC seminars.
Enjoy it!
A Cloud Admin

Categories
General Social

Traditional On-Premise vs Cloud Computing:

The Cloud computing business motivation is that the resources solutions on demand promise greater flexibility, dynamic, timely and green solution than traditional on-premise computing.

Therefore, we must bear in mind that migrate certain parts or all of a classic on-premise IT to Cloud can provide scalability, can reduce the costs of physical growth, reduce costs and reduce energy use .

On-premise computing needs an initial capital investment, maintenance and the costs of future updates. In contrast Cloud does not need an important initial cost so it has a lower initial investment because Cloud offer elasticity and pay-as-you go cost model.

It is interesting to find which solution is better. But it is more interesting the utilization into both solutions together to keep the best features of each .

In the paper there is an interesting analysis of cost and performance between “Traditional On-Premise” with Cloud Computing classifying the various types of costs CapEX (CAPitalEXpenditures) and OpEX (OPerationalEXpenditures) depending on the attribute to be analyzed ( Infrastructure, Business, Physical Resources, Network, Performance, Energy, budget, etc.). In short we can discuss that in Cloud Computing there are more OpEx and in the traditional on-premise there are more CapEx.

Nowadays generally on-premise infrastructure run with low utilization, sometimes it goes down up to 5 to 10 percent of average utilization. Data centers that utilize Cloud technologies are more efficient than traditional data centers. Energy is usually lost through server under utilization, because most of the time these servers are just in idle mode. But in a Cloud environment the system is managed to run at the highest efficiency. In addition, data center planning allows better power utilization. In traditional data centers, they can have cooling problems and you can run out of space for more servers. There is also a consortium of Cloud providers, who assure that its members optimize their data centers to minimize power consumption.

On-premise solution can be better, whenever if we have a constant full utilization of the IT infrastructure. This often happens in large companies that offers constant services around the world. For example, in their start Facebook was using Amazon services but finally due to their large increase in business, Facebook built his own data center, adapted to their business needs.

Cloud solutions are highly recommended in most areas. But an important factor to consider is that network latency influences negatively in the response time of the Cloud solutions. Traditional On-Premise Computing usually have better network latency and therefore the response time gives better results for the solution.

And also a lot of companies prefer to use on-premise infrastructure for its data privacy and protection. In this project, however, we do not focus on Cloud security.

In conclusion, it is necessary to analyze the CapEx/OpEx balance and the consumption depending on each own case. As we have said, what we study is the energy consumption and in the next chapter, we would like to show our structure solution of hybrid architectures and how they are a solution to reduce energy consumption, without losing too much performance.

Paper: Predicting the Energy, Cost and Performance of Cloud Computing http://bit.ly/yxyCg2

By Cloud Admin

Categories
General

Microsoft hará llegar Linux en el Cloud mediante Azure

 
La Linux Foundation explica que las tendencias como la virtualización, el Cloud Computing y la gestión de Big Data son los máximos exponentes a la hora de adoptar Linux en las empresas. http://www.siliconnews.es/2012/01/19/aumenta-la-adopcion-de-linux-en-las-empresas/
Posiblemente Microsoft para contrarestar esta influencia hará llegar Linux a su Windows Azure esta primavera http://zd.net/syKUEK
Por cierto, habrán intereses al detrás de la felicitación sorpresa que le hizo Microsoft a Linux por su 20 aniversario? Tened también en cuenta que Microsoft a contribuido mucho últimamente con el desarollo del kernel de Linux 3.0 aunque sea porqué persigue ciertos intereses con su aportación al desarrollo de Linux. Básicamente las contribuciones han sido para sus propios drivers hypervisor de virtualización Hyper-V”, según explica ZDnet.