Componentes de região

Esta seção aborda os componentes de região necessários e opcionais que podem ser configurados. Informações adicionais são fornecidas em Dados de configuração de região.

Nome e caminho de região

É necessário escolher um nome e um caminho para a região.

Inicialização automática de região

A configuração da propriedade autoboot determina se a região é inicializada automaticamente quando uma região global é inicializada. Os serviços de região svc:/system/zones:default também devem ser ativados.

Associação de grupo de recursos

Se você configurou grupos de recursos no sistema como descrito no Capítulo 13Criação e administração de grupos de recursos (tarefas), pode usar a propriedade pool para associar a região a um dos grupos de recursos ao configurar a região.

A partir da versão Solaris 10 8/07, se grupos de recursos não estiverem configurados, você ainda pode especificar que um subconjunto dos processadores do sistema seja dedicado a uma região não global quando estiver em execução ao usar o recurso dedicated-cpu. O sistema criará dinamicamente um grupo temporário para uso enquanto a região estiver em execução. Com a especificação através de zonecfg, as configurações de pool se propagam durante as migrações.

Uma configuração de região que use um grupo persistente definido através da propriedade pool é incompatível com um grupo temporário configurado através do recurso dedicated-cpu. Você pode definir somente uma destas duas propriedades.

Solaris 10 8/07: recurso dedicated-cpu

O recurso dedicated-cpu especifica que um subconjunto dos processadores do sistema devem ser dedicados a uma região não global enquanto estiver em execução. Quando a região for inicializada, o sistema criará dinamicamente um grupo temporário para uso enquanto a região estiver em execução.

Com a especificação em zonecfg, as configurações de pool se propagam durante as migrações.

O recurso dedicated-cpu define limites para ncpus e, opcionalmente, para importance.

ncpus

Especifique o número de CPUs ou especifique um intervalo, como 2 – 4 CPUs. Se você especificar um intervalo porque deseja um comportamento dinâmico do grupo de recursos, faça também o seguinte:

• Defina a propriedade importance.

• Ative o serviço poold. Para instruções, consulte Solaris 10 11/06 e posterior: como ativar o serviço de grupos de recursos dinâmicos usando svcadm.

importance

Se estiver usando um intervalo de para obter o comportamento dinâmico, defina também a propriedade importance. A propriedade importance, que é opcional, define a importância relativa do grupo. Esta propriedade é necessária somente quando você especifica um intervalo para ncpus e usa grupos de recursos dinâmicos gerenciados por poold. Se poold não estiver em execução, importance será ignorado. Se poold estiver em execução e importance não estiver definido, importance assumirá 1 como padrão. Para obter mais informações, consulte Restrição da propriedade pool.importance.

O recurso capped-cpu e o recurso dedicated-cpu são incompatíveis. O controle de recursos cpu-shares rctl e o recurso dedicated-cpu são incompatíveis.

Solaris 10 5/08: recurso capped-cpu

O recurso capped-cpu oferece um limite absoluto na quantidade de recursos da CPU que podem ser consumidos por um projeto ou uma região. Quando usado em conjunto com conjuntos de processadores, os caps de CPU limitam o uso da CPU dentro de um conjunto. O recurso capped-cpu possui uma única propriedade ncpus que é um decimal positivo com dois dígitos à direita do decimal. Esta propriedade corresponde a unidades de CPUs. O recurso não aceita um intervalo. O recurso não aceita um número decimal. Ao especificar ncpus, um valor 1 significa 100% de uma CPU. Um valor 1,25 significa 125% pois 100% corresponde a uma CPU completa no sistema.

O recurso capped-cpu e o recurso dedicated-cpu são incompatíveis.

Classe de agendamento em uma região

Você pode usar o fair share scheduler (FSS) para controlar a alocação dos recursos de CPU disponíveis entre regiões, com base na importância das cargas de trabalho na região. Essa importância da carga de trabalho é expressa pelo número de compartilhamentos de recursos de CPU que você atribui a cada região. Mesmo que não esteja usando o FSS para gerenciar alocação de recursos de CPU entre regiões, você pode definir a classe de agendamento da região para usar o FSS, de modo que possa definir compartilhamentos em projetos dentro da região.

Quando você define explicitamente a propriedade cpu-shares, o fair share scheduler (FSS) é usado como a classe de agendamento para essa região. No entanto, a forma preferida de usar o FSS neste caso é definir o FSS para ser a classe de agendamento padrão do sistema com o comando dispadmin. Desta forma todas as regiões irão se beneficiar de um compartilhamento justo dos recursos de CPU do sistema. Se cpu-shares não estiver definido para uma região, a região usará a classe de agendamento padrão do sistema. As ações a seguir definem a classe de agendamento para uma região:

• Na versão Solaris 10 8/07, você pode usar a propriedade scheduling-class em zonecfg para definir a classe de agendamento para a região.

• Você pode definir a classe de agendamento para uma região através do procedimento de grupos de recursos. Se a região estiver associada a um grupo cuja propriedade pool.scheduler esteja definida como uma classe de agendamento válida, os processos executados na região serão executados nessa classe de agendamento por padrão. Consulte Introdução a grupos de recursos e Como associar um grupo a uma classe de agendamento.

• Se o controle de recurso cpu-shares estiver definido e o FSS não foi definido como a classe de agendamento para a região através de outro ação, zoneadmd definirá a classe de agendamento como FSS quando a região for inicializada.

• Se a classe de agendamento não estiver definida através de qualquer outra ação, a região herdará a classe de agendamento padrão do sistema.

Observe que você pode usar o priocntl descrito na página do manual priocntl(1) para mover processos em execução para uma classe de agendamento diferente sem alterar a classe de agendamento padrão e sem reinicializar.

Solaris 10 8/07: controle da memória física e o recurso capped-memory

O recurso capped-memory define limites para a memória física, de permuta e bloqueada. Cada limite é opcional, mas pelo menos um deve ser definido.

• Determine valores para este recurso, se planejar limitar memória para a região usando rcapd da região global. A propriedade physical do recurso capped-memory é usada por rcapd como valor max-rss para a região.

• A propriedade swap do recurso capped-memory é a forma preferida de definir o controle de recurso zone.max-swap.

• A propriedade locked do recurso capped-memory é a forma preferida de definir o controle de recurso zone.max-locked-memory.

Os aplicativos geralmente não bloqueiam significativas quantidades de memória, mas você pode decidir definir a memória bloqueada caso os aplicativos da região bloqueiem memória. Se a segurança da região for preocupante, você também pode optar por definir o limite de memória bloqueada como 10 por cento da memória física do sistema ou 10 por cento do limite de memória física da região.

Para obter mais informações, consulte o Capítulo 10Controle da memória física usando o resource capping daemon (visão geral), Capítulo 11Administração do resource capping daemon (tarefas) e Como configurar a região. Para definir provisoriamente o limite de recurso de uma região, consulte Como especificar um limite de recurso provisório de uma região.

Interfaces de rede de região

Interfaces de rede de região configuradas pelo comando zonecfg para fornecer conectividade de rede serão configuradas automaticamente e colocadas na região quando esta for inicializada.

A camada Internet Protocol (IP) aceita e entrega pacotes para a rede. Esta camada inclui roteamento de IP, o Address Resolution Protocol (ARP), a arquitetura de segurança IP (IPsec) e filtro de IP.

Há dois tipos de IP disponíveis para regiões não globais são IP compartilhado e IP exclusivo. A região com IP compartilhado compartilha a interface de rede e a região com IP exclusivo deve ter uma interface de rede dedicada.

Para obter informações sobre recursos de IP em cada tipo, consulte Conexão à rede em regiões não globais com IP compartilhado e Solaris 10 8/07: conexão à rede em regiões não globais com IP exclusivo.

Regiões não globais com IP compartilhado

A região com IP compartilhado é o tipo padrão. A região deve ter um ou mais endereços IP dedicados. Uma região com IP compartilhado compartilha a configuração da camada IP e o estado com a região global. A região deve usar a instância de IP compartilhado se ambos que se segue for verdadeiro:

• A região deve estar conectada ao link de dados, ou seja, deve estar na mesma sub-rede ou sub-redes de IP que a região global.

• Você não deseja outras capacidades que a região com IP exclusivo fornece.

Regiões com IP compartilhado recebem um ou mais endereços IP usando-se o comando zonecfg . Os nomes do link de dados devem também ser configurados na região global.

Esses endereços são associados a interfaces de rede lógica. O comando ifconfig pode ser usado a partir da região global para adicionar ou remover interfaces lógicas em uma região em execução. Para obter mais informações, consulte Interfaces de rede com IP compartilhado.

Solaris 10 8/07: regiões não globais com IP exclusivo

A funcionalidade total no nível de IP é uma região com IP exclusivo.

Uma região com IP exclusivo tem seu próprio estado relacionado a IP.

Isto inclui a capacidade de usar os seguintes recursos em uma região com IP exclusivo:

• Autoconfiguração de endereço sem informações de estado de DHCPv4 e IPv6

• Filtro de IP, incluindo a funcionalidade de conversão de endereço de rede (NAT)

• Vários caminhos de rede IP (IPMP)

• roteamento de IP

• ndd para definir TCP/UDP/SCTP, assim como botões no nível de IP/ARP

• Segurança de IP (IPsec) e Internet Key Exchange (IKE), que automatiza a provisão de material de entrada autenticado para a associação de segurança IPsec

Uma região com IP exclusivo recebe seu pr≤prio conjunto de links de dados usando-se o comando zonecfg. A região recebe um nome de link de dados como xge0 , e1000g1, ou bge32001, usando-se a propriedadephysical do recurso net. A propriedade address do recurso net não é definida.

Observe que o link de dados atribuído permite que o comando snoop seja usado.

O comando dladm pode ser usado com o subcomando show-linkprop para mostrar a atribuição de links de dados a regiões com IP exclusivo em execução. O comando dladm pode ser usado com o subcomando set-linkprop para atribuir links de dados adicionais a regiões em execução. Para exemplos de uso, consulte Solaris 10 8/07: administração de links de dados em regiões não globais com IP exclusivo.

No interior de uma região com IP exclusivo em execução, o comando ifconfig pode ser usado para configurar IP, que inclui a capacidade de adicionar ou remover interfaces lógicas. A configuração de IP em uma região pode ser definida da mesma forma que para a região global, usando-se o sysidtools descrito em sysidcfg(4).

A configuração de IP de uma região com IP exclusivo pode somente ser visualizada a partir da região global usando-se o comando zlogin. Segue-se um exemplo.

global# zlogin zone1 ifconfig -a

Diferenças de segurança entre regiões não globais com IP compartilhado e IP exclusivo

Em uma região com IP compartilhado, aplicativos na região, inclusive o superusuário, não podem enviar pacotes com endereços IP de origem que não sejam os atribuídos à região através do utilitário zonecfg. Este tipo de região não tem acesso para enviar e receber pacotes de link de dados arbitrário (camada 2).

Para uma região com IP exclusivo, zonecfg em vez disso concede à região o link de dados especificado inteiro. Como resultado, o superusuário em uma região com IP exclusivo pode enviar pacotes spoof nesses links de dados, assim como isso pode ser feito na região global.

Uso de regiões não globais com IP compartilhado e IP exclusivo ao mesmo tempo

As regiões com IP compartilhado sempre compartilham a camada IP com a região global, e as regiões com IP exclusivo sempre têm sua própria instância na camada IP. As regiões com IP compartilhado e as regiões com IP exclusivo pode ser usadas na mesma máquina.

Sistemas de arquivos montados em regiões

Geralmente, os sistemas de arquivos montados em uma região incluem o seguinte:

• O conjunto de sistemas de arquivos montados quando a plataforma virtual é inicializada

• O conjunto de sistemas de arquivos montados a partir do próprio ambiente do aplicativo

Isso pode incluir, por exemplo, os seguintes sistemas de arquivos:

• Sistemas de arquivos especificados em um arquivo /etc/vfstab da região

• Montagens acionadas por AutoFS e AutoFS

• Montagens executadas explicitamente por um administrador de regiões

Determinadas restrições são colocadas em montagens executadas a partir do ambiente do aplicativo. Essas restrições impedem que o administrador de regiões negue serviços ao resto do sistema, de outra forma exercendo impacto negativo sobre outras regiões.

Há restrições de segurança associadas à montagem de determinados sistemas de arquivos a partir de uma região. Outros sistemas de arquivos expõem comportamento especial quando montados em uma região. Para obter mais informações, consulte Sistemas de arquivos e regiões não globais.

Dispositivos configurados em regiões

O comando zonecfg usa um sistema de coincidência de regras para especificar quais dispositivos devem aparecer em uma determinada região. Os dispositivos que atendem a uma das regras são incluídos no sistema de arquivos /dev da região. Para obter mais informações, consulte Como configurar a região.

Host ID em regiões

Você pode configurar uma propriedade hostid para uma região não global diferente a partir do hostid da região global. Isso seria feito se uma máquina física fosse consolidada em uma região utilizando a capacidade física para virtual. Os aplicativos, agora dentro da região, podem depender do hostid original e não seria possível atualizar a configuração do aplicativo. Consulte Tipos de recurso e propriedade para mais informações.

Definição de controles de recursos de região geral

O administrador global pode definir controles de recursos de região geral privilegiados para uma região. Os controles de recursos gerais de região limitam o uso total de recursos de todas as entidades de processamento dentro de uma região.

Esses limites são especificados para regiões globais e não globais usando-se o comando zonecfg. Consulte Como configurar a região.

A partir da versão Solaris 10 8/07, o método preferido, mais simples, para definir o controle de recurso de região geral é usar o nome da propriedades em vez do recurso rctl.

Solaris 10 5/08: O controle de recursos zone.cpu-cap define um limite absoluto na quantidade de recursos da CPU que podem ser consumidos por uma região. Um valor 100 significa 100% de uma CPU como a definição project.cpu-cap. Um valor 125 é 125% pois 100% corresponde a uma CPU completa no sistema durante o uso de caps de CPU.

Ao definir o recurso capped-cpu, você pode usar um número decimal para a unidade. O valor se correlaciona ao controle de recursos zone.capped-cpu, mas a definição é diminuída por 100. A definição 1 é equivalente a uma definição 100 para o controle de recursos.

O controle de recurso zone.cpu-shares define um limite para o número de compartilhamentos de CPU do fair share scheduler (FSS) para uma região. Os compartilhamentos de CPU são primeiro alocados para a região e, em seguida, subdivididos entre projetos dentro da região como especificado nas entradas project.cpu-shares. Para obter mais informações, consulte Uso do fair share scheduler em um sistema do Solaris com regiões instaladas. O nome da propriedade global para este controle é cpu-shares.

O controle de recurso zone.max-locked-memory limita a quantidade de memória física bloqueada disponível para uma região. A alocação do recurso de memória entre projetos dentro da região pode ser controlada usando-se o controle de recurso project.max-locked-memory. Para obter mais informações, consulte a Tabela 6–1

O controle de recurso zone.max-lwps aprimora o isolamento do recurso impedindo que demasiadas LWPs em uma região afetem outras regiões. A alocação do recurso LWP entre projetos dentro da região pode ser controlada usando-se o controle de recurso project.max-lwps. Para obter mais informações, consulte a Tabela 6–1 O nome da propriedade global para este controle é max-lwps.

Os controles de recurso zone.max-msg-ids, zone.max-sem-ids , zone.max-shm-ids e zone.max-shm-memory são usados para limitar os recursos V de sistema usados por todos os processos dentro de uma região. A alocação de recursos V de sistema entre projetos dentro da região pode ser controlada usando-se as versões de projeto desses controles de recursos. Os nomes da propriedade global para esses controles são max-msg-ids, max-sem-ids, max-shm-ids e max-shm-memory.

O controle de recurso zone.max-swap limita permuta consumida por mapeamentos de espaço de endereço de processos do usuário e montagens tmpfs dentro de uma região. A saída de prstat -Z exibe uma coluna SWAP. A permuta relatada é a permuta total consumida pelos processos da região e pelas montagens tmpfs. Esse valor auxiliar na monitoração da permuta reservada por região, que pode ser usada para escolher uma configuração de zone.max-swap apropriada.

Esses limites podem ser especificados para processos em execução usando-se o comando prctl . Um exemplo é fornecido em Como definir compartilhamentos FSS na região global usando o comando prctl. Limites especificados através do comando prctl não são persistentes. Os limites estão em vigor somente até o sistema ser reinicializado.

Solaris 10 11/06 e versões posteriores: Privilégios configuráveis

Quando uma região é inicializada, um conjunto padrão de privilégios safe é incluído na configuração. Esses privilégios são considerados seguros porque eles impedem que um processo privilegiado na região afete processos em outras regiões não globais no sistema ou na região global. Você também pode usar o comando zonecfg para fazer o seguinte:

• Adicionar ao conjunto de privilégios padrão, tendo em conta que tais alterações podem fazer com que os processos de uma região afetem os processos de outras regiões por serem capazes de controlar um recurso global.

• Remover do conjunto de privilégios padrão, tendo em conta que tais alterações podem impedir que alguns processos funcionem corretamente, se requererem que esses privilégios sejam executados.

Há alguns privilégios que não podem ser removidos do conjunto de privilégios padrão da região, e também há alguns privilégios que não podem ser adicionados ao conjunto neste momento.

Para obter mais informações, consulte Privilégios em uma região não global, Como configurar a região e privileges(5).

Inclusão de comentário para uma região

Você também pode adicionar um comentário para uma região usando o tipo de recurso attr. Para obter mais informações, consulte Como configurar a região.