Selecionar segmento
Estude com questões de diferentes segmentos
Atenção: Isso limpará todos os campos já preenchidos no filtro!
Foram encontradas 18.462 questões
Resolva questões gratuitamente!
Junte-se a mais de 4 milhões de concurseiros!
Q484988
Algoritmos e Estrutura de Dados
João trabalha no setor de BI da empresa e recebeu a tarefa de identificar agrupamentos de alunos de uma escola segundo seu desempenho acadêmico. A partir das notas obtidas, João deve formar grupos tal que integrantes de um grupo tenham desempenho similar, e que integrantes de grupos distintos sejam dissimilares. O algoritmo mais apropriado para essa tarefa é:
Q484987
Banco de Dados
Os termos Business Intelligence (BI) e Big Data confundem-se em certos aspectos. Uma conhecida abordagem para identificação dos pontos críticos de cada paradigma é conhecida como 3V, e destaca:
Q484986
Banco de Dados
João escreveu os dois comandos SQL abaixo.
I.
select * from T where x>5
II.
select * from T where not x>5
Curiosamente, os dois comandos produziram resultados com zero linha. Intrigado, pois sabia que a instância de T não estava vazia, João escreveu outros dois comandos:
III.
select count(*) from T
IV.
select count(x) from T
Quando executados, os comandos III e IV, necessariamente, produziram resultados r1 e r2, tal que:
I.
select * from T where x>5
II.
select * from T where not x>5
Curiosamente, os dois comandos produziram resultados com zero linha. Intrigado, pois sabia que a instância de T não estava vazia, João escreveu outros dois comandos:
III.
select count(*) from T
IV.
select count(x) from T
Quando executados, os comandos III e IV, necessariamente, produziram resultados r1 e r2, tal que:
Q484985
Banco de Dados
ACID é uma conhecida sigla do jargão da área de banco de dados, e refere-se às propriedades que as transações executadas por um sistema gerenciador devem observar. A letra ”I” nessa sigla está associada ao algoritmo:
Q484984
Banco de Dados
Segundo a teoria de projeto relacional, um dos requisitos para determinar se um conjunto X de atributos pode ser utilizado como chave de uma tabela T é que a dependência funcional X→W seja verdadeira, onde W é o conjunto de atributos de T. Considere que para uma tabela S, com atributos R,N,M e C, as seguintes dependências funcionais se verifiquem:
M,R,N →C
C→M
É correto afirmar que, para S, o requisito acima mencionado é atendido apenas pelos conjuntos:
M,R,N →C
C→M
É correto afirmar que, para S, o requisito acima mencionado é atendido apenas pelos conjuntos:
Q484983
Banco de Dados
Tabelas do tipo partitioned, no Oracle, permitem que a locação dos registros seja feita por:
Q484982
Banco de Dados
No MySQL, o comando
create table teste
( numeracao int,
nota float not null
)
engine = myisam
select matricula,
disciplina,
nota as nota_antes
from inscricao
where nota is null
provoca a criação de uma tabela denominada teste contendo as colunas:
create table teste
( numeracao int,
nota float not null
)
engine = myisam
select matricula,
disciplina,
nota as nota_antes
from inscricao
where nota is null
provoca a criação de uma tabela denominada teste contendo as colunas:
Q484981
Banco de Dados
No Oracle, o uso da opção index organized table na criação de uma tabela relacional faz com que os registros dessa tabela:
Q484980
Banco de Dados
Considerando duas tabelas relacionais R e S, tal que haja uma chave primária definida para cada uma delas e que a instância de R contenha um número maior de registros que a instância de S, analise os comandos SQL a seguir.
I.
select *
from r full outer join s on r.a = s.a
II.
select *
from r left outer join s on r.a = s.a
union select *
from r right outer join s on r.a = s.a
Sabendo-se que as instâncias de R e S não são vazias, é correto concluir que:
I.
select *
from r full outer join s on r.a = s.a
II.
select *
from r left outer join s on r.a = s.a
union select *
from r right outer join s on r.a = s.a
Sabendo-se que as instâncias de R e S não são vazias, é correto concluir que:
Q484979
Engenharia de Software
João está preparando uma palestra sobre diagramas de classe da
UML, e criou um slide com a figura:
O título correto para esse slide deve ser “Relacionamento de":
O título correto para esse slide deve ser “Relacionamento de":
Q484978
Modelagem de Processos de Negócio (BPM)
Na construção de diagramas para modelagem de processos de negócios, sob o BPMN, retângulos com cantos arredondados representam:
Q484977
Gerência de Projetos
No PMBOK 3a Edição, os processos Quality Planning, Perform Quality Assurance e Perform Quality Control estão classificados, respectivamente, sob os grupos de processos denominados:
Q484976
Engenharia de Software
O SCRUM, processo para o desenvolvimento de software ágil, estrutura-se sobre:
Q484975
Banco de Dados
Sabendo-se que S é um objeto sequence num banco de dados Oracle, o comando que apresenta uma forma correta de referenciá-lo é:
Q483304
Inglês
Texto associado
Virtual network appliances: Benefits and drawbacks
There's lots of talk about network virtualization benefits, but are virtual network appliances all they're cracked up to be? Only in some scenarios.
Network virtualization benefits can be plentiful, but only in certain scenarios. Learn where virtual network appliances can work -- and where they can't.
If virtualization enables servers to be spun up and down on demand for cost efficiency and agility, wouldn't it make sense to implement virtual network components too? After all, virtual servers need to communicate inbound and outbound and still be firewall-protected and load balanced. That would seem to be best addressed by virtual network appliances that can be spun-up on demand, right? Only in some scenarios.
Many networking vendors have already begun to minimize development cost by using Intel-based platforms and commodity hardware. Examples of this range from the Cisco ASA firewall to F5 load balancers and Vyatta routers. The obvious next step for some of these vendors has been to offer their products in virtual appliance packaging. F5 took a small step forward with the Local Traffic Manager - Virtual Edition (LTM VE), while Vyatta claims to offer a full range of virtual appliance solutions. VMware was somewhat late to the game, but it also offers virtualized firewalls (vShield Zones and vShield App) and routers/load balancers (vShield Edge).
Virtual network appliances: What's the catch?
The problem is that unlike servers, networking appliances commonly perform I/O-intensive tasks, moving large amounts of data between network interfaces with minimal additional processing, relying heavily on dedicated hardware. All high-speed routing and packet forwarding, as well as encryption (both IPsec and SSL) and load balancing, rely on dedicated silicon. When a networking appliance is repackaged into a virtual machine format, the dedicated hardware is gone, and all these tasks must now be performed by the general- purpose CPU, sometimes resulting in extreme reduction in performance.
Implementing routers, switches or firewalls in a virtual appliance would just burn the CPU cycles that could be better used elsewhere -- unless, of course, you’ve over-provisioned your servers and have plenty of idle CPU cycles, in which case something has gone seriously wrong with your planning.
To make matters worse, the hypervisor software used in server virtualization solutions also virtualizes the network interfaces. That means that every I/O access path to virtualized hardware from the networking appliance results in a context switch to higher privilege software (the hypervisor), which uses numerous CPU cycles to decode what needs to be done and emulate the desired action. Also, data passed between virtual machines must be copied between their address spaces, adding further latency to the process.
There is some help in that the VMware hypervisor has the DVFilter API, which allows a loadable kernel module to inspect and modify network traffic either within the hypervisor (vNetwork Data Path Agent) or in combination with a virtual machine (vNetwork Control Path Agent). The loadable kernel module significantly reduces the VM context switching overhead.
Where virtual network appliances can work?
There are some use cases in which virtual network appliances make perfect sense. For instance, you could virtualize an appliance that performs lots of CPU-intensive processing with no reliance on dedicated hardware. Web application firewalls (WAFs) and complex load balancers are perfect examples (no wonder they’re commonly implemented as loadable modules in Apache Web servers or as Squid reverse proxy servers).
Also, if you’re planning to roll out multi-tenant cloud, the flexibility gained by treating networking appliances as click-to-deploy Lego bricks might more than justify the subpar performance. This is especially so if you charge your users by their actual VM/CPU usage, in which case you don’t really care how much CPU they’re using.
Virtualized networking also makes sense when firewall and routing functions are implemented as part of the virtual switch in each hypervisor. This could result in optimal traffic flow between virtual machines (regardless of whether they belong to the same IP subnet or not) and solve the problem of traffic trombones. Unfortunately, it seems that Cisco is still the only vendor that extends the VMware hypervisor switch using the Virtual Ethernet Module (VEM) functionality. While numerous security solutions already deploy the VMsafe APIs, the networking appliances I’ve seen so far (including the vShield Edge from VMware) rely on virtual machines to forward traffic between virtual (or physical) LANs.
Obviously the networking vendors have a very long way to go before reaching the true potential of virtualized networking.
Disponível em: http://searchnetworking.techtarget.com/tip/Virtual-network-appliances-Benefits-and- drawbacks
Search Networking - Tech Target - Texto de Ivan Pepelnjak (Março de 2011)
There's lots of talk about network virtualization benefits, but are virtual network appliances all they're cracked up to be? Only in some scenarios.
Network virtualization benefits can be plentiful, but only in certain scenarios. Learn where virtual network appliances can work -- and where they can't.
If virtualization enables servers to be spun up and down on demand for cost efficiency and agility, wouldn't it make sense to implement virtual network components too? After all, virtual servers need to communicate inbound and outbound and still be firewall-protected and load balanced. That would seem to be best addressed by virtual network appliances that can be spun-up on demand, right? Only in some scenarios.
Many networking vendors have already begun to minimize development cost by using Intel-based platforms and commodity hardware. Examples of this range from the Cisco ASA firewall to F5 load balancers and Vyatta routers. The obvious next step for some of these vendors has been to offer their products in virtual appliance packaging. F5 took a small step forward with the Local Traffic Manager - Virtual Edition (LTM VE), while Vyatta claims to offer a full range of virtual appliance solutions. VMware was somewhat late to the game, but it also offers virtualized firewalls (vShield Zones and vShield App) and routers/load balancers (vShield Edge).
Virtual network appliances: What's the catch?
The problem is that unlike servers, networking appliances commonly perform I/O-intensive tasks, moving large amounts of data between network interfaces with minimal additional processing, relying heavily on dedicated hardware. All high-speed routing and packet forwarding, as well as encryption (both IPsec and SSL) and load balancing, rely on dedicated silicon. When a networking appliance is repackaged into a virtual machine format, the dedicated hardware is gone, and all these tasks must now be performed by the general- purpose CPU, sometimes resulting in extreme reduction in performance.
Implementing routers, switches or firewalls in a virtual appliance would just burn the CPU cycles that could be better used elsewhere -- unless, of course, you’ve over-provisioned your servers and have plenty of idle CPU cycles, in which case something has gone seriously wrong with your planning.
To make matters worse, the hypervisor software used in server virtualization solutions also virtualizes the network interfaces. That means that every I/O access path to virtualized hardware from the networking appliance results in a context switch to higher privilege software (the hypervisor), which uses numerous CPU cycles to decode what needs to be done and emulate the desired action. Also, data passed between virtual machines must be copied between their address spaces, adding further latency to the process.
There is some help in that the VMware hypervisor has the DVFilter API, which allows a loadable kernel module to inspect and modify network traffic either within the hypervisor (vNetwork Data Path Agent) or in combination with a virtual machine (vNetwork Control Path Agent). The loadable kernel module significantly reduces the VM context switching overhead.
Where virtual network appliances can work?
There are some use cases in which virtual network appliances make perfect sense. For instance, you could virtualize an appliance that performs lots of CPU-intensive processing with no reliance on dedicated hardware. Web application firewalls (WAFs) and complex load balancers are perfect examples (no wonder they’re commonly implemented as loadable modules in Apache Web servers or as Squid reverse proxy servers).
Also, if you’re planning to roll out multi-tenant cloud, the flexibility gained by treating networking appliances as click-to-deploy Lego bricks might more than justify the subpar performance. This is especially so if you charge your users by their actual VM/CPU usage, in which case you don’t really care how much CPU they’re using.
Virtualized networking also makes sense when firewall and routing functions are implemented as part of the virtual switch in each hypervisor. This could result in optimal traffic flow between virtual machines (regardless of whether they belong to the same IP subnet or not) and solve the problem of traffic trombones. Unfortunately, it seems that Cisco is still the only vendor that extends the VMware hypervisor switch using the Virtual Ethernet Module (VEM) functionality. While numerous security solutions already deploy the VMsafe APIs, the networking appliances I’ve seen so far (including the vShield Edge from VMware) rely on virtual machines to forward traffic between virtual (or physical) LANs.
Obviously the networking vendors have a very long way to go before reaching the true potential of virtualized networking.
Disponível em: http://searchnetworking.techtarget.com/tip/Virtual-network-appliances-Benefits-and- drawbacks
Search Networking - Tech Target - Texto de Ivan Pepelnjak (Março de 2011)
O texto II faz um comentário sobre o uso de appliances de rede virtuais em “multi-tenant cloud”. Com base nesse comentário, é possível concluir que:
Q483303
Inglês
Texto associado
Virtual network appliances: Benefits and drawbacks
There's lots of talk about network virtualization benefits, but are virtual network appliances all they're cracked up to be? Only in some scenarios.
Network virtualization benefits can be plentiful, but only in certain scenarios. Learn where virtual network appliances can work -- and where they can't.
If virtualization enables servers to be spun up and down on demand for cost efficiency and agility, wouldn't it make sense to implement virtual network components too? After all, virtual servers need to communicate inbound and outbound and still be firewall-protected and load balanced. That would seem to be best addressed by virtual network appliances that can be spun-up on demand, right? Only in some scenarios.
Many networking vendors have already begun to minimize development cost by using Intel-based platforms and commodity hardware. Examples of this range from the Cisco ASA firewall to F5 load balancers and Vyatta routers. The obvious next step for some of these vendors has been to offer their products in virtual appliance packaging. F5 took a small step forward with the Local Traffic Manager - Virtual Edition (LTM VE), while Vyatta claims to offer a full range of virtual appliance solutions. VMware was somewhat late to the game, but it also offers virtualized firewalls (vShield Zones and vShield App) and routers/load balancers (vShield Edge).
Virtual network appliances: What's the catch?
The problem is that unlike servers, networking appliances commonly perform I/O-intensive tasks, moving large amounts of data between network interfaces with minimal additional processing, relying heavily on dedicated hardware. All high-speed routing and packet forwarding, as well as encryption (both IPsec and SSL) and load balancing, rely on dedicated silicon. When a networking appliance is repackaged into a virtual machine format, the dedicated hardware is gone, and all these tasks must now be performed by the general- purpose CPU, sometimes resulting in extreme reduction in performance.
Implementing routers, switches or firewalls in a virtual appliance would just burn the CPU cycles that could be better used elsewhere -- unless, of course, you’ve over-provisioned your servers and have plenty of idle CPU cycles, in which case something has gone seriously wrong with your planning.
To make matters worse, the hypervisor software used in server virtualization solutions also virtualizes the network interfaces. That means that every I/O access path to virtualized hardware from the networking appliance results in a context switch to higher privilege software (the hypervisor), which uses numerous CPU cycles to decode what needs to be done and emulate the desired action. Also, data passed between virtual machines must be copied between their address spaces, adding further latency to the process.
There is some help in that the VMware hypervisor has the DVFilter API, which allows a loadable kernel module to inspect and modify network traffic either within the hypervisor (vNetwork Data Path Agent) or in combination with a virtual machine (vNetwork Control Path Agent). The loadable kernel module significantly reduces the VM context switching overhead.
Where virtual network appliances can work?
There are some use cases in which virtual network appliances make perfect sense. For instance, you could virtualize an appliance that performs lots of CPU-intensive processing with no reliance on dedicated hardware. Web application firewalls (WAFs) and complex load balancers are perfect examples (no wonder they’re commonly implemented as loadable modules in Apache Web servers or as Squid reverse proxy servers).
Also, if you’re planning to roll out multi-tenant cloud, the flexibility gained by treating networking appliances as click-to-deploy Lego bricks might more than justify the subpar performance. This is especially so if you charge your users by their actual VM/CPU usage, in which case you don’t really care how much CPU they’re using.
Virtualized networking also makes sense when firewall and routing functions are implemented as part of the virtual switch in each hypervisor. This could result in optimal traffic flow between virtual machines (regardless of whether they belong to the same IP subnet or not) and solve the problem of traffic trombones. Unfortunately, it seems that Cisco is still the only vendor that extends the VMware hypervisor switch using the Virtual Ethernet Module (VEM) functionality. While numerous security solutions already deploy the VMsafe APIs, the networking appliances I’ve seen so far (including the vShield Edge from VMware) rely on virtual machines to forward traffic between virtual (or physical) LANs.
Obviously the networking vendors have a very long way to go before reaching the true potential of virtualized networking.
Disponível em: http://searchnetworking.techtarget.com/tip/Virtual-network-appliances-Benefits-and- drawbacks
Search Networking - Tech Target - Texto de Ivan Pepelnjak (Março de 2011)
There's lots of talk about network virtualization benefits, but are virtual network appliances all they're cracked up to be? Only in some scenarios.
Network virtualization benefits can be plentiful, but only in certain scenarios. Learn where virtual network appliances can work -- and where they can't.
If virtualization enables servers to be spun up and down on demand for cost efficiency and agility, wouldn't it make sense to implement virtual network components too? After all, virtual servers need to communicate inbound and outbound and still be firewall-protected and load balanced. That would seem to be best addressed by virtual network appliances that can be spun-up on demand, right? Only in some scenarios.
Many networking vendors have already begun to minimize development cost by using Intel-based platforms and commodity hardware. Examples of this range from the Cisco ASA firewall to F5 load balancers and Vyatta routers. The obvious next step for some of these vendors has been to offer their products in virtual appliance packaging. F5 took a small step forward with the Local Traffic Manager - Virtual Edition (LTM VE), while Vyatta claims to offer a full range of virtual appliance solutions. VMware was somewhat late to the game, but it also offers virtualized firewalls (vShield Zones and vShield App) and routers/load balancers (vShield Edge).
Virtual network appliances: What's the catch?
The problem is that unlike servers, networking appliances commonly perform I/O-intensive tasks, moving large amounts of data between network interfaces with minimal additional processing, relying heavily on dedicated hardware. All high-speed routing and packet forwarding, as well as encryption (both IPsec and SSL) and load balancing, rely on dedicated silicon. When a networking appliance is repackaged into a virtual machine format, the dedicated hardware is gone, and all these tasks must now be performed by the general- purpose CPU, sometimes resulting in extreme reduction in performance.
Implementing routers, switches or firewalls in a virtual appliance would just burn the CPU cycles that could be better used elsewhere -- unless, of course, you’ve over-provisioned your servers and have plenty of idle CPU cycles, in which case something has gone seriously wrong with your planning.
To make matters worse, the hypervisor software used in server virtualization solutions also virtualizes the network interfaces. That means that every I/O access path to virtualized hardware from the networking appliance results in a context switch to higher privilege software (the hypervisor), which uses numerous CPU cycles to decode what needs to be done and emulate the desired action. Also, data passed between virtual machines must be copied between their address spaces, adding further latency to the process.
There is some help in that the VMware hypervisor has the DVFilter API, which allows a loadable kernel module to inspect and modify network traffic either within the hypervisor (vNetwork Data Path Agent) or in combination with a virtual machine (vNetwork Control Path Agent). The loadable kernel module significantly reduces the VM context switching overhead.
Where virtual network appliances can work?
There are some use cases in which virtual network appliances make perfect sense. For instance, you could virtualize an appliance that performs lots of CPU-intensive processing with no reliance on dedicated hardware. Web application firewalls (WAFs) and complex load balancers are perfect examples (no wonder they’re commonly implemented as loadable modules in Apache Web servers or as Squid reverse proxy servers).
Also, if you’re planning to roll out multi-tenant cloud, the flexibility gained by treating networking appliances as click-to-deploy Lego bricks might more than justify the subpar performance. This is especially so if you charge your users by their actual VM/CPU usage, in which case you don’t really care how much CPU they’re using.
Virtualized networking also makes sense when firewall and routing functions are implemented as part of the virtual switch in each hypervisor. This could result in optimal traffic flow between virtual machines (regardless of whether they belong to the same IP subnet or not) and solve the problem of traffic trombones. Unfortunately, it seems that Cisco is still the only vendor that extends the VMware hypervisor switch using the Virtual Ethernet Module (VEM) functionality. While numerous security solutions already deploy the VMsafe APIs, the networking appliances I’ve seen so far (including the vShield Edge from VMware) rely on virtual machines to forward traffic between virtual (or physical) LANs.
Obviously the networking vendors have a very long way to go before reaching the true potential of virtualized networking.
Disponível em: http://searchnetworking.techtarget.com/tip/Virtual-network-appliances-Benefits-and- drawbacks
Search Networking - Tech Target - Texto de Ivan Pepelnjak (Março de 2011)
O texto apresenta vantagem do uso de plataforma baseada em intel para dispositivos de rede. A vantagem e o próximo passo adotado pelas empresas são, respectivamente:
Q483302
Inglês
Texto associado
Virtual network appliances: Benefits and drawbacks
There's lots of talk about network virtualization benefits, but are virtual network appliances all they're cracked up to be? Only in some scenarios.
Network virtualization benefits can be plentiful, but only in certain scenarios. Learn where virtual network appliances can work -- and where they can't.
If virtualization enables servers to be spun up and down on demand for cost efficiency and agility, wouldn't it make sense to implement virtual network components too? After all, virtual servers need to communicate inbound and outbound and still be firewall-protected and load balanced. That would seem to be best addressed by virtual network appliances that can be spun-up on demand, right? Only in some scenarios.
Many networking vendors have already begun to minimize development cost by using Intel-based platforms and commodity hardware. Examples of this range from the Cisco ASA firewall to F5 load balancers and Vyatta routers. The obvious next step for some of these vendors has been to offer their products in virtual appliance packaging. F5 took a small step forward with the Local Traffic Manager - Virtual Edition (LTM VE), while Vyatta claims to offer a full range of virtual appliance solutions. VMware was somewhat late to the game, but it also offers virtualized firewalls (vShield Zones and vShield App) and routers/load balancers (vShield Edge).
Virtual network appliances: What's the catch?
The problem is that unlike servers, networking appliances commonly perform I/O-intensive tasks, moving large amounts of data between network interfaces with minimal additional processing, relying heavily on dedicated hardware. All high-speed routing and packet forwarding, as well as encryption (both IPsec and SSL) and load balancing, rely on dedicated silicon. When a networking appliance is repackaged into a virtual machine format, the dedicated hardware is gone, and all these tasks must now be performed by the general- purpose CPU, sometimes resulting in extreme reduction in performance.
Implementing routers, switches or firewalls in a virtual appliance would just burn the CPU cycles that could be better used elsewhere -- unless, of course, you’ve over-provisioned your servers and have plenty of idle CPU cycles, in which case something has gone seriously wrong with your planning.
To make matters worse, the hypervisor software used in server virtualization solutions also virtualizes the network interfaces. That means that every I/O access path to virtualized hardware from the networking appliance results in a context switch to higher privilege software (the hypervisor), which uses numerous CPU cycles to decode what needs to be done and emulate the desired action. Also, data passed between virtual machines must be copied between their address spaces, adding further latency to the process.
There is some help in that the VMware hypervisor has the DVFilter API, which allows a loadable kernel module to inspect and modify network traffic either within the hypervisor (vNetwork Data Path Agent) or in combination with a virtual machine (vNetwork Control Path Agent). The loadable kernel module significantly reduces the VM context switching overhead.
Where virtual network appliances can work?
There are some use cases in which virtual network appliances make perfect sense. For instance, you could virtualize an appliance that performs lots of CPU-intensive processing with no reliance on dedicated hardware. Web application firewalls (WAFs) and complex load balancers are perfect examples (no wonder they’re commonly implemented as loadable modules in Apache Web servers or as Squid reverse proxy servers).
Also, if you’re planning to roll out multi-tenant cloud, the flexibility gained by treating networking appliances as click-to-deploy Lego bricks might more than justify the subpar performance. This is especially so if you charge your users by their actual VM/CPU usage, in which case you don’t really care how much CPU they’re using.
Virtualized networking also makes sense when firewall and routing functions are implemented as part of the virtual switch in each hypervisor. This could result in optimal traffic flow between virtual machines (regardless of whether they belong to the same IP subnet or not) and solve the problem of traffic trombones. Unfortunately, it seems that Cisco is still the only vendor that extends the VMware hypervisor switch using the Virtual Ethernet Module (VEM) functionality. While numerous security solutions already deploy the VMsafe APIs, the networking appliances I’ve seen so far (including the vShield Edge from VMware) rely on virtual machines to forward traffic between virtual (or physical) LANs.
Obviously the networking vendors have a very long way to go before reaching the true potential of virtualized networking.
Disponível em: http://searchnetworking.techtarget.com/tip/Virtual-network-appliances-Benefits-and- drawbacks
Search Networking - Tech Target - Texto de Ivan Pepelnjak (Março de 2011)
There's lots of talk about network virtualization benefits, but are virtual network appliances all they're cracked up to be? Only in some scenarios.
Network virtualization benefits can be plentiful, but only in certain scenarios. Learn where virtual network appliances can work -- and where they can't.
If virtualization enables servers to be spun up and down on demand for cost efficiency and agility, wouldn't it make sense to implement virtual network components too? After all, virtual servers need to communicate inbound and outbound and still be firewall-protected and load balanced. That would seem to be best addressed by virtual network appliances that can be spun-up on demand, right? Only in some scenarios.
Many networking vendors have already begun to minimize development cost by using Intel-based platforms and commodity hardware. Examples of this range from the Cisco ASA firewall to F5 load balancers and Vyatta routers. The obvious next step for some of these vendors has been to offer their products in virtual appliance packaging. F5 took a small step forward with the Local Traffic Manager - Virtual Edition (LTM VE), while Vyatta claims to offer a full range of virtual appliance solutions. VMware was somewhat late to the game, but it also offers virtualized firewalls (vShield Zones and vShield App) and routers/load balancers (vShield Edge).
Virtual network appliances: What's the catch?
The problem is that unlike servers, networking appliances commonly perform I/O-intensive tasks, moving large amounts of data between network interfaces with minimal additional processing, relying heavily on dedicated hardware. All high-speed routing and packet forwarding, as well as encryption (both IPsec and SSL) and load balancing, rely on dedicated silicon. When a networking appliance is repackaged into a virtual machine format, the dedicated hardware is gone, and all these tasks must now be performed by the general- purpose CPU, sometimes resulting in extreme reduction in performance.
Implementing routers, switches or firewalls in a virtual appliance would just burn the CPU cycles that could be better used elsewhere -- unless, of course, you’ve over-provisioned your servers and have plenty of idle CPU cycles, in which case something has gone seriously wrong with your planning.
To make matters worse, the hypervisor software used in server virtualization solutions also virtualizes the network interfaces. That means that every I/O access path to virtualized hardware from the networking appliance results in a context switch to higher privilege software (the hypervisor), which uses numerous CPU cycles to decode what needs to be done and emulate the desired action. Also, data passed between virtual machines must be copied between their address spaces, adding further latency to the process.
There is some help in that the VMware hypervisor has the DVFilter API, which allows a loadable kernel module to inspect and modify network traffic either within the hypervisor (vNetwork Data Path Agent) or in combination with a virtual machine (vNetwork Control Path Agent). The loadable kernel module significantly reduces the VM context switching overhead.
Where virtual network appliances can work?
There are some use cases in which virtual network appliances make perfect sense. For instance, you could virtualize an appliance that performs lots of CPU-intensive processing with no reliance on dedicated hardware. Web application firewalls (WAFs) and complex load balancers are perfect examples (no wonder they’re commonly implemented as loadable modules in Apache Web servers or as Squid reverse proxy servers).
Also, if you’re planning to roll out multi-tenant cloud, the flexibility gained by treating networking appliances as click-to-deploy Lego bricks might more than justify the subpar performance. This is especially so if you charge your users by their actual VM/CPU usage, in which case you don’t really care how much CPU they’re using.
Virtualized networking also makes sense when firewall and routing functions are implemented as part of the virtual switch in each hypervisor. This could result in optimal traffic flow between virtual machines (regardless of whether they belong to the same IP subnet or not) and solve the problem of traffic trombones. Unfortunately, it seems that Cisco is still the only vendor that extends the VMware hypervisor switch using the Virtual Ethernet Module (VEM) functionality. While numerous security solutions already deploy the VMsafe APIs, the networking appliances I’ve seen so far (including the vShield Edge from VMware) rely on virtual machines to forward traffic between virtual (or physical) LANs.
Obviously the networking vendors have a very long way to go before reaching the true potential of virtualized networking.
Disponível em: http://searchnetworking.techtarget.com/tip/Virtual-network-appliances-Benefits-and- drawbacks
Search Networking - Tech Target - Texto de Ivan Pepelnjak (Março de 2011)
Existem requisitos de hardware ao virtualizar aplicações de aplicações de roteamento e encaminhamento de pacotes e encriptação.
O requisito de hardware necessário e o desempenho esperado das aplicações são, respectivamente:
O requisito de hardware necessário e o desempenho esperado das aplicações são, respectivamente:
Q483301
Redes de Computadores
Texto associado
Virtual network appliances: Benefits and drawbacks
There's lots of talk about network virtualization benefits, but are virtual network appliances all they're cracked up to be? Only in some scenarios.
Network virtualization benefits can be plentiful, but only in certain scenarios. Learn where virtual network appliances can work -- and where they can't.
If virtualization enables servers to be spun up and down on demand for cost efficiency and agility, wouldn't it make sense to implement virtual network components too? After all, virtual servers need to communicate inbound and outbound and still be firewall-protected and load balanced. That would seem to be best addressed by virtual network appliances that can be spun-up on demand, right? Only in some scenarios.
Many networking vendors have already begun to minimize development cost by using Intel-based platforms and commodity hardware. Examples of this range from the Cisco ASA firewall to F5 load balancers and Vyatta routers. The obvious next step for some of these vendors has been to offer their products in virtual appliance packaging. F5 took a small step forward with the Local Traffic Manager - Virtual Edition (LTM VE), while Vyatta claims to offer a full range of virtual appliance solutions. VMware was somewhat late to the game, but it also offers virtualized firewalls (vShield Zones and vShield App) and routers/load balancers (vShield Edge).
Virtual network appliances: What's the catch?
The problem is that unlike servers, networking appliances commonly perform I/O-intensive tasks, moving large amounts of data between network interfaces with minimal additional processing, relying heavily on dedicated hardware. All high-speed routing and packet forwarding, as well as encryption (both IPsec and SSL) and load balancing, rely on dedicated silicon. When a networking appliance is repackaged into a virtual machine format, the dedicated hardware is gone, and all these tasks must now be performed by the general- purpose CPU, sometimes resulting in extreme reduction in performance.
Implementing routers, switches or firewalls in a virtual appliance would just burn the CPU cycles that could be better used elsewhere -- unless, of course, you’ve over-provisioned your servers and have plenty of idle CPU cycles, in which case something has gone seriously wrong with your planning.
To make matters worse, the hypervisor software used in server virtualization solutions also virtualizes the network interfaces. That means that every I/O access path to virtualized hardware from the networking appliance results in a context switch to higher privilege software (the hypervisor), which uses numerous CPU cycles to decode what needs to be done and emulate the desired action. Also, data passed between virtual machines must be copied between their address spaces, adding further latency to the process.
There is some help in that the VMware hypervisor has the DVFilter API, which allows a loadable kernel module to inspect and modify network traffic either within the hypervisor (vNetwork Data Path Agent) or in combination with a virtual machine (vNetwork Control Path Agent). The loadable kernel module significantly reduces the VM context switching overhead.
Where virtual network appliances can work?
There are some use cases in which virtual network appliances make perfect sense. For instance, you could virtualize an appliance that performs lots of CPU-intensive processing with no reliance on dedicated hardware. Web application firewalls (WAFs) and complex load balancers are perfect examples (no wonder they’re commonly implemented as loadable modules in Apache Web servers or as Squid reverse proxy servers).
Also, if you’re planning to roll out multi-tenant cloud, the flexibility gained by treating networking appliances as click-to-deploy Lego bricks might more than justify the subpar performance. This is especially so if you charge your users by their actual VM/CPU usage, in which case you don’t really care how much CPU they’re using.
Virtualized networking also makes sense when firewall and routing functions are implemented as part of the virtual switch in each hypervisor. This could result in optimal traffic flow between virtual machines (regardless of whether they belong to the same IP subnet or not) and solve the problem of traffic trombones. Unfortunately, it seems that Cisco is still the only vendor that extends the VMware hypervisor switch using the Virtual Ethernet Module (VEM) functionality. While numerous security solutions already deploy the VMsafe APIs, the networking appliances I’ve seen so far (including the vShield Edge from VMware) rely on virtual machines to forward traffic between virtual (or physical) LANs.
Obviously the networking vendors have a very long way to go before reaching the true potential of virtualized networking.
Disponível em: http://searchnetworking.techtarget.com/tip/Virtual-network-appliances-Benefits-and- drawbacks
Search Networking - Tech Target - Texto de Ivan Pepelnjak (Março de 2011)
There's lots of talk about network virtualization benefits, but are virtual network appliances all they're cracked up to be? Only in some scenarios.
Network virtualization benefits can be plentiful, but only in certain scenarios. Learn where virtual network appliances can work -- and where they can't.
If virtualization enables servers to be spun up and down on demand for cost efficiency and agility, wouldn't it make sense to implement virtual network components too? After all, virtual servers need to communicate inbound and outbound and still be firewall-protected and load balanced. That would seem to be best addressed by virtual network appliances that can be spun-up on demand, right? Only in some scenarios.
Many networking vendors have already begun to minimize development cost by using Intel-based platforms and commodity hardware. Examples of this range from the Cisco ASA firewall to F5 load balancers and Vyatta routers. The obvious next step for some of these vendors has been to offer their products in virtual appliance packaging. F5 took a small step forward with the Local Traffic Manager - Virtual Edition (LTM VE), while Vyatta claims to offer a full range of virtual appliance solutions. VMware was somewhat late to the game, but it also offers virtualized firewalls (vShield Zones and vShield App) and routers/load balancers (vShield Edge).
Virtual network appliances: What's the catch?
The problem is that unlike servers, networking appliances commonly perform I/O-intensive tasks, moving large amounts of data between network interfaces with minimal additional processing, relying heavily on dedicated hardware. All high-speed routing and packet forwarding, as well as encryption (both IPsec and SSL) and load balancing, rely on dedicated silicon. When a networking appliance is repackaged into a virtual machine format, the dedicated hardware is gone, and all these tasks must now be performed by the general- purpose CPU, sometimes resulting in extreme reduction in performance.
Implementing routers, switches or firewalls in a virtual appliance would just burn the CPU cycles that could be better used elsewhere -- unless, of course, you’ve over-provisioned your servers and have plenty of idle CPU cycles, in which case something has gone seriously wrong with your planning.
To make matters worse, the hypervisor software used in server virtualization solutions also virtualizes the network interfaces. That means that every I/O access path to virtualized hardware from the networking appliance results in a context switch to higher privilege software (the hypervisor), which uses numerous CPU cycles to decode what needs to be done and emulate the desired action. Also, data passed between virtual machines must be copied between their address spaces, adding further latency to the process.
There is some help in that the VMware hypervisor has the DVFilter API, which allows a loadable kernel module to inspect and modify network traffic either within the hypervisor (vNetwork Data Path Agent) or in combination with a virtual machine (vNetwork Control Path Agent). The loadable kernel module significantly reduces the VM context switching overhead.
Where virtual network appliances can work?
There are some use cases in which virtual network appliances make perfect sense. For instance, you could virtualize an appliance that performs lots of CPU-intensive processing with no reliance on dedicated hardware. Web application firewalls (WAFs) and complex load balancers are perfect examples (no wonder they’re commonly implemented as loadable modules in Apache Web servers or as Squid reverse proxy servers).
Also, if you’re planning to roll out multi-tenant cloud, the flexibility gained by treating networking appliances as click-to-deploy Lego bricks might more than justify the subpar performance. This is especially so if you charge your users by their actual VM/CPU usage, in which case you don’t really care how much CPU they’re using.
Virtualized networking also makes sense when firewall and routing functions are implemented as part of the virtual switch in each hypervisor. This could result in optimal traffic flow between virtual machines (regardless of whether they belong to the same IP subnet or not) and solve the problem of traffic trombones. Unfortunately, it seems that Cisco is still the only vendor that extends the VMware hypervisor switch using the Virtual Ethernet Module (VEM) functionality. While numerous security solutions already deploy the VMsafe APIs, the networking appliances I’ve seen so far (including the vShield Edge from VMware) rely on virtual machines to forward traffic between virtual (or physical) LANs.
Obviously the networking vendors have a very long way to go before reaching the true potential of virtualized networking.
Disponível em: http://searchnetworking.techtarget.com/tip/Virtual-network-appliances-Benefits-and- drawbacks
Search Networking - Tech Target - Texto de Ivan Pepelnjak (Março de 2011)
Os exemplos de aplicações que fazem sentido com appliances de rede virtuais são:
Q483300
Sistemas Operacionais
Texto associado
Virtual network appliances: Benefits and drawbacks
There's lots of talk about network virtualization benefits, but are virtual network appliances all they're cracked up to be? Only in some scenarios.
Network virtualization benefits can be plentiful, but only in certain scenarios. Learn where virtual network appliances can work -- and where they can't.
If virtualization enables servers to be spun up and down on demand for cost efficiency and agility, wouldn't it make sense to implement virtual network components too? After all, virtual servers need to communicate inbound and outbound and still be firewall-protected and load balanced. That would seem to be best addressed by virtual network appliances that can be spun-up on demand, right? Only in some scenarios.
Many networking vendors have already begun to minimize development cost by using Intel-based platforms and commodity hardware. Examples of this range from the Cisco ASA firewall to F5 load balancers and Vyatta routers. The obvious next step for some of these vendors has been to offer their products in virtual appliance packaging. F5 took a small step forward with the Local Traffic Manager - Virtual Edition (LTM VE), while Vyatta claims to offer a full range of virtual appliance solutions. VMware was somewhat late to the game, but it also offers virtualized firewalls (vShield Zones and vShield App) and routers/load balancers (vShield Edge).
Virtual network appliances: What's the catch?
The problem is that unlike servers, networking appliances commonly perform I/O-intensive tasks, moving large amounts of data between network interfaces with minimal additional processing, relying heavily on dedicated hardware. All high-speed routing and packet forwarding, as well as encryption (both IPsec and SSL) and load balancing, rely on dedicated silicon. When a networking appliance is repackaged into a virtual machine format, the dedicated hardware is gone, and all these tasks must now be performed by the general- purpose CPU, sometimes resulting in extreme reduction in performance.
Implementing routers, switches or firewalls in a virtual appliance would just burn the CPU cycles that could be better used elsewhere -- unless, of course, you’ve over-provisioned your servers and have plenty of idle CPU cycles, in which case something has gone seriously wrong with your planning.
To make matters worse, the hypervisor software used in server virtualization solutions also virtualizes the network interfaces. That means that every I/O access path to virtualized hardware from the networking appliance results in a context switch to higher privilege software (the hypervisor), which uses numerous CPU cycles to decode what needs to be done and emulate the desired action. Also, data passed between virtual machines must be copied between their address spaces, adding further latency to the process.
There is some help in that the VMware hypervisor has the DVFilter API, which allows a loadable kernel module to inspect and modify network traffic either within the hypervisor (vNetwork Data Path Agent) or in combination with a virtual machine (vNetwork Control Path Agent). The loadable kernel module significantly reduces the VM context switching overhead.
Where virtual network appliances can work?
There are some use cases in which virtual network appliances make perfect sense. For instance, you could virtualize an appliance that performs lots of CPU-intensive processing with no reliance on dedicated hardware. Web application firewalls (WAFs) and complex load balancers are perfect examples (no wonder they’re commonly implemented as loadable modules in Apache Web servers or as Squid reverse proxy servers).
Also, if you’re planning to roll out multi-tenant cloud, the flexibility gained by treating networking appliances as click-to-deploy Lego bricks might more than justify the subpar performance. This is especially so if you charge your users by their actual VM/CPU usage, in which case you don’t really care how much CPU they’re using.
Virtualized networking also makes sense when firewall and routing functions are implemented as part of the virtual switch in each hypervisor. This could result in optimal traffic flow between virtual machines (regardless of whether they belong to the same IP subnet or not) and solve the problem of traffic trombones. Unfortunately, it seems that Cisco is still the only vendor that extends the VMware hypervisor switch using the Virtual Ethernet Module (VEM) functionality. While numerous security solutions already deploy the VMsafe APIs, the networking appliances I’ve seen so far (including the vShield Edge from VMware) rely on virtual machines to forward traffic between virtual (or physical) LANs.
Obviously the networking vendors have a very long way to go before reaching the true potential of virtualized networking.
Disponível em: http://searchnetworking.techtarget.com/tip/Virtual-network-appliances-Benefits-and- drawbacks
Search Networking - Tech Target - Texto de Ivan Pepelnjak (Março de 2011)
There's lots of talk about network virtualization benefits, but are virtual network appliances all they're cracked up to be? Only in some scenarios.
Network virtualization benefits can be plentiful, but only in certain scenarios. Learn where virtual network appliances can work -- and where they can't.
If virtualization enables servers to be spun up and down on demand for cost efficiency and agility, wouldn't it make sense to implement virtual network components too? After all, virtual servers need to communicate inbound and outbound and still be firewall-protected and load balanced. That would seem to be best addressed by virtual network appliances that can be spun-up on demand, right? Only in some scenarios.
Many networking vendors have already begun to minimize development cost by using Intel-based platforms and commodity hardware. Examples of this range from the Cisco ASA firewall to F5 load balancers and Vyatta routers. The obvious next step for some of these vendors has been to offer their products in virtual appliance packaging. F5 took a small step forward with the Local Traffic Manager - Virtual Edition (LTM VE), while Vyatta claims to offer a full range of virtual appliance solutions. VMware was somewhat late to the game, but it also offers virtualized firewalls (vShield Zones and vShield App) and routers/load balancers (vShield Edge).
Virtual network appliances: What's the catch?
The problem is that unlike servers, networking appliances commonly perform I/O-intensive tasks, moving large amounts of data between network interfaces with minimal additional processing, relying heavily on dedicated hardware. All high-speed routing and packet forwarding, as well as encryption (both IPsec and SSL) and load balancing, rely on dedicated silicon. When a networking appliance is repackaged into a virtual machine format, the dedicated hardware is gone, and all these tasks must now be performed by the general- purpose CPU, sometimes resulting in extreme reduction in performance.
Implementing routers, switches or firewalls in a virtual appliance would just burn the CPU cycles that could be better used elsewhere -- unless, of course, you’ve over-provisioned your servers and have plenty of idle CPU cycles, in which case something has gone seriously wrong with your planning.
To make matters worse, the hypervisor software used in server virtualization solutions also virtualizes the network interfaces. That means that every I/O access path to virtualized hardware from the networking appliance results in a context switch to higher privilege software (the hypervisor), which uses numerous CPU cycles to decode what needs to be done and emulate the desired action. Also, data passed between virtual machines must be copied between their address spaces, adding further latency to the process.
There is some help in that the VMware hypervisor has the DVFilter API, which allows a loadable kernel module to inspect and modify network traffic either within the hypervisor (vNetwork Data Path Agent) or in combination with a virtual machine (vNetwork Control Path Agent). The loadable kernel module significantly reduces the VM context switching overhead.
Where virtual network appliances can work?
There are some use cases in which virtual network appliances make perfect sense. For instance, you could virtualize an appliance that performs lots of CPU-intensive processing with no reliance on dedicated hardware. Web application firewalls (WAFs) and complex load balancers are perfect examples (no wonder they’re commonly implemented as loadable modules in Apache Web servers or as Squid reverse proxy servers).
Also, if you’re planning to roll out multi-tenant cloud, the flexibility gained by treating networking appliances as click-to-deploy Lego bricks might more than justify the subpar performance. This is especially so if you charge your users by their actual VM/CPU usage, in which case you don’t really care how much CPU they’re using.
Virtualized networking also makes sense when firewall and routing functions are implemented as part of the virtual switch in each hypervisor. This could result in optimal traffic flow between virtual machines (regardless of whether they belong to the same IP subnet or not) and solve the problem of traffic trombones. Unfortunately, it seems that Cisco is still the only vendor that extends the VMware hypervisor switch using the Virtual Ethernet Module (VEM) functionality. While numerous security solutions already deploy the VMsafe APIs, the networking appliances I’ve seen so far (including the vShield Edge from VMware) rely on virtual machines to forward traffic between virtual (or physical) LANs.
Obviously the networking vendors have a very long way to go before reaching the true potential of virtualized networking.
Disponível em: http://searchnetworking.techtarget.com/tip/Virtual-network-appliances-Benefits-and- drawbacks
Search Networking - Tech Target - Texto de Ivan Pepelnjak (Março de 2011)
O software hipervisor usado em soluções de virtualização de servidores também virtualiza as interfaces de rede. Uma consequência que isso tem para o appliance de rede virtual é:
Q483299
Inglês
Texto associado
Virtual network appliances: Benefits and drawbacks
There's lots of talk about network virtualization benefits, but are virtual network appliances all they're cracked up to be? Only in some scenarios.
Network virtualization benefits can be plentiful, but only in certain scenarios. Learn where virtual network appliances can work -- and where they can't.
If virtualization enables servers to be spun up and down on demand for cost efficiency and agility, wouldn't it make sense to implement virtual network components too? After all, virtual servers need to communicate inbound and outbound and still be firewall-protected and load balanced. That would seem to be best addressed by virtual network appliances that can be spun-up on demand, right? Only in some scenarios.
Many networking vendors have already begun to minimize development cost by using Intel-based platforms and commodity hardware. Examples of this range from the Cisco ASA firewall to F5 load balancers and Vyatta routers. The obvious next step for some of these vendors has been to offer their products in virtual appliance packaging. F5 took a small step forward with the Local Traffic Manager - Virtual Edition (LTM VE), while Vyatta claims to offer a full range of virtual appliance solutions. VMware was somewhat late to the game, but it also offers virtualized firewalls (vShield Zones and vShield App) and routers/load balancers (vShield Edge).
Virtual network appliances: What's the catch?
The problem is that unlike servers, networking appliances commonly perform I/O-intensive tasks, moving large amounts of data between network interfaces with minimal additional processing, relying heavily on dedicated hardware. All high-speed routing and packet forwarding, as well as encryption (both IPsec and SSL) and load balancing, rely on dedicated silicon. When a networking appliance is repackaged into a virtual machine format, the dedicated hardware is gone, and all these tasks must now be performed by the general- purpose CPU, sometimes resulting in extreme reduction in performance.
Implementing routers, switches or firewalls in a virtual appliance would just burn the CPU cycles that could be better used elsewhere -- unless, of course, you’ve over-provisioned your servers and have plenty of idle CPU cycles, in which case something has gone seriously wrong with your planning.
To make matters worse, the hypervisor software used in server virtualization solutions also virtualizes the network interfaces. That means that every I/O access path to virtualized hardware from the networking appliance results in a context switch to higher privilege software (the hypervisor), which uses numerous CPU cycles to decode what needs to be done and emulate the desired action. Also, data passed between virtual machines must be copied between their address spaces, adding further latency to the process.
There is some help in that the VMware hypervisor has the DVFilter API, which allows a loadable kernel module to inspect and modify network traffic either within the hypervisor (vNetwork Data Path Agent) or in combination with a virtual machine (vNetwork Control Path Agent). The loadable kernel module significantly reduces the VM context switching overhead.
Where virtual network appliances can work?
There are some use cases in which virtual network appliances make perfect sense. For instance, you could virtualize an appliance that performs lots of CPU-intensive processing with no reliance on dedicated hardware. Web application firewalls (WAFs) and complex load balancers are perfect examples (no wonder they’re commonly implemented as loadable modules in Apache Web servers or as Squid reverse proxy servers).
Also, if you’re planning to roll out multi-tenant cloud, the flexibility gained by treating networking appliances as click-to-deploy Lego bricks might more than justify the subpar performance. This is especially so if you charge your users by their actual VM/CPU usage, in which case you don’t really care how much CPU they’re using.
Virtualized networking also makes sense when firewall and routing functions are implemented as part of the virtual switch in each hypervisor. This could result in optimal traffic flow between virtual machines (regardless of whether they belong to the same IP subnet or not) and solve the problem of traffic trombones. Unfortunately, it seems that Cisco is still the only vendor that extends the VMware hypervisor switch using the Virtual Ethernet Module (VEM) functionality. While numerous security solutions already deploy the VMsafe APIs, the networking appliances I’ve seen so far (including the vShield Edge from VMware) rely on virtual machines to forward traffic between virtual (or physical) LANs.
Obviously the networking vendors have a very long way to go before reaching the true potential of virtualized networking.
Disponível em: http://searchnetworking.techtarget.com/tip/Virtual-network-appliances-Benefits-and- drawbacks
Search Networking - Tech Target - Texto de Ivan Pepelnjak (Março de 2011)
There's lots of talk about network virtualization benefits, but are virtual network appliances all they're cracked up to be? Only in some scenarios.
Network virtualization benefits can be plentiful, but only in certain scenarios. Learn where virtual network appliances can work -- and where they can't.
If virtualization enables servers to be spun up and down on demand for cost efficiency and agility, wouldn't it make sense to implement virtual network components too? After all, virtual servers need to communicate inbound and outbound and still be firewall-protected and load balanced. That would seem to be best addressed by virtual network appliances that can be spun-up on demand, right? Only in some scenarios.
Many networking vendors have already begun to minimize development cost by using Intel-based platforms and commodity hardware. Examples of this range from the Cisco ASA firewall to F5 load balancers and Vyatta routers. The obvious next step for some of these vendors has been to offer their products in virtual appliance packaging. F5 took a small step forward with the Local Traffic Manager - Virtual Edition (LTM VE), while Vyatta claims to offer a full range of virtual appliance solutions. VMware was somewhat late to the game, but it also offers virtualized firewalls (vShield Zones and vShield App) and routers/load balancers (vShield Edge).
Virtual network appliances: What's the catch?
The problem is that unlike servers, networking appliances commonly perform I/O-intensive tasks, moving large amounts of data between network interfaces with minimal additional processing, relying heavily on dedicated hardware. All high-speed routing and packet forwarding, as well as encryption (both IPsec and SSL) and load balancing, rely on dedicated silicon. When a networking appliance is repackaged into a virtual machine format, the dedicated hardware is gone, and all these tasks must now be performed by the general- purpose CPU, sometimes resulting in extreme reduction in performance.
Implementing routers, switches or firewalls in a virtual appliance would just burn the CPU cycles that could be better used elsewhere -- unless, of course, you’ve over-provisioned your servers and have plenty of idle CPU cycles, in which case something has gone seriously wrong with your planning.
To make matters worse, the hypervisor software used in server virtualization solutions also virtualizes the network interfaces. That means that every I/O access path to virtualized hardware from the networking appliance results in a context switch to higher privilege software (the hypervisor), which uses numerous CPU cycles to decode what needs to be done and emulate the desired action. Also, data passed between virtual machines must be copied between their address spaces, adding further latency to the process.
There is some help in that the VMware hypervisor has the DVFilter API, which allows a loadable kernel module to inspect and modify network traffic either within the hypervisor (vNetwork Data Path Agent) or in combination with a virtual machine (vNetwork Control Path Agent). The loadable kernel module significantly reduces the VM context switching overhead.
Where virtual network appliances can work?
There are some use cases in which virtual network appliances make perfect sense. For instance, you could virtualize an appliance that performs lots of CPU-intensive processing with no reliance on dedicated hardware. Web application firewalls (WAFs) and complex load balancers are perfect examples (no wonder they’re commonly implemented as loadable modules in Apache Web servers or as Squid reverse proxy servers).
Also, if you’re planning to roll out multi-tenant cloud, the flexibility gained by treating networking appliances as click-to-deploy Lego bricks might more than justify the subpar performance. This is especially so if you charge your users by their actual VM/CPU usage, in which case you don’t really care how much CPU they’re using.
Virtualized networking also makes sense when firewall and routing functions are implemented as part of the virtual switch in each hypervisor. This could result in optimal traffic flow between virtual machines (regardless of whether they belong to the same IP subnet or not) and solve the problem of traffic trombones. Unfortunately, it seems that Cisco is still the only vendor that extends the VMware hypervisor switch using the Virtual Ethernet Module (VEM) functionality. While numerous security solutions already deploy the VMsafe APIs, the networking appliances I’ve seen so far (including the vShield Edge from VMware) rely on virtual machines to forward traffic between virtual (or physical) LANs.
Obviously the networking vendors have a very long way to go before reaching the true potential of virtualized networking.
Disponível em: http://searchnetworking.techtarget.com/tip/Virtual-network-appliances-Benefits-and- drawbacks
Search Networking - Tech Target - Texto de Ivan Pepelnjak (Março de 2011)
Os tipos de aplicação de rede que fazem sentido com appliances de rede virtuais são:
Conheça nossos planos