Diseño integral de plataforma de virtualización

L'objectiu d'aquest projecte és el disseny, raonat i recolzat en dades objectives, d'una plataforma de virtualització basada en VMWARE ESXi (versió gratuïta de VMWARE), orientada al segment d'empreses i organitzacions que per la seva grandària podrien beneficiar-se d'un entorn de servidors virtualizados però que pel seu pressupost no poden accedir a tecnologies capdavanteres d'implantació.

Tecnologies de cloud computing Openstack/StackOps

El propòsit d'aquest TFC és investigar i fer una instal·lació des de zero d'un model de negoci basat en l'allotjament web fent servir tecnologies de Cloud Computing. El software open-source que es farà servir per aquesta finalitat serà Openstack el qual es basa en un model de servei com infraestructura (IaaS). La nostra finalitat és poder implementar el model IaaS basat en Openstack. Per duu a terme aquest desplegament es farà servir dos hipervisors (KVM i VMware ESXi) per tal de testejar diferents sistemes d¿hipervisors treballant conjuntament.

Desempenho comparativo do BLAST e do mpiBLAST

Em Bioinformática são frequentes problemas cujo tratamento necessita de considerável poder de processamento/cálculo e/ou grande capacidade de armazenamento de dados e elevada largura de banda no acesso aos mesmos (de forma não comprometer a eficiência do seu processamento). Um exemplo deste tipo de problemas é a busca de regiões de similaridade em sequências de amino-ácidos de proteínas, ou em sequências de nucleótidos de DNA, por comparação com uma dada sequência fornecida (query sequence). Neste âmbito, a ferramenta computacional porventura mais conhecida e usada é o BLAST (Basic Local Alignment Search Tool) [1]. Donde, qualquer incremento no desempenho desta ferramenta tem impacto considerável (desde logo positivo) na atividade de quem a utiliza regularmente (seja para investigação, seja para fins comerciais). Precisamente, desde que o BLAST foi inicialmente introduzido, foram surgindo diversas versões, com desempenho melhorado, nomeadamente através da aplicação de técnicas de paralelização às várias fases do algoritmo (e. g., partição e distribuição das bases de dados a pesquisar, segmentação das queries, etc. ), capazes de tirar partido de diferentes ambientes computacionais de execução paralela, como: máquinas multi-core (BLAST+ 2), clusters de nós multi-core (mpiBLAST3J e, mais recentemente, co-processadores aceleradores como GPUs" ou FPGAs. É também possível usar as ferramentas da família BLAST através de um interface/sítio WEB5, que permite, de forma expedita, a pesquisa de uma variedade de bases de dados conhecidas (e em permanente atualização), com tempos de resposta suficientemente pequenos para a maioria dos utilizadores, graças aos recursos computacionais de elevado desempenho que sustentam o seu backend. Ainda assim, esta forma de utilização do BLAST poderá não ser a melhor opção em algumas situações, como por exemplo quando as bases de dados a pesquisar ainda não são de domínio público, ou, sendo-o, não estão disponíveis no referido sitio WEB. Adicionalmente, a utilização do referido sitio como ferramenta de trabalho regular pressupõe a sua disponibilidade permanente (dependente de terceiros) e uma largura de banda de qualidade suficiente, do lado do cliente, para uma interacção eficiente com o mesmo. Por estas razões, poderá ter interesse (ou ser mesmo necessário) implantar uma infra-estrutura BLAST local, capaz de albergar as bases de dados pertinentes e de suportar a sua pesquisa da forma mais eficiente possível, tudo isto levando em conta eventuais constrangimentos financeiros que limitam o tipo de hardware usado na implementação dessa infra-estrutura. Neste contexto, foi realizado um estudo comparativo de diversas versões do BLAST, numa infra-estrutura de computação paralela do IPB, baseada em componentes commodity: um cluster de 8 nós (virtuais, sob VMWare ESXi) de computação (com CPU Í7-4790K 4GHz, 32GB RAM e 128GB SSD) e um nó dotado de uma GPU (CPU Í7-2600 3.8GHz, 32GB RAM, 128 GB SSD, 1 TB HD, NVIDIA GTX 580). Assim, o foco principal incidiu na avaliação do desempenho do BLAST original e do mpiBLAST, dado que são fornecidos de base na distribuição Linux em que assenta o cluster [6]. Complementarmente, avaliou-se também o BLAST+ e o gpuBLAST no nó dotado de GPU. A avaliação contemplou diversas configurações de recursos, incluindo diferentes números de nós utilizados e diferentes plataformas de armazenamento das bases de dados (HD, SSD, NFS). As bases de dados pesquisadas correspondem a um subconjunto representativo das disponíveis no sitio WEB do BLAST, cobrindo uma variedade de dimensões (desde algumas dezenas de MBytes, até à centena de GBytes) e contendo quer sequências de amino-ácidos (env_nr e nr), quer de nucleótidos (drosohp. nt, env_nt, mito. nt, nt e patnt). Para as pesquisas foram 'usadas sequências arbitrárias de 568 letras em formato FASTA, e adoptadas as opções por omissão dos vários aplicativos BLAST. Salvo menção em contrário, os tempos de execução considerados nas comparações e no cálculo de speedups são relativos à primeira execução de uma pesquisa, não sendo assim beneficiados por qualquer efeito de cache; esta opção assume um cenário real em que não é habitual que uma mesma query seja executada várias vezes seguidas (embora possa ser re-executada, mais tarde). As principais conclusões do estudo comparativo realizado foram as seguintes: - e necessário acautelar, à priori, recursos de armazenamento com capacidade suficiente para albergar as bases de dados nas suas várias versões (originais/compactadas, descompactadas e formatadas); no nosso cenário de teste a coexistência de todas estas versões consumiu 600GBytes; - o tempo de preparação (formataçâo) das bases de dados para posterior pesquisa pode ser considerável; no nosso cenário experimental, a formatação das bases de dados mais pesadas (nr, env_nt e nt) demorou entre 30m a 40m (para o BLAST), e entre 45m a 55m (para o mpiBLAST); - embora economicamente mais onerosos, a utilização de discos de estado sólido, em alternativa a discos rígidos tradicionais, permite melhorar o tempo da formatação das bases de dados; no entanto, os benefícios registados (à volta de 9%) ficam bastante aquém do inicialmente esperado; - o tempo de execução do BLAST é fortemente penalizado quando as bases de dados são acedidas através da rede, via NFS; neste caso, nem sequer compensa usar vários cores; quando as bases de dados são locais e estão em SSD, o tempo de execução melhora bastante, em especial com a utilização de vários cores; neste caso, com 4 cores, o speedup chega a atingir 3.5 (sendo o ideal 4) para a pesquisa de BDs de proteínas, mas não passa de 1.8 para a pesquisa de BDs de nucleótidos; - o tempo de execução do mpiBLAST é muito prejudicado quando os fragmentos das bases de dados ainda não se encontram nos nós do cluster, tendo que ser distribuídos previamente à pesquisa propriamente dita; após a distribuição, a repetição das mesmas queries beneficia de speedups de 14 a 70; porém, como a mesma base de dados poderá ser usada para responder a diferentes queries, então não é necessário repetir a mesma query para amortizar o esforço de distribuição; - no cenário de teste, a utilização do mpiBLAST com 32+2 cores, face ao BLAST com 4 cores, traduz-se em speedups que, conforme a base de dados pesquisada (e previamente distribuída), variam entre 2 a 5, valores aquém do máximo teórico de 6.5 (34/4), mas ainda assim demonstradores de que, havendo essa possibilidade, compensa realizar as pesquisas em cluster; explorar vários cores) e com o gpuBLAST, realizada no nó com GPU (representativo de uma workstation típica), permite aferir qual a melhor opção no caso de não serem possíveis pesquisas em cluster; as observações realizadas indicam que não há diferenças significativas entre o BLAST e o BLAST+; adicionalmente, o desempenho do gpuBLAST foi sempre pior (aproximadmente em 50%) que o do BLAST e BLAST+, o que pode encontrar explicação na longevidade do modelo da GPU usada; - finalmente, a comparação da melhor opção no nosso cenário de teste, representada pelo uso do mpiBLAST, com o recurso a pesquisa online, no site do BLAST5, revela que o mpiBLAST apresenta um desempenho bastante competitivo com o BLAST online, chegando a ser claramente superior se se considerarem os tempos do mpiBLAST tirando partido de efeitos de cache; esta assunção acaba por se justa, Já que BLAST online também rentabiliza o mesmo tipo de efeitos; no entanto, com tempos de pequisa tão reduzidos (< 30s), só é defensável a utilização do mpiBLAST numa infra-estrutura local se o objetivo for a pesquisa de Bds não pesquisáveis via BLAS+ online.

Palveluiden konsolidointi Vmware ESX -järjestelmään

Tässä insinöörityössä vertaillaan fyysisten koneiden konsolidointitekniikoita ja perehtyy tarkemmin Vmware ESX Server 2.5 -arkkitehtuuriin. Konsolidointimenetelmistä käsitellään: palveluiden keskittäminen, fyysinen konsolidointi, tietojen integrointi sekä sovellusten integrointi. Virtuaalijärjestelmistä vertailtiin markkinoiden yleisimmin käytössä olevat tuotteet. Vertailuun otettiin Vmwaren ESX sekä Server -tuote. Vastaavasti Microsoftilta valittiin tuote Virtual Server 2005. Projektissa toteutettiin Vmware ESX 2.5 -järjestelmän asennus sekä konfigurointi. Järjestelmään luotiin standardi virtuaalikoneita varten sekä määriteltiin Golden master -levykuva. Varsinaisessa konsolidointiosuudessa toteutettiin fyysisten laitteiden keskittämistä ja virtualisointia. Kohteena oli NT4-toimialue, tiedosto, tulostus, Exchange Outlook Web Access, Exchange 5.5 -tietokanta sekä SMTP -palvelimen siirto VMware ESX -järjestelmään. Työn lopputuloksean saavutettiin toimiva virtuaali-infrastruktuuri, johon voidaan tarvittaessa helposti luoda virtuaalikoneita.

VMWare e tecniche di virtualizzazione: un caso di studio

Il lavoro svolto da Fabrizio Amici ha suscitato immediatamente il mio interesse in primo luogo perché quando si parla di virtualizzazione con vari fornitori e commerciali, questi la indicano come una soluzione che possa coprire a 360 gradi le esigenze di un Datacenter. Questo è vero nella misura in cui il progetto di virtualizzazione e consolidamento dei Server sia svolto sotto certi criteri progettuali. Per esperienza personale non ho trovato in letteratura lavori che potessero fornire indicazioni approfondite sui parametri da considerare per una corretta progettazione di sistemi di virtualizzazione, spesso ci si avvale di vari fornitori che accennano ad eventuali criticità. Un lavoro come quello proposto da Fabrizio va esattamente nella direzione di rispondere a quelle domande che nascono quando si affronta la tematica della virtualizzazione e soprattutto cerca di capire quali siano i limiti intrinseci della virtualizzazione. In particolare nei vari confronti che, con piacere, ho avuto con Fabrizio, il mio suggerimento è stato quello di esasperare il sistema che aveva assemblato, caricando i test sino ad osservarne i limiti. Dai vari test sono emerse sia conferme, sia inaspettati comportamenti del sistema che rendono ancora più chiaro che solo una prova sperimentale può essere il banco di prova di un sistema complesso. L'elemento che colpisce maggiormente analizzando i risultati è il diverso comportamento in funzione delle CPU utilizzate. I risultati indicano chiaramente che le prestazioni sono fortemente influenzate da come si distribuiscono i core nelle macchine virtuali. Dalla lettura dei risultati viene confermato che i sistemi virtualizzati devono essere progettati per non raggiungere il 70-80% della componente più critica (RAM, CPU) ma anche che sono fortemente sensibili alle disponibilità prestazionali dei sistemi al contorno (Rete, SAN/Dischi). L'approccio metodico sperimentale ed i risultati forniscono una serie di elementi che permettono di affrontare la tematica della virtualizzazione in un quadro generale più solido, offrendo fra l'altro spunti di ricerca ulteriori anche in previsione di nuove soluzioni che vari costruttori, sviluppatori e system integrator proporranno nei prossimi anni. Ing. Massimiliano Casali Esperto di Gestione ICT, Pubblica Amministrazione,Repubblica di San Marino

vMotion Migración en Caliente

Esta memoria nos introduce en el mundo de los servidores de máquinas virtuales procurando no saltarse ningún paso, de una forma gráfica y sin necesidad de conocimientos previos sobre virtualización. Es una guía para la instalación y configuración de un centro de datos con las siguientes tecnologías de virtualización de la compañía VMware: vCenter Server y vSphere ESXi; y el almacenamiento en red open-source FreeNAS. Este despliegue se usará para poner a prueba el funcionamiento de la tecnología vMotion. vMotion es una tecnología para migrar en caliente una máquina virtual de un servidor de máquinas virtuales a otro, de forma transparente y sin desconexiones. Esta tecnología, con la potencia de los procesadores y el ancho de banda actual, es casi inocua al rendimiento de la máquina virtual, lo cual permite su aplicación en una gran diversidad de sectores.

Estudo e planeamento de uma infraestrutura computacional

As tecnologias de informação representam um pilar fundamental nas organizações como sustento do negócio através de infraestruturas dedicadas sendo que com o evoluir do crescimento no centro de dados surgem desafios relativamente a escalabilidade, tolerância à falha, desempenho, alocação de recursos, segurança nos acessos, reposição de grandes quantidades de informação e eficiência energética. Com a adoção de tecnologias baseadas em cloud computing aplica-se um modelo de recursos partilhados de modo a consolidar a infraestrutura e endereçar os desafios anteriormente descritos. As tecnologias de virtualização têm como objetivo reduzir a infraestrutura levantando novas considerações ao nível das redes locais e de dados, segurança, backup e reposição da informação devido á dinâmica de um ambiente virtualizado. Em centros de dados esta abordagem pode representar um nível de consolidação elevado, permitindo reduzir servidores físicos, portas de rede, cablagem, armazenamento, espaço, energia e custo, assegurando os níveis de desempenho. Este trabalho permite definir uma estratégia de consolidação do centro de dados em estudo que permita a tolerância a falhas, provisionamento de novos serviços com tempo reduzido, escalabilidade para mais serviços, segurança nas redes Delimitarized Zone (DMZ), e backup e reposição de dados com impacto reduzido nos recursos, permitindo altos débitos e rácios de consolidação do armazenamento. A arquitetura proposta visa implementar a estratégia com tecnologias otimizadas para o cloud computing. Foi realizado um estudo tendo como base a análise de um centro de dados através da aplicação VMWare Capacity Planner que permitiu a análise do ambiente por um período de 8 meses com registo de métricas de acessos, utilizadas para dimensionar a arquitetura proposta. Na implementação da abordagem em cloud valida-se a redução de 85% de infraestrutura de servidores, a latência de comunicação, taxas de transferência de dados, latências de serviços, impacto de protocolos na transferência de dados, overhead da virtualização, migração de serviços na infraestrutura física, tempos de backup e restauro de informação e a segurança na DMZ.

Framework para a construção de “portais de negócio” para gestão de solicitações de consumidores IaaS na HP Cloud

Dissertação para obtenção do Grau de Mestre em Engenharia Informática

An efficient use of virtualization in grid/cloud environments

Grid is a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to high-end computational resources. Grid enables access to the resources but it does not guarantee any quality of service. Moreover, Grid does not provide performance isolation; job of one user can influence the performance of other user’s job. The other problem with Grid is that the users of Grid belong to scientific community and the jobs require specific and customized software environment. Providing the perfect environment to the user is very difficult in Grid for its dispersed and heterogeneous nature. Though, Cloud computing provide full customization and control, but there is no simple procedure available to submit user jobs as in Grid. The Grid computing can provide customized resources and performance to the user using virtualization. A virtual machine can join the Grid as an execution node. The virtual machine can also be submitted as a job with user jobs inside. Where the first method gives quality of service and performance isolation, the second method also provides customization and administration in addition. In this thesis, a solution is proposed to enable virtual machine reuse which will provide performance isolation with customization and administration. The same virtual machine can be used for several jobs. In the proposed solution customized virtual machines join the Grid pool on user request. Proposed solution describes two scenarios to achieve this goal. In first scenario, user submits their customized virtual machine as a job. The virtual machine joins the Grid pool when it is powered on. In the second scenario, user customized virtual machines are preconfigured in the execution system. These virtual machines join the Grid pool on user request. Condor and VMware server is used to deploy and test the scenarios. Condor supports virtual machine jobs. The scenario 1 is deployed using Condor VM universe. The second scenario uses VMware-VIX API for scripting powering on and powering off of the remote virtual machines. The experimental results shows that as scenario 2 does not need to transfer the virtual machine image, the virtual machine image becomes live on pool more faster. In scenario 1, the virtual machine runs as a condor job, so it easy to administrate the virtual machine. The only pitfall in scenario 1 is the network traffic.

Anàlisi de solucions de virtualització

El projecte té com a finalitat avaluar alguns dels productes de virtualització disponibles al mercat per diferents plataformes i amb diferents perspectives d'aquesta tecnologia. L'objectiu és esbrinar quins són els més adequats en segons quins entorns, quins donen un millor rendiment, quins són els que aporten més funcionalitats i, finalment, quins són els més fàcils d'implantar i administrar.

Virtuaalikoneiden hallinta ohjelmointirajapintaa käyttäen

Työssä tutustutaan VMwaren Vix- ja VmCOM-rajapintoihin sekä luodaan ohjelmia, joilla käyttäjä voi hallita VMware Server -ohjelmaa rajapintojen avulla. Vix-rajapinnan avulla luodaan C++-kielellä komentoliittymä-ohjelma, joka on suorassa yhteydessä VMware Server -ohjelmaan. Työssä luodaan palvelin joka käyttää yhteydenhallintaan käyttäjän ja palvelimen välillä TCP-teknologiaa. Palvelin keskustelee VMware Serverin kanssa käyttäen VmCOM-rajapintaa. Windows käyttöjärjestelmälle luodaan Client-ohjelma. Ohjelmasta luodaan suoraan VMware Serveriin yhteydessä oleva versio sekä palvelinpohjainen versio. ASP.NET:lla luodaan dynaamiset web-sivut, joka käyttää myös yhteydenhallintaa palvelinta. Dynaamisten web-sivujen avulla voidaan myös muokata SQL Serverillä olevia käyttäjien tietotauluja. Windows-ohjelmat, dynaamiset web-sivut sekä TCP-palvelin on kirjoitettu C#-ohjelmointikielellä.

Sistemes de virtualització en els centres educatius

El present document tracta de presentar una alternativa de programari lliure a l'eina de virtualització VMware. Concretament proposa l'ús de Proxmox (KVM) com a eina de control d'un entorn virtual en els centres educatius.

Virtualització de servidors i escriptoris

Aquest treball explica com una pime passa d'un entorn de servidors majoritàriament físic a un entorn virtual aprofitant la necessitat d'actualitzar la infraestructura. La plataforma de virtualització utilitzada serà VMware tant per a servidors com per a escriptoris.

Despliegue masivo de escritorios virtuales

El proyecto consiste en el despliegue de un sistema de escritorios virtuales (UDI) para 300. Se trata de un caso real que se ha implantado en una empresa y se han conseguido los objetivos deseados. En el proyecto abordamos temas de storage, virtualización (VMware), diseño de infraestructura, uso de Thinclients y Green IT.

The assessment of benchmarks executed on bare-metal and using para-virtualization

A full assessment of para-­virtualization is important, because without knowledge about the various overheads, users can not understand whether using virtualization is a good idea or not. In this paper we are very interested in assessing the overheads of running various benchmarks on bare-­‐metal, as well as on para-­‐virtualization. The idea is to see what the overheads of para-­‐ virtualization are, as well as looking at the overheads of turning on monitoring and logging. The knowledge from assessing various benchmarks on these different systems will help a range of users understand the use of virtualization systems. In this paper we assess the overheads of using Xen, VMware, KVM and Citrix, see Table 1. These different virtualization systems are used extensively by cloud-­‐users. We are using various Netlib1 benchmarks, which have been developed by the University of Tennessee at Knoxville (UTK), and Oak Ridge National Laboratory (ORNL). In order to assess these virtualization systems, we run the benchmarks on bare-­‐metal, then on the para-­‐virtualization, and finally we turn on monitoring and logging. The later is important as users are interested in Service Level Agreements (SLAs) used by the Cloud providers, and the use of logging is a means of assessing the services bought and used from commercial providers. In this paper we assess the virtualization systems on three different systems. We use the Thamesblue supercomputer, the Hactar cluster and IBM JS20 blade server (see Table 2), which are all servers available at the University of Reading. A functional virtualization system is multi-­‐layered and is driven by the privileged components. Virtualization systems can host multiple guest operating systems, which run on its own domain, and the system schedules virtual CPUs and memory within each Virtual Machines (VM) to make the best use of the available resources. The guest-­‐operating system schedules each application accordingly. You can deploy virtualization as full virtualization or para-­‐virtualization. Full virtualization provides a total abstraction of the underlying physical system and creates a new virtual system, where the guest operating systems can run. No modifications are needed in the guest OS or application, e.g. the guest OS or application is not aware of the virtualized environment and runs normally. Para-­‐virualization requires user modification of the guest operating systems, which runs on the virtual machines, e.g. these guest operating systems are aware that they are running on a virtual machine, and provide near-­‐native performance. You can deploy both para-­‐virtualization and full virtualization across various virtualized systems. Para-­‐virtualization is an OS-­‐assisted virtualization; where some modifications are made in the guest operating system to enable better performance. In this kind of virtualization, the guest operating system is aware of the fact that it is running on the virtualized hardware and not on the bare hardware. In para-­‐virtualization, the device drivers in the guest operating system coordinate the device drivers of host operating system and reduce the performance overheads. The use of para-­‐virtualization [0] is intended to avoid the bottleneck associated with slow hardware interrupts that exist when full virtualization is employed. It has revealed [0] that para-­‐ virtualization does not impose significant performance overhead in high performance computing, and this in turn this has implications for the use of cloud computing for hosting HPC applications. The “apparent” improvement in virtualization has led us to formulate the hypothesis that certain classes of HPC applications should be able to execute in a cloud environment, with minimal performance degradation. In order to support this hypothesis, first it is necessary to define exactly what is meant by a “class” of application, and secondly it will be necessary to observe application performance, both within a virtual machine and when executing on bare hardware. A further potential complication is associated with the need for Cloud service providers to support Service Level Agreements (SLA), so that system utilisation can be audited.