Performance analysis of secure unified communications in the VMware-based cloud

Unified communications as a service (UCaaS) can be regarded as a cost-effective model for on-demand delivery of unified communications services in the cloud. However, addressing security concerns has been seen as the biggest challenge to the adoption of IT services in the cloud. This study set up a cloud system via VMware suite to emulate hosting unified communications (UC), the integration of two or more real time communication systems, services in the cloud in a laboratory environment. An Internet Protocol Security (IPSec) gateway was also set up to support network-level security for UCaaS against possible security exposures. This study was aimed at analysis of an implementation of UCaaS over IPSec and evaluation of the latency of encrypted UC traffic while protecting that traffic. Our test results show no latency while IPSec is implemented with a G.711 audio codec. However, the performance of the G.722 audio codec with an IPSec implementation affects the overall performance of the UC server. These results give technical advice and guidance to those involved in security controls in UC security on premises as well as in the cloud.

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

Resource usage monitoring for KVM based virtual machines

Realization of cloud computing has been possible due to availability of virtualization technologies on commodity platforms. Measuring resource usage on the virtualized servers is difficult because of the fact that the performance counters used for resource accounting are not virtualized. Hence, many of the prevalent virtualization technologies like Xen, VMware, KVM etc., use host specific CPU usage monitoring, which is coarse grained. In this paper, we present a performance monitoring tool for KVM based virtualized machines, which measures the CPU overhead incurred by the hypervisor on behalf of the virtual machine along-with the CPU usage of virtual machine itself. This fine-grained resource usage information, provided by the above tool, can be used for diverse situations like resource provisioning to support performance associated QoS requirements, identification of bottlenecks during VM placements, resource profiling of applications in cloud environments, etc. We demonstrate a use case of this tool by measuring the performance of web-servers hosted on a KVM based virtualized server.

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.

Trust ticket deployment : a notion of a data owner's trust in cloud computing

While cloud computing (CC) is a scalable model of shared infrastructure and on-demand computing, it lacks a transparent trust and security mechanism. A data owner (DO) loses control over the data outsourced to a machine in the cloud controlled and operated by a cloud service provider (CSP). This machine is at a location unknown to a data owner. This loss of control over data is further intensified with the lack of managing users' access to the data from practical cloud computing perspectives. In this paper, we introduce a new mechanism of ensuring trust and security in Software as a Service (SaaS) CC. Trust Ticket, with the supporting protocols, is our mechanism that helps a data owner in establishing a link between a CSP and a registered user. In our mechanism, a user first gets registered with a DO before receiving a Trust Ticket and a secret key from that DO. Each Trust Ticket is unique and encrypted. On completing the registration of each user, the DO apprises the CSP of the Trust Ticket. Trust Ticket and secret key are respectively for the registered user's getting accepted to the CSP and having a view of the data owner's data upon a successful verification by the CSP. We have done our experiment in Java network programming by creating an emulated cloud computing framework under the VMware ESXi 4.1 hyper visor based platform. Using the framework, we have evaluated our algorithmic protocol for Trust Ticket. We have also compared our work with prior work. Overall performance of our work is better. We argue that our proposed algorithmic protocol for Trust Ticket deployment establishes a data owner's trust. This trust is established through a data owner's control over data and a registered user, because a registered user is linked with a CSP by a data owner through Trust Ticket.

Evoluzione tecnologica in ambito End User Computing: un caso d'uso basato su Horizon Workspace Portal

L'obbiettivo del progetto di cui tratta questa tesi è costituire un ambiente intuitivo e facilmente utilizzabile dall'utente finale che permetta di accedere sia alle applicazioni aziendali sia ai desktop virtuali da qualsiasi dispositivo effettui l'accesso. Grazie alle recenti tecnologie di End User Computing messe a disposizione da VMware è possibile virtualizzare qualsiasi applicazione Windows e renderla disponibile tramite Internet a qualsiasi utente la richieda, indifferentemente dal sistema operativo o dal luogo in cui si trova. Il progetto descritto nella tesi spiega come implementare tale ambiente tramite il prodotto Horizon Workspace Portal integrato nella suite Horizon 6.

Diseño e implementación de una solución de VoIP en un entorno empresarial

El desarrollo de las redes IP ha marcado un creciente interés por unificar todas las comunicaciones sobre una misma infraestructura aprovechando así el cableado existente. Con esta idea nació la tecnología conocida como VoIP (Voice Over Internet Protocol) que consiste en la trasmisión de la voz sobre paquetes IP. El objetivo principal de este proyecto es el diseño e implementación de una infraestructura de voz sobre IP que utilice una red de datos existente. La primera parte del proyecto estará formada por un estudio detallado de los factores que influyen en esta tecnología: codecs, protocolos y otros factores a tener en cuenta. Tras esta parte, aprovechando la experiencia adquirida durante casi tres años en una empresa integradora de servicios, se realizará un caso de estudio en el que, bajo las premisas impuestas por un supuesto cliente, se diseñará una solución que cumpla todos los requisitos y aporte un valor añadido sobre el sistema de telefonía que posee el cliente. El diseño de la mejor solución se hará utilizando productos del fabricante Cisco Systems y, además del coste económico, se valorarán los esfuerzos personales que costará montar dicha solución, incluyendo un valor añadido como es el dotar de buzón de voz y mensajería a todos los usuarios. La última parte del caso de estudio consistirá en la implementación de la infraestructura anteriormente diseñada adquiriendo conocimientos sobre virtualización de servidores utilizando productos de la compañía VMWare (especialista en virtualización), instalación y parametrización de aplicativos de Cisco y, finalmente, la interconexión con la red pública a través de gateways para poder hacer llamadas al exterior. El proyecto finalizará con la presentación de unas conclusiones finales y la exposición de unas líneas futuras de trabajo. ABSTRACT. The IP network development has marked a growing interest in unifying all communications over the same infrastructure taking advantage of the existing wiring. From this idea, a technology was born known as VoIP (Voice Over Internet Protocol) which consists of the transmission of voice packets over the IP network. The main goal of this project is the design and implementation of a VoIP infrastructure for transmitting voice packets over the existing wired network infrastructure on the client. The first part of the project will consist of a detailed study of the factors influencing this technology: codecs, protocols, and other factors to consider. After this part, drawing on the experience gained during nearly three years in an integrated services company, a case study will be made under the premises imposed for a supposed client. A solution that serves all the requirements will be designed and provide an added value on the customer’s telephone system. The design of the best solution will be done using Cisco Systems products and besides the economic cost of the whole solution, the personal effort cost will be valued. The added value named before will be provided with two important applications such as voice mail and instant messaging for all users. The last part of the case study will consist in the implementation of an infrastructure designed to acquire knowledge about virtualization, using VMWare company products (specialist in virtualization), installation and configuration of applications from Cisco Systems and finally the interconnection with the public network through gateway routers in order to make external calls. The project will end with the presentation of final conclusions and exposing future working lines.

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.

Estudo da efetividade dos mecanismos de compartilhamento de memória em hipervisores

The growing demand for large-scale virtualization environments, such as the ones used in cloud computing, has led to a need for efficient management of computing resources. RAM memory is the one of the most required resources in these environments, and is usually the main factor limiting the number of virtual machines that can run on the physical host. Recently, hypervisors have brought mechanisms for transparent memory sharing between virtual machines in order to reduce the total demand for system memory. These mechanisms “merge” similar pages detected in multiple virtual machines into the same physical memory, using a copy-on-write mechanism in a manner that is transparent to the guest systems. The objective of this study is to present an overview of these mechanisms and also evaluate their performance and effectiveness. The results of two popular hypervisors (VMware and KVM) using different guest operating systems (Linux and Windows) and different workloads (synthetic and real) are presented herein. The results show significant performance differences between hypervisors according to the guest system workloads and execution time.

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.

Execução "cruzada" de produtos / aplicações

O presente trabalho propõe-se estudar a execução "cruzada” de produtos/aplicações, particularmente de aplicações num sistema para o qual não foram concebidas. Em concreto, pretende-se analisar a execução de programas nativos do Windows em ambiente Linux e vice-versa. Na exploração desta tese foi seleccionado um conjunto representativo de diferentes aplicações, desde produtos genéricos como o Microsoft Office, soluções ERP (Enterprise Resource Planning) e software mais utilizado em ambientes académicos e científicos. Para a execução de aplicações-Windows no Linux utilizaram-se essencialmente dois tipos de ferramentas: a camada de tradução Wine (capaz de executar programas nativos do Windows) e máquinas virtuais, como a VirtualBox e VMWare Player. Para a componente inversa deste trabalho (a execução de aplicações Linux em Windows), fez-se uso essencialmente dessas mesmas máquinas virtuais contendo embora (tendo­lhes sido adicionadas) as distribuições Linux, o Ubuntu 10.04 e OpenSUSE 11.3. ABSTRACT: This work intent to examine the "crossed “execution of products / applications, particularly in an operative system for which such products and applications were not designed. More specially, the purpose of this work is to analyze the performance of native Windows programs under within Linux and vice versa. Throughout the development of this thesis we selected a representative set of different applications, from generic products such 88 Microsoft Office, ERP (Enterprise Resource Planning) and software mainly used in academic and scientific environments. For the execution of Windows applications in Linux, we used essentially two types of tools: the translation layer Wine (capable of running native Windows programs) and virtual machines, such 88 VirtualBox and VMWare Player. For the reverse case, running Linux applications in Windows, the main solution was the use of virtual machines, added with Linux distributions, Ubuntu 10.04 and OpenSUSE 11.3.