EMC
AppSync
Versão 2.2.2
Guia de Instalação e Configuração
302-002-308 01
Publicado Setembro , 2015
A EMC assegura que as informações apresentadas neste documento estão corretas. As informações estão sujeitas a alterações sem prévio aviso.
AS INFORMAÇÕES CONTIDAS NESTA PUBLICAÇÃO SÃO FORNECIDAS “NO ESTADO EM QUE SE ENCONTRAM." A EMC CORPORATION NÃO GARANTE NENHUM TIPO DE INFORMAÇÃO CONTIDA NESTA PUBLICAÇÃO, ASSIM COMO SE ISENTA DAS GARANTIAS PARA A COMERCIALIZAÇÃO DE UM PRODUTO PARA UM PROPÓSITO ESPECÍFICO.
EMC² e, EMC e o logotipo da EMC são marcas registradas da EMC Corporation nos Estados Unidos. Todas as outras marcas comerciais aqui utilizadas pertencem a seus respectivos proprietários.
Para obter a documentação regulatória mais atualizada para sua linha de produtos, visite o site Suporte on-line da EMC (https://support.emc.com).
EMC Computer Systems Brasil Ltda
Rua Verbo Divino, 1.488 – 4º andar São Paulo – SP – 04719-002 0800-553622 Tel.: (11) 5185-8800 Fax: (11) 5185-8999
Pré-requisitos 5
Pré-requisitos do servidor do AppSync... 6
Pré-requisitos do plug-in de host de aplicativo... 6
Pré-requisitos do console do AppSync ...7
Requisitos de exibição ... 7
Lista de verificação para a implementação de AppSync...8
Configuração de blocks do VNX ... 9
Considerações sobre o plano de serviço para aplicativos no armazenamento de block do VNX...10
Montagens dinâmicas ... 10
Montagens de Microsoft Cluster Server para SQL Server...11
Política de SAN no Windows Server Standard Edition ... 11
Configuração do VNX file... 12
Considerações sobre o plano de serviço para um aplicativo no armazenamento do VNX File...13
Montagem do VNX File... 14
Configuração do VNXe...14
Considerações sobre o plano de serviço com o VNXe... 15
Considerações sobre a montagem e desmontagem de cópia para o VNXe...15
Considerações sobre montagem/desmontagem de datastore NFS do VNXe...15
Considerações sobre a restauração de datastore do VNXe NFS...16
Configuração do VMAX... 16
Considerações sobre o plano de serviço para aplicativos no armazenamento do VMAX... 16
Montar e desmontar cópias do VMAX... 18
Montagens de Microsoft Cluster Server para SQL Server...18
Restauração do VMAX... 18
Configuração do VMAX 3... 19
Montar/desmontar cópias de VMAX 3... 19
Considerações de plano de serviço para aplicativos no armazenamento do VMAX 3... 19
Configuração do ViPR Controller... 20
Considerações sobre o plano de serviço com o ViPR Controller... 21
Montar e desmontar cópias do ViPR Controller... 21
Restauração da cópia do ViPR Controller... 22
Configuração do XtremIO ...22
Resumo dos recursos de planos de serviço para o XtremIO... 24
Opções de restauração com o armazenamento do XtremIO... 24
Configuração do RecoverPoint ... 25
Considerações sobre o plano de serviço para aplicativos com proteção do RecoverPoint... 25
Pré-requisitos do RecoverPoint...25
Montagens dinâmicas ou estáticas... 26
Instalação 29 Visão geral de nova instalação do AppSync...30
Instalando o servidor... 30
Capítulo 1
Capítulo 2
Instalando o plug-in de host manualmente - apenas servidores
Windows...30
Adicionando servidores... 32
Visão geral de upgrade...34
Fazendo upgrade do servidor do AppSync...34
Fazendo upgrade do plug-in do agente do AppSync ... 35
Visão geral da instalação de pacote de serviço...36
Instalando o servidor do AppSync 2.2 Service Pack 2... 36
Fazendo upgrade do plug-in do agente do AppSync em um servidor para 2.2 SP2... 37
Desinstalando o servidor ...38
Revertendo o software do servidor do AppSync ... 38
Remover um servidor do AppSync... 39
Desinstalando o plug-in do servidor do AppSync...39
Configuração e gerenciamento de recursos 41 Backup e restauração de AppSync usando a ferramenta Backup Assistant....42
Argumentos e ações do Backup Assistant do AppSync...42
Restaurar um backup automatizado...42
Migrando um servidor do AppSync... 43
Gerenciamento de recursos ...44
Adição de um local do RecoverPoint ...44
Adicionando armazenamento de VMAX e VMAX 3... 45
Adicionar um VNX, array do VNXe ou local do RecoverPoint ao AppSync... 47
Adicione e registre o armazenamento do ViPR Controller no AppSync ... 49
Adicionar um array de XtremIO a AppSync...51
Exibindo armazenamento da EMC... 52
Removendo o sistema de armazenamento da EMC ...52
Detectar novamente um sistema de armazenamento da EMC ... 52
Adicionar um VMware vCenter Server ... 52
Reutilizar cópias no VMAX...53
Reutilização de cópias de bookmarks do RecoverPoint de bancos de dados Oracle ou SQL Server... 54
Pré-requisitos
Este capítulo contém os seguintes tópicos:
l Pré-requisitos do servidor do AppSync... 6
l Pré-requisitos do plug-in de host de aplicativo... 6
l Pré-requisitos do console do AppSync ...7
l Lista de verificação para a implementação de AppSync...8
l Configuração de blocks do VNX ... 9
l Configuração do VNX file... 12
l Configuração do VNXe...14
l Configuração do VMAX... 16
l Configuração do VMAX 3... 19
l Configuração do ViPR Controller... 20
l Configuração do XtremIO ...22
l Configuração do RecoverPoint ... 25
Pré-requisitos do servidor do AppSync
O servidor do AppSync deve atender a pré-requisitos específicos.
A AppSync Support Matrix em https://elabnavigator.emc.com/eln/extendedSupport é a fonte consagrada de informações em plataformas e software compatíveis.
Para obter todas as informações de licença do AppSync e arrays, consulte o Guia de Configuração de Segurança do EMC AppSync.
Tabela 1 Pré-requisitos do servidor do AppSync
Item Valor
Sistema operacional Windows Server 2008 SP2 (x64), Windows Server 2008 R2 (x64), Windows Server 2008 R2 SP1 (x64), Windows Server 2012, Windows Server 2012 R2
Espaço em disco Mínimo de 775 MB. O valor exato é exibido no Assistente de instalação.
Memória Mínimo de 6 GB, 8 GB recomendado CPU Mínimo de 2 CPUs, 4 CPUs recomendadas
Ambientes virtuais Máquina virtual do VMware. Os requisitos de espaço de memória e disco são os mesmos que os de um host físico.
Informações adicionais
O AppSync Server agora pode coexistir no mesmo servidor com qualquer outro produto da EMC que use o RSA Common Security Toolkit, por exemplo, o NetWorker Server, o Unisphere CLI e o Navisphere CLI.
Pré-requisitos do plug-in de host de aplicativo
Analise essas informações sobre os requisitos específicos antes de instalar o agente do AppSync (plug-in de host). A AppSync Support Matrix em https://
elabnavigator.emc.com/eln/extendedSupport é a fonte consagrada de informações em plataformas e software compatíveis.
Tabela 2 Pré-requisitos do plug-in de host de aplicativo
Item Valor a partir do lançamento (consulte a matriz de suporte para versões mais recentes)
Sistema operacional l Windows Server l Linux
l AIX
Espaço em disco Mínimo de 150 MB O valor exato será exibido no Assistente de instalação.
Memória Mínimo de 2 GB
Tabela 2 Pré-requisitos do plug-in de host de aplicativo (continuação)
Item Valor a partir do lançamento (consulte a matriz de suporte para versões mais recentes)
Ambientes virtuais l Máquina virtual do VMware. Os requisitos de espaço de
memória e disco são os mesmos que os de um host físico.
l HyperV
Portas do Windows 8085, 10004, forçando o plug-in do host a um host Windows exige acesso CIFS (porta TCP 139 e a porta TCP 445).
Portas do UNIX: O IP de origem é o servidor do AppSync:
l IP de destino = Host de produção ou montagem que
executa o plug-in de host do AppSync UNIX
l Porta de destino = 22 (SSH porta). Protocolo: TCP
IP de origem = Host de produção ou montagem que executa o plug-in do host do AppSync UNIX
l IP de destino = Servidor do AppSync
l Porta de destino = 22 (porta SSH). Protocolo: TCP
Pré-requisitos do console do AppSync
O console do AppSync é executado em vários navegadores da web.
Navegadores compatíveis siga, para suporte à versão: A AppSync Support Matrix em
https://elabnavigator.emc.com/eln/extendedSupport é a fonte consagrada de informações em plataformas e software compatíveis.
l Internet Explorer l Firefox
l Chrome
O Flash é necessário independentemente do tipo de navegador, versão mínima 10.2. O console requer 1 GB de RAM quando carregado e operando adequadamente.
Requisitos de exibição
O AppSync requer uma resolução de exibição de 1280 x 1024.
Lista de verificação para a implementação de AppSync
Saiba mais sobre as etapas de implementação iniciais do AppSync e como usar a lista de verificação como um mapa para preocupações com a instalação e a segurança.
Tabela 3 Lista de verificação para implementação
Etapa básica Detalhes Obs. Concluído?
Identifique um sistema que executa uma versão compatível do Windows para atuar como o servidor do AppSync.
Consulte uma matriz de suporte recente do AppSync para versões do Windows exatas para o servidor do AppSync. Consulte a lista de pré-requisitos de servidor neste guia para outros detalhes.
Verifique se você tem um navegador da Web compatível para executar o console do AppSync.
Consulte o tópico de pré-requisitos do console para a lista dos navegadores compatíveis.
Verifique se o host do aplicativo (por exemplo, servidor de caixa de correio do Microsoft Exchange) atende aos requisitos.
Consulte a Guia de administração e usuário do EMC AppSync e Matriz de suporte do EMC AppSync mais recente.
Instalar o executável do servidor do AppSync no sistema de servidor designado.
Obtenha o executável de instalação do servidor em Brazil.EMC.com.
Em um navegador da web, abra o console do AppSync.
http://<appsync_server>:8085/appsync No atalho da área de trabalho ou no
console do AppSync, adicione o armazenamento onde residem os dados de aplicativos.
l Para adicionar qualquer um dos seguintes arrays de
armazenamento, acesse Settings > Storage Infrastructure n VNX, VNXe n VMAX n XtremIO n Local do RecoverPoint: n ViPR Controller
l Se estiver montando de cópias em uma máquina virtual
que usa discos RDM, procure Copy Protection >
VMware Datacenters e clique em Discover Datacenters > Add vCenter Servers. No console do AppSync, instale o
plug-in do AppSync no host do aplicativo de host.
Settings > Servers e clique em Add. Quando a segurança impede a instalação forçada, instale manualmente executando o AppSync-Host-Plug-in-2.2.2-win-x64.exe no host.
No console do AppSync, detecte os objetos de aplicativos nos respectivos servidores.
Copy Management > Microsoft Exchange / SQL Server / Oracle / VMware Datacenters / FileSystem.
Tabela 3 Lista de verificação para implementação (continuação)
Etapa básica Detalhes Obs. Concluído?
No console do AppSync, aloque objetos de aplicativos em um plano de serviço para iniciar a proteção de dados.
Copy Management > Microsoft Exchange / SQL Server / Oracle / VMware Datacenters / FileSystem.
l Proteja imediatamente com Subscribe to Plan and
Run, que inscreve o objeto do aplicativo em um plano de serviço e executa a proteção imediatamente, somente para o objeto selecionado.
l Subscribe to Plan, que inscreve o objeto do aplicativo
em um plano de serviço, mas não executa o plano. A proteção ocorre conforme o agendamento do plano de serviço.
No console do AppSync, você pode reutilizar cópias de banco de dados de aplicativos para SQL Server e Oracle para uso em teste e desenvolvimento, break-fix, data mining e emissão de relatórios. Use o Assistente Repurpose para agendar ou criar imediatamente cópias de primeira ou segunda geração, conforme necessário.
Copy Management > Oracle or SQL Server para exibir a lista de aplicativos disponíveis.
l Selecione a instância do banco de dados que você deseja
reutilizar e, em seguida, selecione Repurpose para iniciar o assistente.
l Siga as etapas do assistente.
l Selecione Run now ou Run later. Preencha todos os
detalhes exibidos no guia do usuário e na ajuda on-line.
Configuração de blocks do VNX
O AppSync aceita a criação e o gerenciamento de cópias de aplicativos usando a tecnologia de cópias de snapshot do VNX. Considere as práticas recomendadas para configuração do array do VNX antes de implementar o AppSync.
Conectividade
Considere as seguintes informações para a conectividade do VNX com o AppSync.
l O AppSync aceita a conectividade Fiber, iSCSI e FCoE entre o host que executa o
software AppSync e o array do VNX. É necessária conectividade de rede entre o array e o servidor do AppSync.
l O controle de armazenamento ocorre apenas no servidor do AppSync. Não é
necessário zoneamento do array do VNX para o servidor do AppSync. Não é necessário expor previamente todas as LUNs.
l Configurações com vários servidores do AppSync por array do VNX são compatíveis.
Suporte à LUN do VNX
Considere as seguintes informações para o suporte a LUNs do VNX.
l O AppSync é compatível apenas com LUNs que estão em um pool. Se você executar a
replicação de snapshots do VNX, deverá usar LUNs em pool, não LUNs em RAID. Para o RecoverPoint, use o armazenamento RAID.
l O AppSync não pode criar snapshots em LUNs com compactação habilitada. l Para snapshots do VNX, o AppSync é compatível com LUNs primárias de qualquer
tamanho.
Grupos de consistência do VNX
Considere as seguintes informações ao usar grupos de consistência do VNX:
l Todas as limitações que se aplicam a grupos de consistência do VNX também se
aplicam ao AppSync.
l Você pode ter vários grupos de consistência em um único plano de serviço. l Se você estiver usando grupos de consistência do VNX, todos os file systems
relacionados a um aplicativo no conjunto de snapshots deverão residir no mesmo plano de serviço. Caso contrário, você pode encontrar problemas com a montagem e a restauração.
Montagem do VNX
As seguintes considerações de configuração se aplicam:
l Os hosts de montagem exigem visibilidade de SAN para o array do VNX. l As alterações feitas em um snapshot do VNX enquanto ele é montado são
persistentes.
l Se você excluir acidentalmente cópias de hardware no array, não será possível
montar essas cópias com o AppSync. Evitando substituições acidentais
Quando você usa o AppSync para criar uma cópia de um conjunto de dados que
compartilha uma LUN com outros dados, a cópia contém todos os dados sobre essa LUN. Durante a restauração, você pode inadvertidamente gravar dados mais antigos sobre os novos. As entidades substituídas são chamadas de entidades afetadas. Configure sempre os dados para que as entidades afetadas sejam reduzidas ou eliminadas. Cada LUN deve conter um único arquivo de banco de dados ou file system. Se você tiver certeza de que a tabela de file system e/ou banco de dados que residem nessa LUN sempre serão armazenados em backup ou restaurados como uma unidade, exceções se aplicam.
Considerações sobre o plano de serviço para aplicativos no armazenamento de
block do VNX
Depois de registrar o armazenamento do VNX, você pode inscrever o aplicativo em um plano de serviço para criar e gerenciar cópias.
Os planos Bronze são aceitos. O AppSync aceita o snapshot do VNX como tecnologia de cópia. Assine o plano de serviço Bronze para criar e gerenciar cópias locais para
recuperação de operação, aceleração de backup ou reutilização (criar cópias para teste/ desenvolvimento). O AppSync é compatível com LUNs em pool (TLU/DLU) se a tecnologia de snapshot aceitar essas LUNs.
O número máximo de cópias que o AppSync pode criar e gerenciar para o block do VNX é imposto pelos limites da tecnologia de snapshots do VNX. O número máximo de
snapshots do VNX por origem é 256. Isso permite um rodízio de plano de serviço AppSync máximo de 255.
Montagens dinâmicas
Com zoneamento adequado, o AppSync apresenta o armazenamento para o host quando uma cópia é montada.
Host físico
Quando o AppSync monta uma cópia, ele atribui dinamicamente um snapshot ao host. O host físico deve ser zoneado para o array VNX.
Máquina virtual
Montagens dinâmicas acontecem como RDM (raw device mapping) ou por meio de iSCSI nativo na máquina virtual.
l Para RDM, o ESX server onde a máquina virtual reside deve ser zoneado para o array
VNX.
l Para RDM e discos virtuais, a central virtual (que gerencia o ESX server onde o host
de montagem da máquina virtual reside) deve ser registrada com o servidor de AppSync.
l Para iSCSI nativo, a máquina virtual deve ser zoneada para o array VNX. l Para discos virtuais, a central virtual do ESXi server (onde reside o host de
montagem) deve ser registrada com AppSync. Registre a máquina virtual com o indicador de disk.EnableUUID ativado. O AppSync instalará o plug-in de host na máquina virtual durante o registro para o disco virtual e proteção em nível de aplicativo.
Montagens de Microsoft Cluster Server para SQL Server
As montagens de Microsoft Cluster Server (MSCS) para SQL Server podem ser feitas em clusters de produção ou alternativos.
Quando você montar em um nó de cluster usando o armazenamento do VNX:
l A configuração do grupo de armazenamento se aplica somente a hosts físicos ou
máquinas virtuais com o NPIV ou iSCSI conectadas diretamente ao VNX. Para clusters configurados usando máquinas virtuais com RDM ou disco virtual, a cópia que está montada só é visível para o nó selecionado (geralmente o nó passivo).
l Quando você montar em um nó de cluster para fins de backup, crie um grupo de
armazenamento dedicado para um dos nós do cluster, preferencialmente o nó passivo.
l O AppSync não aceita a montagem de um cluster como um recurso em cluster. Para
montar em um cluster como um recurso em cluster (em um ambiente físico/iSCSI), desmarque a configuração padrão e selecione Use dedicated storage group na caixa de diálogo de montagem do AppSync. Durante a montagem, o AppSync faz a cópia visível para vários nós no cluster por meio de um grupo de armazenamento com vários nós atribuídos. O AppSync também monta os file systems no host de montagem selecionado. Após a conclusão da montagem do AppSync, adicione manualmente os dispositivos montados sob o gerenciamento de cluster para evitar a possibilidade de qualquer corrupção dos dados.
l Se o PowerPath 5.7 estiver instalado, o IP do host no grupo de armazenamento de
VNX muda para o IP que corresponde ao adaptador virtual de cluster de failover da Microsoft. O PowerPath 5.7 tem um recurso de registro automático do host que intercepta a operação do agente do host e substitui o IP por sua própria seleção. Esse recurso não pode ser desativado. Faça o upgrade para o PowerPath 5.7.2 ou superior para corrigir esse problema.
Política de SAN no Windows Server Standard Edition
No Windows Server, a política de SAN determina se um disco fica on-line ou off-line quando ele surge no sistema. Para sistemas Enterprise Edition, a política padrão é estar off-line. Na Standard Edition, a política padrão é estar on-line. Você precisa definir a política para off-line compartilhado para impedir falhas de montagem.
Para definir a política de SAN como off-line em um host do Windows Server 2008 Standard Edition, abra uma janela de linha de comando e execute os seguintes comandos:
C:\>diskpart Microsoft DiskPart version 6.0.6001 Copyright (C) 1999-2007 Microsoft Corporation. No computador: abcxyz DISKPART> san policy=offlineshared DiskPart alterou a política SAN para o sistema operacional atual.
Configuração do VNX file
O AppSync aceita a criação e o gerenciamento de cópias de aplicativos usando a tecnologia de cópia VNX File SnapSure. AppSync– as cópias gerenciadas podem ser locais, remotas (fora do destino do VNX Replicator) ou remotas e locais point-in-time idênticas.
Considere as práticas recomendadas para a instalação do VNX file antes de implementar o AppSync.
VNX SnapSure
O VNX SnapSure cria uma cópia point-in-time de todos os dados no file system de rede (NFS). Para o snapshot inicial, esse método cria uma cópia completa do file system original, exigindo, assim, a mesma quantidade de espaço no file system. A utilização de espaço de snapshots subsequentes depende de quanto os dados foram alterados desde que o último snapshot foi obtido.
O SnapSure tem as seguintes características:
l Serviço de armazenamento — VNX File Server l Origem – LUN de VNX
l Destino — snapshot local do VNX SnapSure
l Requisitos de armazenamento — aplicam-se aos seguintes requisitos de
armazenamento:
n Os dados de origem devem residir nos file systems do VNX.
n O armazenamento deve incluir espaço suficiente para os snapshots do VNX. n Os pools de armazenamento não podem ser definidos para trabalhos do VNX. l Montagem e recuperação — você pode montar a réplica em um host de destino e/ou
fazer a recuperação direta do destino à origem. VNX Replicator
O VNX Replicator cria uma cópia point-in-time de todos os dados no file system de rede (NFS). O VNX Replicator mantém a consistência entre os file systems de origem e de destino que se baseiam nas configurações da política do Time Out of Sync.
O VNX Replicator tem as seguintes características:
l Serviço de armazenamento — VNX File Server l Origem — NFS de VNX
l Destino — Snapshot remoto do Replicator
l Requisitos de armazenamento — os dados de origem devem residir nos file systems
de rede.
l Montagem e recuperação — pode-se montar a cópia em um host de destino e
VNX Remote Protection
A proteção ocorre entre um Data Mover local e um Data Mover em um sistema VNX remoto.
Os dois VNX para gabinetes de arquivos devem estar configurados para se comunicarem entre si por meio de uma senha comum, e os dois Data Movers devem ser configurados para se comunicarem entre si usando uma interconexão de Data Mover. Após a
comunicação ser estabelecida, uma sessão remota pode ser configurada para criar e atualizar periodicamente um objeto de origem em um local de destino remoto. A cópia inicial do file system de origem pode ser feita por uma rede IP ou pelo método de transferência por fita.
Algumas recomendações para a sessão incluem:
l A sessão deve ser criada com a política de atualização do Time Out of Sync em vez de
uma atualização manual.
l O valor de Time Out of Sync deve ser definido como o valor mais baixo possível para
a configuração de rede.
Depois da cópia inicial, as alterações feitas no objeto de origem local serão transferidas para um objeto de destino remoto usando a rede IP. Essas transferências são
automáticas e se baseiam em propriedades da sessão de proteção e políticas de atualização personalizáveis.
Configurações de replicação um-para-muitos não são compatíveis com o AppSync. Proteção de dados em file systems de rede do VNX
Para planos de serviço configurados para proteção remota, a cópia do NFS é criada como um snapshot do SnapSure no file system local e/ou remoto. A cópias de datastores do NFS podem ser criadas de planos de serviço configurados para proteção local; remota; e local e remota.
Durante a restauração de uma cópia de NFS, o AppSync cria um snapshot de reversão para cada file system que tenha sido restaurado. O nome de cada snapshot de reversão pode ser encontrado nos detalhes da restauração.
Você pode excluir manualmente o snapshot de reversão novamente depois de verificar o conteúdo da restauração. Manter esses snapshots além de sua vida útil poderá encher o cache de snapshots do VNX e causar problemas de recursos.
Considerações sobre o plano de serviço para um aplicativo no armazenamento do
VNX File
Depois de registrar o armazenamento do VNX, você pode inscrever o aplicativo em um plano de serviço para criar e gerenciar cópias.
Os planos Bronze, Silver e Gold são aceitos para cópias de aplicativos (datastore de NFS, Oracle NFS) que residem no VNX File.
Os limites da tecnologia VNX SnapSure determinam o número máximo de cópias que o AppSync pode criar e gerenciar para o VNX File.
Para cópias locais do SnapSure, você pode ter um máximo de 96 snapshots RO (somente leitura). O rodízio de planos de serviço do AppSync para o file system de NFS do VNX é um máximo de 95.
Para cópias remotas do SnapSure (em Remote Replicator), você pode ter um máximo de 95 snapshots RO. O rodízio de plano de serviço do AppSync para o file system de NFS do VNX é um máximo de 94.
Para montagens RW (leitura/gravação), o SnapSure permite até 16 que snapshots RW dos snapshots RO existentes. Um máximo de 16 snapshots para uma determinada origem pode ser montado, somente leitura, a qualquer momento especificado. Por
padrão, os planos de serviço desmontam a cópia de provisionamento antes de montar a nova cópia para que esse limite não tenha consequências. No entanto, se a
implementação exigir a montagem simultaneamente várias cópias para a mesma origem somente leitura, o limite de 16 deve ser considerado.
Montagem do VNX File
Você pode montar qualquer cópia de snapshot do VNX File criada no plano de serviço, a qualquer momento, independentemente de outras cópias criadas no mesmo plano de serviço.
As seguintes considerações se aplicam:
l Os hosts de montagem do ESX devem pertencer a um vCenter server. l Os hosts de montagem do ESX exigem visibilidade da rede.
l NFS.MaxVolumes, uma configuração avançada do ESX Server, deve ser definida
como o número de datastores de NFS que será montado para cada ESX na rede.
l Ao montar em um ESX server, o AppSync usa a interface de número menor que tem
conectividade.
Configuração do VNXe
Saiba mais sobre o gerenciamento de cópias, suporte a aplicativos, e tipos de replicação e armazenamento permitidos do VNXe e AppSync.
Os arrays do VNXe aceitam todos os aplicativos no AppSync. O VNXe não aceita a seguinte configuração com o AppSync:
l File systems NFS em plataformas UNIX l Reutilização de cópias em arrays do VNXe
Gerenciamento de cópias do VNXe
Esta seção descreve um fluxo de trabalho típico do AppSync, onde você pode criar e gerenciar cópias consistentes com aplicativos no armazenamento do VNXe. O AppSync gerencia os arrays do VNXe com a interface de gerenciamento em vez de com a interface do processador de serviços.
Execute o registro de recursos para o VNXe quando iniciar o AppSync após a instalação. Registre os hosts, bem como os sistemas de armazenamento e vCenter para que o AppSync possa realizar várias operações que são necessárias para criar e gerenciar cópias de aplicativos. Normalmente, o registro de uma entidade inclui a identificação do sistema usando o nome/endereço IP e fornecendo as credenciais necessárias (nome de usuário e senha) para que o AppSync detecte e opere no sistema registrado.
Tipo de replicação e armazenamento
O AppSync aceita a tecnologia de replicação Unified Snapshot para criar e gerenciar cópias locais dos aplicativos que residem no armazenamento de arquivos ou block do VNXe.
As LUNs do armazenamento de blocks de origem podem ser LUNs de pool, tanto thick quanto thin. Você pode provisionar os dispositivos de block de origem necessários usando os Assistentes de datastores de LUN do VNXe ou VMware na UI do Unisphere. Ao criar LUNs básicas usando o Assistente de LUNs selecione uma das seguintes opções:
l Create a LUN – cria uma LUN individual de um pool de armazenamento desejado. l Create a LUN group – cria um agrupamento de LUNs a partir de um pool de
armazenamento desejado. A vantagem de usar um grupo de LUNs é que todas as LUNs dentro do grupo são agrupadas, o que garante a consistência no array.
As práticas recomendadas orientam que, em ambientes Microsoft, você deve usar grupos de LUNs em seu layout de armazenamento para auxiliar a criação consistente com aplicativos dos snapshots do VNXe dentro da janela de tempo do serviço Microsoft VSS. Você pode provisionar os dispositivos de arquivos de origem necessários usando o file system do VNXe ou o Assistente de datastores do VMware. Ao fazer o provisionamento a partir do Assistente de file systems, somente os file systems de compartilhamento do NFS são aceitos.
Considerações sobre o plano de serviço com o VNXe
Antes de adicionar um plano de serviço para criar cópias de VNXe, analise estas considerações.
Depois de registrar o armazenamento do VNXe, inscreva-se no plano de serviço Bronze para criar e gerenciar cópias locais para a aceleração de backup e recuperação de operação. Depois de registrar o armazenamento do VNXe, o AppSync escolhe o snapshot para planos Bronze por padrão.
Para cópias em RecoverPoint Continuous Remote Replication ou CLR, assine o plano de serviço Silver ou Gold, respectivamente. Você pode alterar o snapshot de bookmark para cópias do RecoverPoint.
Considerações sobre a montagem e desmontagem de cópia para o VNXe
As operações de montagem/desmontagem em arrays do VNXe envolvem conexão/ desconexão de snapshots para SMPs, e conceder/remover (mascaramento/
desmascaramento) acesso de snapshot a LUNs de SMP ou um conjunto de SMPs para um host.
O VNXe permite apenas um snapshot de cada vez de um conjunto de LUNs ou grupo de LUNs para o anexo a LUNs de SMP. As LUNs contidas em um grupo de LUNs são conectadas e desconectadas em conjunto, não há conexão/desconexão parcial. Antes de executar uma montagem e desmontagem, realize o zoneamento do host de montagem para o array do VNXe e registre o nome no host em seus iniciadores.
A primeira etapa que o AppSync realiza ao montar um snapshot no VNXe é a detecção do iniciador de host para o host de montagem. Com base nas informações do snapshot, o AppSync associa-se aos grupos de LUNs/LUN de origem apropriados para determinar o acesso ao host para o host de montagem. O AppSync verifica se nenhum outro snapshot está conectado às LUNs de SMP. A seguir, o AppSync modifica o acesso do host para conceder acesso ao snapshot para executar uma montagem, ou remover o acesso do host para desmontar.
Para montagem/desmontagem de RDM ou vDISK, oAppSync identifica o acesso do host com base no iniciador do host para o ESX server.
Os grupos de LUNs têm uma abordagem tudo ou nada para montagens. Em produtos da Microsoft, todos os dispositivos dentro ou fora de um grupo de LUNs precisam ser inicialmente expostos ao host de montagem para que a importação de VSS possa ser executada corretamente. Alguns dispositivos podem permanecer visíveis, mas não conectados a um ponto de montagem no host de montagem.
Considerações sobre montagem/desmontagem de datastore NFS do VNXe
Analise as seguintes informações sobre a montagem/desmontagem do datastore NFS. O AppSync cria um compartilhamento com base no snapshot do arquivo do VNXe que você deseja montar. O compartilhamento será visível para o host de montagem. Durante
a desmontagem, o compartilhamento criado durante a montagem será excluído. O nome do compartilhamento é exibido no seguinte formato:
AS-Share- lastFourDigitOfVNXeSerialNum-ProductionFilesystemId-TimeOfShareCreated
Com relação a IPs de exportação, o AppSync cria uma lista de interfaces de IP de exportação do array do VNXe. O IP de exportação de produção é uma prioridade.
Considerações sobre a restauração de datastore do VNXe NFS
Antes da restauração, o AppSync cria automaticamente um snapshot de ponto de restauração do recurso de armazenamento de produção atual no array do VNXe. Esse snapshot do ponto de restauração tem a seguinte nomenclatura: AppSync-
ROLLBACK-NXeSerialNumber_ProductionFilesystemId_TimeOfSnapCreation.TimeofRe store.
O AppSync-ROLLBACK-VNXeSerialNumber_xxxxx do snapshot não é excluído depois da restauração.
Configuração do VMAX
Para criar e gerenciar cópias de seus aplicativos, o AppSync aceita a tecnologia de replicação TimeFinder Clone e TimeFinder VP Snap. O AppSync também aceita o
gerenciamento de cópias remotas de um R2 em uma configuração de SRDF/A ou SRDF/S. Analise as seções a seguir antes de adicionar seu armazenamento VMAX.
Considerações sobre o plano de serviço para aplicativos no armazenamento do
VMAX
Depois de registrar o armazenamento do VMAX você pode inscrever seu aplicativo em um plano de serviço para criar e gerenciar cópias.
Os planos Bronze e Silver são aceitos. TimeFinder VP Snap é a tecnologia de replicação padrão usada para os planos de serviço. Você pode alterar a preferência para clonar se cópias do TimeFinder Clone forem desejadas.
O número máximo de cópias recomendado a ser mantido antes da expiração é de 6 para Timefinder Clones, e até 31 para VP Snap. O número de cópias do Timefinder Clone e VP Snap que podem ser criadas e gerenciadas é influenciado por outras tecnologias de replicação e cópia usadas nas LUNs de origem. Consulte a seção sobre os limites da sessão de cópia para seu planejamento. Consulte Limites da sessão de cópia do VMAX. na página 17
Plano Bronze
Você pode se inscrever no plano de serviço Bronze para criar e gerenciar cópias locais para recuperação de operação, aceleração de backup ou reutilização (criar cópias para teste/desenvolvimento).
Para LUNs de RAID o AppSync escolhe TimeFinder Clones para o plano Bronze. Se a origem for uma LUN de RAID ou uma combinação de RAID e LUNs thin, o AppSync seleciona clone, mesmo se você selecionar o TimeFinder VP Snap como preferência. Plano Silver
Obs.
A criação de cópias remotas em uma configuração de SRDF/A não é aceita por aplicativos Microsoft.
Advertências SRDF/A: A criação de um TimeFinder VP Snap ou TimeFinder Clone do dispositivo R2 não é permitida se qualquer uma das opções a seguir for verdadeira:
l O write pacing em nível de dispositivo do SRDF/A não está ativado e não é aceito
pela sessão do SRDF/A.
l O par do SRDF é o R21-> R2 de uma configuração em cascata, e qualquer uma das
afirmações a seguir for verdadeira:
n O array Symmetrix R21 está executando um nível de Enginuity inferior a
5876.159.102
n O array Symmetrix de R2 está executando um nível de Enginuity inferior a 5875. n O dispositivo R21 sem drive não tem capacidade de ritmo.
l A restauração a partir de SRDF/A não é aceita.
As LUNs de armazenamento de origem podem ser LUNs tradicionais do RAID ou LUNs thin (TDEVs). O suporte a TimeFinder VP Snap vale somente para LUNs thin. Considere as recomendações a seguir:
l R1 > R2 devem estar no estado sincronizado (para SRDF/S) e consistente (para
SRDF/A)
l Para a cópia de criação do plano Silver: O Affinitizer divide os aplicativos com base
no grupo do RDF (grupo RA) ao qual pertencem os dispositivos de origem.
l Coloque todas as LUNs de aplicativos no mesmo grupo RDF.
Limites de sessão de cópia
Os arrays da série Symmetrix VMAX aceitam até 16 sessões diferenciais por dispositivo de origem, que podem ser usadas para operações do TimeFinder/Clone, TimeFinder/ Snap, TimeFinder VP Snap, SRDF/Star, Solutions Enabler Open Replicator (ORS) ou Symmetrix Differential Data Facility (SDDF).
Isso limita o número de cópias disponíveis que podem ser criadas.
O TimeFinder VP Snap permite 32 sessões adicionais por dispositivo Symmetrix, o que inclui a disponibilidade de uma sessão de 16 sessões tradicionais disponíveis. Se você quiser executar uma restauração, uma sessão adicional é necessária das 16.
Por exemplo, se você usa o VP Snap para uma LUN de origem e deseja executar uma operação de restauração, essa ação deixa 14 sessões disponíveis para outras
tecnologias de cópia (TF Clone, ORS, Timefinder/Snap, SRDF/Star, e assim por diante). Além disso, se você deseja criar e gerenciar cópias de TF Clone para a mesma origem, você não pode criar mais que sete cópias de TF Clone usando o AppSync. (O AppSync cria cópias diferenciais do TimeFinder Clone que ocupam 2 sessões diferenciais por cópia, 14/2 = 7.) Como o AppSync não exclui nem expira uma cópia antes de criar uma nova, a origem de rotação do AppSync para as cópias do TimeFinder Clone não pode ser mais que 6. Isso permite que uma cópia adicional seja criada antes da exclusão/expiração da cópia mais antiga.
Obs.
Consulte os limites de sessão adicionais do TimeFinder em: Guia de produto EMC Solutions Enabler Symmetrix TimeFinder Family CLI.
Montar e desmontar cópias do VMAX
As operações de montagem/desmontagem no VMAX envolvem o mascaramento/ desmascaramento de LUNs ou conjunto de LUNs a um host.
O AppSync depende do recurso de provisionamento automático do VMAX. O AppSync exige que o host de montagem seja zoneado para o array do VMAX. Você deve criar uma exibição de mascaramento com o grupo de iniciadores, o grupo de portas e o grupo de armazenamento apropriados.
Quando o AppSync executa uma operação de montagem no VMAX, primeiro, ele detecta o iniciador de host para o host de montagem. Com base no iniciador do host, ela se associa à exibição de mascaramento apropriado para determinar o grupo de
armazenamento do ou para o qual as LUNs de destino são mascaradas/sem máscaras para executar uma operação de montagem/desmontagem.
Para montagem/desmontagens de RDM ou Vdisk, o AppSync identifica a exibição de mascaramento com base no iniciador do host para o ESX server.
Montagens de Microsoft Cluster Server para SQL Server
As montagens de Microsoft Cluster Server (MSCS) para SQL Server podem ser feitas em clusters de produção ou alternativos.
Quando você monta em um nó de cluster usando o armazenamento do VMAX:
l A configuração do grupo de armazenamento se aplica somente a hosts físicos ou
máquinas virtuais com iSCSI diretamente conectados ao VMAX. Para clusters configurados usando máquinas virtuais com RDM ou disco virtual, a cópia montada só é visível para o nó selecionado (normalmente o nó passivo).
l Quando você montar em um nó de cluster para fins de backup, crie um grupo de
armazenamento dedicado para um dos nós do cluster, preferencialmente o nó passivo.
l O AppSync não aceita a montagem para um cluster como um recurso em cluster. Para
montar em um cluster como um recurso em cluster (em um ambiente físico/iSCSI), desmarque a configuração padrão Use dedicated storage group na caixa de diálogo de montagem do AppSync. Durante a montagem, o AppSync tornará a cópia visível para vários nós no cluster por meio de um grupo de armazenamento com vários nós atribuídos. O AppSync também monta os sistemas de arquivos no host de montagem selecionado. Após a conclusão da montagem do AppSync, adicione manualmente os dispositivos montados sob o gerenciamento de cluster para evitar a possibilidade de qualquer corrupção dos dados.
Restauração do VMAX
O VMAX restringe o número máximo de nós de rede em cascata a dois.
Se a origem A tem as seguintes sessões como A > D e A > B > C (quando criados por um plano de serviço ou usando fluxo de trabalho de reutilização), então, durante a restauração de D, o número de nós de rede é alterado para 3, pois a sessão de restauração leva a D > A > B > C. Portanto, o Appsync oferece uma opção para encerrar a sessão B > C, se for um clone.
Durante execuções consecutivas, se o AppSync escolhe C como um destino para B, então, será uma sincronização completa em vez de uma ressincronização, pois a sessão B > C será encerrada durante a restauração.
Por exemplo: A > B > C
A > D > E
Restauração de B encerrará D > E. A restauração de D encerrará B > C. As sessões necessárias serão encerradas apenas se você selecionar a opção.
Se a cópia de segunda geração é um TimeFinder VPSnap, você deve expirar os snapshots de segunda geração manualmente. A restauração falhará se um snapshot do clone existe para a origem e exibe todas as cópias que precisam ser expiradas na janela de
andamento.
Obs.
Consulte Guia de suporte ao AppSync VMAX Array no site de suporte da EMC para obter mais informações.
Configuração do VMAX 3
Os arrays do VMAX 3 são compatíveis com o AppSync. Esta seção descreve os recursos compatíveis e as considerações de plano de serviço, inclusive montagem/desmontagem e restauração de cópias do VMAX 3.
Para criar e gerenciar cópias de aplicativos, o AppSync aceita a tecnologia de replicação de snapshots SnapVX nos arrays do VMAX 3.
Montar/desmontar cópias de VMAX 3
As operações de montagem/desmontagem no VMAX 3 incluem o mascaramento/ desmascaramento de LUNs ou de um conjunto de LUNs para um host. O AppSync depende do recurso de provisionamento automático do VMAX 3.
O host de montagem deve ser zoneado para o array do VMAX 3. Em seguida, você pode criar uma exibição de mascaramento com o grupo de iniciadores, grupo de portas e grupo de armazenamentos.
Quando o AppSync executa uma operação de montagem no VMAX 3, ele detecta o iniciador de host para o host de montagem em primeiro lugar, depois, de acordo com o iniciador de host, o AppSync associa à (ou da) exibição de mascaramento. Essa operação determina o grupo de armazenamento em que as LUNs de destino são mascaradas/ desmascaradas. Para montagem/desmontagem de RDM ou Vdisk, o AppSync identifica a exibição de mascaramento que se baseia no iniciador do host para o ESX server.
Você pode selecionar o objetivo de nível de serviço (SLO) desejado para a LUN de destino na fase de montagem do plano de serviço. Se houver um grupo de
armazenamento para o host de montagem com o SLO necessário, o AppSync adiciona a LUN ao grupo de armazenamento. Se o grupo de armazenamento não existir, o AppSync adicionará a LUN a qualquer grupo de armazenamento mascarado para o host.
Se um grupo de armazenamento estiver configurado para selecionar dispositivos de destino, o AppSync removerá os dispositivos do grupo de armazenamento no momento da montagem e os adicionará ao grupo de armazenamento para o host de montagem. Os dispositivos são adicionados ao grupo de armazenamento original quando a cópia expira.
Considerações de plano de serviço para aplicativos no armazenamento do VMAX 3
Analise essas considerações para obter suporte de plano de serviço com o VMAX v3.
Visão geral
Depois de registrar (adicionar) o armazenamento do VMAX 3, registre um aplicativo em um plano de serviço para criar e gerenciar cópias.
Para esta versão do AppSync, os planos de serviço Bronze e Silver são aceitos com o VMAX 3. Um snapshot de um plano de serviço com VMAX 3 é equivalente a um snapshot do SnapVX vinculado no modo no copy. Um clone em um plano de serviço é
equivalente a snapshot do SnapVX vinculado em modo de cópia. A preferência padrão de um plano de serviço é snapshot.
Montar/desmontar cópias de VMAX 3
As operações de montagem/desmontagem no VMAX 3 incluem o mascaramento / desmascaramento de LUNs ou de um conjunto de LUNs para um host. O AppSync depende do recurso de provisionamento automático do VMAX 3. O host de montagem deve ser zoneado para o array do VMAX 3. Crie uma exibição de mascaramento com o grupo de iniciadores, grupo de portas e grupo de armazenamento.
Quando o AppSync executa uma operação de montagem no VMAX 3, ele detecta o iniciador de host para o host de montagem em primeiro lugar, depois, de acordo com o iniciador de host, o AppSync associa à (ou da) exibição de mascaramento. Essa ação determina o grupo de armazenamento em que as LUNs de destino são mascaradas/sem máscaras. Para montagem/desmontagem de RDM ou Vdisk, o AppSync identifica a exibição de mascaramento que se baseia no iniciador do host para o ESX server. Você pode selecionar o objetivo de nível de serviço (SLO) desejado para a LUN de destino na fase de montagem do plano de serviço. Se houver um grupo de
armazenamento para o host de montagem com o SLO necessário, o AppSync adiciona a LUN ao grupo de armazenamento. Se o grupo de armazenamento não existir, o AppSync adicionará a LUN a qualquer grupo de armazenamento mascarado para o host.
Se um grupo de armazenamento estiver configurado para selecionar dispositivos de destino, o AppSync removerá os dispositivos do grupo de armazenamento no momento da montagem e os adicionará ao grupo de armazenamento para o host de montagem. Os dispositivos são adicionados ao grupo de armazenamento original quando expirados.
Configuração do ViPR Controller
Saiba mais sobre o suporte a ViPR Controller com o AppSync, incluindo considerações sobre configuração, aplicativos e planos de serviço compatíveis.
Com esta versão do AppSync, o ViPR Controller opera como outro sistema de
armazenamento. Isso significa que o ViPR Controller precisa ser registrado e detectado no AppSync. Consulte a seção sobre a adição de ViPR Controller a AppSync.
O AppSync aceita snapshots do ViPR Controller como tecnologia de cópia para aplicativos provisionados usando o ViPR Controller.
Obs.
Aplicativos com uma combinação de LUNs para proteção não são aceitos. Por exemplo, o AppSync não aceita uma combinação de LUNs (baseadas em AppSync) nativas no VMAX e LUNs do ViPR Controller.
O AppSync aceita somente aplicativos provisionados pelo ViPR Controller com pools virtuais de blocks respaldos pelo VMAX/VPLEX com armazenamento VMAX e XtremIO. O AppSync não aceita aplicativos provisionados em pools virtuais de arquivo e objeto.
Obs.
O AppSync não aceita ISCSI com o AIX para armazenamento nativo do XtremIO ou XtremIO no ViPR Controller.
Migração de array nativo para o ViPR controller
O AppSync aceita a funcionalidade de gerenciamento de cópias do ViPR Controller, de modo que a migração de aplicativos de plataforma nativa para ViPR ocorre sem qualquer interrupção em cópias existentes e planos de serviço, e sem intervenção manual. Por exemplo:
1. Suponha que você tem um banco de dados Oracle em execução em um VMAX, e está usando o AppSync para proteger esse banco de dados usando um plano de serviço Bronze para proteção local.
2. O AppSync cria um snapshot diário do banco de dados interagindo direta e nativamente com o armazenamento do VMAX, usando um provedor de SMI-S. 3. Em algum momento no futuro, você decide usar uma plataforma ViPR Controller para
automatizar sua infraestrutura de armazenamento. Como parte dessa automação, você move todos os volumes existentes para ViPR Controller. O ViPR Controller exige que todas as tarefas de gerenciamento de armazenamento, como provisionamento de volumes para criação de snapshots, exclusão e assim por diante, sejam
realizadas usando o ViPR Controller.
4. Você ainda precisa de proteção local de seu banco de dados Oracle no
armazenamento do VMAX, mas você deseja migrar para o ViPR Controller, para todas as operações de snapshot.
5. Com o AppSync você pode migrar perfeitamente para a plataforma ViPR Controller sem qualquer intervenção manual nem modificações nos seus planos atuais.
Considerações sobre o plano de serviço com o ViPR Controller
Antes de adicionar um plano de serviço a cópias do ViPR Controller, analise essas considerações.
O recurso de gerenciamento de cópia de ViPR Controller segue o mesmo fluxo de trabalho que o de AppSync para o suporte de array de armazenamento nativo. Por exemplo, você deve configurar um host, um recurso de ViPR Controller dentro de
AppSync e, em seguida, realizar a detecção do aplicativo. Uma vez detectado, você pode inscrever o aplicativo em um plano de serviço existente no AppSync. Para esta versão, são compatíveis os planos de serviço Bronze.
Montar e desmontar cópias do ViPR Controller
Analise essas informações em relação à montagem e desmontagem de cópias do ViPR Controller com o AppSync.
O AppSync permite a montagem de cópias de aplicativos criados usando o ViPR
snapshot para os hosts registrados com ViPR Controller. O AppSync faz uso de grupos de exportação do ViPR enquanto monta cópias de um aplicativo.
Como parte da montagem, o AppSync determina se um host de montagem já tem um grupo de exportação provisionado no array do ViPR e do projeto em que os snapshots estão armazenados. Se o AppSync encontrar um grupo de exportação existente, ele atualiza o grupo de exportação adicionando snapshots ao grupo de exportação. Se o AppSync não puder encontrar um grupo de exportação para o host de montagem e o array do ViPR onde o snapshot está armazenado, o AppSync usa APIs do ViPR para provisionar um novo grupo de exportação para o host do projeto necessário para os arrays do ViPR, onde os snapshots estão localizados.
Dica de solução de problemas de zoneamento automático: Quando uma conta do Fabric Manager tem acesso somente leitura e o zoneamento de SAN de um array do ViPR está definido como Automatic > Create Export Group, essa ação falhará se o host não tiver sido zoneado para o array. O zoneamento automático não pode ser realizado, uma vez que a conta do Fabric Manager tem acesso somente leitura ao fabric. Para contornar esse problema, defina o zoneamento de SAN para Manual e, em seguida, crie manualmente uma zona entre o host e o array físico.
Restauração da cópia do ViPR Controller
Analise esses cenários ao considerar uma restauração de uma cópia de ViPR Controller. O AppSync não aceita a restauração a partir de cópias de aplicativos que são criadas usando o ViPR Controller nos quais o volume foi provisionado pelo ViPR Controller, em um array back-end XtremIO (modo nativo ou por meio de VPLEX no front-end).
Restauração em nível de LUN de snapshot do ViPR
Durante a restauração a partir de um snapshot de ViPR Controller, o AppSync verifica se há uma entidade afetada em caso de grupos de consistência e avisa sobre outros aplicativos que podem ser afetados pela restauração.
Restauração granular
O AppSync aceita restauração granular para máquinas virtuais e arquivo com o ViPR Controller, como a plataforma de armazenamento. Como o ViPR Controller não tem a capacidade de criar uma cópia de uma cópia, a restauração granular para máquinas virtuais sempre usa a clonagem de máquinas virtuais ao recuperar as máquinas virtuais de uma réplica.
A funcionalidade de restauração instantânea é desativada durante o uso do ViPR Controller.
Configuração do XtremIO
Analise os aplicativos compatíveis, a tecnologia de replicação, os requisitos de
configuração e as restrições para os arrays do XtremIO com o AppSync antes de começar a instalação.
Suporte a aplicativos
O AppSync cria snapshots consistentes com gravação no array do XtremIO para cada aplicativo que você adicionar a um plano de serviço. O XtremIO aceita os seguintes aplicativos:
l Bancos de dados Oracle l Bancos de dados SQL Server
l DAG e bancos de dados do Exchange l File systems
l Datastores do VMware
l O RecoverPoint (versão mínima 4.1.2) é compatível com o XtremIO 4.0 e posteriores e
com o AppSync 2.2.2 e posteriores. Tecnologia de replicação
O AppSync cria snapshots do XtremIO dos dados de aplicativos e coloca os snapshots na pasta comum: /AppSyncSnapshots/APPSYNCSERVERNAME/
PRODUCTIONHOSTNAME/Mova os snapshots do XtremIO da pasta comum somente se você usar o recurso de remoção do AppSync, que remove uma cópia de AppSync, mas não remove os snapshots de XtremIO.
O AppSync nomeia os snapshots usando a seguinte nomenclatura:
TIMESTAMP.snap.ORIGINALVOLNAMEDevido ao limite de XtremIO de 64 caracteres em um nome de snapshot, o ORIGINALVOLNAME deve ter 40 caracteres ou menos. Analise os limites do XtremIO com relação ao número de snapshots de LUNs que podem ser criados ao mesmo tempo. Não permita que as configurações de banco de dados Oracle excedam o número de volumes limitado pelos recursos de snapshot máximo do XtremIO.
Obs.
Para conhecer os limites do XtremIO, especialmente os limites relacionados aos snapshots e às pastas do XtremIO, analise as Notas da versão do EMC XtremIO. Essas notas estão disponíveis no site de suporte da EMC.
Restrições
Considere as seguintes restrições para o XtremIO com o AppSync:
l O XtremIO não aceita a restauração de XtremIO Snapshots para o volume original. No
entanto, procedimentos de recuperação semimanuais usando cópias do AppSync existem para cada aplicativo aceito.
l Os grupos de iniciadores do XtremIO devem ser definidos no XtremIO para todos os
hosts de montagem aos quais o AppSync monta cópias do XtremIO.
l Para esta versão, o AppSync não aceita o XtremIO com a conectividade ISCSI para
hosts do AIX.
Considerações sobre a configuração
l O Management Server do XtremIO (XMS) deve ser configurado em uma SAN com um
array de XtremIO.
l Faça o zoneamento dos arrays do XtremIO para os hosts de produção e montagem
(físicos) ou ESX servers (virtuais).
l Para montar e desmontar cópias:
n Certifique-se de configurar os bancos de dados Oracle ou SQL Server nos arrays
do XtremIO para dados e registros.
n Fibre Channel e iSCSI são compatíveis.
Considerações para antes de adicionar um array:
Para adicionar e configurar um array do XtremIO para funcionar com AppSync, você precisa de um Management Server do XtremIO (XMS) configurado em uma SAN com pelo menos um array de XtremIO. Um XMS gerencia cada array do XtremIO. Analise as seguintes considerações antes de adicionar um array:
l Privilégios de administrador são necessários para adicionar o array do XtremIO. l Certifique-se de que o zoneamento do armazenamento do XtremIO foi feito para os
hosts de produção (físicos) ou ESX servers (virtuais). RDM e discos virtuais são compatíveis com máquinas virtuais VMware. iSCSI é compatível com hosts Windows e Linux, permitindo que você consulte o armazenamento do XtremIO por meio de uma LAN iSCSI. iSCSI é compatível com hosts físicos ou virtuais e também ESX servers.
l Oracle, file systems e datastores VMFS no AIX/Linux são compatíveis. File systems e
discos virtuais são compatíveis no Windows.
l Você precisa do nome/endereço IP e credenciais do XMS.
Para consultar as etapas para adicionar um array do XtremIO, acesse Adicionar um array do XtremIO ao AppSync na página 51.
Resumo dos recursos de planos de serviço para o XtremIO
Para criar cópias de dados consistentes com aplicativos, os planos de serviço estão habilitados para XtremIO. Analise essas considerações quando você adiciona um plano de serviço a um array do XtremIO.
O AppSync 2.2.2 e posterior com o XtremIO 4.0 e posterior aceitam os planos de serviço Bronze, Silver e Gold. O AppSync é compatível somente com os planos de serviço Bronze no XtremIO 3.x, usando o AppSync 2.1.x.x até 2.2.1.x.
O AppSync seleciona o snapshot do XtremIO como a tecnologia de replicação padrão para cópias de pedidos de armazenamento quando um plano de serviço é executado. Os planos de serviço do XtremIO permitem que você coloque os itens de aplicativos de vários sistemas de armazenamento do XtremIO no mesmo plano de serviço. O scripting de plano de serviço é ativado quando você configura ações de script de montagem e desmontagem. Você também pode configurar a contagem de rodízio de expiração e executar um plano de serviço em uma programação ou sob demanda.
Opções de restauração com o armazenamento do XtremIO
Saiba mais sobre as opções de restauração para cópias de aplicativos nos arrays do XtremIO ao planejar a instalação.
O AppSync 2.2.2 e posteriores aceitam a restauração automática de cópias do XtremIO 4.0 e posteriores. Os seguintes aplicativos são compatíveis:
l Bancos de dados SQL Server
l Bancos de dados do Exchange independentes e grupos de disponibilidade de dados
(DAG) do Exchange
l Datastores do VMware l File systems
l RecoverPoint
O AppSync usa o Assistente Restore para a restauração automatizada no armazenamento do XtremIO. O botão de restauração não fica mais desabilitado para cópias do XtremIO. Clique no botão Restore para iniciar o Assistente Restore para os respectivos aplicativos. Durante a restauração, o AppSync cria outro snapshot gerado pelo XtremIO, armazenado sob a marca /volumes/AppSyncSnapshots/RestoredSnapshots. Um
administrador deve limpar esses snapshots manualmente.
Obs.
Se você tiver duas cópias para restaurar, uma para o XtremIO 3.x e outra para o XtremIO 4.0, o AppSync permite restaurar apenas para a cópia de 4.0. Uma advertência é exibida para a cópia de 3.x.
O AppSync 2.1 até 2.2.1.x com o XtremIO 3.0 aceita a restauração semimanual para os seguintes aplicativos:
l Bancos de dados SQL Server
l Bancos de dados do Exchange independentes e grupos de disponibilidade de dados
(DAG) do Exchange
l File systems
O Guia de administração e usuário do AppSync fala sobre os procedimentos para cada tipo de restauração semimanual.
Configuração do RecoverPoint
Considere as práticas recomendadas para a configuração do RecoverPoint antes de implementar o AppSync. Por exemplo, não se esqueça de observar as práticas recomendadas de granularidade do grupo de consistência do RecoverPoint.
Considerações sobre o plano de serviço para aplicativos com proteção do
RecoverPoint
O AppSync aceita diferentes opções de replicação do RecoverPoint. Três tipos de opções de replicação:
Proteção contínua de dados
Na proteção contínua de dados (CDP), o RecoverPoint replica para um array de armazenamento no mesmo local. Em uma instalação do RecoverPoint que é usada exclusivamente para CDP, você instala RPAs em apenas um local e não especifica uma interface de WAN. O plano de serviço Bronze protege a replicação de
aplicativos.
Replicação contínua remota
Na replicação contínua remota (CRR), o RecoverPoint replica em uma WAN para um local remoto. Não há limite para a distância de replicação. O plano de serviço Silver protege a replicação de aplicativos.
Simultânea local e remota
Na replicação simultânea local e remota (CLR), o RecoverPoint protege LUNs de produção local usando CDP e, remotamente, usando CRR. As duas cópias têm políticas RPO e janelas de proteção distintas. O plano de serviço Gold protege a replicação de aplicativos. Vários locais de (vários locais remotos) do RecoverPoint não são compatíveis no momento.
Pré-requisitos do RecoverPoint
Verifique se a configuração do RecoverPoint atende aos pré-requisitos necessários para uso com o AppSync.
l Instale e configure o RecoverPoint de acordo com a sua documentação. l Use o RecoverPoint para criar grupos de consistência.
l Certifique-se de que os divisores para todos os hosts de montagem estão conectados
aos volumes de destino do RecoverPoint que eles vão usar.
l Sincronize a hora em todos os sistemas. Siga as etapas na documentação do
sistema operacional para configurar o servidor do AppSync e todos os hosts de produção e montagem que serão sincronizados com um servidor de hora. Isso inclui todos os hosts, armazenamento VNX e os dispositivos RecoverPoint.
l Para a preparação de failover, lembre-se de que o AppSync exige que os grupos de
consistência do RecoverPoint simultâneos local e remotos (CLR) tenham cópias locais e remotas, mesmo em uma situação de failover. As etapas de configuração de administrador do RecoverPoint podem ser necessárias após o failover para configurar uma cópia local no local remoto.
l Durante a configuração do AppSync, o local do RecoverPoint é adicionado como um
recurso. Na configuração de um CLR, o AppSync detecta todos os locais na configuração do sistema do RecoverPoint. Credenciais para uma conta que tenha privilégios de administrador do RecoverPoint são necessárias ao adicionar o local.
Montagens dinâmicas ou estáticas
As cópias do RecoverPoint podem ser montadas de duas maneiras, de forma estática ou dinâmica.
O AppSync aceita montagens estáticas de destinos do RecoverPoint. Usando montagens estáticas, as LUNs (CDP ou CRR) de destino do RecoverPoint precisavam ser expostas previamente (mascaradas) para o host de montagem antes que você pudesse montar as cópias do RecoverPoint. Se você estiver usando montagens estáticas em um ambiente de máquina virtual, as LUNs de destino do RecoverPoint deverão ser mascaradas para o ESX server e adicionadas como RDMs às máquinas virtuais antes da montagem da cópia. Os destinos do RecoverPoint também podem ser montados dinamicamente. As LUNs de destino do RecoverPoint são associadas na hora da montagem para identificar as LUNs, e as LUNs são mascaradas (movidas para o grupo de armazenamento de host de
montagem) e apresentadas antes da montagem. Quando as LUNs de destino para a montagem dinâmica estão no armazenamento do VNX, o VNX deve ser registrado com o AppSync.
Para montagens dinâmicas do VMAX, siga as instruções de provisionamento automático do VMAX para realizar efetivamente o mascaramento.
Se você estiver usando montagens dinâmicas em um ambiente virtual, não mascare as LUNs de destino para o ESX server. O AppSync vai mascarar a LUN para o ESX server e, em seguida, adicionar a LUN como um RDM no host de montagem. Consulte Montar e desmontar cópias do VMAX na página 18.
Ao desmontar:
l As LUNs que foram montadas dinamicamente são desmontadas dinamicamente, ou
seja, as LUNs são removidas do grupo de armazenamento.
l As LUNs que foram montadas estaticamente permanecem no grupo de
armazenamento após a conclusão da desmontagem.
l Para cópias de aplicativos com LUNs misturadas (tanto montadas de modo estático
quanto dinâmico), as LUNs serão dinamicamente desmontadas. Todas as LUNs montadas são removidas do grupo de armazenamento.
Com o zoneamento adequado, o AppSync apresenta o armazenamento ao host automaticamente quando uma cópia é montada.
Host físico
O AppSync atribui dinamicamente um snapshot para o host quando a cópia é montada. O host físico deve ser zoneado para o array do VNX das LUNs de destino do RecoverPoint (CDP ou CRR).
Máquina virtual
Montagens dinâmicas acontecem como um mapeamento de dispositivos brutos (RDM) ou por meio de iSCSI nativo na máquina virtual.
l Para RDM, o ESX server onde a máquina virtual reside deve ser zoneado para o array
do VNX das LUNs de destino do RecoverPoint (CDP ou CRR).
l Para RDM e discos virtuais, a central virtual (que gerencia o ESX server onde reside o
host de montagem da máquina virtual) deve ser registrado com o servidor do AppSync.
l Para iSCSI nativo, a máquina virtual deve estar conectada aos iniciadores de VNX das
LUNs de destino do RecoverPoint (CDP ou CRR). O VNX deve ter um grupo de armazenamento definido para o host.
Instalação
Este capítulo inclui informações sobre como instalar o software AppSync. Para obter informações sobre como instalar os arrays, consulte o capítulo sobre configuração, seção sobre gerenciamento de recursos.
Os tópicos deste capítulo incluem:
l Visão geral de nova instalação do AppSync...30 l Visão geral de upgrade...34 l Visão geral da instalação de pacote de serviço...36 l Desinstalando o servidor ...38 l Remover um servidor do AppSync... 39 l Desinstalando o plug-in do servidor do AppSync...39
Visão geral de nova instalação do AppSync
Analise esta seção antes de realizar uma nova instalação do AppSync. Isso significa que não há versões anteriores do AppSync no sistema.
Para instalar o AppSync, você deve executar as seguintes operações que são discutidas em mais detalhes nesta seção:
l Instalar o servidor do AppSync.
l Instalar o plug-in do agente do AppSync. l Adicionar os servidores ao AppSync.
Se você deseja fazer upgrade de uma instalação existente do AppSync para a versão atual completa (não um service pack), consulte Upgrade da instalação do AppSync na página 34.
Para instalar um Service Pack do AppSync, consulte Instalar um service pack.
Instalando o servidor
O primeiro passo para instalar seu AppSync é instalar o servidor do AppSync executando o executável de instalação do host do servidor do AppSync.
Antes de você começar
Obtenha o executável de instalação da distribuição do AppSync ou na página de download do AppSync, no site de suporte da EMC.
Procedimento
1. Execute o arquivo executável de instalação. 2. Siga as etapas do assistente:
a. Aceite o contrato de licença.
b. Informe um nome de usuário para a conta de administrador padrão. c. Digite uma nova senha para a conta de administrador.
A senha da conta de administrador padrão deve ter no mínimo oito caracteres, com maiúsculas e minúsculas e deve conter pelo menos um número e um caractere especial da seguinte lista: !@#$%^&()_-+={}[]<>?/`:;',.|\" d. Se você deseja um local de instalação diferente do padrão, especifique-o.
O caminho do local de instalação não pode conter um espaço.
Local do registro de instalação para o servidor
O registro de instalação para o AppSync Server, appsync_setup.log, fica na pasta definida pela variável de ambiente TEMP do usuário instalador.
Instalando o plug-in de host manualmente - apenas servidores Windows
Instale o plug-in de host manualmente quando um firewall ou outras medidas de segurança impeçam a instalação forçada (push) do servidor para o host do aplicativo.
Antes de você começar
Você precisa obter o executável de instalação do plug-in de host do AppSync da distribuição de AppSync ou na página de suporte de AppSync, em: https:// support.emc.com
Procedimento
1. Execute o arquivo de instalação do executável do plug-in. 2. Siga as etapas do assistente.
Aceite o contrato de licença. Você pode especificar um local de instalação e uma porta diferente do padrão. Se você usar uma configuração de porta não padrão, mantenha um registro dela. Você precisa especificá-la quando adicionar o host do AppSync.
Depois que você terminar
Hosts instalados manualmente também devem ser adicionados ao AppSync. Use o console do AppSync, em Settings > Servers.
Obs.
Talvez seja necessário reinicializar o Exchange após a instalação do plug-in do host.
Execute a instalação forçada do plug-in de host UNIX com o usuário sudo
Esta seção demonstra como realizar uma instalação forçada do plug-in de host do AppSync UNIX do servidor do AppSync. É necessária a configuração manual. Este exemplo usa o usuário sudo no Linux.
Antes de você começar
l Crie um usuário no host onde você planeja executar o agente do AppSync.
l Edite o arquivo sudousers usando visudo. (Você deve editar o arquivo como root.)
Certifique-se de que tem permissões para gravar no diretório. Adicione as seguintes linhas ao final do arquivo:
n n Defaults: user !requiretty
n n Defaults: user !env_reset
n n {user} ALL = (root) NOPASSWD: /{install path}/acp, onde {user} é
o nome de usuário que você criou, {install path} é o local onde você deseja
instalar o AppSync. Por exemplo:
appsync ALL = (root) NOPASSWD: /opt/emc/appsync/acp
Acesse o console do AppSync como o usuário que você criou nos pré-requisitos, em seguida, acesse o caminho de instalação que você definiu para sua instalação do AppSync.
Este exemplo (específico para AIX) mostra a configuração necessária para executar uma implementação bem-sucedida usando o usuário sudo appsync no local de
implementação a seguir: /opt/emc/appsync. Procedimento
1. Instale o pacote RPM SUDO, sudo-1.7.10p7-1 no AIX 6.1.
2. Instale o zlib, caso ainda não tenha sido instalado.
3. Instale o openssh para o AIX 6.1. 4. Execute o servidor SFTP como root.
5. Crie o usuário appsync usando a smit.
6. Execute o comando visudo como root para abrir o arquivo do sudoers e depois
edite o arquivo de sudousers para incluir as seguintes linhas para o appsync do
usuário sudo como root:
l n Defaults: {user} !requiretty
l n Defaults: {user} !env_reset
l n user} ALL = (root) NOPASSWD: /{install path}/acp
Onde {user} é o nome de usuário que você criou e {install path} é o local onde você deseja instalar o AppSync.
Obs.
A pasta acp deve ser usada especificamente com a opção NOPASSWD.
7. Crie uma pasta, /appsync em /opt/emc, com permissões de leitura, gravação e execução para o usuário sudo appsync.
8. Inicie o serviço do servidor SFTP para o usuário do appsync.
Detectar novamente o servidor
Detectar novamente um servidor recupera as informações do servidor no plug-in de host do AppSync. Por exemplo, se você adicionou o Exchange ao host, usar Rediscover deve atualizar o servidor com o novo aplicativo associado.
Antes de você começar
Essa operação requer a função de administrador de recursos em AppSync Procedimento
1. Selecione Settings > Servers.
2. Selecione o servidor que você deseja atualizar. 3. Selecione Rediscover.
4. Selecione Yes para confirmar.
Adicionando servidores
Saiba como adicionar seus servidores para a configuração do AppSync. Antes de você começar
Analise essas informações antes de começar. Quando você adiciona um servidor, o AppSync registra o servidor em seu banco de dados e detecta os objetos que podem ser protegidos naquele servidor. Se o software de plug-in de host não estiver presente ainda, o AppSync tenta instalá-lo. Se o software de plug-in de host estiver presente, o AppSync tenta registrá-lo. Ocorre um erro se o software de plug-in de host já estiver registrado em outro servidor do AppSync.
l Os servidores precisam estar acessíveis via IP ao servidor do AppSync. l Você precisa informar as credenciais para uma conta que tem privilégios de
administrador local no servidor.
l Para servidores Windows: se o servidor não for parte de um domínio, desabilite o
seguinte controle de acesso de usuário: User Access Control: Run all administrators in Admin Approval Mode .
