BR112013024883B1 - Frameworks e interfaces para processamento de pacote à base de dispositivo de descarga - Google Patents

Abstract

frameworks e interfaces para processamento de pacote à base de dispositivo de descarga. processamento de alta velocidade de pacotes para, e a partir de, um ambiente de virtualização pode ser provido enquanto utiliza descarga de segmentação à base de hardware e outra funcionalidade tal. um fornecedor de hardware, tal como um fabricante de cartão de interface de rede (nic) pode permitir que o hardware suporte o tunelamento sem estado proprietário ou aberto em conjunção com um protocolo, tal como virtualização i/o de raiz única (sr-iov) a fim de implementar uma rede sobreposta virtualizada. o hardware pode utilizar várias regras, por exemplo, que podem ser utilizadas pelo nic para desempenhar certas ações, tais como encapsular pacotes de egresso e desencapsular pacotes.

Description

FUNDAMENTOS

[0001] Como um número crescente de aplicações e serviços são disponibilizados ao longo de redes, tais como a internet, um número crescente de conteúdo, aplicação, e/ou provedores de serviço estão se voltando para tecnologias de recurso compartilhado por inquilinos múltiplos. A computação em nuvem, por exemplo, pode prover consumidores com acesso a recursos eletrônicos através de serviços, tais como serviços na Web, onde o hardware e/ou software utilizado para suportar aqueles serviços é dinamicamente escalável para atender às necessidades dos serviços a qualquer momento dado. Um consumidor tipicamente alugará, arrendará, ou pagará de outro modo pelo acesso a recursos através da nuvem, e assim não precisa adquirir e manter o hardware e/ou software necessário.

[0002] Tal acesso vem com riscos para provedores desses recursos compartilhados, entretanto, como haverá tipicamente usuários múltiplos acessando os recursos em vários tempos. Em casos em que usuários têm um espaço de endereço virtual, de modo que a rede do consumidor funcione como uma rede virtual única sem as restrições ou endereços adicionais de uma ou mais redes físicas adicionais, pode ser desejável prover o processamento e roteamento de pacotes pertencentes a esse espaço de endereço virtual. Quando os consumidores têm acesso aos dispositivos, entretanto, o desempenho do roteamento e processamento em um dispositivo podem potencialmente permitir que o usuário modifique o roteamento ou outro processamento tal dos pacotes. Ademais, tal funcionalidade não pode ser facilmente movida para muitos dispositivos de hardware existentes que não são expostos ao usuário, por razões tais como restrições de tamanho, limitações de protocolo, etc.

BREVE DESCRIÇÃO DAS FIGURAS

[0003] Várias modalidades em conformidade com a presente divulgação serão descritas com referência às figuras, em que:

[0004] FIG. 1 ilustra um ambiente em que várias modalidades podem ser implementadas;

[0005] FIG. 2 ilustra um ambiente para prover acesso a vários recursos que podem ser utilizados em conformidade com uma modalidade;

[0006] FIG. 3 ilustra uma configuração para acessar recursos de hardware específicos que podem ser utilizados em conformidade com uma modalidade;

[0007] FIG. 4 ilustra um processo de encapsulamento de pacote que pode ser utilizado em conformidade com uma modalidade;

[0008] FIG. 5 ilustra a configuração para processamento de pacotes que pode ser utilizada em conformidade com uma modalidade;

[0009] FIG. 6 ilustra um header de pacote exemplar que pode ser utilizado em conformidade com várias modalidades;

[0010] FIG. 7 ilustra um exemplo de um quinto processo para processamento de pacotes que pode ser utilizado em conformidade com várias modalidades;

[0011] FIG. 8 ilustra um exemplo de um sexto processo para processamento de pacotes que podem ser utilizados em conformidade com várias modalidades; e

[0012] FIG. 9 ilustra um fluxo exemplar para processamento de pacotes que pode ser utilizado em conformidade com várias modalidades.

DESCRIÇÃO DETALHADA

[0013] Sistemas e métodos em conformidade com várias modalidades da presente divulgação podem superar uma ou mais das deficiências mencionadas acima ou outras experimentadas em abordagens convencionais para gerenciar recursos em um ambiente eletrônico. Sistemas e métodos em conformidade com várias modalidades proveem o processamento de pacotes entre um primeiro espaço de endereço, tal como um espaço de endereço virtual ou de consumidor, e um segundo espaço de endereço, tal como um provedor de rede em nuvem ou espaço de endereço físico. Características, tal como segmentação e dessegmentação de características de descarga de dispositivos de mercadoria, tais como vários dispositivos de descarga de rede, podem ser utilizadas para ajudar a reduzir o excedente em relação ao tráfego de rede, particularmente como se refere a um ambiente virtualizado. Várias abordagens para prover a segmentação e dessegmentação de características de descarga são descritas, por exemplo, no pedido de Patente US copendente de número de série 12/556.453, intitulado “Stateless Packet Segmentation and Processing” (Processamento e Segmentação de Pacote Sem Estado), depositado em “9 de Setembro de 2009”, e pedido de número de série 12/885.258, intitulado “Framework for Stateless Packet Tunneling” (Framework para Tunelamento de Pacote Sem Estado), depositado em 17 de Setembro de 2010, cada um dos quais está incorporado aqui por referência.

[0014] Várias modalidades permitem que um dispositivo de descarga suporte o tunelamento sem estado proprietário ou aberto em conjunção com um protocolo, tal como a virtualização I/O de raiz única (SR-IOV) a fim de implementar uma rede sobreposta virtualizada. SR-IOV geralmente se refere a uma especificação padrão para interoperabilidade que permite que um dispositivo, tal como um dispositivo de interconexão de componentes periféricos (PCI) apareçam como dispositivos físicos independentes múltiplos. SR-IOV tira vantagem de funções físicas (PFs) e funções virtuais (VFs). As funções físicas são geralmente funções completamente apresentadas, enquanto que as funções virtuais são geralmente funções de peso mais leve que podem não apresentar pelo menos alguns recursos de configuração. SR-IOV tipicamente requer suporte na BIOS, bem como suporte na instância de sistema de operação ou hipervisor funcionando no hardware.

[0015] Em pelo menos algumas modalidades, um dispositivo de descarga (ou um fornecedor ou fabricante de tal dispositivo) pode prover funcionalidade específica para processamento de pacote. Por exemplo, uma implementação com base em Dom-0 (ou seja, domínio zero, tipicamente o primeiro domínio iniciado pelo hipervisor Xen no tempo de inicialização) pode utilizar várias regras que podem ser utilizadas por um dispositivo de descarga para desempenhar certas ações, tais como encapsular pacotes de egresso e desencapsular pacotes de ingresso. A verificação de fonte de pacote de egresso pode ser desempenhada em cada um dos pacotes de egresso com base na fonte VM, incluindo a verificação de endereço de MAC de fonte e endereço de IP de fonte. Em algumas modalidades, o dispositivo de descarga pode reforçar etiquetas de VLAN (rede de área local virtual) específicas ou, de outro modo, adicionar etiquetas de VLAN. Após a verificação de fonte de pacote de egresso, os pacotes podem ser coincididos contra uma lista de regras existentes. Caso haja uma coincidência, uma ação de encapsulação correspondente pode ser tomada no pacote e o pacote transmitido correspondentemente. Se não, o pacote pode ser enviado ao software de controle de Dom-0 para processamento adicional.

[0016] Para pacotes de ingresso, os pacotes em certas modalidades podem ser identificados como sendo encapsulados utilizando um formato especial com base, por exemplo, em um número de protocolo de IP predefinido e um valor de um byte predefinido em um deslocamento predefinido a partir da extremidade de header L2. Esses valores podem ser, cada um, configurados pelo Dom-0. Todos os pacotes de ingresso que não são encapsulados podem ser entregues ao Dom-0. Para ingresso encapsulado, quaisquer bits opacos (localizados apenas após o header L3 externo) podem ser identificados utilizando um comprimento predefinido de bits opacos. Cada pacote pode adicionalmente ser classificado como pertencente a uma máquina virtual particular (VM) (por exemplo, um vetor SR-IOV) utilizando um campo de um byte nos bits opacos em um deslocamento predefinido.

[0017] Cada função de SR-IOV pode ser configurada com um conjunto de regras de ingresso. Cada regra pode consistir primariamente em bits opacos a serem coincididos com bits opacos de pacotes de ingresso encapsulado, um endereço de IP de fonte externo, um endereço de IP de destino externo, e endereços de MAC de alvo e fonte. Quando um pacote encapsulado de ingresso coincide com uma das regras de ingresso para uma função de SR-IOV particular (ou seja, os bits opacos coincidem), o pacote pode ser desencapsulados (ou seja, os bits opacos são removidos), o TTL do header de IP interno é decrescido por um valor especificado na regra, e o pacote é entregue ao VM correspondente à função de SR- IOV. Pacotes de ingresso que não coincide com qualquer uma das regras podem ser entregues ao Dom-0.

[0018] Em pelo menos algumas modalidades, o dispositivo de descarga manterá uma contagem de pacote e uma contagem de byte para cada regra de encapsulamento e desencapsulamento que poderia ser lida ou reestabelecida a partir do Dom-0. Várias modalidades também podem prover a capacidade de injetar pacotes em uma função de SR-IOV a partir do Dom-0. Certas modalidades podem prover um modo de depuração em que cada pacote é forçado a atravessar o irrespectivo Dom-0 das regras coincidentes que estão em efeito. Uma unidade de transmissão máxima (MTU) para funções de SR-IOV pode ser estabelecida a partir do Dom-0, em pelo menos uma modalidade, em default para 1500. Se e quando um convidado tentar alterar o tamanho de MTU, o dispositivo de descarga pode assegurar que a MTU proposta não exceda a MTU máxima estabelecida pelo Dom-0. Em algumas modalidades, o dispositivo de descarga pode também desempenhar rastreamento de conexão, que pode ser utilizado para prover uma implementação de firewall de estado de sessão no dispositivo de descarga.

[0019] Em pelo menos algumas modalidades, o software de controle de Dom-0 pode ser provido, que gerencia as regras de encapsulamento e desencapsulamento para tanto pacotes de egresso quanto de ingresso. O software de controle de Dom-0 pode gerenciar o cache de Protocolo de Resolução de Endereço (ARP) para a rede de substrato, por exemplo, utilizando a estatística de contagem de pacote provida pelo dispositivo de descarga, bem como os questionamentos de ARP de substrato. O software de controle de Dom-0 pode também determinar quais regras, se houver, devem ser empurradas para o dispositivo de descarga e quais regras devem ser gerenciadas pelo Dom-0 como regras de sobrefluxo no caso em que o dispositivo de descarga não suporta todas as regras que são necessárias.

[0020] A FIG. 1 ilustra um exemplo de um ambiente 100 para implementação de aspectos em conformidade com várias modalidades. Conforme será apreciado, embora um ambiente baseado na Web seja utilizado para propósitos de explicação, diferentes ambientes podem ser utilizados, conforme apropriado, para implementar várias modalidades. O ambiente 100 mostrado inclui tanto uma porção de desenvolvimento ou teste (ou lado) e uma porção de produção. Um dispositivo de cliente eletrônico 102 pode incluir qualquer dispositivo apropriado operável para enviar e receber solicitações, mensagens, ou informação ao longo de uma rede apropriada 104 e transmitir informação de volta a um usuário do dispositivo. Exemplos de tais dispositivos de cliente incluem computadores pessoais, telefones celulares, dispositivos de mensagem portáteis, computadores tipo laptop, conversores tipo set-top box, assistentes de dados pessoais, leitores de livro eletrônicos, e similares. A rede pode incluir qualquer rede apropriada, incluindo uma intranet, a internet, uma rede celular, uma rede de área local, ou qualquer outra rede tal ou sua combinação. Componentes utilizados para tal sistema podem depender pelo menos em parte do tipo de rede e/ou ambiente selecionado. Protocolos e componentes para comunicação através de tal rede são bem conhecidos e não serão discutidos aqui em detalhes. A comunicação ao longo da rede pode ser permitida por conexões com ou sem fio, e suas combinações. Nesse exemplo, a rede inclui a internet, como o ambiente inclui um servidor Web 106 para receber solicitações e servir conteúdo em resposta às mesmas, embora para outras redes um dispositivo alternativo servindo um propósito similar poderia ser utilizado como seria evidente para aquele versado na técnica.

[0021] O ambiente ilustrativo inclui pelo menos um servidor de aplicação 108 e uma pluralidade de recursos, servidores, hospedeiros, instâncias, roteadores, comutadores, armazenadores de dados, e/ou outros componentes tais definindo o que será referido aqui como um plano de dados 110, embora deva ser compreendido que os recursos desse plano não são limitados ao armazenamento e provimento de acesso aos dados. Deve ser compreendido que pode haver vários servidores de aplicação, camadas, ou outros elementos, processos, ou componentes, que podem ser encadeados ou configurados de outro modo, que podem interagir para desempenhar tarefas, tais como a obtenção de dados a partir de um armazenamento de dados apropriado. Conforme utilizado aqui, o termo “armazenamento de dados” refere-se a qualquer dispositivo ou combinação de dispositivos capazes de armazenar, acessar e recuperar dados, que podem incluem qualquer combinação e número de servidores de dados, bases de dados, dispositivos de armazenamento de dados, e meios de armazenamento de dados, em qualquer ambiente padrão, distribuído ou agrupado. O servidor de aplicação pode incluir qualquer hardware e software apropriados para integração com o armazenamento de dados conforme necessário para executar aspectos de uma ou mais aplicações para o dispositivo de cliente, manuseamento de uma maioria do acesso de dados e lógica de negócios para uma aplicação. O servidor de aplicação provê serviços de controle de admissão em cooperação com o armazenamento de dados, e é capaz de gerar conteúdo, tal como texto, gráficos, áudio, e/ou vídeo a serem transferidos ao usuário, que pode ser servido ao usuário através do servidor Web na forma de HTML, XML, ou outra linguagem estruturada apropriada nesse exemplo. Em algumas modalidades, o servidor Web 106, servidor de aplicação 108 e componentes similares podem ser considerados como sendo parte do plano de dados. O manuseamento de todas as solicitações e respostas, bem como a entrega de conteúdo entre o dispositivo de cliente 102 e o servidor de aplicação 108, pode ser manuseado pelo servidor Web. Deve ser compreendido que a Web e servidores de aplicação não são requeridos e são meramente componentes exemplares, conforme o código estruturado pode ser executado em qualquer dispositivo apropriado ou máquina hospedeira conforme discutido em outro lugar aqui.

[0022] O ambiente também inclui um lado de desenvolvimento e/ou teste, que inclui um dispositivo de usuário 118 permitindo que um usuário tal como um desenvolvedor, administrador de dados, ou testador acesse o sistema. O dispositivo de usuário 118 pode ser qualquer dispositivo apropriado ou máquina, tal como é descrito acima em relação ao dispositivo de cliente 102. O ambiente também inclui um servidor de desenvolvimento 120, que funciona de modo similar ao servidor de aplicação 108, mas tipicamente percorre o código durante o desenvolvimento e teste antes do código ser distribuído e executado no lado de produção e é acessível um usuários externos, por exemplo. Em algumas modalidades, um servidor de aplicação de aplicação pode funcionar como um servidor de desenvolvimento, e a produção separada e armazenamento de teste pode não ser utilizada.

[0023] Os armazenadores de dados do plano de dados 110 pode incluir várias tabelas de dados separadas, bases de dados, ou outros mecanismos de armazenamento de dados e meios para armazenar dados em relação a um aspecto particular. Por exemplo, o plano de dados ilustrado inclui mecanismos para armazenar dados de produção 112 e informação de usuário 116, que podem ser utilizados para servir o conteúdo para o lado de produção. O plano de dados também é mostrado para incluir um mecanismo para armazenar dados de teste 114, que pode ser utilizado com a informação de usuário para o lado de teste. Deve ser compreendido que pode haver muitos outros aspectos que podem necessitar ser armazenados em um armazenamento de dados, tal como para informação de imagem de página e informação correta de acesso, que podem ser armazenados em qualquer dos mecanismos listados acima conforme apropriado ou em mecanismos adicionais no plano de dados 110. O plano de dados 110 é operável, através da lógica associada com o mesmo, para receber instruções a partir do servidor de aplicação 108 ou servidor de desenvolvimento 120, e obter, atualizar, ou processar, de outro modo, os dados, instruções, ou outra informação tal em resposta às mesmas. Em um exemplo, um usuário pode submeter uma solicitação de pesquisa para certo tipo de item. Nesse caso, componentes do plano de podem acessar a informação de usuário para verificar a identidade do usuário, e acessar a informação de detalhe de catálogo para obter informação sobre itens daquele tipo. A informação então pode ser retornada ao usuário, tal como em uma listagem de resultados em uma página da Web que o usuário é capaz de visualizar através de um navegador no dispositivo de usuário 102. A informação para um item particular de interesse pode ser visualizado em uma página dedicada ou janela do navegador.

[0024] Cada servidor tipicamente incluirá um sistema de operação que provê instruções de programa executável para a administração e operação geral daquele servidor, e tipicamente incluirá um meio legível em computador armazenando instruções que, quando executadas por um processador do servidor, permite que o servidor desempenhe suas funções pretendidas. Implementações adequadas para o sistema de operação e funcionalidade geral dos servidores são conhecidos ou estão comercialmente disponíveis, e são prontamente implementados por pessoas tendo habilidades comuns na técnica, particularmente à luz da divulgação aqui.

[0025] O ambiente em uma modalidade é um ambiente de computação distribuída utilizando vários sistemas de computador e componentes que são interconectados através de ligações de comunicação, utilizando uma ou mais redes de computador ou conexões diretas. Entretanto, será apreciado por aqueles comumente versados na técnica que tal sistema poderia operar igualmente bem em um sistema tendo menor ou maior número de componentes do que são ilustrados na FIG. 1. Assim, a representação do sistema 100 na FIG. 1 deve ser tomada como sendo de natureza ilustrativa, e não limitando o escopo da divulgação.

[0026] Um ambiente tal como aquele ilustrado na FIG. 1 pode ser útil para vários provedores de conteúdo ou outras de tais entidades, em que hospedeiros múltiplos e vários tipos de recursos podem ser utilizados para desempenhar tarefas, tais como servir conteúdo, autenticar usuários, alocar recursos, ou desempenhar qualquer um dentre um número de outras tarefas tais. Alguns desses hospedeiros podem ser configurados para oferecer funcionalidade similar, enquanto outros servidores podem ser configurados para desempenhar pelo menos algumas funções diferentes. O ambiente eletrônico em tais casos pode incluir componentes adicionais e/ou outros arranjos, tais como aqueles ilustrados na configuração 200 da FIG. 2, discutida em detalhes abaixo.

[0027] Sistemas e métodos em conformidade com uma modalidade proveem pelo menos um caminho de acesso de recurso, ou plano de controle, como parte do ambiente de dados ou em uma via entre o usuário e o plano de dados, que permite que usuários e aplicações acessem recursos compartilhados e/ou dedicados, enquanto permite que consumidores, administradores, ou outros usuários autorizados aloquem recursos para vários usuários, clientes, ou aplicações e asseguram a aderência àquelas alocações. Tal funcionalidade permite que um usuário desempenhe tarefas tais como armazenamento, processamento, e questionamento de conjuntos de dados relacionais em uma nuvem sem se preocupar com degradação de latência ou outros assuntos tais devido a outros usuários compartilharem o recurso. Tal funcionalidade também permite que usuários convidados obtenham acesso a recursos para desempenhar qualquer funcionalidade apropriada, tal como render e/ou servir fluxo de mídia ou desempenhar qualquer uma dentre um número de outras operações tais. Enquanto que esse exemplo é discutido em relação à internet, serviços na web, e tecnologia com base na internet, deve ser compreendido que aspectos das várias modalidades podem ser utilizados com quaisquer recursos apropriados ou serviços disponíveis ou oferecidos ao longo de uma rede em um ambiente eletrônico. Ademais, enquanto que vários exemplos são apresentados em relação ao acesso compartilhado ao disco, armazenamento de dados, hospedeiros, e dispositivos periféricos, deve ser compreendido que qualquer recurso apropriado pode ser utilizado dentro do escopo das várias modalidades para qualquer propósito apropriado, e qualquer parâmetro apropriado pode ser monitorado e utilizado para ajustar o acesso ou uso de tal recurso por qualquer ou todos os respectivos usuários.

[0028] Um caminho de recurso ou plano de controle 208 pode ser utilizado em alguns ambientes para prover e/ou gerenciar o acesso a vários recursos no plano de dados 232. Em um ambiente de computação em nuvem, isso pode corresponder a um gerenciador em nuvem 210 ou sistema similar que gerencia o acesso aos vários recursos na nuvem. Em uma modalidade, um conjunto de interfaces de programação de aplicação (APIs) 220 ou outras interfaces tais são providas que permitem que um usuário ou consumidor faça solicitações para acessar vários recursos. Uma vez que o acesso é estabelecido, um recurso é alocado, etc., um usuário pode se comunicar diretamente com o recurso para desempenhar certas tarefas em relação àquele recurso, tal como armazenamento ou processamento de dados. O usuário pode utilizar interfaces diretas ou APIs para se comunicar com as instâncias de dados, hospedeiros, ou outros recursos uma vez que o acesso é estabelecido, mas utiliza o(s) componente(s) de plano de controle para obter o acesso.

[0029] A FIG. 2 ilustra um exemplo de uma configuração 200, tal como pode incluir um sistema de gerenciamento de computação em nuvem, que pode ser utilizado em conformidade com uma modalidade. Nesse exemplo, um dispositivo de computação 202 para um usuário final é mostrado como sendo capaz de fazer ligações através de uma rede 206 para um plano de controle 208 (ou outra camada de acesso tal) para desempenhar uma tarefa, tal como obter o acesso a um recurso específico ou tipo de recurso. Enquanto um dispositivo de computação de usuário final e aplicação são utilizados para propósitos de explicação, deve ser compreendido que qualquer usuário apropriado, aplicação, serviço, dispositivo, componente, ou recurso pode acessar a(s) interface(s) e componentes do componente de conexão e ambiente de dados conforme apropriado nas várias modalidades. Ademais, enquanto que certos componentes estão agrupados em um “plano” de dados, deve ser compreendido que isso pode se referir a uma separação real ou virtual de pelo menos alguns recursos (por exemplo, hardware e/ou software) utilizados para prover a respectiva funcionalidade. Ademais, o plano de controle pode ser considerado como sendo parte do plano de dados em certas modalidades. Enquanto que um único plano de controle é mostrado nessa modalidade, pode haver instâncias múltiplas de controle ou acesso de serviços ou componentes de gerenciamento em outras modalidades. Um plano de controle pode incluir qualquer combinação apropriada de hardware e/ou software, tal como pelo menos um servidor configurado com instruções executáveis em computador. O plano de controle também pode incluir um conjunto de APIs (ou outras interfaces tais) para receber chamadas de serviços na Web ou outras solicitações tais de através da rede 206, que uma camada de serviços na Web 212 pode avaliar ou analisar de outro modo para determinar as etapas ou ações necessárias para atuar ou processar a chamada. Por exemplo, uma chamada de serviço na Web pode ser recebida, que inclui uma solicitação para estabelecer uma conexão a um repositório de dados para executar um questionamento a um usuário. Nesse exemplo, a camada de serviços na Web pode avaliar a solicitação para determinar o tipo de conexão ou acesso necessário, o(s) tipo(s) apropriado(s) de recurso necessário, ou outros aspectos tais.

[0030] O plano de controle pode incluir um ou mais gerenciadores de alocação de recurso 210, cada um responsável por tarefas, tais como validação do usuário ou cliente associado à solicitação e obtenção ou alocação de aceso ao(s) recurso(s) apropriado(s). Um sistema tal pode lidar com vários tipos de solicitação e estabelecer vários tipos de conexão. Um sistema tal pode também lidar com solicitações para vários tipos de recursos, tais como processadores gráficos específicos ou outros tipos de hardware ou funcionalidade de hardware, e podem prover acesso ao(s) recurso(s) apropriado(s). Componentes do plano de dados, ou a camada de recurso da nuvem, podem desempenhar as tarefas necessárias para prover o recurso. Para acessar uma instância de dados, por exemplo, isso pode incluir tarefas tais como a provisão de uma instância de armazenamento de dados, alocação de um volume de armazenamento persistente fora da instância, anexação do volume de armazenamento persistente à instância de armazenamento de dados, e alocação e anexação de um endereço de IP (derivado a partir de mapeamentos de DNS) ou outro endereço, porta, interface, ou identificador que o consumidor pode utilizar para acessar ou conectar-se de outro modo à instância de dados. Para tarefas tais como obtenção de processamento de uma instrução utilizando um tipo particular de hardware, por exemplo, os componentes do plano de dados, em conjunção com o plano de controle, podem desempenhar ações tais como o provimento de um dispositivo para um usuário e provimento de acesso compartilhado e/ou dedicado ao recurso durante um período de tempo em um nível particular de acesso ao recurso. Nesse exemplo, um usuário pode ser provido com o endereço de IP e um endereço de porta a ser utilizado para acessar um recurso. Um usuário então pode acessar o recurso diretamente utilizando o endereço de IP e porta, sem ter que acessar ou atravessar o plano de controle 208.

[0031] O plano de controle 208 nessa modalidade também inclui pelo menos um monitoramento de componente 214. Quando uma instância de dados ou outro recurso é alocado, criado, ou disponibilizado de outro modo no plano de dados, a informação para o recurso pode se escrita para um armazenamento de dados acessível ao plano de controle, tal como um armazenamento de dados de monitoramento 216. Deve ser compreendido que o armazenamento de dados de monitoramento pode ser um armazenamento de dados separado ou uma porção de outro armazenamento de dados. Um monitoramento de componente 214 pode acessar a informação no armazenamento de dados de monitoramento 216 para determinar a informação, tal como o uso passado de recursos por vários usuários, um número atual ou tipo de encadeamentos ou recursos sendo alocados a um usuário, e outra informação de uso tal. Um monitoramento de componente também pode chamar componentes do ambiente de dados para determinar a informação tal como o número de conexões ativas para um dado usuário no ambiente de dados e aspectos sobre o uso de cada conexão. Um monitoramento de componente pode monitorar constantemente o uso de cada recurso através de um usuário, cliente, etc., tendo uma alocação provida através do gerenciador de conexão. Um monitoramento de componente também pode acessar a informação armazenada em um armazenamento de dados administrativo (“Admin”) ou similar 216, que pode armazenar informação, tal como a alocação geral concedida a um usuário, regulando ou limitando a informação para um usuário, permissões de recurso para um usuário, ou qualquer outra informação tal que pode ser especificada e/ou atualizada por um administrador ou outro usuário tal.

[0032] Em um exemplo em que usuários solicitam conexões a várias instâncias de dados, cada instância 222 no ambiente de dados pode incluir pelo menos um armazenamento de dados 226 e um componente gerenciador hospedeiro 228 para a máquina provendo acesso ao armazenamento de dados. Um gerenciador hospedeiro em uma modalidade é uma agente de aplicação ou software executando em uma instância e/ou servidor de aplicação, tal como um servidor de aplicação Tomcat ou Java, programado para gerenciar tarefas tais como as operações de distribuição de software e armazenamento de dados, bem como monitoramento de um estado do armazenamento de dados e/ou a respectiva instância. Um gerenciador hospedeiro pode ser responsável por gerenciar e/ou desempenhar tarefas tais como instalar as instâncias para um novo repositório, incluindo a instalação de volumes lógicos e sistemas de arquivo, instalar binários de base de dados e sementes, e iniciando ou parando o repositório. Um gerenciador hospedeiro pode monitorar a saúde do armazenamento de dados, monitoramento do armazenamento de dados para condições de erro, tais como erros de I/O ou erros de armazenamento de dados, e pode reiniciar o armazenamento de dados, caso necessário. Um gerenciador hospedeiro pode também desempenhar e/ou gerenciar a instalação de emendas de software e atualizações para versões mais recentes, para o armazenamento de dados e/ou sistema de operação. Um gerenciador hospedeiro também pode coletar medições relevantes, tais como podem se relacionar à CPU, memória, e uso de I/O.

[0033] O gerenciador de recurso 210 pode se comunicar periodicamente com cada gerenciador hospedeiro 228 para o qual uma conexão foi estabelecida, ou com um servidor de administração ou outro componente do ambiente de recurso, para determinar a informação de status, tal como carga, uso, capacidade, etc.

[0034] Conforme discutido, uma vez que um recurso é provido e um usuário é provido com um endereço de IP derivado a partir de mapeamentos de DNS ou outro endereço ou localização, o usuário pode se comunicar “diretamente” com componentes ou recursos do plano de dados 232 através da rede utilizando uma Conectividade de Banco de Dados em Java (JDBC) ou outro protocolo tal para interagir diretamente com aquele recurso 222. Em várias modalidades, conforme discutido, o plano de dados toma a forma de (ou pelo menos inclui ou é parte de) um ambiente em nuvem de computação, ou um conjunto de serviços na Web e recursos que provê o armazenamento de dados e acesso ao longo de uma “nuvem” ou rede dinâmica de componentes de hardware e/ou software. Um endereço de IP derivado a partir de mapeamentos de DNS é benéfico em um ambiente de nuvem dinâmico, como falhas de disponibilidade ou instância, por exemplo, podem ser mascaradas através do remapeamento programático do endereço de IP para qualquer instância de substituição apropriada para um uso. Uma solicitação recebida a partir de um usuário 202 ou aplicação 204, por exemplo, pode ser direcionada a um roteador de tradução do endereço de rede (NAT) 224, ou outro componente apropriado, que pode direcionar a solicitação ao recurso real 222 ou hospedeiro correspondente ao endereço mapeado da solicitação. Tal abordagem permite que instâncias sejam dinamicamente movidas, atualizadas, replicadas, etc., sem requerer que o usuário ou a aplicação altere o endereço de IP ou outro endereço utilizado para acessar a instância. Em alguns casos, um recurso 222, tal como uma instância de dados, pode ter pelo menos uma instância de backup 230 ou cópia em armazenamento persistente.

[0035] Conforme discutido, um recurso pode ser compartilhado dentre usuários múltiplos, clientes, aplicações, etc., seja concorrentemente ou em tempos diferentes, com variações de níveis de acesso ou alocação. Quando um usuário tem acesso dedicado a uma máquina ou recurso, o usuário pode ter também acesso nativo ou “a partir do zero” para o recurso durante um período de tempo, dependendo do tipo de acesso necessário, e outros fatores tais. O provimento desse nível de acesso a um recurso vem com riscos em potencial para um provedor do recurso, como um usuário tendo acesso nativo ao dispositivo pode ter a capacidade de modificar o firmware ou outra informação de configuração para o recurso, que pode afetar a capacidade de um usuário subsequente utilizar o recurso sem primeiro representar novamente por imagem ou verificar de outro modo o estado do recurso.

[0036] Várias modalidades permitem que um provedor conceda um usuário ou consumidor acesso substancialmente completo a um recurso de hardware com um nível razoável de segurança. Esse acesso a nível nativo a hardware remoto pode ser provido para recursos tais como servidores, hospedeiros, e instâncias de aglomeração, por exemplo. Para recursos tais como instâncias de aglomeração, os consumidores podem ter acesso nativo a um subconjunto dos recursos de hardware, tais como podem incluir dispositivos periféricos conectados utilizando um componente tal como um barramento interconexão de componente periférico (PCI). Esses dispositivos periféricos podem incluir cartões de interface de rede (NICs), unidades de processamento gráfico (GPUs), e dispositivos similares que frequentemente seriam virtualizados em um ambiente de nuvem atual. Em alguns casos, um consumidor pode ter acesso integral a uma máquina completa, ou grupos de máquinas, incluindo quaisquer ou todos os dispositivos incorporados na mesma. Para um grupo de máquinas tais como um rack de servidores, pode ser concedido a um usuário o acesso substancialmente completo ao rack completo, incluindo quaisquer comutadores ou outros dispositivos ou componentes providos como parte do rack.

[0037] Certos provedores apresentam tais recursos de hardware como uma abstração virtualizada, de modo que o gerenciamento do hardware físico possa ocorrer em um contexto de execução “mais confiável”, e pode prover benefícios adicionais, tais como a capacidade de migrar consumidores para diferentes recursos sem interromper a execução e, uma vez que consumidores ou “convidados” não estão presos ao hardware específico, a capacidade de fornecedores de competir para prover o melhor valor de computação de utilidade por preço. Também, imagens de instância de convidado mais simples e em menor quantidade podem ser utilizadas, uma vez que os convidados não necessitam de uma multitude de drivers específicos ao hardware. Tal virtualização pode vir com custos potencialmente significativos, entretanto, como a virtualização pode incorrer em penalidade de desempenho de ordem de magnitude para o hardware que não inclui aceleração nativa para virtualização, e a virtualização de um dispositivo particular de hardware pode consumir recursos substanciais não relativos àquele dispositivo (por exemplo, um processador e/ou memória utilizada para virtualizar uma interface de rede). Também, o suporte de virtualização pode se atrasar anos atrás de disponibilidade de comodidade do novo hardware (por exemplo, cartões de vídeo), e certo hardware de utensílio é frequentemente muito específico ou de “nicho” para em algum momento garantir o suporte de virtualização convincente. Há potencialmente grandes oportunidades no mercado no suporte utensílios de nicho de alta margem ou em ser o primeiro a comercializar o suporte de nuvem de novos tipos de hardware. O provimento de tal suporte através de acesso nativo, entretanto, pode levar a vários aspectos vulneráveis da nuvem interna, tal como o provimento de tecnologia, faturamento, utilização e balanceamento de recurso, e do layout de 2 camadas de rede, por exemplo, e pode violar modelos de ameaça bem além das solicitações do consumidor.

[0038] Várias modalidades podem prover acesso “parcial” ou “substancialmente” integral a um recurso, tal como um servidor hospedeiro, ao prover aos usuários acesso nativo ao hardware hospedeiro ou dispositivos específicos, tais como cartões plugados em um barramento de controle periférico ou via de dados de hardware similar. Em certas modalidades em que níveis específicos de desempenho são uma questão, a tecnologia tal como uma unidade de gerenciamento de memória de entrada/saída (I/O MMU) pode ser utilizada para “designar” dispositivos periféricos a sistemas de operação convidados (por exemplo, tecnologia de virtualização para I/O direcionada (VT-D da Intel)), efetivamente dando o acesso nativo de convidados a apenas aqueles dispositivos periféricos. Como deve ser evidente àquele versado na técnica, um sistema de operação convidado (OS) pode se referir a diferentes sistemas em diferentes modalidades, tais como uma máquina virtual hospedando um OS em funcionamento com acesso não virtualizado pelo menos parcial do qual algum estado de hardware ou máquina que o OS ou hipervisor depende incluindo BIOS, configuração, etc., que não está sob o controle administrativo do provedor de hospedagem. Em outras modalidades, o OS convidado pode se referir a um OS que não está sob o controle administrativo do provedor de hospedagem em funcionamento sem virtualização integral. Em uma modalidade, um MMU pode se conectar logicamente a um barramento de I/O capaz de acesso de memória direto (DMA) (por exemplo, um barramento PCI) para memória principal em um hospedeiro, e pode gerenciar o mapeamento de dispositivos de I/O para endereços físicos para regular o fluxo de informação a partir de um convidado para vários dispositivos PCI ou similares. Esses dispositivos podem incluir, por exemplo, coprocessadores de unidade de processamento gráfico (GPU), NICs de alto desempenho, controladores de disco, ou outros dispositivos de coprocessamento de “nicho”, tais como cartões criptográficos ou codecs de hardware. Em algumas instâncias, a virtualização ou outra tecnologia tal pode ser utilizada para prover um nível de separação entre convidados e máquinas hospedeiras a partir do hardware de sistema central (por exemplo, CPU, memória, etc.), com acesso nativo potencialmente estando disponível para dispositivos específicos em um dado hospedeiro. Em outras modalidades, o acesso nativo pode ser provido a qualquer hardware incluído em, ou disponível para, um hospedeiro específico.

[0039] Uma das principais questões em prover aos consumidores o acesso nativo ao hardware específico é que os consumidores podem ter a capacidade de modificar configuração privilegiada ou opções de BIOS (sistema de I/O básico), ou outras imagens de firmware em hardware hospedeiro. Essas alterações podem persistir ao longo de uma reinicialização do sistema físico, de modo que o hardware pode não retornar ao mesmo estado em que o hardware estava antes que seja concedido ao consumidor o acesso ao hospedeiro ou seu(s) dispositivo(s). No caso de opções configuráveis dinamicamente para um monitor de máquina virtual (VMM) gerenciado por um hipervisor de Anel 1, por exemplo, as alterações, em geral, não persistiriam ao longo da reinicialização, mas poderiam persistir ao longo de instanciações de sistemas de operação convidados em um ambiente virtualizado (por exemplo, opções de conjunto de circuitos integrados para suportar a tecnologia IOMMU). Essa capacidade de um consumidor de modificar as opções ou firmware que, de outro modo, deveriam ser imutáveis, podem ter sérias implicações de segurança. Por exemplo, o software malicioso (por exemplo, Cavalos de Troia ou vírus) pode ser inserido no firmware para vários dispositivos. Mesmo se as alterações de firmware não envolverem programações intencionalmente maliciosas, entretanto, as alterações ainda poderiam ser não intencionalmente danosas por causarem questões de desempenho e/ou compatibilidade. O processo de troca de firmware pode potencialmente destruir fisicamente o hardware irreparavelmente (também conhecido como “bricking” do hardware). Certas tecnologias foram desenvolvidas que podem se dirigir a pelo menos alguns desses desafios, particularmente para firmware de placa mãe ou configurações de conjunto de circuitos integrados. Essas tecnologias incluem, por exemplo, Módulo de Plataforma Confiável (TPM), LaGrande Tecnologia (LT) da Intel, tecnologia de inicialização medida, tecnologia de inicialização confiável, tecnologia de Raiz Dinâmica de Confiança (DRTM) e de Raiz Estática de Confiança (SRTM). Nenhuma dessas soluções, entretanto, é conhecida por se endereçar a várias questões específicas para o firmware de dispositivo, hospedeiros completos, e outros aspectos de hardware tais.

[0040] Sistemas e métodos em conformidade com várias modalidades podem evitar e/ou monitorar o acesso e/ou manipulação de imagens de firmware ou informação de configuração por convidados em uma nuvem ou ambiente eletrônico similar. Em certas modalidades, um consumidor pode ser provido com acesso de convidado dedicado para um rebcurso de hardware durante qualquer período de tempo desejado, tal como uma questão de horas ou até mesmo minutos. A FIG. 3 ilustra um exemplo de uma configuração 300 que pode ser feita para prover tal acesso nativo a um consumidor em conformidade com uma modalidade. Esse exemplo será discutido em relação à concessão a um usuário de acesso a um dispositivo periférico em uma máquina hospedeira utilizando tecnologia à base de PCI convencional, mas deve ser compreendido que isso é meramente um exemplo e que abordagens dentro do escopo das várias modalidades podem ser utilizados com qualquer hardware apropriado (incluindo com base em diferentes tecnologias de barramento ou com maiores ou menores graus de integração de sistema dentro de componentes individuais ou “chipes”), software, e protocolos atualmente utilizados ou desenvolvidos subsequentemente para tais propósitos.

[0041] Essa configuração exemplar 300 inclui um conjunto de dispositivos hospedeiros 302, tais como servidores ou dispositivos similares, que cada um pode ter uma série de portas de rede 304. Algumas dessas portas podem funcionar como portas de “produção” que conectam cada hospedeiro a pelo menos um comutador de rede 306 capaz de processar e rotear o tráfego de rede para/a partir de cada dispositivo. Em algumas modalidades, o comutador de rede pode ser um comutador de rede “inteligente”, enquanto que, em outras modalidades, a segregação pode ocorrer em um nível mais alto na rede que o primeiro pavimento de comutadores. Em um exemplo de centro de dados, pode haver um comutador inteligente para cada rack de servidores 308, por exemplo. Pelo menos uma dessas portas de rede 304 pode hospedar o tráfego para um sistema de operação convidado, onde o convidado está operando efetivamente “em cima de” pelo menos uma unidade de processamento central (CPU) 310 no dispositivo hospedeiro particionado ou alocado (por exemplo, servidor) 302 que tem acesso a essa porta de rede de produção. O dispositivo hospedeiro 302 também pode ter pelo menos uma porta de terminal 312 e um controlador de terminal 314, que pode se conectar uma rede de terminal separada 316. Essa “rede de terminal” também pode ser implementada utilizando a mesma tecnologia de rede que a “rede de produção”, tal como a tecnologia de Ethernet. Em algumas modalidades, pelo menos algumas dessas portas podem ser fundidas, mas separadas logicamente (por exemplo, multiplexada na mesma porta física). Cada dispositivo hospedeiro também poderia ter uma ou mais unidades de suprimento de energia dedicadas (PSUs) 318, que podem ser acessadas pelo controlador de terminal e/ou a CPU principal, através das quais a máquina pode ser desligada através da CPU hospedeira ou um dispositivo na rede, por exemplo. O suprimento de energia para cada servidor em um rack pode estar conectado a uma unidade de distribuição de energia de rack (PDU) 320, que pode estar conectada por um cabo de energia maior a um ou mais PDUs de centro de dados 322, cada uma das quais pode suportar PDUs de rack múltiplas. Em alguns casos, os hospedeiros 302 podem ser ligados e desligados pelo funcionamento de uma linha para o controlador de terminal a partir da PDU de rack com relés ou outros componentes tais para ciclos de energia de cada dispositivo.

[0042] Pelo menos um roteador 324 pode conectar os dispositivos hospedeiros a um ou mais sistemas de provisão 326, e o comutador e/ou roteador pode gerenciar o acesso a esses sistemas de provisão. Em algumas modalidades, o tráfego de rede dentro de um rack é agregado a fim de minimizar o número de cabos deixando cada rack. Em algumas modalidades, uma capacidade tal como um ambiente de execução de pré-inicialização (PXE) existe em uma máquina hospedeira 302 na porta de rede de produção 304, de modo que a energia pode ser circulada utilizando o terminal e, quando a máquina se inicializa, o código de PXE pode executar na porta de rede. O acesso de PXE poderia também ser habilitado ou desabilitado dependendo do tipo de reinicialização que foi autorizado. Por exemplo, as reinicializações poderiam ser permitidas a partir de imagens locais no hospedeiro para reinicializações iniciadas de consumidor, mas o acesso de PXE pode ser desabilitado a montante. Quando o comutador 306 é configurado para conectar uma máquina hospedeira 302 aos sistemas de provisão, o PXE pode conectar o dispositivo aos sistemas de provisão e inicializar a máquina em um disco de RAM (memória de acesso randômico) ou outro bloco de armazenamento, por exemplo, que habilita operações de controle, tais como o processo de troca de firmware ou provisão de uma nova imagem de fornecedor. Um disco de RAM com drivers especializados em uma modalidade pode ser utilizado para inicializar e/ou executar uma imagem desconhecida ou não confiável, que pode, de outro modo, não ser capaz de inicializar em uma máquina específica. A provisão de imagens, assim, pode ser recebida, ao longo da rede para o PXE, que contém o código de provisão ou código processo de troca de firmware. Uma vez completa a provisão, redes de consumidor autorizadas 328 podem interagir com os dispositivos 302 através do comutador 306. Os sistemas de controle e provisão pode controlar o comutador em tempo real sem humanos envolvidos, uma vez que a comutação automática daquela via pode ser com base em eventos de provisão e coordenação externa, por exemplo. A coordenação pode ser provida e/ou gerenciada por um sistema externo, tal como um sistema e base de dados de gerenciador em nuvem 330, ou outro plano de controle ou sistema de controle tal conforme discutido em outro local aqui, que pode instruir o(s) sistema(s) de provisão 326, rede de terminal 316, e componentes de rack para desempenhar certas ações. O gerenciador em nuvem 330 pode incluir um ou mais sistemas de fluxo de trabalho que trabalha com uma base de dados central, em uma modalidade, para desempenhar vários aspectos do gerenciamento de recurso.

[0043] Em um ambiente tal como um ambiente de computação em nuvem onde diferentes servidores físicos podem ser utilizados para consumidores hospedeiros em tempos diferentes, pode ser desejável prover um nível de abstração para um usuário ou rede do consumidor para evitar dependências em alocações de recurso que podem se alterar ao longo do tempo. A apresentação de equipamento de rede virtual, tal como roteadores de rede do consumidor e firewalls de rede do consumidor, pode também ser obtida utilizando tecnologia de rede de sobreposição. Por exemplo, uma rede local virtual do consumidor ou outra rede virtual entre nodos de computação múltiplos pode ser provida em pelo menos algumas modalidades através de uma rede de sobreposição ao longo de uma ou mais redes físicas intermediárias separando os nodos de computação múltiplos. A rede de sobreposição pode ser implementada de vários modos em várias modalidades, tais como através de encapsulamento de comunicações e embutimento de informação de endereço virtual de rede para uma rede virtual em um espaço de endereço de rede física maior utilizado para um protocolo de rede da uma ou mais redes físicas intermediárias.

[0044] Isso permite que os consumidores utilizem um espaço padronizado de endereço para endereçar recursos na rede do consumidor. Ao utilizar um espaço padronizado de endereço, um consumidor pode criar uma rede de sobreposição ou “virtual” que pode utilizar endereços de base comum, sub-redes, etc., sem as restrições que a rede de substrato coloca no espaço de endereço físico.

[0045] Utilizando a virtualização, um número de instâncias de máquina virtual pode ser gerado que aparece e funciona para um usuário como sendo uma parte da rede do consumidor, as que são mapeadas para servidores reais ou outros recursos físicos em uma nuvem remota ou separada, rede, etc. Conforme discutido, a utilização de um espaço padronizado de endereço pode requerer a construção e manutenção de um mapeamento entre os endereços de substrato físico e os endereços de sobreposição virtual que são utilizados para o espaço de endereço do consumidor. Em algumas abordagens existentes, uma unidade de processamento central funcionando em um dispositivo hospedeiro pode controlar o mapeamento dos endereços físicos e virtuais, de modo que uma solicitação recebida a partir de um consumidor pode ser direcionada ao recurso apropriado. Isso pode tomar a forma de encapsulamento e desencapsulamento de pacote de dados, por exemplo, em que o endereço físico e/ou informação de header podem “coexistir” em vários tempos com o endereço virtual e/ou informação de header, de modo que um pacote pode ser endereçado ao endereço virtual por uma fonte na rede do consumidor, mas pode ser apropriadamente roteada ao endereço físico apropriado através da adição da informação de header física quando na nuvem ou infraestrutura de rede remota.

[0046] Por exemplo, a FIG. 4 ilustra um exemplo em que um pacote 400 recebido a partir de um consumidor ou rede de “sobreposição” é encapsulado a fim de ser roteado dentro de uma rede de substrato físico em que o ambiente de nuvem virtual é hospedado, em conformidade com uma modalidade. Nesse exemplo, o pacote de consumidor recebido 400 inclui três partes principais: um endereço virtual 402 (tal como um “endereço de IP virtual” relevante para o rede de sobreposição de consumidor, denotado aqui como “IPv”), um header de protocolo 404 (tal como um header de protocolo de controle de transmissão original conforme encontrado no conjunto de protocolo de internet, denotado aqui como “TCPo”), e uma porção de “carga útil” ou dados 406. O endereço de IP virtual pode ser um endereço relevante apenas para o consumidor ou rede de sobreposição. A fim de rotear apropriadamente o pacote ao hospedeiro de destino pretendido, esse pacote pode ser encapsulado para incluir uma estrutura de dados “externa” ou quadro que pode rotear o pacote dentro da rede de substrato ou nuvem ou outro agrupamento de recursos tal. Nesse exemplo, o processo de encapsulamento é mostrado como produzindo um pacote de “substrato” ou datagrama 410, que inclui o IPV, TCPo, e a carga útil do pacote de consumidor original, mas tem acrescida a ele informação de “header” adicional, incluindo aqui um endereço “real” ou físico 412 (tal como o endereço de IP ou “IPR” dentro da rede de substrato da nuvem) e um header de controle 414 (tal como um header de protocolo útil através do plano de controle para processar e/ou rotear o pacote). Sem o acréscimo de qualquer uma dessa informação “real”, os roteadores e outros componentes tais que hospedam a infraestrutura de nuvem geralmente não seriam capazes de rotear apropriadamente os pacotes ao(s) destino(s) apropriado(s), uma vez que a informação de roteamento de consumidor (por exemplo, modalizado por 402) é apenas significativa para a rede de sobreposição do consumidor e não a infraestrutura de rede física à qual os recursos de hospedeiro em nuvem estão conectados. Em algumas modalidades, qualquer pacote de consumidor sendo recebido para um dispositivo na nuvem pode ser encapsulado para incluir essa informação de roteamento físico a ser utilizado dentro da nuvem. Uma vez que o primeiro dispositivo para receber um pacote na nuvem pode ser considerado como estando na “borda” da nuvem, esses dispositivos serão referidos aqui como dispositivos de “borda”. Um dispositivo de “borda” conforme utilizado aqui pode se referir a qualquer dispositivo em hardware e/ou software capaz de receber um pacote de informação a partir do exterior da nuvem, e/ou capaz de transmitir um pacote de informação a partir do interior da nuvem. O processo de encapsulamento pode acontecer em qualquer dispositivo de borda apropriado em algumas modalidades, enquanto que, em outras modalidades, os dispositivos de borda podem rotear os pacotes a um componente de encapsulamento ou outro dispositivo capaz de encapsulamento ou desencapsulamento dos pacotes. Conforme deve ser compreendido, quando um pacote deve ser transmitido de volta à rede do consumidor, ou transmitido de outro modo fora da nuvem, um processo de “desencapsulamento” pode ser desempenhado, em que o IPR 412 e um header de controle 414 são removidos e o pacote pode ser roteado utilizando a informação de espaço de endereço virtual para a rede do consumidor. Para propósitos de simplicidade, o processo de encapsulamento será discutido em relação a várias modalidades, mas deve ser compreendido que um a processo de desencapsulamento pode também ser desempenhado utilizando tais componentes e processos em conformidade com as várias modalidades.

[0047] Certas abordagens convencionais desempenham um nível de encapsulamento no hardware tais como dispositivos hospedeiros e servidores. Nessas abordagens, um processador central pode desempenhar o procedimento de encapsulamento a fim de rotear pacotes recebidos para uma porta de rede, cartão de interface de rede (NIC), ou dispositivo similar. O processo de encapsulamento em geral não é exposto ao usuário. Em algumas modalidades, o driver para o NIC seria diretamente acessível pelo processador, de modo que o processador pode acessar um mecanismo de mapeamento ou serviço de mapeamento distribuído para mapear pacotes de substrato físico para pacotes de sobreposição virtual, e vice-versa, antes de rotear pacotes para, ou a partir de, as redes de consumidor através de NIC. Em alguns casos, a informação de mapeamento pode ser distribuída a partir de um serviço centralizado para cada nodo apropriado ao longo da nuvem.

[0048] Conforme discutido, entretanto, um provedor de recurso pode querer a capacidade de prover aos usuários ou consumidores acesso nativo substancialmente integral, ou acesso “a partir do zero”, a um recurso de hardware, tal como uma máquina hospedeira. Caso o mapeamento seja gerenciado por uma aplicação executando em uma CPU da máquina hospedeira, por exemplo, então, aquele mapeamento pode ser potencialmente acessado através de um usuário ou sistema de operação convidado (OS) executando na máquina hospedeira. Tal acesso pode comprometer potencialmente o serviço de mapeamento, e pode permitir que um sistema de operação convidado redirecione pacotes, rejeite pacotes, ou impacte de outro modo o processamento de pacotes na rede em nuvem. Ademais, tal funcionalidade poderia ser comprometida de modo que os pacotes podem ser enviados a localizações não pretendidas fora da nuvem. Outros problemas em potencial incluem “mascaramento de pacote”, em que um hospedeiro envia pacotes que parecem se originar a partir de um hospedeiro ou localização diferente. Isso é frequentemente utilizado para ofuscar de onde ataques adversários estão vindo, e também podem ser a base de ataques de Negação de Serviço (DoS) “à base de ACK”, onde pacotes de reconhecimento que são parte de protocolos de rede padrão são enviados aos hospedeiros que nunca iniciaram transmissões, etc. Várias outras questões em potencial surgem quando o OS convidado ou CPU potencialmente tem acesso à funcionalidade de mapeamento e/ou encapsulamento.

[0049] Correspondentemente, sistemas e métodos em conformidade com várias modalidades podem prover recursos de acesso substancialmente “a partir do zero” por vários usuários, enquanto desempenha operações, tais como encapsulamento, desencapsulamento, e operações de realização de firewall de estado de sessão utilizando componentes que não são expostos ao consumidor, OS convidado, CPU em uma máquina hospedeira provida, ou outras fontes de manipulação em potencial. FIG. 5 ilustra um exemplo de uma configuração 500 que pode ser utilizado para desempenhar processamento de pacote e assegurar outras funções de rede em conformidade com várias modalidades. Nesse exemplo, os pacotes são encapsulados “a montante” dos recursos de hospedeiros acessíveis ao consumidor, aqui no nível de cartão de rede, tal como apenas antes de um pacote estar em quadros para transmissão de interconexão física (por exemplo, enquadramento de Ethernet). Nesse exemplo, pode-se observar que o dispositivo de descarga 506 tem uma porta externa 508 que pode se comunicar com componentes tais como o gerenciador em nuvem 504 e um serviço de mapeamento 502. A porta externa 508 pode permitir que esses componentes se comuniquem com o dispositivo de descarga independente da CPU 514 na máquina hospedeira 516, ou qualquer imagem de convidado 518 ou o OS convidado provido na máquina hospedeira. Utilizando uma abordagem tal, qualquer pacote transmitido para, ou a partir de, a nuvem pode ser processada independente das porções acessíveis ao convidado, de modo que o mapeamento não está acessível a, ou modificável por, o usuário. Nesse exemplo, o dispositivo de descarga pode ter memória 510 e um dispositivo de processamento 512 capaz de desempenhar pelo menos o mapeamento básico, encapsulamento, desencapsulamento, e/ou tais funções similar. Isso será referido geralmente aqui como encapsulamento “à base de dispositivo de descarga”, embora deva ser compreendido que outros dispositivos periféricos ou componentes de hardware possam desempenhar funcionalidade similar, e que a funcionalidade não é limitada a encapsulamento, mas pode também incluir outras funções, tais como desencapsulamento, realização de firewall, etc. Um dispositivo de descarga pode funcionar como um sistema embutido na máquina hospedeira que não é exposta ao usuário ou sistema de operação convidado. Em casos em que o usuário pode querer o acesso nativo a pelo menos algumas das funcionalidades do dispositivo de descarga, o dispositivo de descarga pode ter apenas certas porções de memória mapeadas para o OS convidado, de modo que apenas algumas funcionalidades possam ser acessadas. Em algumas modalidades, isso pode tomar a forma de uma imagem de dispositivo de descarga virtual, em que o OS convidado pode descobrir e/ou utilizar porções do dispositivo de descarga, mas não pode acessar porções utilizadas para assegurar ações, tais como encapsulamento.

[0050] A funcionalidade de encapsulamento à base de dispositivo de descarga pode ser provida em uma base por hospedeiro, ou pelo menos para aquelas máquinas hospedeiras capazes de receber e/ou transmitir pacotes, e/ou capazes de ter uma imagem de fornecedor provida nos mesmos. Em tais casos, o gerenciador em nuvem 504 ou um componente ou sistema similar pode gerenciar a distribuição de informação de mapeamento aos vários hospedeiros e/ou nodos, bem como outros de tais aspectos e informação de configuração úteis para tais processos. Em tais casos, o gerenciador em nuvem podem se comunicar com um dispositivo de descarga 506 através da porta externa 508 para atualizar a informação de configuração, firmware, ou outra informação útil para desempenhar o encapsulamento e tais ações similares. Os processos para atualização da informação de configuração através de um via canal externo são divulgados no Pedido de Patente US copendente No. 12/554.690, depositado em 4 de Setembro de 2009, [DOCUMENTO DE PROCURAÇÃO 026014- 010700US], que é incorporado aqui por referência. Utilizando uma abordagem tal, o firmware e/ou informação de configuração para o dispositivo de descarga pode ser atualizado para desempenhar a funcionalidade desejada, bem como para se comunicar com o serviço de mapeamento 502 ou outro(s) componente(s) apropriado(s) conforme necessário. A configuração pode ser atualizada periodicamente, uma vez que pode ser gerenciada pelo gerenciador em nuvem e/ou sistema(s) de mapeamento, tal como para enviar grandes cargas úteis ou ajustar de outro modo a funcionalidade do dispositivo de descarga.

[0051] Em algumas modalidades, o encapsulamento e processos similares podem ser executados em outros componentes que não são expostos ao usuário, tais como um comutador inteligente 520 configurado para rotear mensagens para, e a partir de, um dispositivo de descarga 506 e/ou porta de rede 520 de uma máquina hospedeira 516. Um comutador tal pode incluir um processador 522 operável para desempenhar operações, tais como encapsulamento de pacotes, por meio de que o comutador pode processar e rotear pacotes aos endereços apropriados em espaço de endereço virtual e/ou físico. Em tais casos, a máquina hospedeira pode ser considerada (a partir de uma perspectiva de espaço de endereço) como estando fora da nuvem, ou ambiente confiável, por meio de que o comutador pode funcionar como um dispositivo de borda e modificar pacotes recebidos a partir do espaço de endereço virtual da máquina hospedeira (e redes de cliente) para o espaço de endereço físico de recursos na nuvem. Vários outros componentes podem ser utilizados também, tais como roteadores ou dispositivos de borda dedicados, dentro do escopo das várias modalidades.

[0052] Uma das limitações em muitos sistemas convencionais é que a via de transmissão física ou “cabo” pode apenas permitir que pacotes de informação relativamente pequenos, tais como pacotes de 1,5KB ou 9KB. O uso de pacotes menores não é estritamente uma consideração física, mas também resulta a de razões de definição de protocolo e históricas. Por exemplo, em redes modernas onde a maioria ou todos os links são comutados e as taxas de transmissão são altas, essa limitação poderia ser aumentada em ordens de magnitude sem aumentar colisões intoleravelmente. Apesar de uma interface de rede física, tal como um dispositivo de descarga, poder apenas transmitir ou receber pacotes de 1,5KB ou 9KB, é desejável, em pelo menos algumas modalidades, a transmissão de pacotes maiores a partir da pilha de rede do DOM-U para o DOM-0 e daí para o dispositivo de descarga, e têm o segmento de dispositivo de descarga o pacote maior para dentro de pacotes múltiplos de 1,5KB ou 9KB. Muitos dispositivos de descarga de comodidade suportam funcionalidade avançada, tal como a descarga de segmentação para se endereçar a esse requerimento. Um dispositivo de descarga com capacidades de descarga de segmentação pode ser configurado para receber e/ou carregar pacotes relativamente grandes, e segmenta ou enquadra aqueles pacotes maiores em pacotes menores ou quadros de Ethernet que cumpre com a restrição de 1,5KB, 9KB, ou outra restrição de tamanho. Dispositivos recebendo esses pacotes podem ser configurados para rearranjar os pacotes maiores com base na pluralidade de pacotes menores.

[0053] Muitos dispositivos de descarga proveem características avançadas, tais como descarga de segmentação TCP que podem assistir com rede de alta velocidade. Sistemas e métodos em conformidade com várias modalidades podem tirar vantagem de tais características para prover rede “virtual”, tal como onde um consumidor tem acesso a um dispositivo hospedeiro assentado entre um espaço de endereço do consumidor e um espaço de endereço de rede de provedor. Tipicamente, a funcionalidade de descarga de segmentação trabalha apenas com protocolos nível quatro (“L4”) bem conhecidos, tais como TCP. Quando os pacotes são encapsulados, tais como descritos no parágrafo anterior em relação à FIG. 4, o protocolo L4 é alterado para algo outro além do TCP. Assim, as características de descarga de segmentação no dispositivo de descarga não são capazes de trabalhar em tais pacotes encapsulados. Conforme utilizado na técnica para descrever camadas entre o hardware físico (“nível um”) e uma aplicação em funcionamento naquele hardware (“nível sete”), o nível quatro refere-se a um nível de “protocolo”, que, no caso de protocolos de internet, pode se referir a protocolos tais como o Protocolo de Controle de Transmissão (TCP) e Protocolo de Datagrama de Usuário (UDP). O processamento de segmento de TCP do lado de recebimento assume que a carga útil de segmento de TCP é completamente dados do consumidor (ou outros dados tais). Assim, no lado de transmissão, os metadados relativos ao encapsulamento não podem ser adicionados à carga útil de L4 a fim de reter o header de L4 original, como a adição de metadados levaria o lado de recebimento a corromper a carga útil de pacote com metadados de encapsulamento/desencapsulamento.

[0054] Outro problema em potencial com a existência de encapsulamento e/ou implementações de rede de sobreposição é que os headers frequentemente não incluem informação de porta física, que é utilizada por dispositivos de hardware convencionais para propósitos tais como roteamento e equilíbrio de carga.

[0055] Várias modalidades podem utilizar header de TCP falso com números de portal originais ou, em alguns casos, falsos, onde o header é estendido seguindo as regras de protocolo estabelecidas (por exemplo, opções de TCP) e a informação de encapsulamento/desencapsulamento é atravessada na extensão de protocolo. Um header de TCP “falso”, por exemplo, podem incluir qualquer informação de porta apropriada à convenção em adição a qualquer informação relativa à TCP apropriada. Ao incluir essa informação de porta falsa, roteadores convencionais e outros dispositivos tais podem obter distribuição de carga melhorada, como muitas decisões de distribuição de carga à base de dispositivos de hardware convencionais pelo menos em parte mediante a porta especificada no header. Um roteador ou dispositivo de descarga pode ver um endereço de IP e informação de TCP, por exemplo, e pode processar o pacote como um pacote padrão. Uma abordagem tal pode também ser vantajosa uma vez que pode ser implementada primariamente em software utilizando dispositivos de hardware convencionais e redes.

[0056] Um protocolo também pode ser utilizado que não altera a carga útil de nível quatro (na pilha de rede, conforme discutido acima). Como o pacote original recebido a partir de um usuário pode incluir a carga útil (aqui, uma carga útil de nível quatro), juntamente com um endereço de IP virtual (em nível três na pilha de rede) e um header de TCP original (em nível quatro). Utilizando uma abordagem de encapsulamento, conforme discutido anteriormente, um hospedeiro de controle pode anexar um endereço verdadeiro, tal como IPR, e um header de TCP falso, TCPF, (ou UDPF, por exemplo) para uso no roteamento do pacote (ou quadro) na rede física ou segura. Para o pacote após o encapsulamento, o endereço de IP virtual original, o TCP (ou UDP, etc.), e a informação de carga útil agora efetivamente forma a carga útil de nível quatro, com IPR formando os endereços de nível três e TCPF formando o header de protocolo de nível quatro. Uma vez que os pacotes têm números de porta originais ou falsos, tal como um formato pode também resolver questões tais como a questão de dispersão de ECMP de roteador mencionada anteriormente. Um NIC convencional ou dispositivo similar, entretanto, não saberá como dividir apropriadamente um pacote de 64K ou similar de acordo com o quadro encapsulado, uma vez que o NIC não será capaz de interpretar apropriadamente a informação agora contida dentro da carga útil de nível quatro. Também, conforme discutido, a carga útil de nível quatro se alterou através da inclusão da informação de IPv e TCPO.

[0057] Várias modalidades podem, ao contrário, tirar vantagem de um formato de protocolo levemente modificado para lidar com os pacotes encapsulados. Protocolos convencionais proveem espaço extra na extremidade de um header de TCP, que tipicamente permite o que são referidas como “opções de TCP” ou “add-ons de TCP”. Essas opções de TCP permitem que o protocolo de TCP como sendo expandido para incluir características adicionais. Em algumas modalidades, o pacote de TCP para efetivamente ser estendido em cerca de 24 bytes, com a informação adicional sempre declarada como uma escolha de TCP. Conforme deve ser compreendido, os pacotes podem ser estendidos por quantidades diferentes em modalidades e/ou implementações diferentes, e uma extensão de 24 bytes é apenas um exemplo. O header de TCP falso, assim, pode incluir a informação de TCP original, mais a informação de header de controle. A informação para o endereço de IP virtual pode também ser incluída nesse espaço de escolha de TCP. Assim, em vez de adicionar os cabeçalhos reais durante o encapsulamento e modificação da carga útil, a informação de IPv e TCPO pode ser incluída nas opções de seção de TCP do TCP falso, de modo que a carga útil ou porção de dados é inalterada.

[0058] Em um processo exemplar para gerenciar informação de pacote em relação a um ambiente virtualizado, um pacote é recebido, que inclui informação de endereço virtual. Se recebido para um dispositivo hospedeiro ou outra máquina para a qual o usuário tem acesso substancialmente integral, o pacote é direcionado a um ou mais dispositivos ou componentes a montante do hardware controlável por usuário, de modo que o usuário é incapaz de modificar o roteamento e outro processamento tal. O pacote transmitido entre componentes, tais como a partir do convidado para DOM-0, pode ser de até 64KB em tamanho em algumas modalidades, e, assim, pode requerer segmentação. A informação de mapeamento para o pacote pode ser determinada, tal como pelo contato de um serviço de mapeamento para determinar a informação de endereço físico que corresponde à informação de endereço virtual. A informação de endereço pode ser adicionada à mensagem recebida, tal como a um header (tal como uma seção de IPR), onde a informação de endereço corresponde ao endereço físico ao qual o pacote deve ser direcionado. A informação de endereço virtual pode ser adicionada a um header de protocolo, tal como um header de TCP, para o pacote, sem modificar a carga útil, de modo que o pacote pode ainda ser roteado, segmentado, e processado de outro modo através do hardware de comodidade. O pacote é transmitido ao dispositivo de descarga, que pode segmentar os pacotes utilizando funcionalidade de TCP de descarga de segmentação e transmitir os pacotes resultantes ao cabo, e então para o destino final. Conforme deve ser evidente, funcionalidade similar pode ser utilizada para processar pacotes recebidos a partir de um espaço de endereço físico, em que a informação de mapeamento é determinada para o pacote e informação de endereço virtual é adicionada ao pacote. Onde a informação de mapeamento virtual não especifica uma porta, uma porta “falsa” pode ser utilizada, o que permite que o pacote seja processado a caminho do destino virtual, tal como para permitir o equilíbrio de carga ou funcionalidade similar.

[0059] Em um exemplo de um processo similar para gerenciamento de informação de pacote em relação a um ambiente virtualizado, um quadro de Ethernet é recebido para uma interface de rede física (por exemplo, um NIC), onde o quadro inclui informação de endereço físico. Segmentos com informação, tal como IPR e TCPF, podem ser coalescidos em algumas modalidades, para gerar um ou mais segmentos maiores, o que melhora o desempenho. Isso pode também ser feito através de NICs de comodidade que suporta a Coalescência de Lado de Recebimento, uma vez que o formato de pacote segue todas as regras de formato de TCP e a carga útil de TCP é exatamente a mesma que o pacote de carga útil do consumidor. O dispositivo de descarga (ou outro dispositivo tal) está a montante do hardware controlável por usuário, de modo que o usuário é incapaz de modificar o roteamento e outro processamento tal. A informação de endereço virtual pode ser extraída a partir do header de protocolo, tal como um header de TCP, para a carga útil, após a remoção do header e informação de enquadramento de footer, por exemplo. A informação de endereço virtual pode ser utilizada para montar um header para o pacote de dados, extraído a partir do quadro de Ethernet recebido. O pacote então pode ser processado, tal como através de transmissão do pacote a um destino no espaço de endereço virtual. Conforme deve ser evidente, funcionalidade similar pode ser utilizada para processar quadros de Ethernet recebidos a partir de um espaço de endereço virtual, em que a informação de endereço virtual é extraída a partir do header para o pacote.

[0060] Simplesmente estender o header de TCP pode não ser desejável em algumas modalidades, entretanto, como se cada pacote recebido for de 1,5K, e 24 bytes de informação forem adicionados a cada um desses pacotes, então os pacotes seriam agora cada um de mais que 1,5K de limite de produção e cada um precisaria ser dividido em dois pacotes, o que pode levar a uma quantidade indesejável de tráfego excedente e adicional. Isso, assim, pode ser desejável em pelo menos algumas modalidades para utilizar essa informação adicional enquanto não aumenta significativamente o excedente.

[0061] Várias modalidades tiram vantagem do fato de que a informação, tal como a informação de IPv e TCPO, não é necessária para cada pacote mediante segmentação, mas pode ser determinada mediante desegmentação. Uma abordagem, assim, é tomar a informação adicional para a informação de IPv e TCPO, etc., (cerca de 24 bytes em um exemplo) e criar informação codificada (cerca de 120 bytes em um exemplo), que, em uma modalidade, é aproximadamente uma para cinco instâncias da informação em várias modalidades, embora outros comprimentos de informação codificada possam ser utilizados também, tal como, pode depender da técnica de dispersão. A informação codificada pode ser reconstruída utilizando uma dispersão ou mecanismo similar de modo que a informação original pode ser reconstruída a partir de pelo menos 24 bytes de metadados dispersos, o que poderia ser obtido a partir de uma ou mais instâncias do segmento de pacote. Assim, em vez de acionar 24 bytes a cada segmento de pacote, por exemplo, os mais ou menos 120 bytes adicionais podem ser divididos em número de peças apropriado e podem ser posicionados estrategicamente ao longo da carga útil, tal como em fronteiras onde os dados serão segmentados. Por exemplo, um dispositivo de descarga ou dispositivo similar pode saber que os dados serão segmentados automaticamente com base no tamanho em certas localizações (incluindo os 50 bytes adicionais). Uma vez que essas localizações de segmentação são conhecidas, o dispositivo de descarga pode inserir as instâncias da informação adicional nessas linhas de segmento (ou, de outro modo, dentro de segmentos diferentes) de modo que pelo menos cinco dos pacotes de 1,5K (ou qualquer outro número apropriado de um tamanho apropriado) terão informação para o IPv e TCPO armazenada nos mesmos, mas cada pacote não incluirá todos os 10 bytes de informação adicional.

[0062] Quando os pacotes são recebidos, um processo de desegmentação pode ocorrer como com sistemas convencionais. Quando os segmentos de 1,5K são montados na carga útil de 64K, ou durante o processo de desegmentação, as porções de informação podem ser utilizadas para reconstruir a informação de IPv e TCPO, etc. Uma vantagem para a utilização de um processo de dispersão e distribuição da informação dentre os vários pacotes, por exemplo, é que a informação de IPv e TCPO pode ser reconstruída mesmo se os pacotes de 1,5K forem perdidos, desde que pelo menos dois segmentos com as porções de informação sejam recebidos. A carga útil completa pode não ser capaz de ser reconstruída, mas pelo menos a informação de header pode ser reconstruída. Ademais, o dispositivo de recepção pode simplesmente requisitar aqueles segmentos de 1,5K (por exemplo, quadros de Ethernet) que não são recebidos, uma vez que a informação de header pode ser reconstruída, e, portanto, não necessita requisitar o reenvio da carga útil completa. Uma abordagem tal pode ter uma variação de instabilidade muito menor, uma vez que frequentemente não haverá necessidade de reenviar pacotes grandes, o que poderia resultar em grandes variações em desempenho. No caso de tráfego de vídeo, por exemplo, desde que os dados perdidos não sejam significativos, o tráfego perdido pode ser negligenciado e, assim, não necessitam ser requeridos em pelo menos algumas modalidades. Isso é uma vantagem de ser capaz de receber segmentos parciais com sucesso.

[0063] Em um processo exemplar para processamento de pacotes em um ambiente virtualizado, um pacote é recebido a partir de um espaço de endereço do consumidor, o que inclui informação de endereço virtual. Conforme discutido, o pacote inicial recebido a partir do usuário pode ser um pacote de 64K com informação de IPv e TCPO. O pacote pode ser recebido ou direcionado a um hospedeiro de controle ou outro componente seguro tal, que está menos parcialmente inacessível um usuário de um dispositivo particionado de consumidor. A informação de endereço virtual pode ser traduzida em um endereço verdadeiro utilizando o componente seguro, tal como através do contato de um serviço de mapeamento conforme discutido acima. O header de TCP (ou outro header de protocolo) pode ser atualizado se desejado, mas a informação adicional, tal como a informação de IPv e TCPO pode, em vez disso, ser inserida nos dados. Quando a adição da informação de IPv e TCPO aos dados, essa informação de “virtualização” pode ser dispersa ou dividida de outro modo em porções múltiplas. Se ainda não for determinada, um dispositivo seguro pode descobrir os limites de segmentação para a via de transmissão, e fronteiras para a carga útil de segmentos do usuário podem ser determinadas. As porções da informação de virtualização podem ser posicionadas adjacentes a, ou posicionadas em relação a, fronteiras de segmentação em pacotes centrais da carga útil. O “novo” pacote ou quadro então pode ser passado adiante para o dispositivo de descarga ou outro dispositivo seguro tal, por exemplo, que pode segmentar automaticamente o pacote em um conjunto de pacotes do tamanho determinado, tal como pacotes de 1,5K, com o número de segmentos dependendo pelo menos em parte do tamanho do pacote total. O IP e header de TCP podem ser replicados para cada pacote, com potencialmente algumas pequenas alterações para compensar a alteração total em tamanho, utilizando processos de descarga de segmentação do dispositivo de descarga ou outro dispositivo tal. Os pacotes podem então ser transmitidos ao destino.

[0064] Um processo similar pode ser utilizado para processar pacotes para um ambiente virtualizado, em que um conjunto de quadros de Ethernet é recebido, pelo menos alguns dos quadros de Ethernet incluindo informação de “virtualização” que foi disperso ou dividido de outro modo em porções múltiplas. A informação de virtualização pode ser extraída a partir do segmento subjacente de cada quadro que inclui uma porção da informação de virtualização na carga útil associada. A informação de virtualização (por exemplo, dados de header) é remontada, desde que um número suficiente de quadros incluindo a informação de virtualização fosse recebido, e os pacotes recebidos podem ser desegmentados até a extensão possível. Se nem todos os quadros forem recebidos, mas os dados de header forem capazes de serem remontados, uma solicitação para apenas os segmentos faltantes pode ser enviada.

[0065] Quando pelo menos a maior parte dos pacotes é finalmente recebida em um destino, ou o dispositivo ao longo da via para o destino, o dispositivo pode tentar desegmentar ou remontar esses pacotes em pelo menos um segmento maior, se não o pacote de 64K integral ou outro pacote. Desde que dois pacotes (ou um número menor de pacotes que foi gerado originalmente durante a segmentação onde o número de pacotes necessário é determinado através da técnica de dispersão específica) com informação adicional de header na carga útil é recebido, em pelo menos algumas modalidades, esses pacotes podem ser utilizados para reconstruir os dados de header e desegmentar os pacotes, substituindo o endereço verdadeiro e informação de protocolo com informação para a rede de cliente ou virtual, por meio de que os segmentos montados maiores podem ser passados adiante para o cliente ou outro destino. Em algumas modalidades, a desegmentação pode ocorrer em um dispositivo de descarga ou dispositivo similar, enquanto que, em outras modalidades, a desegmentação pode ocorrer utilizando o sistema de operação convidado em um dispositivo de recepção, etc. Ademais, várias etapas do processo acima podem ser desempenhadas em qualquer outra ordem, ou em paralelo, e menos etapas alternativas ou adicionais são possíveis dentro do escopo das várias modalidades.

[0066] Utilizando a virtualização, um número de instâncias de máquina virtual pode ser gerado, que aparecem e funcionam para um usuário como sendo uma parte da rede do consumidor, mas que são mapeadas para servidores reais ou outros recursos físicos em uma nuvem remota ou separada, rede, etc. Conforme discutido, a utilização de um espaço padronizado de endereço pode requerer a construção e manutenção de um mapeamento entre os endereços de substrato físico e os endereços de sobreposição virtual que são utilizados para o espaço de endereço do consumidor. Em algumas abordagens existentes, uma unidade de processamento central funcionando em um dispositivo hospedeiro pode controlar o mapeamento dos endereços físicos e virtuais, de modo que uma solicitação recebida a partir de um consumidor pode ser direcionada ao recurso apropriado. Isso pode tomar a forma de encapsulamento e desencapsulamento de pacote de dados, por exemplo, em que o endereço físico e/ou informação de header podem “coexistir” em vários tempos com o endereço virtual e/ou informação de header, de modo que um pacote pode ser endereçado ao endereço virtual através de uma fonte na rede do consumidor, mas pode ser roteada apropriadamente ao endereço físico apropriado.

[0067] Um framework pode ser implementado através de componentes de rede convencionais ou outros, tais como dispositivos de NIC de comodidade, que podem permitir que esses componentes suportem protocolos múltiplos, tais como uma variedade de protocolos de proprietário e padrão diferentes. Esses dispositivos de mercadoria então podem prover o desempenho aprimorado e outras vantagens utilizadas para os protocolos convencionais desses dispositivos, independente do formato específico de consumidor dos pacotes. Um vendedor de NIC, por exemplo, pode implementar um framework que permite que o NIC seja utilizado por um consumidor com qualquer protocolo compatível, sem qualquer personalização ou necessidade de hardware especial.

[0068] Em um exemplo, um dispositivo de descarga em uma rede ambiente pode processar segmentos de TCP. A rede do consumidor pode utilizar pacotes de um tamanho (por exemplo, 64K) que não pode tipicamente ser passado a partir do dispositivo de descarga para fora na rede, conforme o dispositivo de descarga pode apenas ser capaz de transmitir pacotes de rede na ordem de 8K ou 9K em tamanho, por exemplo (dependendo da configuração de rede e outras questões tais). Conforme discutido acima, há tecnologias que permitem que pacotes maiores sejam segmentados no dispositivo de descarga em quadros de Ethernet múltiplos do tamanho apropriado (por exemplo, 1,5K ou 9K, etc.). Por exemplo, Descarga de Segmentação de TCP (TSO) e Coalescência de Lado de Recebimento (RSC) podem ser utilizadas para os pontos de extremidade de ingresso e egresso, respectivamente, para aumentar o desempenho de rendimento de rede ao permitir que o hospedeiro lide com segmentos maiores de TCP (por exemplo, 64K em tamanho). TSO é uma técnica para segmentação de pacotes de TCP em segmentos do tamanho apropriado para transmissão longo da rede, e RSC permite que esses segmentos sejam remontados no outro lado da rede. Em geral, entretanto, técnicas tais como TSO e RSC não são suportadas para pacotes encapsulados com informação de protocolo de proprietário, tal como a informação adicional de header ilustrada na FIG. 4(b). Por exemplo, pacotes que são encapsulados utilizando um formato de proprietário são tipicamente maiores que pacotes de TCP e não têm a informação de TCP de header antecipada, de modo que o dispositivo de descarga não reconhecerá esses pacotes encapsulados.

[0069] Através da implementação de um framework apropriado, entretanto, um dispositivo de descarga ou outro componente de rede apropriado pode ter a capacidade e especificações para mapear o pacote encapsulado para algo que o componente pode compreender como um pacote de TCP. Uma vez que um dispositivo de descarga reconhece o pacote como um pacote de TCP, por exemplo, o dispositivo de descarga pode segmentar o pacote, adicionar os cabeçalhos apropriado, e/ou fazer qualquer uma das outras coisas que um dispositivo de descarga tipicamente faria para um pacote de TCP convencional. Mesmo para pacotes encapsulados com qualquer um dentre uma variedade de protocolos diferentes, TSO e RSC podem prover uma melhoria significativa (por exemplo, até uma amplificação de desempenho de 80%) bem como outras vantagens bem estabelecidas. Ademais, ao implementar um framework, os dispositivos de descarga não podem apenas ser utilizados com protocolos diferentes, mas também podem permitir que consumidores atualizem para versões mais recentes ou alterem protocolos sem ter que adquirir, atualizar para versões mais recentes, ou modificar seu hardware existente.

[0070] Um campo opaco pode ser utilizado com um pacote encapsulado para incluir qualquer informação utilizada pelo formato ou protocolo particular da rede do consumidor, tal como s GRE ou outros protocolos tais. O campo opaco em pelo menos algumas modalidades é um header à base de TCP ou UDP, ou outro header de protocolo tal. Em um exemplo, o header opaco tem um primeiro conjunto de informação em um deslocamento especificado no campo opaco que indica ou identifica o formato particular do segmento ou pacote. Por exemplo, a informação pode ser um campo de dois bytes que inclui um calor correspondente a um formato particular. O hardware de rede pode conter, ou ter acesso a, um mapeamento de valores a partir do primeiro valor de deslocamento e dos formatos correspondentes a fim de determinar, a partir do valor do primeiro conjunto de informação, o formato apropriado do pacote.

[0071] Nesse exemplo, o campo opaco também inclui um segundo campo de informação em um segundo deslocamento especificado no campo opaco. Esse segundo campo pode ser de um comprimento apropriado, tal como dois bytes, e pode incluir um valor que especifica um identificador de fluxo, ou um identificador para um fluxo de tráfego específico, como pode ser útil para a desegmentação. Em algumas modalidades, esse campo pode identificar um fluxo de TCP único (ou outros fluxos, tais como um fluxo de UDP) juntamente com um 5-tuplo regular quando desempenha uma operação de ISO ou RSC em um pacote de formato particular.

[0072] Esses exemplos podem corresponder a um ambiente para um protocolo específico, por exemplo, onde o header tem informação tal como a rede virtual à qual o pacote pertence, a máquina virtual a partir da qual o pacote originou, e/ou a máquina virtual para a qual o pacote está se dirigindo. Essa informação não se alterará entre pacotes dentro de uma corrente de TCP comum. IDs de fenda, ou identificadores de máquina virtual, podem ser utilizados para informação de conexão, uma vez quem, em um ambiente de rede virtualizado, por exemplo, possa haver duas máquinas virtuais diferentes no mesmo hospedeiro físico que pertence a duas redes virtuais diferentes. Aquelas máquinas virtuais poderiam ter exatamente o mesmo endereço de IP, e poderiam se comunicar potencialmente com alguém que coincidentemente tem a mesma porta e endereço de IP. A partir de um ponto de vista de TCP, o 5-tuplo pode ser exatamente o mesmo. Outra informação, tal como o IP de fonte e IP de destino, porta- fonte e porta-alvo, etc., pode também ser exatamente a mesma. Assim, a partir de um ponto de vista de TCP, as conexões aparentam ser a mesma conexão, mas poderia, na realidade, estar em duas redes privadas diferentes. O uso de IDs de fenda pode separar de modo único essas situações. Para outros protocolos, outros valores além dos identificadores de máquina virtual podem ser utilizados conforme seria evidente.

[0073] Em um exemplo, um pacote encapsulado é recebido para um dispositivo de descarga. O dispositivo de descarga, utilizando as especificações do framework, pode analisar o pacote para identificar que o pacote é encapsulado e deve ser manuseado diferentemente de um pacote de TCP ou UDP convencional. Em um exemplo, um pacote encapsulado inclui cabeçalhos de IP interno e externo. O pacote encapsulado também tem um campo opaco (que pode aparecer como parte da carga útil), que pode ser utilizada para informação específica do protocolo. O comprimento do campo opaco, e a informação contida no mesmo, pode variar entre modalidades. A fim de identificar o pacote como sendo encapsulado, o header de IP externo pode conter informação de protocolo pré-configurada. Ademais, o pacote pode conter pelo menos um campo de dois bytes no campo opaco (embora outros tamanhos e localizações possam ser utilizados também dentro do escopo de outras modalidades). O campo de dois bytes pode ser uma distância pré-configurada a partir do início do campo opaco, e o valor do campo de dois bytes também pode ser pré-configurado. A combinação da informação de protocolo no header de IP externo e a informação de formato no campo de dois bytes do campo opaco podem permitir que o dispositivo de descarga ou componente de rede reconheça que o pacote é encapsulado, bem como o formato do encapsulamento. Uma vez que o dispositivo de descarga não vê de outro modo outra informação no header opaco, o header opaco pode incluir informação específica para qualquer protocolo particular sem afetar o processamento do pacote pelo dispositivo de descarga. Os dois bytes no header opaco podem identificar um formato específico do pacote, que pode auxiliar na determinação das regras ou políticas para processamento do pacote. Com base nessa informação no header de IP externo e campo opaco, o dispositivo de descarga pode analisar cada pacote recebido para determinar se o pacote pode ser processado utilizando abordagens convencionais ou se o pacote é um pacote encapsulado e deve ser processado de acordo com regras especiais especificados pelo framework.

[0074] Durante um processo de TSO, por exemplo, a segmentação de segmentos de TCP de egresso (por exemplo, de saída) pode ser desempenhada utilizando um algoritmo padrão nos dados de segmento de TCP iniciando no header de IP interno. O pacote encapsulado grande é segmentado em um número de pacotes de um tamanho que permite que os segmentos sejam transmitidos ao longo da rede. A fim de que o framework também funcione com tunelamento sem estado, o campo opaco é copiado literalmente para cada um dos pacotes de TCP/IP segmentados resultantes, e posicionado entre os cabeçalhos de IP interno e externo. O header de IP externo é copiado para cada pacote resultante e ajustes apropriados, tal como uma alteração para a informação de “comprimento”, podem ser feitos utilizando a mesma lógica aplicada ao header de IP interno. Ademais, um ID de IP pode ser gerado, que é parte do header de IP, juntamente com uma soma de verificação para o header de IP.

[0075] De modo semelhante, durante um processo de RSC, fluxos de TCP dos pacotes ou segmentos tendo a informação de formato de protocolo especial são definidos por 5-tuplo regular das portas de TCP, o endereços de IP internos, o campo de protocolo de IP interno, e as portas de L4 internas (por exemplo, portas de TCP ou UDP portas), bem como um adicional de dois bytes no deslocamento pré- configurado a partir do início de campo opaco. Deve ser compreendido que fluxos de TCP dos pacotes de formato especial não irão se sobrepor aos fluxos de pacotes regulares. Ademais, deve ser compreendido que termos tais como “pacotes” são utilizados inteiramente para propósitos de simplicidade da explicação, mas em outas localizações ou processos de instâncias podem envolver objetos mais comumente referidos como segmentos ou quadros, e o nome comum para um único objeto pode se alterar entre esses e outros termos em vários pontos nos processos discutidos aqui.

[0076] RSC é desempenhado utilizando um algoritmo convencional nos dados de pacote de TCP iniciando no header de IP interno. Quando em coalescência dos pacotes de TCP relacionados, o campo opaco a partir do primeiro pacote de TCP pode ser copiado para o segmento de TCP resultante entre o header de IP interno e o header de IP externo. O header de IP externo do segmento de TCP resultante pode ser coalescido do mesmo modo que o header de IP interno é coalescido. Caso haja restrições nos sinalizadores de IP (por exemplo, “Não fragmentar” ou “Mais bit”) que force os pacotes de ingresso a serem inelegíveis para RSC, as restrições podem ser aplicadas aos sinalizadores de IP em ambos os cabeçalhos de IP interno e externo.

[0077] RSC pode manter recipientes de dispersão (ou outras filas de espera ou localizações de armazenamento temporário) para cada conexão para a qual os pacotes estão sendo recebidos. Quando um pacote de TCP é recebido, o dispositivo de recepção então pode determinar a conexão à qual o pacote pertence, utilizando informação, tal como o IP e informação de TCP bem como bits de número de sequência no header de TCP externo, e pode enfileirar o pacote para o recipiente de dispersão apropriado. Para recipientes onde já há pacotes, o componente de rede pode tentar fundir os pacotes segmentados até que o pacote completo tenha sido coalescido. Critérios convencionais podem se aplicar, tais como o envio do pacote coalescido para o sistema de operação quando o tamanho alcança certo limiar ou os pacotes são enfileirados para um comprimento específico ou faixa de tempo.

[0078] Em pelo menos algumas modalidades, entretanto, o conceito de uma conexão diferirá a partir de uma conexão para processamento de pacote de TCP padrão. Ao invés do 5- tuplo convencional, mencionado acima, conexões serão determinadas com base em um 6-tuplo, que inclui a informação de conexão de TCP padrão do 5-tuplo juntamente com o novo pedaço de informação de conexão identificado nos dois bytes do campo opaco. Uma vez que o componente de rede descobre que o pacote deve ser processado utilizando as regras especiais, o componente utiliza o 6-tuplo ao invés do 5-tuplo para descobrir a informação de conexão, e então executa o processo de RSC essencialmente o mesmo que para os pacotes convencionais, para coalescer os pacotes, verificar o número de sequência, etc.

[0079] Adicionalmente, o RSC também, em muitos casos, necessita se desfazer dos bits opacos completamente, mas aquele dos pacotes sendo coalescidos, tal como o primeiro pacote recebido em algumas modalidades. Em algumas modalidades, o RSC pode não ser desempenhado quando os campos opacos não coincidem, de modo que os campos opacos a partir de outros não serão descartados pelo menos até aqueles pacotes poderem ser processados de outro modo. Após uma cópia dos bits opacos ser recebida e armazenada (pelo menos armazenada temporariamente ou em cache, por exemplo), bits opacos de todos os outros pacotes a serem coalescidos, que coincidem com a cópia armazenada do campo opaco, podem ser descartados pelo dispositivo de descarga. Ademais, uma vez que o comprimento total do pacote está se alterando durante a fusão do dispositivo de descarga terão que fazer ajustes apropriados à soma de verificação, header de sinalizadores de IP, ou outra informação tal, tanto para o header de IP interno quanto de IP externo. Nos campos opacos, e em outro local, a contagem de bytes e outros aspectos poderiam também ser garantidos. Além dos dois bytes (ou n-bytes) de informação utilizados para identificação, a expectativa é que o resto dos bits opacos serão exatamente os mesmos para todos os pacotes dentro de uma corrente de TCP particular. Em um exemplo de protocolo, a informação opaca poderia corresponder a um identificador de rede específico. Pode haver também outra informação, tal como um identificador de máquina virtual ou ID de fenda, que seria o mesmo para cada pacote em uma corrente de TCP. Em particular, os n-bytes podem identificar o pacote como correspondente a uma máquina virtual particular.

[0080] Em muitas modalidades, o framework se apoia em valores pré-configurados específicos. Por exemplo, conforme discutido acima, o framework pode se apoiar em um comprimento pré-configurado do campo opaco, bem como um valor de protocolo de IP que identifica formatos especiais ou específicos para os pacotes recebidos. O comprimento do campo opaco, em algumas modalidades, corresponde ao comprimento do header para o formato especial do pacote. O valor de protocolo de IP poderia ser qualquer identificador apropriado para um protocolo específico. O framework pode esperar que o deslocamento do campo de n-byte no campo opaco que identifica o formato seja pré-configurado. Em algumas modalidades, isso pode corresponder a um valor de porta específico.

[0081] Os valores pré-configurados específicos do campo opaco podem variar para certos protocolos. Por exemplo, o comprimento do campo opaco para suporte de GRE pode ser de 16 bytes em uma modalidade, com o valor de protocolo de IP que identifica um formato de segmento ou pacote específico estabelecido para um valor tal como 47. O valor de deslocamento que identifica um fluxo único pode ser estabelecido para um valor tal como 10 para apontar para uma parte de um campo-‘chave’ ou outro valor tal.

[0082] No caso de um protocolo exemplar, o comprimento do campo opaco pode coincidir com o comprimento de um header específico de protocolo, com um valor tal como 20. O valor de protocolo de IP que identifica pacotes ou segmentos de um protocolo particular pode ser estabelecido para o número de protocolo IANA para UDP, por exemplo, com um valor tal como 17. O valor de deslocamento no campo opaco que identifica pacotes ou segmentos de um formato particular pode se apoiar pelo menos em parte na porta de UDP específica utilizada, tal como uma porta de destino de UDP com um valor 2. O valor do campo que identifica um fluxo único quando desempenhando TSO ou RSC pode especificar a fenda de fonte e IDs de fenda-alvo juntamente com o 5-tuplo de conexão regular para identificar um fluxo de TCP único. Deve ser compreendido que abordagens similares podem ser utilizadas para determinar valores para outros protocolos dentro do escopo das várias modalidades.

[0083] Conforme mencionado acima, um objetivo de um ambiente tal como uma plataforma de computação em nuvem pode ser prover a cada consumidor a ilusão de que uma porção da infraestrutura de rede é dedicada àquele consumidor. A fim de prover essa ilusão, a plataforma necessita prover certos níveis de desempenho, tais como poder incluir desempenho de rede de alto rendimento, baixa latência e baixa instabilidade. Apesar de que a instabilidade deve sempre ser geralmente baixa, a definição de baixa latência e alto rendimento para uma dada implementação depende de fatores, tais como o equipamento de rede física e design do produto, e poderá variar entre as instâncias. A ilusão pode também ser provida em parte ao permitir que o consumidor defina uma topologia de rede de nível dois (L2) ou nível três (L3) personalizada, sem restrições de endereçamento resultando a parir de outras preferências do consumidor. Em certos ambientes, tal como o ambiente de Nuvem Privada Virtual (VPC) oferecido pela Amazon.com, Inc. de Seattle, Washington, a opção de uma rede roteável L2 ou L3 personalizável é obtida amplamente através da implementação de um software sofisticado de tunelamento de endereço de IP. Em pelo menos algumas dessas implementações de software, entretanto, pode ser difícil manter o desempenho de rede de alto rendimento, baixa latência e baixa instabilidade em um ambiente virtualizado. O problema pode ser adicionalmente exacerbado conforme as tendências de hardware atual continuam com mais núcleos, RAM, e máquinas virtuais por hospedeiro, colocando um fardo crescente no subsistema de rede. Embora os ganhos possam ser feitos através da otimização da pilha de software de extremidade a extremidade, pode ser benéfico em pelo menos some ambientes o provimento de uma assistência de hardware na virtualização de recursos de rede.

[0084] A fim de satisfazer pelo menos alguns dos objetivos delineados acima, o hardware, tal como vários dispositivos de descarga, pode necessitar incluir várias características. Conforme utilizado aqui, processamento “à base de hardware” geralmente refere-se a qualquer processamento em que um dispositivo de hardware desempenha pelo menos uma parte daquele processamento, ou em que um componente de processamento se apresenta como um dispositivo físico (por exemplo, um NIC), mas pode na verdade ser implementado como hardware e/ou software. Em algumas modalidades, processamento à base de hardware pode ser provido através de um dispositivo de descarga genérico ou sistema embutido que aparenta aos componentes do sistema como sendo pelo menos um componente de hardware. Como um exemplo, um dispositivo de descarga genérico pode ser utilizado, que apresenta em si um dispositivo de SR-IOV. Uma discussão dessas características será provida dando-se um panorama de alto nível das vias de ingresso e egresso propostas, seguido por detalhes sobre estágios individuais que podem ser implementados em conformidade com várias modalidades. Por exemplo, a FIG. 6 ilustra um formato exemplar 600 de um pacote virtual tal. A FIG. 7 ilustra um panorama de alto nível de um processo de egresso de hardware de descarga exemplar 700 que pode ser utilizado com tais pacotes de consumidor de um consumidor em um centro de dados virtualizado em conformidade com pelo menos uma modalidade. Como parte do processo de egresso, uma Função Virtual (VF) de SR-IOV designada à máquina virtual de consumidor recebe um pacote de egresso destinado para a rede virtual do consumidor 702. Nesse estado inicial, os componentes internos 608, 610, 612 do header de pacote 600 estão presentes, enquanto que os componentes externos 602, 604, 606 e 614 não estão presentes. Uma ou mais verificações genéricas podem ser aplicadas aos pacotes de egresso 704. Essas verificações podem incluir, por exemplo, anti-marcaramento de fonte de L2 e/ou L3, bem como o aprisionamento para todos os pacotes de broadcast e não-IP (ou seja, para serviços de DHCP, ARP, etc.). O dispositivo de descarga pode desempenhar uma busca em uma tabela de regras pré-populada 706, tal como pode ser com base em um destino de L2 e um destino de L3 com uma máscara de sub- rede, com um caso genérico sendo uma sub-rede IPV4 “/32” que especifica um único alvo. Assumindo um hit de regra com um tipo de regra de encaminhamento, a regra pode também especificar um apontador em memória de sistema ao header de túnel que o dispositivo de descarga incluirá ao pacote de saída. Nesse ponto, o pacote pode também incluir os componentes externos iniciais 602, 604, 606. O dispositivo de descarga pode desempenhar uma ou mais atualizações métricas 708, que são discutidas em mais detalhes abaixo.

[0085] Com base pelo menos em parte na coincidência de regra (ou falta de uma coincidência de regra), o dispositivo de descarga pode determinar uma ação apropriada a ser tomada 710. As ações podem incluir, por exemplo, para aprisionar o domínio de raiz confiável 712, deixar o pacote 714, ou encaminhar o pacote com encapsulamento e/ou deformação 716. Se o dispositivo de descarga decidir aprisionar o pacote ao domínio confiável 712, uma chamada de retorno de driver pode permitir que o domínio confiável desempenhe processamento à base de software do pacote adicional. Se o dispositivo de descarga decidir deixar o pacote 714, nenhum processamento adicional será feito (em pelo menos algumas modalidades). Se o dispositivo de descarga, em vez disso, decide encaminhar o pacote 716, o processamento adicional pode ser requerido antes do pacote poder ser liberado para a rede física. Nesse exemplo, o dispositivo de descarga realiza a ação de QoS e regulagem no pacote 718, tal como é descrito abaixo em mais detalhes. O dispositivo de descarga também pode construir e/ou deformar o pacote final que será alimentado ao motor de descarga 720. Os componentes de header de pacote externo 602, 604, 606 podem ser acrescentados ao pacote. Estes podem ser recuperados através de disseminação e/ou reunião de DMA juntamente com os bytes de pacote com base em uma coincidência de regra anterior. O dispositivo de descarga então pode desempenhar a(s) descarga(s) 720, incluindo TSO se aplicável. Os campos de header de pacote podem ser atualizados conforme necessário incluindo, mas não necessariamente se limitando a, comprimento de IP interno e externo, soma de verificação de TCP interna ou externa (ou seja, caso o protocolo IP seja TCP), fonte de MAC de L2 interna e endereço de destino, e TTL de IP de L3 interno, conforme discutido em mais detalhes abaixo.

[0086] A FIG. 8 ilustra um panorama de alto nível similar de um processo de ingresso à base de hardware de dispositivo de descarga exemplar 800 para um pacote de consumidor no centro de dados virtualizado que pode ser utilizado em conformidade com pelo menos uma modalidade. Nesse processo exemplar 800, um pacote é recebido na função física de dispositivo de descarga 802. O dispositivo de descarga pode construir uma chave de busca de regra que será construída para processamento de regra subsequente 804, conforme discutido em maiores detalhes abaixo. O dispositivo de descarga então pode desempenhar uma busca em uma tabela de regras pré-populada com base na chave de busca derivada 806. O dispositivo de descarga pode desempenhar várias atualizações métricas 808 conforme necessário, e determinar a ação apropriada a ser tomada com base pelo menos em parte em uma coincidência de regra (ou falta de coincidência de regra) 810. Em uma primeira ação, o dispositivo de descarga pode decidir aprisionar o pacote ao domínio de raiz confiável 812. Nesse caso, uma chamada de retorno de driver pode permitir que o domínio confiável desempenhe processamento adicional à base de software do pacote. Em outra ação possível, o dispositivo de descarga pode decidir deixar o pacote 814, de modo que nenhum processamento adicional daquele pacote será realizado. Como outra ação possível, o dispositivo de descarga pode decidir encaminhar o pacote a uma VF interna 816, tal como com encapsulamento e/ou deformação. A ID de VF (VM) pode ser especificada na regra de encaminhamento. O dispositivo de descarga pode retirar o header de encapsulamento externos 602, 604, 606 a partir do pacote 818. Nenhuma deformação interna é requerida nesse exemplo, uma vez que toda a deformação tal foi realizada anteriormente em egresso. Varias outras modificações de pacote podem ser desempenhadas também, tal como para reordenar, dividir, ou modificar de outro modo um ou mais pacotes ou porções de dados de pacote. Nesse estágio, o pacote pode ser entregue ao VM convidado através da VF convidada 820.

[0087] Conforme mencionado, uma abordagem tal pode prover deformação e encapsulamento de pacotes de pacote à base de hardware e à base de regra. Uma abordagem tal permite que consumidor de redes virtuais múltiplas (e possivelmente sobrepostas) seja sobreposto em um substrato físico roteável de L3 unificado. Uma tabela de regras comum pode ser utilizada tanto para vias de pacote de ingresso quanto de egresso, a tabela de regras sendo populada pelo domínio de raiz confiável através de mecanismos de software em pelo menos algumas modalidades.

[0088] O seguinte provê direcionamentos sobre o tamanho e desempenho de uma implementação de tabela de regras exemplar que pode ser utilizada em conformidade com várias modalidades. Uma tabela de regras exemplar pode ser na ordem de cerca de 1.000 entradas de regra (compartilhadas entre ingresso e egresso) por máquina virtual em funcionamento no hospedeiro. Embora em pelo menos algumas modalidades possa ser desejável utilizar o maior tamanho de tabela de regras possível, haverá em pelo menos alguns casos um limite no tamanho de tabela de regras imposto pelo dispositivo RAM, uma vez que o custo primário do tamanho de tabela maior será requerimentos de RAM maiores no dispositivo de descarga. Conforme o número de VMs em um hospedeiro aumenta, o número de regras pode variar correspondentemente. Por exemplo, caso haja 128 VMs e 128 VFs de SR-IOV correspondentes, haveria 128.000 entradas de regra em pelo menos uma modalidade, embora um número tal com 32.000 ou 16.000 pode ser sustentável. As entradas de regra em pelo menos algumas modalidades devem ser divisíveis entre VFs, conforme definido pelo domínio de raiz confiável. Por exemplo, uma VF poderia ter 10 entradas de regra enquanto que outra VF em 2.000 fora do número de entradas de regra total possível. O desempenho de atualizações de tabela de regras deve também ser rápido o suficiente, de modo que não cause filas excessivas no processamento de rota de pacote. Em algumas modalidades, a tabela de regras pode ser modificada em sua totalidade na ordem de a cada cinco segundos mais ou menos, durante a operação normal.

[0089] Uma tabela de regras de egresso exemplar pode ter uma variedade de campos diferentes. Em um exemplo, uma tabela de regras tem um campo de MAC (alvo coincidente) de Destino de L2 interno. Todas as regras de egresso podem ser coincididas no endereço de MAC de L2 interno. Isso permite que a rede virtual do consumidor seja de L2 apenas, se desejado (e para suportar protocolos como RoCE que não cientes de L3). A tabela também pode ter um destino IPV4/IPV6 interno opcional com campo de máscara de sub-rede (alvo coincidente). As regras de egresso podem ser opcionalmente coincididas no endereço-alvo de IP/sub-rede. O uso de regras de sub-rede permite que regras múltiplas sejam quebradas se desejado. Uma fonte de MAC de L2 interna opcional / campo de substituições de deformação de destino pode ser utilizada também. A fim de suportar uma topologia de L3 arbitrária, uma capacidade de trocar tanto o destino interno quanto os endereços de MAC de fonte para suportar os “roteadores fantasmas” pode ser suportado. Um VM pode, por exemplo, acreditar que está em sub-rede A e está tentando enviar um pacote à sub-rede B. Assim, o pacote poderia ter um header de L2 conforme construído pelo VM convidado, tal como: Endereço de fonte de MAC de L2: endereço de MAC de dispositivo de descarga de VF de hospedeiro 1 (sub-rede A) Endereço de destino de MAC de L2: endereço de MAC de caminho de sub-rede A

[0090] No tempo de egresso, pode ser desejável em pelo menos algumas modalidades ser capaz de deformar dinamicamente o HEADER de L2 interno para parecer o exemplo a seguir (de modo que, quando o pacote é descapsulado no alvo, o HEADER de L2 interno parece o que é esperado que fosse roteador(es) real(is) entre as 2 máquinas virtuais): Endereço de fonte de MAC de L2: endereço de MAC de caminho de sub-rede B Endereço de destino de MAC de L2: endereço de MAC de dispositivo de descarga de VF de hospedeiro 2 (sub-rede B) Um campo de decréscimo TTL de IP interno opcional pode também ser utilizado. A fim de suportar “roteadores fantasmas”, por exemplo, a capacidade de opcionalmente auto-descrescer o TTL de IP interno (se aplicável) pode ser requerida. Se o TTL alcança zero, o pacote deve ser aprisionado à partição de raiz confiável.

[0091] A tabela pode também ter um campo, tal como para um apontador para bolha de encapsulamento em sistema RAM. Uma tabela de bolha pode ser armazenada em memória pertencente à partição de raiz confiável. Esses endereços de memória podem ser, por exemplo, endereços físicos de hospedeiro ou endereços físicos de convidado da partição de raiz confiável, tal como pode depender de mecanismos de DMA específicos da máquina. A tabela pode também incluir campos adicionais também, tal como um campo para medições e pelo menos um campo para ações de regra. Conforme discutido acima, as ações de regra podem designar, por exemplo, para aprisionar uma partição de raiz confiável, deixar ou encapsular / deformar e encapsular um pacote.

[0092] Uma tabela de regras de ingresso exemplar pode ter vários campos também. Por exemplo, um campo de chave coincidente (alvo coincidente) pode ser utilizado para coincidência de regra de ingresso, o que pode ser um dos aspectos mais complicados do sistema. A fim de não ter hardware que requeria um formato de encapsulamento específico, um esquema pode ser utilizado que é o mais genérico possível dentro do que é razoavelmente obtenível em hardware. A FIG. 9 mostra um exemplo implementação de criação de chave de coincidência de ingresso que pode ser utilizada em conformidade com uma modalidade. O dispositivo de descarga pode utilizar várias faixas de byte definida pelo sistema e/ou intercaladores de faixa de byte 904, que pode ser programado pela partição de raiz confiável em inicialização de sistema, para intercalar faixas de byte a partir de pacotes em aproximação 902. Esses pacotes podem ser intercalados em um registro de byte temporário 906, ou outra localização apropriada. Em pelo menos uma modalidade, quatro faixas de byte de 0-128 bytes, com não mais que 256 bytes a partir do início do pacote, pode ser suficiente, onde todas as faixas de byte em conjunto não totalizem mais que 128 bytes. Uma máscara de bit amplo de sistema adicional 908 (programada pela partição de raiz confiável) então pode ser aplicada ao registro de byte para determinar quais bytes são utilizados para coincidir com a tabela de regras. A chave de coincidência de ingresso final 910 então pode ser produzida como um resultado, onde a chave pode ser utilizada para procurar a regra apropriada na tabela de regras de ingresso.

[0093] Outros campos podem ser utilizados com a tabela de regras de ingresso também. Por exemplo, um campo de ID de VM/VF pode ser utilizado, que pode especificar explicitamente o ID de VM/VF para o qual encaminhar, onde a ação de regra inclui o encaminhamento para um VM/VF. Outros campos podem incluir, por exemplo, um campo de medições e um campo de ação de regra, semelhante à tabela de regras de egresso discutida acima. As medições podem ser coletadas pelo hardware para recuperação posterior pela partição de raiz confiável. Exemplo de medições que podem ser requeridas por regra de ingresso / egresso incluem o número de bytes atuados (deixados, encaminhados, etc.) e o número de pacotes atuados (deixados, encaminhados, etc.). Cada campo métrico deve ser legível e passível de esclarecimento pela partição de raiz confiável. O tamanho dos campos pode ficar a critério do fornecedor de hardware, por exemplo, e pode assumir um método de coleta acionado por interrupção a partir da partição de raiz confiável.

[0094] Em pelo menos algumas modalidades, há pelo menos dois tipos brutos de regulamento ou possível qualidade de serviço (QoS). Um primeiro tipo é referido aqui como um tipo de regulamento de “topos rígidos”, em que cada entidade regulada é tem topo em uma quantidade específica, independentemente do uso de outras entidades reguladas no sistema. Um segundo tipo é referido aqui como um tipo “topos passíveis de ultrapassagem”, em que é permitido que entidades reguladas ultrapassem seus topos dependendo se há excesso de capacidade disponível no sistema. Em uma modalidade exemplar, a capacidade de colocar topos rígidos pode ser requerida, tal como em intervalos de 50 Mb/s (ou intervalos de 10-25 Mb/s, em algumas modalidades), em Funções Virtuais de SR-IOV. Em pelo menos algumas modalidades para utilizar, em hardware, pelo menos uma classe de regulamento por regra de egresso, de modo que tráfego diferente possa ser regulado em diferentes taxas, e uma classe de QoS por regra de egresso, de modo que tráfego diferente possa ser priorizado. Também pode ser desejável em pelo menos algumas modalidades para prover um ou mais classes de regulagens passíveis de ultrapassagem configuráveis por regra, de modo que a capacidade não utilizada pode ser consumida caso disponível e desejada.

[0095] Em pelo menos algumas modalidades, pode ser desejável prover várias verificações em pacotes. Por exemplo, em algumas modalidades, todos os pacotes de egresso devem ser verificados para o endereço de MAC de L2 correto que foi designado para a VF. Caso o pacote de egresso seja um IP de L3, o endereço de IP de fonte deve ser checado também em pelo menos algumas modalidades. Pacotes que não têm o MAC de L2 correto e/ou endereço de IP de L3 devem ser deixados em pelo menos algumas modalidades. Também pode haver a capacidade de configurar todo o tráfego de broadcast de L2 e/ou L3 para ser aprisionado à partição de raiz confiável, incluindo broadcast e multicast de IP, ARP, DHCP, etc. Ademais, a partição de raiz confiável em pelo menos algumas modalidades terá a capacidade de injetar pacotes de ingresso em filas de espera de pacote de função virtual. Esses pacotes podem contornar o sistema de encapsulamento / deformação.

[0096] Em pelo menos algumas modalidades, o hardware de dispositivo de descarga suportará pelo menos um conjunto padrão de descargas e aprimoramentos de hardware enquanto realiza o encapsulamento / deformação em funções virtuais de SR-IOV. Estas podem incluir, por exemplo, descarga de segmentação TCP (TSO) incluindo as várias descargas de soma de verificação, capacidade de multi-enfileiramento, e coalescência de interrupção. O conjunto também pode incluir suporte de RDMA (por exemplo, RoCE ou iWARP). Mesmo se um Protocolo de RDMA apenas de L2 seja utilizado, por exemplo, o fato de que o pacote é encapsulado dentro de um meio de embalagem de L3 que o protocolo de nível de aplicação pode ser agnóstico a partir do substrato de rede física subjacente.

[0097] O uso de SR-IOV pode nevar um benefício de virtualização em que o hardware subjacente não é mais abstraído. A fim de preservar o mesmo nível de flexibilidade enquanto provê funcionalidade avançada aos usuários, os fornecedores de hardware podem prover abordagens para injetar dinamicamente código de driver a partir do VMM para o VM convidado. Uma abordagem tal pode permitir que um único driver abstrato em um VM convidado para funcionar no hardware arbitrário através de uma interface comum, envolvendo assim um dispositivo de hardware completamente emulado em software ou um que seja amplamente implementado em hardware.

[0098] Adicionalmente àqueles listados acima, várias outras regras podem ser implementadas também. Por exemplo, para pacotes de egresso, pode haver uma lista de endereços de MAC de destino permissível e sub-redes de IP de destino que formam a parte ‘de coincidência’ de cada regra. Uma regra pode ter um endereço de MAC de destino e sub-rede de IP de destino, ou a regra pode ter apenas um endereço de MAC de destino, em cujo caso, todos os endereços de IP podem ser aceitos. Cada regra pode ter um header opaco de 'N' byte, um endereço de MAC de fonte, e um endereço de MAC-alvo como parte da regra. Quando uma regra é coincidida, o header opaco de 'N' byte pode ser inserido antes do header de L2 original, e os endereços de MAC no header de L2 podem ser substituídos por valores pré- especificados. Novos headers L2 e L3 externos (por exemplo, MAC e IP) podem ser inseridos em frente ao campo opaco com um endereço de IP de fonte externo, endereço de IP de destino externo, MAC de destino externo, e MAC de fonte externo a partir da tabela de regras. Opcionalmente, o header opaco pode incluir headers de L2 e L3, onde o dispositivo de descarga pode preencher em tais campos, tais como ID, comprimento, soma de verificação, e sinalizações em tempo real. Em algumas modalidades, os endereços de IP de fonte e destino interno são também substituíveis, tais como para permitir a virtualização futura de NAT, anycast, etc.

[0099] Pelo menos parte do processamento e gerenciamento pode ser desempenhada por uma interface de gerenciamento de software operável para executar em uma plataforma de hospedeiro confiável, tal como Xen Dom-0. Uma interface tal pode se com serviços distribuídos para carregar especificações de rede por inquilino em tempo real, tal como pode incluir regulamento, grupos de segurança, e componentes parceiros. A interface pode instruir um componente de descarga para executar especificações por- inquilino (SR-IOV), por exemplo. Esses comandos podem ser processados em tempo real, conforme as especificações se alteram. A interface também pode desempenhar gerenciamento estendido das regras à base de componente de descarga caso o hardware ou outro componente de descarga seja incapaz de manter concorrentemente a totalidade das regras a qualquer momento dado. Essas podem incluir, por exemplo, técnicas tais como o carregamento de regras quentes, ou um subconjunto de regras frequentemente utilizadas, enquanto processa um subconjunto de regras menos frequentemente utilizadas através de aprisionamento de software ou outro processo tal. A interface pode se diferenciar entre diferentes tipos de tráfego, tais como tráfego destinado para a plataforma de hospedeiro confiável ou um inquilino virtual, e pode entregar correspondentemente.

[00100] Em pelo menos algumas modalidades, pacotes que requerem manuseamento especial, tal como pacotes de Protocolo de Resolução de Endereço (ARP) e pacotes multicast podem também ser gerenciados por um componente de gerenciamento de software no Dom-0. Outra funcionalidade avançada, tal como DNS, uma interface de segurança, e uma interface de Web de servidor pode também ser manuseada pela interface de gerenciamento de software. Para uma interface de segurança, uma instância pode desempenhar uma conexão segura antes de obter a conectividade de rede. A interface de Web de servidor pode ser, por exemplo, uma interface para um serviço de metadados ou outra aplicação tal.

[00101] Várias modalidades podem ser descritas em vista das seguintes cláusulas: 1. Um FRAMEWORK para processamento de pacotes de dados em um ambiente de inquilinos múltiplos, compreendendo: pelo menos um processador; e memória incluindo instruções que, quando executadas pelo processador, permitem que o FRAMEWORK: comunique-se com um ou mais serviços distribuídos para carregar uma ou mais especificações de rede por inquilino; instrua pelo menos um dispositivo de descarga para executar as especificações de rede carregadas por inquilino; gerencie um conjunto de regras para o pelo menos um dispositivo de descarga quando o pelo menos um dispositivo de descarga é incapaz de armazenar concorrentemente todas dentre o conjunto de regras; e entregue pacotes de dados para um destino apropriado para cada um dentre uma pluralidade de tipos de tráfego. 2. O FRAMEWORK da cláusula 1, em que o FRAMEWORK provê uma interface de gerenciamento de software operável para executar em um domínio de hospedeiro confiável. 3. O FRAMEWORK da cláusula 2, em que uma interface de gerenciamento de software é adicionalmente operável para gerenciar pacotes que requerem processamento especial. 4. O FRAMEWORK da cláusula 3, em que os pacotes que requerem processamento especial incluem pacotes MULTICAST, pacotes BROADCAST, e pacotes de Protocolo de Resolução de Endereço (ARP). 5. O FRAMEWORK da cláusula 2, em que a interface de gerenciamento de software é adicionalmente operável para gerenciar funcionalidade incluindo pelo menos um dentre serviço de nome de domínio (DNS), interface de segurança, e interface de servidor da web. 6. O FRAMEWORK da cláusula 2, em que a interface de gerenciamento de software é operável para configurar estatísticas de rede que necessitam ser coletadas, e estatísticas para serem mantidas, pelo dispositivo de descarga. 7. O FRAMEWORK da cláusula 1, em que as especificações de rede por inquilino incluem especificações para pelo menos um dentre pacotes de dados de regulamento, grupos de segurança de operação, e comunicando-se entre componentes parceiros. 8. O FRAMEWORK da cláusula 1, em que as especificações de rede por inquilino são especificações rede de SR-IOV. 9. O FRAMEWORK da cláusula 1, em que as especificações de rede por inquilino são processadas em tempo real conforme as especificações se alteram. 10. O FRAMEWORK da cláusula 1, em que o gerenciamento de um conjunto de regras para o pelo menos um dispositivo de descarga inclui o carregamento de um primeiro subconjunto de regras em um dispositivo de descarga enquanto processa um segundo subconjunto de regras utilizando a amarração do software. 11. O FRAMEWORK da cláusula 10, em que o primeiro subconjunto de regras é utilizado mais frequentemente que o segundo subconjunto de regras. 12. O FRAMEWORK da cláusula 1, em que as especificações por-inquilino permitem que um fornecedor de hardware suporte protocolos múltiplos sem obter informação específica sobre aqueles protocolos múltiplos. 13. O FRAMEWORK da cláusula 1, em que os tipos de tráfego incluem pelo menos um dentre tráfego destinado para uma plataforma de hospedeiro confiável e tráfego destinado para um inquilino virtual. 14. Um dispositivo de descarga, compreendendo: um processador; e instruções de armazenamento de memória que, quando executadas pelo processador, permitem que o dispositivo de descarga: exponha o dispositivo de descarga como um dispositivo de hardware; desempenhe pelo menos a porção de processamento de um pacote de dados de usuário recebido para uma função física associada ao dispositivo de hardware de descarga, o processamento incluindo pelo menos a retirada de um HEADER interno e externo do pacote de dados, o despenho qualquer modificação de pacote, e encaminhamento do pacote de dados de usuário para uma função virtual interna, a função virtual interna operável para entregar o pacote de dados de usuário a uma máquina virtual convidada. 15. O dispositivo de descarga da cláusula 14, em que o processamento inclui a remoção de pelo menos um HEADER de encapsulamento externo a partir do pacote de dados de usuário. 16. O dispositivo de descarga da cláusula 14, em que o dispositivo de descarga é um cartão de interface de rede (NIC). 17. O dispositivo de descarga da cláusula 14, em que o dispositivo de descarga é operável para suportar protocolos múltiplos sem obter informação específica sobre aqueles protocolos múltiplos. 18. Um método para processamento de pacotes de dados em um ambiente de inquilinos múltiplos, compreendendo: a comunicação com um ou mais serviços distribuídos para carregar uma ou mais especificações de rede por inquilino; a instrução pelo menos um dispositivo de descarga para executar as especificações de rede carregadas por inquilino; o gerenciamento de um conjunto de regras para o pelo menos um dispositivo de descarga quando o pelo menos um dispositivo de descarga é incapaz de armazenar concorrentemente todas dentre o conjunto de regras; e a entrega de pacotes de dados a um destino apropriado para cada um dentre uma pluralidade de tipos de tráfego. 19. O método da cláusula 18, adicionalmente compreendendo: a exposição de uma interface de gerenciamento de software operável para executar em um domínio de hospedeiro confiável. 20. O método da cláusula 19, em que a interface de gerenciamento de software é adicionalmente operável para gerenciar a funcionalidade incluindo pelo menos um dentre o serviço de nome de domínio (DNS), interface de segurança, e interface de servidor da web. 21. O método da cláusula 19, em que o dispositivo de descarga opera de acordo com especificações de rede de SR- IOV. 22. Um método implementado por computador para processamento de pacotes de dados em um ambiente eletrônico, compreendendo: sob o controle de um ou mais sistemas de computador configurados com instruções executáveis, receber um pacote de dados de usuário para uma função virtual associada a uma rede virtual para um usuário; desempenhar uma busca em uma tabela de regras para pelo menos uma regra para processamento do pacote de dados de usuário; desempenhar o processamento à base de software do pacote de dados de usuário em um domínio confiável em resposta à determinação de uma regra de aprisionamento a partir da tabela de regras; não desempenhar nenhum processamento adicional do pacote de dados de usuário em resposta à determinação de uma regra de soltura a partir da tabela de regras; e desempenhar pelo menos uma porção do processamento do pacote de dados de usuário utilizando um dispositivo de descarga em resposta à determinação de uma regra de encaminhamento a partir da tabela de regras, o processamento incluindo pelo menos a adição de um HEADER externo ao pacote de dados de usuário e enviar o pacote de dados de usuário para fora em uma rede física, o HEADER externo incluindo pelo menos um campo opaco e incluindo informação específica do protocolo. 23. O método implementado por computador da cláusula 22, adicionalmente compreendendo: o desempenho de pelo menos uma verificação genérica no pacote de dados de usuário antes de desempenhar a busca. 24. O método implementado por computador da cláusula 23, em que a pelo menos uma verificação genérica inclui pelo menos um dentre anti-mascaramento de nível dois (L2) ou nível três (L3), ou aprisionamento para pelo menos um tipo de pacote. 25. O método implementado por computador da cláusula 22, em que a busca é desempenhada pelo dispositivo de descarga. 26. O método implementado por computador da cláusula 25, em que o dispositivo de descarga provê uma rede sobreposta virtualizada com base em um protocolo de virtualização I/O de raiz única (SR-IOV). 27. O método implementado por computador da cláusula 22, adicionalmente compreendendo: o desempenho de pelo menos uma atualização métrica no pacote de dados de usuário antes de desempenhar a busca. 28. O método implementado por computador da cláusula 22, em que o processamento utilizando um dispositivo de descarga adicionalmente inclui pelo menos um dentre o regulamento o pacote de dados de usuário, ou desempenho de uma ação de qualidade de serviço. 29. O método implementado por computador da cláusula 22, em que o envio do pacote de dados de usuário para fora em uma rede física é desempenhado como parte de um processo de descarga de segmentação. 30. O método implementado por computador da cláusula 22, em que o processamento utilizando um dispositivo de descarga adicionalmente inclui a atualização dos campos de HEADER do pacote de dados de usuário, os campos de HEADER incluindo pelo menos um dentre um comprimento de pacote interno e um externo, e soma de verificação interna e uma externa, uma fonte e um endereço de destino, e um valor de TIME-TO-LIVE (TTL). 31. O método implementado por computador da cláusula 22, em que o processamento utilizando um dispositivo de descarga inclui o desempenho de verificação de fonte de pacote em cada pacote de egresso com base pelo menos em parte em uma fonte máquina virtual. 32. O método implementado por computador da cláusula 22, em que o processamento à base de software inclui o processamento por software de controle de Dom-0. 33. O método implementado por computador da cláusula 22, em que o processamento utiliza um formato genérico de modo que qualquer protocolo apropriado é capaz de ser suportado através de alteração de parâmetros de uma chave de busca. 34. O método implementado por computador da cláusula 33, em que o protocolo apropriado é capaz de ser mapeado para um protocolo de tunelamento sem estado. 35. Um método implementado por computador para processamento de pacotes de dados em um ambiente eletrônico, compreendendo: sob o controle de um ou mais sistemas de computador configurados com instruções executáveis, receber um pacote de dados de usuário para uma função física associada a um dispositivo de descarga; construir uma chave de busca para o pacote de dados de usuário utilizando o dispositivo de descarga; desempenhar uma busca em uma tabela de regras para pelo menos uma regra para processamento do pacote de dados de usuário utilizando a chave de busca; desempenhar processamento à base de software do pacote de dados de usuário em um domínio confiável em resposta à determinação de uma regra de aprisionamento a partir da tabela de regras; não desempenhar nenhum processamento adicional do pacote de dados de usuário em resposta à determinação de uma regra de soltura a partir da tabela de regras; e desempenhar pelo menos uma porção do processamento do pacote de dados de usuário utilizando o dispositivo de descarga em resposta à determinação de uma regra de encaminhamento a partir da tabela de regras, o processamento incluindo pelo menos a retirada de um HEADER interno e externo, desempenho de qualquer modificação de pacote, e encaminhamento do pacote de dados de usuário para uma função virtual interna, a função virtual interna operável para entregar o pacote de dados de usuário a uma máquina virtual convidada. 36. O método implementado por computador da cláusula 35, em que o processamento utilizando o dispositivo de descarga inclui a remoção de pelo menos um HEADER de encapsulamento externo a partir do pacote de dados de usuário. 37. O método implementado por computador da cláusula 35, em que a função virtual interna é identificada pela regra de encaminhamento. 38. O método implementado por computador da cláusula 35, em que o processamento utilizando o dispositivo de descarga é operável para identificar o pacote de dados de usuário como sendo encapsulado utilizando um formato de um protocolo predefinido em um deslocamento predefinido. 39. O método implementado por computador da cláusula 35, adicionalmente compreendendo: o processamento do pacote de dados de usuário utilizando processamento à base de software quando o pacote de dados de usuário não é encapsulado. 40. O método implementado por computador da cláusula 35, em que o dispositivo de descarga é um cartão de interface de rede (NIC). 41. O método implementado por computador da cláusula 35, adicionalmente compreendendo: a determinação de uma máquina virtual correspondente ao pacote de dados de usuário utilizando um campo de comprimento fixo nos bits opacos em um deslocamento predeterminado no pacote de dados de usuário. 42. O método implementado por computador da cláusula 35, em que cada função física tem um conjunto de regras de ingresso, cada regra consistindo pelo menos parcialmente em um conjunto de bits opacos capazes de ser coincididos com os bits opacos de pacotes de ingresso encapsulado. 43. O método implementado por computador da cláusula 35, em que outro tráfego é atravessado em resposta à determinação de uma regra de passagem a partir da tabela de regras. 44. O método implementado por computador da cláusula 35, em que tráfego encapsulado de consumidor e tráfego de controle é aprisionado independente de determinar uma regra de passagem a partir da tabela de regras. 45. Um sistema para processamento de pacotes de dados em um ambiente eletrônico, compreendendo: um processador; e um dispositivo de memória incluindo instruções que, quando executadas pelo processador, fazem com que o processador: receba um pacote de dados de usuário para uma função virtual associada a uma rede virtual para um usuário; desempenhe uma busca em uma tabela de regras para pelo menos uma regra para processamento do pacote de dados de usuário; desempenhe processamento à base de software do pacote de dados de usuário em um domínio confiável em resposta à determinação de uma regra de aprisionamento a partir da tabela de regras; não desempenhe processamento adicional do pacote de dados de usuário em resposta à determinação de uma regra de soltura a partir da tabela de regras; e desempenhe pelo menos uma porção do processamento do pacote de dados de usuário utilizando um dispositivo de descarga em resposta à determinação de uma regra de encaminhamento a partir da tabela de regras, o processamento incluindo pelo menos a adição de um HEADER externo ao pacote de dados de usuário e envio do pacote de dados de usuário para fora em uma rede física, o HEADER externo incluindo pelo menos um campo opaco e incluindo informação específica do protocolo. 46. O sistema da cláusula 46, adicionalmente compreendendo: pelo menos um dispositivo de descarga operável para desempenhar a busca. 47. O sistema da cláusula 46, em que o dispositivo de descarga provê uma rede sobreposta virtualizada com base em um protocolo de virtualização I/O de raiz única (SR-IOV). 48. Um sistema para processamento de pacotes de dados em um ambiente eletrônico, compreendendo: um processador; e um dispositivo de memória incluindo instruções que, quando executadas pelo processador, fazem com que o processador: receba um pacote de dados de usuário para uma função física associada a um dispositivo de descarga; construa uma chave de busca para o pacote de dados de usuário utilizando o dispositivo de descarga; desempenhe uma busca em uma tabela de regras para pelo menos uma regra para processamento do pacote de dados de usuário utilizando a chave de busca; desempenhe o processamento à base de software do pacote de dados de usuário em um domínio confiável em resposta à determinação de uma regra de aprisionamento a partir da tabela de regras; não desempenhe processamento adicional do pacote de dados de usuário em resposta à determinação de uma regra de soltura a partir da tabela de regras; e desempenhe pelo menos uma porção do processamento do pacote de dados de usuário utilizando o dispositivo de descarga em resposta à determinação de uma regra de encaminhamento a partir da tabela de regras, o processamento incluindo pelo menos a retirada de um HEADER interno e externo, o desempenho de qualquer modificação de pacote, e encaminhamento do pacote de dados de usuário a uma função virtual interna, a função virtual interna operável para entregar o pacote de dados de usuário a uma máquina virtual convidada. 49. O sistema da cláusula 48, em que o processamento utilizando um dispositivo de descarga inclui a remoção de pelo menos um HEADER de encapsulamento externo a partir do pacote de dados de usuário. 50. O sistema da cláusula 48, em que o dispositivo de descarga é um cartão de interface de rede (NIC).

[00102] Conforme discutido acima, as várias modalidades podem ser implementadas em uma ampla variedade de ambientes de operação, que, em alguns casos, podem incluir um ou mais computadores de usuário, dispositivos de computação, ou dispositivos de processamento que podem ser utilizados para operar qualquer uma dentre um número de aplicações. Usuário ou dispositivos de cliente podem incluir qualquer um dentre um número de computadores pessoais de propósito geral, tal como desktop ou computadores do tipo laptop em funcionamento em um sistema de operação padrão, bem como software móvel em funcionamento em dispositivos celulares, sem fio e portáteis dispositivos e capazes de suportar um número de protocolos de mensagem e rede. Um sistema tal também pode incluir um número de estações de trabalho funcionando em qualquer uma dentre uma variedade de sistemas de operação comercialmente disponíveis e outras aplicações conhecidas para propósitos, tais como desenvolvimento e gerenciamento de base de dados. Esses dispositivos também podem incluir outros dispositivos eletrônicos, tais como terminais simbólicos, “thin- clients”, sistemas de jogos, e outros dispositivos capazes de se comunicar através de uma rede.

[00103] Vários aspectos também podem ser implementados como parte de pelo menos um serviço ou serviço da Web, tal como pode ser parte de uma arquitetura orientada ao serviço. Serviços tais como serviços na Web podem se comunicar utilizando qualquer tipo apropriado de mensagem, tal como através da utilização de mensagens em formato de linguagem de marcação extensível (XML) e trocado utilizando um protocolo apropriado, tal como SOAP (derivado de “Protocolo de Acesso de Objeto Simples”). Processos providos ou executados através de tais serviços podem ser escritos em qualquer linguagem apropriada, tal como Linguagem de Descrição de Serviços na Web (WSDL). O uso de uma linguagem tal como WSDL permite a funcionalidade tal como a geração automatizada de código de lado do cliente em vários frameworks de SOAP.

[00104] A maioria das modalidades utilizam pelo menos uma rede que seria familiar àqueles versados na técnica para suportar comunicações utilizando qualquer uma dentre uma variedade de protocolos comercialmente disponíveis, tal como TCP/IP, OSI, FTP, UPnP, NFS, CIFS, e AppleTalk. A rede pode ser, por exemplo, uma rede de área local, uma rede de área ampla, uma rede privada virtual, a internet, uma intranet, uma extranet, uma rede pública de telefone comutado, uma rede infravermelho, uma rede sem fio e qualquer uma de suas combinações.

[00105] Em modalidades utilizando um servidor Web, o servidor Web pode funcionar em qualquer uma dentre uma variedade de servidor ou aplicações de camada média, incluindo servidores HTTP, servidores FTP, servidores CGI, servidores de dados, servidores Java, e servidores de aplicação de negócios. O(s) servidor(s) também pode(m) ser capaz(es) de executar programas ou scripts em resposta a solicitações a partir de dispositivo de usuários, tais como ao executar uma ou mais aplicações de Web que podem ser implementadas como um ou mais scripts ou programas escritos em qualquer linguagem de programação, tal como Java®, C, C# ou C++, ou qualquer linguagem de script, tal como Perl, Python, ou TCL, bem como suas combinações. O(s) servidor(s) pode(m) também incluir servidores de base de dados, incluindo sem limitação aqueles comercialmente disponíveis pela Oracle®, Microsoft®, Sybase®, e IBM®.

[00106] O ambiente pode incluir uma variedade de armazenadores de dados e outra memória e meios de armazenamento, conforme discutido acima. Estes podem residir em uma variedade de localizações, tal como em um meio de armazenamento local a (e/ou residente em) um ou mais dos computadores ou remotos a partir de qualquer ou todos os computadores ao longo da rede. Em um conjunto particular de modalidades, a informação pode residir em uma rede de área de armazenamento (“SAN”) familiar para aqueles versados na técnica. De modo semelhante, quaisquer arquivos necessários para o desempenho das funções atribuídas aos computadores, servidores, ou outros dispositivos de rede podem ser armazenados localmente e/ou remotamente, conforme apropriado. Onde um sistema inclui dispositivos computadorizados, cada tal dispositivo pode incluir elementos hardware que pode estar acoplado eletricamente através de um barramento, os elementos incluindo, por exemplo, pelo menos uma unidade de processamento central (CPU), pelo menos um dispositivo de entrada (por exemplo, um mouse, teclado, controlador, tela de toque, ou teclado numérico), e pelo menos um dispositivo de saída (por exemplo, um dispositivo de exibição, impressora, ou caixa de som). Um sistema tal pode também incluir um ou mais dispositivos de armazenamento, tais como drives de disco, dispositivos de armazenamento óptico, e dispositivos de armazenamento em estado sólido, tais como memória de acesso randômico (“RAM”) ou memória de apenas leitura (“ROM”), bem como dispositivos de mídia removível, cartões de memória, cartões flash, etc.

[00107] Tais dispositivos também podem incluir um leitor de mídia de armazenamento legível em computador, um dispositivo de comunicações (por exemplo, um modem, um cartão de rede (com ou sem fio), um dispositivo comunicação infravermelho, etc.), e memória de trabalho conforme descrito acima. O leitor de mídia de armazenamento legível em computador pode estar conectado a, ou configurado para receber, um meio de armazenamento legível em computador, representando dispositivos de armazenamento remoto, local, fixo, e/ou removível, bem como mídia de armazenamento para conter, armazenar, transmitir e recuperar temporariamente e/ou mais permanentemente informação legível em computador. O sistema e vários dispositivos também tipicamente incluirão um número de aplicações de software, módulos, serviços, ou outros elementos localizados dentro de pelo menos um dispositivo de memória de trabalho, incluindo um sistema de operação e programas de aplicação, tais como uma aplicação de cliente ou navegador de Web. Deve ser apreciado que modalidades alternativas têm inúmeras variações daquela descrita acima. Por exemplo, hardware personalizado pode também ser utilizado e/ou elementos particulares podem ser implementados em hardware, software (incluindo software portável, tais como applets), ou ambos. Ademais, a conexão a outros dispositivos de computação tais como dispositivos de entrada/saída de rede podem ser empregados.

[00108] Mídia de armazenamento e mídia legível em computador para conter código, ou porções de código, podem incluir qualquer mídia apropriada conhecida ou utilizada na técnica, incluindo mídia de armazenamento e comunicação media, tal como, mas não se limita a, mídia volátil e não volátil, removível e não removível implementada em qualquer método ou tecnologia para armazenamento e/ou transmissão de informação, tais como instruções legíveis em computador, estruturas de dados, módulos de programa, ou outros dados, incluindo memória RAM, ROM, EEPROM, flash ou outra tecnologia de memória, CD-ROM, disco versátil digital (DVD) ou outro armazenamento óptico, cassetes magnéticos, fitas magnéticas, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outro meio que pode ser utilizado para armazenar a informação desejada e que pode ser acessível por um dispositivo de sistema. Com base na divulgação e ensinamentos providos aqui, uma pessoa de habilidades comuns na técnica apreciará outros modos e/ou métodos para implementar as várias modalidades.

[00109] A especificação e figuras devem, correspondentemente, ser consideradas em um sentido ilustrativo em vez de restritivo. Será, entretanto, evidente que as várias modificações alterações podem ser feitas para isto sem desviar do espírito e escopo mais amplos da invenção conforme estabelecido nas reivindicações.

Claims (15)

1. Dispositivo de descarga (506), caracterizado pelo fato de que compreende: um processador (512); e memória (510) armazenando instruções que, quando executadas pelo processador, permitem ao dispositivo de descarga: operar de acordo com especificações de rede SR- IOV; expor o dispositivo de descarga como um dispositivo de hardware; construir uma chave de busca para um pacote de dados de usuário recebido para uma função física associada com o dispositivo de descarga utilizando o dispositivo de descarga; desempenhar uma busca (706) em uma tabela de regras para pelo menos uma regra para processamento do pacote de dados de usuário utilizando a chave de busca; desempenhar o processamento (712) à base de software do pacote de dados de usuário em um domínio confiável em resposta à determinação de uma regra de aprisionamento a partir da tabela de regras; não desempenhar nenhum processamento adicional (714) do pacote de dados de usuário em resposta à determinação de uma regra de soltura a partir da tabela de regras; e desempenhar pelo menos uma porção de processamento do pacote de dados de usuário em resposta à determinação de regra de encaminhamento a partir da tabela de regras, o processamento incluindo pelo menos retirar um HEADER externo do pacote de dados, desempenhar qualquer modificação de pacote, e encaminhar o pacote de dados de usuário a uma função virtual interna do dispositivo de descarga, a função virtual interna operável para entregar o pacote de dados de usuário a uma máquina virtual convidada.

2. Dispositivo de descarga, de acordo com a reivindicação 1, caracterizado pelo fato de que o processamento inclui a remoção de pelo menos um HEADER de encapsulamento externo a partir do pacote de dados de usuário.

3. Dispositivo de descarga, de acordo com a reivindicação 1, caracterizado pelo fato de que o dispositivo de descarga é um cartão de interface de rede (NIC).

4. Dispositivo de descarga, de acordo com a reivindicação 1, caracterizado pelo fato de que o dispositivo de descarga é operável para suportar protocolos múltiplos sem obter informação específica sobre aqueles protocolos múltiplos.

5. Método implementado por computador para processamento de pacotes de dados em um ambiente eletrônico, caracterizado pelo fato de que compreende: sob o controle de um ou mais sistemas de computador configurados com instruções executáveis, receber um pacote de dados de usuário para uma função física associada a um dispositivo de descarga (506) que opera de acordo com especificações de rede SR-IOV; construir uma chave de busca para o pacote de dados de usuário utilizando o dispositivo de descarga; desempenhar uma busca (706) em uma tabela de regras para pelo menos uma regra para processamento do pacote de dados de usuário utilizando a chave de busca; desempenhar o processamento (712) à base de software do pacote de dados de usuário em um domínio confiável em resposta à determinação de uma regra de aprisionamento a partir da tabela de regras; não desempenhar nenhum processamento adicional (714) do pacote de dados de usuário em resposta à determinação de uma regra de soltura a partir da tabela de regras; e desempenhar pelo menos uma porção do processamento do pacote de dados de usuário utilizando o dispositivo de descarga em resposta à determinação de uma regra de encaminhamento a partir da tabela de regras, o processamento incluindo pelo menos retirar um HEADER externo, desempenhar qualquer modificação de pacote, e encaminhar (716) o pacote de dados de usuário a uma função virtual interna, a função virtual interna operável para entregar o pacote de dados de usuário a uma máquina virtual convidada.

6. Método implementado por computador, de acordo com a reivindicação 5, caracterizado pelo fato de que o processamento utilizando o dispositivo de descarga inclui a remoção de pelo menos um HEADER de encapsulamento externo a partir do pacote de dados de usuário.

7. Método implementado por computador, de acordo com a reivindicação 5, caracterizado pelo fato de que a função virtual interna é identificada pela regra de encaminhamento.

8. Método implementado por computador, de acordo com a reivindicação 5, caracterizado pelo fato de que o processamento utilizando o dispositivo de descarga é operável para identificar o pacote de dados de usuário como sendo encapsulado utilizando um formato de um protocolo predefinido em um deslocamento predefinido.

9. Método implementado por computador, de acordo com a reivindicação 5, caracterizado pelo fato de que o processamento utilizando um dispositivo de descarga adicionalmente inclui a atualização de campos de HEADER do pacote de dados de usuário, os campos de HEADER incluindo pelo menos um dentre um comprimento de pacote interno e um externo, e soma de verificação interna e uma externa, uma fonte e um endereço de destino, e um valor de TIME-TO-LIVE (TTL).

10. Método implementado por computador, de acordo com a reivindicação 5, caracterizado pelo fato de que adicionalmente compreende: processamento do pacote de dados de usuário utilizando processamento à base de software quando o pacote de dados de usuário não é encapsulado.

11. Método implementado por computador, de acordo com a reivindicação 5, caracterizado pelo fato de que o dispositivo de descarga inclui um cartão de interface de rede (NIC).

12. Método implementado por computador, de acordo com a reivindicação 5, caracterizado pelo fato de que adicionalmente compreende: determinar uma máquina virtual correspondente ao pacote de dados de usuário utilizando um campo de comprimento fixo nos bits opacos em um deslocamento predeterminado no pacote de dados de usuário.

13. Método implementado por computador, de acordo com a reivindicação 5, caracterizado pelo fato de que cada função física tem um conjunto de regras de ingresso, cada regra consistindo em pelo menos parcialmente de um conjunto de bits opacos capazes de serem equiparados com os bits opacos de pacotes de ingresso encapsulado.

14. Método implementado por computador, de acordo com a reivindicação 5, caracterizado pelo fato de que outro tráfego é atravessado sem processamento em resposta à determinação de uma regra de passagem a partir da tabela de regras.

15. Método implementado por computador, de acordo com a reivindicação 5, caracterizado pelo fato de que o tráfego encapsulado de consumidor e tráfego de controle é aprisionado independente da determinação de uma regra de passagem a partir da tabela de regras.

Images