Hide Notes 

Slide 1: Criando sites OLAP de grande escala e disponibilidade: um guia passo a passo Dave Wickert Microsoft Corporation Resumo Este documento apresenta várias técnicas necessárias à criação de sites de processamento analítico on-line (OLAP) de grande escala e disponibilidade por meio do Network Load Balancing e do Analysis Services do Microsoft® SQL Server™ 2000 em uma infra-estrutura do Microsoft Windows® 2000 Advanced Server. Alta disponibilidade refere-se à capacidade de um site com vários servidores de oferecer suporte a interrupções no hardware ou no software que podem afetar servidores individuais. Um site de grande escala é um site que possui centenas de gigabytes (GB) de dados, o que torna ineficientes as operações normais de cópia de arquivos. Este documento fornece instruções passo a passo que demonstram como criar os servidores e a infra-estrutura de suporte de um site de referência com base em arquiteturas de cliente magro e de cliente gordo. As arquiteturas descritas foram desenvolvidas para: • • Proteger os dados de um site OLAP com vários servidores e manter o site ativo e funcionando durante interrupções não planejadas. Coordenar a alocação de recursos de processamento durante interrupções planejadas, como atualizações de dados e ciclos complexos de extração, transformação e carregamento (ETL). • Resolver muitos dos problemas operacionais de teste para produção que podem ocorrer em sites OLAP grandes. Introdução O mundo dos negócios está crescendo a passos largos, às vezes exponencialmente. Em conseqüência disso, as pessoas que trabalham com conhecimento enfrentam muitos desafios. Os clientes esperam que o serviço seja excelente, os negócios terceirizam funções secundárias e o mercado exige um grande desempenho financeiro. Resumindo, espera-se que as pessoas que trabalham com conhecimento façam muito com poucos recursos. As ferramentas que essas pessoas usam para análise são críticas
Slide 2: e devem ser flexíveis e adaptáveis em um clima de constantes mudanças nos negócios. Além das mudanças constantes, a quantidade de dados continua aumentando exponencialmente. Não é incomum os sistemas de suporte a decisões incluírem centenas de gigabytes (GB) de dados. Por fim, a Internet está mudando rapidamente o modo como as informações são passadas aos usuários finais. Mesmo que muitas abordagens sejam possíveis, o acesso de usuários finais é normalmente classificado como cliente magro ou cliente gordo. Cliente magro significa que o único componente de um aplicativo instalado no computador do usuário final é um navegador. Cliente gordo significa que componentes adicionais do aplicativo foram instalados no computador do usuário final. Como as duas abordagens são razoáveis e apropriadas, a arquitetura da rede e de aplicativos deve ser flexível o bastante para a implementação de qualquer uma das abordagens. A arquitetura apresentada neste documento é baseada em um aplicativo de Business Inteligence que fornece dados de comércio eletrônico a seus clientes. Essa arquitetura é baseada no Analysis Services do Microsoft® SQL Server™ 2000 e no Microsoft Windows® 2000 Advanced Server. Além de adicionarem valores a sistemas operacionais padrão e a aplicativos da Internet, as soluções de inteligência de negócios diferem desses sistemas e aplicativos de três maneiras. Estas são as soluções: • • Fornecem a capacidade de extrair, limpar e agregar dados de vários sistemas operacionais em um data mart ou em um data warehouse separado. Armazenam dados, quase sempre em um esquema de estrela ou em um formato de cubo multidimensional (OLAP) para permitir a transmissão rápida de informações resumidas e a capacidade de executar pesquisas mais detalhadas. • Transmitem visões informativas personalizadas e relevantes e entregam recursos de consulta, relatório e análise que vão além dos recursos de relatório padrão de sistemas baseados em transações — requisito para a obtenção de uma melhor compreensão do negócio e para a tomada de boas decisões de maneira rápida. Embora nem todos os aplicativos de inteligência de negócios usem técnicas de OLAP, o OLAP resolve problemas em muitos sistemas, e suas aplicações estão crescendo. Como os aplicativos OLAP continuam expandindo e evoluindo para abordar as necessidades
Slide 3: da comunidade de inteligência de negócios, tornou-se muito importante hospedar aplicativos em uma plataforma flexível que forneça escalabilidade, confiabilidade e disponibilidade. Atualmente, a maioria dos aplicativos OLAP não são necessários para que os padrões de escalabilidade e disponibilidade, que aplicativos de missão crítica devem atender, sejam satisfeitos. No entanto, isso está mudando com rapidez. Em algumas empresas, o produto final são os próprios dados; em outras, os dados OLAP são usados para direcionar as operações rotineiras da empresa. Este documento aborda as necessidades dessas empresas apresentando uma arquitetura de site de referência que combina técnicas de sites com aplicativos OLAP. Metas A arquitetura de site de referência descrita aqui satisfaz às seguintes metas: • Usa técnicas flexíveis de acesso a dados para que as informações possam ser coletadas em várias fontes, como RDBMS, arquivos planos e planilhas do Microsoft Excel. • Usa um processo automatizado para atualizar os cubos de produção que requerem pouca ou nenhuma intervenção do operador. O processo pode ser personalizado. Por exemplo, você pode adicionar etapas de reconciliação, permitindo que os administradores validem os dados antes que eles sejam movidos para produção. • Transfere dados praticamente em tempo real e em um formato on-line que permite pesquisas mais detalhadas e análises, incluindo suporte básico para dinamização e fatiamento. • Inclui produtos Microsoft, como o Microsoft Office 2000, para fornecer acesso de usuário final aos dados, mas a arquitetura também permite que usuários finais avançados executem ferramentas com base em tecnologias novas e sofisticadas, como visualização e busca de dados. • • Oferece suporte à administração remota em um ambiente não monitorado. Fornece serviços de modo robusto e amplamente disponível. Os usuários esperam que os serviços estejam disponíveis 24 horas por dia, sete dias por semana, 365 dias por ano.
Slide 4: • Transfere dados pela Internet, mas a arquitetura é flexível o bastante para permitir que a mesma infra-estrutura seja usada para aplicativos internos da intranet. • Demonstra uma arquitetura construída com hardware comum e pronto para uso, produzido por vários fornecedores, e com os softwares atuais da Microsoft. A arquitetura usa um grande número de produtos e serviços para: • Alta disponibilidade. Network Load Balancing é um recurso do Windows 2000 Advanced Server usado para criar clusters de servidores sem um único ponto de falha. Os servidores de banco de dados também são agrupados em cluster para fornecer alta disponibilidade durante o teste de processamento de dados no final do período. • • Escalabilidade. Se Analysis Servers front-end adicionais forem necessários, será possível adicioná-los de maneira rápida e fácil, sem afetar o site existente. Taxa de transferência para um grande volume de dados. O SQL Server é freqüentemente usado em aplicativos de linhas de negócios que contêm centenas de GB de dados. Inclui serviços de transformação de dados (DTS) e Analysis Services, que transformam e carregam dados, além de processar informações OLAP. Todos os componentes usados na arquitetura são incluídos no SQL Server. • Ferramentas comuns de banco de dados. O DTS usa interfaces abertas do OLE DB, o que permite que empresas utilizem um grande número de fontes de dados. • Acesso de usuário final. OLE DB para OLAP é uma interface amplamente aceita que fornece acesso a dados armazenados no SQL Server em qualquer formato OLAP. O PivotTable® Service, uma versão compacta do Analysis Services do SQL Server, atua como um cache inteligente entre o cliente e o servidor. Juntamente com o Excel 2000, o PivotTable Service diminui os tempos de consulta e dá suporte a análises off-line. Este documento pressupõe que o Analysis Services do SQL Server 2000 esteja sendo usado. Para fins de histórico, quando apropriado, este documento fornecerá informações adicionais sobre os serviços OLAP do SQL Server 7.0. No entanto, as técnicas e as abordagens descritas aqui só foram verificadas com o Analysis Services do SQL Server 2000.
Slide 5: Benefícios desta abordagem Uma solução bem desenvolvida aborda as necessidades atuais dos usuários, fornecendo benefícios imediatos. Além disso, leva em consideração situações futuras, fornecendo benefícios futuros. Os benefícios futuros que uma solução pode oferecer são chamados de flexibilidade. Quanto mais flexível for a solução, maiores serão seus possíveis benefícios. Benefícios imediatos A solução proposta neste documento fornece os seguintes benefícios imediatos para administradores e usuários: • Ao fornecer informações apropriadas a usuários finais, você pode habilitá-los a utilizar e reutilizar as informações em cenários diferentes. Esse é o verdadeiro poder dos aplicativos OLAP. • Ao fornecer administração remota, você cria um verdadeiro ambiente não monitorado. É possível administrar o sistema de qualquer lugar através da Internet. • Como não há pontos de falha, o site é robusto e confiável. Mesmo que haja falha em um servidor ou que ele fique off-line, o site continuará sendo executado. • Ao transmitir informações usando a Internet, você pode: o o o o • Reduzir os custos de transferência. Aumentar o alcance do usuário. Reutilizar a mesma infra-estrutura para administradores. Implementar novos aplicativos de maneira mais rápida (particularmente se você usar uma abordagem de cliente magro). Ao incluir uma disposição para uma conexão direta com a rede corporativa, você pode acessar facilmente sistemas existentes nos quais os dados transacionais de origem estão localizados. Isso reduz os custos e aumenta a velocidade de desenvolvimento de novas interfaces. Benefícios futuros A solução proposta neste documento fornece os benefícios futuros para administradores e usuários:
Slide 6: • Como a solução usa o Network Load Balancing, o cluster de Analysis Servers tem até 32 servidores. Isso fornece mais capacidade de crescimento. Você também pode adicionar mais CPUs a cada servidor. • A presença de vários servidores de banco de dados na arquitetura fornece capacidade adicional caso seja necessário aumentar o teste de dados. No entanto, antes de começar a usar servidores extras, considere os benefícios trazidos por uma maior capacidade e o impacto de um failover. Por exemplo, suponha que existam dois servidores de banco de dados. Se o processamento do final do mês aumentar, você poderá usar os dois servidores para o processamento de dados, mas não terá proteção a falhas. Convém equilibrar a proteção a falhas e os requisitos gerais de processamento do sistema. • A alta disponibilidade aumenta a aceitação dos dados pelos usuários finais. Isso é importante para aplicativos de suporte a decisões, pois o usuário sempre tem a capacidade de adicionar entradas subjetivas ao problema em questão. Se os dados não estiverem disponíveis, os usuários finais poderão achar mais fácil interpretar os dados sem ajuda, em vez de contar com o aplicativo. Se o sistema estiver sempre disponível, os usuários tomarão decisões usando as ferramentas de análise e os dados disponíveis — com todos os benefícios oferecidos. Organização do documento Este documento inclui as seguintes seções: • Questões de design — Esta seção é uma visão geral dos problemas de arquitetura que geralmente surgem na criação de sites OLAP de grande escala e disponibilidade. • Criando sites OLAP de grande escala e disponibilidade — Esta seção resume a arquitetura necessária para a criação e a manutenção de um site OLAP de alta disponibilidade. O Windows 2000 Advanced Server fornece serviços de sistema para Windows Clustering, que é a tecnologia que oferece suporte à arquitetura para a criação de um site de alta disponibilidade. • • Configurações alternativas — Esta seção apresenta sugestões para a adaptação da arquitetura de referência a situações específicas. Localizando mais informações — Esta seção fornece links para recursos adicionais que abordam a tecnologia e as questões usadas neste documento.
Slide 7: • Apêndice A: Guia passo a passo — Este apêndice contém diretrizes para a configuração do Network Load Balancing através do Windows 2000 Advanced Server, do Analysis Services, e de sua infra-estrutura de suporte para o site de exemplo. • Apêndice B: Ferramenta de linha de comando — Este apêndice contém documentação para wlbs, uma ferramenta de linha de comando usada para gerenciar clusters do Network Load Balancing. • Apêndice C: Scripts de exemplo — Este apêndice contém scripts de exemplo para o trabalho com o Network Load Balancing e com o Analysis Services (por exemplo, para parar e iniciar o Network Load Balancing e o Analysis Services, alterar a pasta Data do Analysis Services e mover o repositório da pasta Bin para a pasta Data). • Apêndice D: Configuração de serviço de cluster — Este apêndice descreve como configurar o Analysis Services em um cluster de servidor. Embora não haja suporte para esse recurso, ele pode ser uma alternativa adequada para alguns sistemas. Questões de design Este documento orienta você através das etapas de criação de uma arquitetura de exemplo para um site OLAP escalonável e de alta disponibilidade através do Windows 2000 Advanced Server. Os sites descritos neste documento podem ser usados para a obtenção de serviços OLAP de alta disponibilidade, para sites dedicados ou compartilhados. Um design de site semelhante também pode ser usado como host de um site de intranet de alta disponibilidade. Uma arquitetura de alta disponibilidade permite que um site com vários servidores suporte interrupções de hardware ou software planejadas e não planejadas que afetam servidores individuais do site. Um exemplo de interrupção planejada é colocar o servidor off-line para que a manutenção execute a atualização do software. Enquanto o servidor estiver off-line para a operação de manutenção do software, o resto do site permanecerá on-line, fornecendo serviço aos usuários. Um exemplo de interrupção não planejada é uma falha de hardware. Nesse caso, o resto do site permanece on-line, fornecendo serviço aos usuários, pois os processos que oferecem serviços de dados para o site falham para os clusters de servidor restantes. A arquitetura descrita neste
Slide 8: documento foi desenvolvida para proteger os dados desse site e para manter o site ativo e funcionando. Esta seção descreve alguns requisitos comuns de arquitetura de sites OLAP de grande escala e disponibilidade: • • • A criação de clusters para a obtenção de alta disponibilidade A criação de um recurso de teste de alta disponibilidade que mantém os dados OLAP disponíveis durante o processamento de partição e de cubo A transferência de dados para a produção A solução proposta neste documento aborda essas necessidades. Usando o Windows Clustering O Windows Clustering permite que um grupo de servidores independentes seja gerenciado como um único sistema para a obtenção de disponibilidade mais alta, gerenciamento mais fácil e maior escalabilidade. O sistema operacional Windows 2000 Advanced Server inclui duas tecnologias de cluster desenvolvidas com essa finalidade: clusters de servidor, conhecidos como Microsoft Cluster Server (MSCS), que basicamente fornecem suporte a falhas para aplicativos importantes de linha de negócios, como bancos de dados, sistemas de mensagens e serviços de impressão e arquivo; e o Network Load Balancing, que equilibra o tráfego IP de entrada entre clusters com vários nós. As duas tecnologias estão incluídas como parte do Windows 2000 Advanced Server. Embora cada tecnologia possa ser usada de forma independente para a obtenção de um alto nível de serviço para o site, a escalabilidade, a confiabilidade e a disponibilidade do site são maximizadas quando as tecnologias são usadas em conjunto para a criação da infra-estrutura do site. A arquitetura de referência usa o Network Load Balancing para os Analysis Servers e o serviço Windows Clustering para os serviços de arquivo e os serviços de banco de dados back-end. O Network Load Balancing foi escolhido como a principal tecnologia de clusters para a arquitetura de referência, pois tem boa escalabilidade. Esse equilíbrio pode ser configurado em dois modos: modo de prioridade e modo de vários hosts. No modo de prioridade, geralmente usado quando o failover é a questão principal, um único
Slide 9: servidor lida com todas as solicitações de entrada e o tráfego é roteado para outros servidores quando esse servidor não está disponível. No modo de vários hosts, todos os computadores estão disponíveis para lidar com solicitações de entrada. Para o tipo de solicitação que o Analysis Services envia, é preferível o modo de vários hosts, pois esse modo usa todos os recursos disponíveis, e o equilíbrio é mais eficaz na distribuição da carga. Diferentemente de clusters de servidor, o Network Load Balancing não exige que os servidores sejam idênticos. Você pode ter qualquer combinação de computadores com recursos diferentes. Além disso, o Network Load Balancing não tem uma lista de compatibilidade de hardware (HCL) específica. Para obter mais informações, consulte a HCL (http://www.microsoft.com/hcl/) (site em inglês). Qualquer sistema capaz de executar o Windows 2000 Advanced Server pode ser usado em um cluster de Network Load Balancing. O Network Load Balancing distribui o tráfego IP por várias cópias (ou instâncias) de um serviço TCP/IP, como um servidor Web. Para o Analysis Services, cada Analysis Server é executado em um host do cluster. O Network Load Balancing divide de forma transparente as solicitações de entrada de clientes entre os hosts. Do ponto de vista do cliente, o cluster parece ser um único servidor que responde a solicitações de clientes. À medida que o tráfego da empresa aumenta, os administradores de rede podem adicionar outro servidor ao cluster. Os clusters de servidor foram desenvolvidos especificamente para abordar questões de failover. Eles não são usados para escalabilidade. Em um cluster de servidor, todos os sistemas devem ser idênticos (até o nível de revisão do firmware) e o hardware deve ser selecionado em uma seção separada da HCL. Embora o Analysis Services possa ser executado em clusters de servidor, não há suporte para ele. Para obter mais informações, consulte o "Apêndice D". Este documento não descreve os recursos e as funções do Windows Clustering e do Network Load Balancing. Ele pressupõe que você tenha um conhecimento básico sobre as tecnologias Microsoft usadas nos cenários de alta disponibilidade. Para obter mais informações sobre essas tecnologias, consulte "Localizando mais informações" posteriormente neste documento. Criando um recurso de teste
Slide 10: Um recurso de teste fornece um local onde você pode trabalhar com os dados antes de movê-los para a produção e onde os usuários têm acesso a esses dados. Se usar um recurso de teste separado, você poderá trabalhar com dados sem colocar os servidores de produção off-line. A arquitetura de referência abordada neste documento fornece um extenso recurso de teste para oferecer suporte aos recursos adicionais exigidos por atividades de teste. É preciso que esse recurso possa ser expandido normalmente caso requisitos de armazenamento ou processamento exceda a capacidade inicial. Os aplicativos OLAP integram dados de muitas fontes. Obviamente, o recurso de teste deve ter os recursos de CPU e de disco para lidar com os dados e com o processamento. O recurso de teste também deve fornecer sempre recursos além da soma das fontes de dados individuais. Muitos sistemas transacionais on-line mantêm apenas um instantâneo dos dados que geram, salvando somente as informações necessárias para o processamento imediato. Por exemplo, um sistema de controle de distribuição só pode armazenar registros de remessa do mês atual, excluindo-os depois do recebimento de um item. No entanto, como os sistemas OLAP são quase sempre usados para investigar tendências, geralmente, eles têm períodos de retenção mais longos. Um sistema OLAP pode manter registros por 36 ou 48 meses — muito mais tempo do que suas contrapartes transacionais. Portanto, o recurso de teste pode exigir muito mais espaço de armazenamento e pode apresentar requisitos de processamento adicionais para conseguir manter e processar dados de histórico. Como os dados podem ser provenientes de fontes diversas, o sistema OLAP deve executar muitas das etapas de processamento que sistemas de armazenamento de dados de grande escala executam. Por exemplo, um sistema OLAP pode usar dados provenientes de um sistema de controle de distribuição para fazer a correlação entre o número de uma fatura usada no sistema de cobrança e um número de remessa emitido por uma empresa de remessa externa. O sistema OLAP pode filtrar, limpar, normalizar e mesclar os dados ao processar os dados do cubo ou OLAP. Geralmente, todas essas etapas extras de processamento requerem um recurso de teste separado. Postando dados para a produção
Slide 11: Depois que forem trabalhados, transformados e validados, os dados estarão prontos para serem postados para o ambiente de produção, onde os usuários poderão vê-los e consultá-los. Tradicionalmente, os aplicativos OLAP têm usado uma metodologia de desenvolvimento simples: 1. Os desenvolvedores e os usuários finais trabalham para projetar uma série de cubos. 2. Os administradores de bancos de dados localizam as fontes de dados apropriadas e determinam como filtrar, limpar, normalizar e mesclar os dados para criar os cubos. 3. Os cubos são criados e validados. O processo de validação é feito internamente por administradores de bancos de dados ou externamente por outros usuários finais. Por exemplo, o departamento de contabilidade pode validar um relatório de livro razão. Geralmente, essa é uma atividade executada uma única vez, antes da implementação do sistema. 4. Após sua criação e sua validação, os cubos são consultados pelos usuários finais. No entanto, em alguns aplicativos, é preciso que ocorra uma validação mais extensa antes que os dados sejam movidos dos testes para a produção. Devem ser feitos relatórios de reconciliação ou comparações manuais com relatórios diferentes, caso contrário o gerenciamento sênior precisará revisar os dados financeiros e aprovar sua interpretação antes da postagem desses dados para os livros da empresa. Nesse cenário, os dados devem ser validados sempre que forem transferidos para a produção (por exemplo, toda semana ou todo mês). Essa validação adicional significa que deve haver pelo menos duas cópias, às vezes mais, dos dados OLAP: a cópia que está sendo vista ou usada por usuários finais (atualmente em produção) e a segunda cópia, que está sendo revisada ou validada (atualmente em teste). Quando chegar o momento certo, a segunda cópia deverá ser copiada para a produção. Várias técnicas estão disponíveis para a cópia de dados da fase de teste para a produção, como arquivamento e restauração, cópia de arquivos de dados ou até mesmo permuta física de unidades. Preste muita atenção a essa questão, pois o
Slide 12: Analysis Services não fornece um recurso interno para a cópia de dados entre sistemas e a arquitetura de referência usa vários sistemas para o failover e a escalabilidade. Qualquer que seja o processo escolhido, o impacto para os usuários finais deve ser o menor possível. Em alguns ambientes, é inaceitável colocar o sistema off-line enquanto arquivos de 100 GB são copiados para computadores na rede. Criando sites OLAP de grande escala e disponibilidade Esta seção introduz uma arquitetura para a criação de sites OLAP de grande escala e disponibilidade. O cenário de site de referência abordado neste documento executa um aplicativo chamado Commerce que realiza análises de negócios nos produtos vendidos pela empresa. A empresa disponibiliza essas informações de análises para seus fornecedores através de um site da Internet criado para fornecer o recurso OLAP. Hardware O site de referência usa sete servidores, todos eles executam o Windows 2000 Advanced Server. O hardware usado no site de referência pode ser considerado uma linha de base para um sistema de alta disponibilidade. Consulte o fornecedor do hardware para obter mais informações sobre soluções de hardware que permitem uma maior disponibilidade, como adaptadores Ethernet de interface dual e no-breaks. Todo hardware utilizado está pronto para uso e pode ser obtido com muitos fornecedores. Isso ajuda a reduzir o custo geral do site e garante que os custos de manutenção e suporte serão bem estabelecidos e poderão ser incluídos em um orçamento de departamento de tecnologia de informações normal. Ao criar um site de alta disponibilidade, você deve usar o hardware listado na HCL do Windows em http://www.microsoft.com/hcl/ (site em inglês). Armazenamento de dados A utilização do Network Load Balancing garante que os dados de produção estarão disponíveis quando os usuários do site OLAP emitirem consultas para o sistema. No entanto, a postagem oportuna de dados novos e atualizados também é importante. Uma questão operacional crítica em um site OLAP de produção é que as fontes de
Slide 13: dados relacionais subjacentes devem estar disponíveis quando os dados são processados. Este documento sugere que você use o Windows Clustering para certificar-se de que dados novos ou atualizados são processados dentro dos limites de tempo exigidos. O armazenamento de dados relacionais do site OLAP é gerenciado por dois servidores que executam o Windows Clustering com uma matriz redundante de discos independentes (RAID) compartilhada. O cluster de servidores fornece disponibilidade no caso de uma falha no servidor e a matriz RAID fornece disponibilidade no caso de uma falha no disco. A tecnologia de disco fornecida em matrizes e servidores modernos pode detectar possíveis falhas no disco antes que elas ocorram. Se uma falha no disco for diagnosticada com antecedência pelo sistema, o disco inválido poderá ser intercambiado a partir da matriz RAID 5 e substituído sem a interrupção do serviço. Mesmo que ocorra uma falha inesperada no disco, a matriz RAID 5 trará um disco em espera para que a disponibilidade continue. Não é necessária intervenção manual. Dependendo dos requisitos de E/S dos servidores de banco de dados de um site, convém usar outras técnicas do RAID. Uma alternativa para o RAID 5 é o RAID 1+0 (disco distribuído e espelhado). Essa opção é mais cara que o RAID 5. Os designers de site devem usar o tipo de arquitetura RAID que satisfaça aos requisitos. As matrizes RAID podem ser implementadas no software com os serviços internos do Windows 2000 Advanced Server. No entanto, a arquitetura de referência usa uma implementação de hardware para obter um melhor desempenho de acesso a dados. Analysis Services e configuração do RAID Considere as seguintes diretrizes ao configurar o RAID para Analysis Services: • • • Não há uma única solução que funcione para todos os dados. Para obter o melhor desempenho com chance de recuperação total, use o RAID 0+1. No entanto, essa abordagem pode ter alto custo. O RAID 5 é uma alternativa boa e de baixo custo para a pasta Data do Analysis Services (porque, em sua maioria, os dados são somente leitura).
Slide 14: • Use o RAID 0 (somente distribuição de disco) para a pasta Temp do Analysis Services. A pasta Temp não requer chance de recuperação a longo prazo. É usada somente para processamento de partição ou cubo. • Use um controlador que ofereça suporte a discos em espera ativos que sejam automaticamente adicionados ao conjunto RAID caso ocorra falha no disco. O conjunto RAID será automaticamente recriado, reespelhado, etc. • Use controladores RAID Fibre Channel sempre que possível. A interface SCSI é aceitável para sistemas intermediários, mas não para grandes configurações do RAID ou da rede de sistema (SAN). • Considere a utilização da tecnologia SAN para obter instantâneos de dados (para mover dados da fase de teste para a produção). Isso reduz bastante o tempo necessário para copiar arquivos de banco de dados OLAP. Observação O tipo de sistema de arquivo usado nesta configuração é crítico. Todos os discos usados nesta arquitetura devem ser formatados para utilizar o formato de sistema de arquivo NTFS, pois esse formato fornece um nível mais alto de segurança e de integridade de dados do que o formato de tabela de alocação de arquivos (FAT). Redes Cada servidor tem duas ou três placas de interface de rede (NICs) Ethernet de 100 megabits por segundo (Mbps). O protocolo TCP/IP é usado no site de referência. Em todos os casos, a NIC de rede privada (10.0.0.x, 11.0.0.x) é usada como adaptador dedicado do Windows Clustering. Nos servidores front-end que fornecem dados do Analysis Services, uma NIC é conectada a um comutador de 100 Mbps que, por sua vez, é conectado a uma rede que se conecta à Internet. Essa NIC é vinculada a um endereço IP público de 192.168.18.155. A pulsação do cluster de Network Load Balancing é enviada nessa NIC pública. A outra NIC é conectada à rede privada (10.0.0.x) através do comutador de 100 Mbps que conecta os servidores no site. Nos servidores back-end, uma NIC é conectada a uma rede privada (10.0.0.x) fornecendo acesso ao cluster do Analysis Server através de um comutador de 100 Mbps. O site de referência usa um segundo endereço de rede privada do intervalo de 11.0.0.x de endereços IP da pulsação de serviço de cluster do servidor de teste.
Slide 15: O cluster de servidor da rede virtual privada (VPN) fornece uma VPN à rede pública e serviços do sistema de nomes de domínios (DNS) à rede privada. Uma NIC é conectada a um comutador de 100 Mbps que, por sua vez, é conectado a uma rede que se conecta à Internet. Essa NIC é vinculada a um endereço IP público de 192.168.18.160. A outra NIC é conectada à rede privada (10.0.0.x) através do comutador de 100 Mbps que conecta os servidores no site. O firewall é configurado de modo que somente a porta HTTP 80 (ou porta 433 se a camada de soquetes de segurança (SSL) for usada) possa acessar o endereço IP 192.168.18.155 e somente o número de porta da VPN possa acessar o endereço IP 192.168.18.160. Arquitetura de site de referência de alta disponibilidade O provedor de serviços apresenta infra-estrutura preexistente e modelos de negócios diferentes. A arquitetura do site de referência foi projetada para ser genérica o suficiente para permitir que os conceitos principais possam ser usados em vários cenários. A figura 1 mostra a arquitetura do site de referência (cliente gordo) da rede baseada no Windows 2000 Advanced Server. Os endereços IP e as conexões com diferentes partes da rede são ilustrados com cores diferentes, da seguinte maneira: • • • A rede externa é mostrada como uma linha azul sólida. Ela também é a pulsação para o cluster do Analysis Server. A rede interna de banco de dados é mostrada como uma linha verde tracejada. A rede interna de pulsação do cluster de banco de dados é mostrada como uma linha preta pontilhada. Se o navegador não oferecer suporte a quadros in-line, clique aqui para exibir em uma página separada. Figura 1 Arquitetura do site de referência (cliente gordo) ou cliente magro usando o cluster do Analysis Server para serviços da Web e Analysis Services (acesso somente à Internet)
Slide 16: Computador VPN1 Configuração Windows 2000 Advanced Server com VPN, controlador de domínio (DC) principal, DNS, Cluster Sentinel, 192.168.18.180, 10.0.0.41 Windows 2000 Advanced Server com VPN, controlador de domínio (DC) backup, DNS secundário, Cluster Sentinel, 192.168.18.181, 10.0.0.42 Windows 2000 Advanced Server com o Network Load Balancing, IIS, Analysis Services, 192.168.18.161, 10.0.0.1 Windows 2000 Advanced Server com o Network Load Balancing, IIS, Analysis Services, 192.168.18.162, 10.0.0.2 Windows 2000 Advanced Server com o Network Load Balancing, IIS, Analysis Services, 192.168.18.163, 10.0.0.3 Windows 2000 Advanced Server com Windows Clustering, SQL Server 2000 (banco de dados relacional) com Analysis Services (servidor de teste), 10.0.0.52, 11.0.0.1 Windows 2000 Advanced Server com Windows Clustering, VPN2 AS1 AS2 AS3 Db1 Db2
Slide 17: SQL Server 2000 (banco de dados relacional) com Analysis Services (servidor de teste), 10.0.0.52, 11.0.0.2 Observação Todos os diagramas do sistema neste documento foram simplificados para facilitar a leitura. Para um site de produção, você deve criar a arquitetura de hardware com redundância total, isto é, sistemas de alimentação de caminho dual, placas NIC agrupadas, firewalls e comutadores duais e assim por diante, de modo que não haja nenhum ponto de falha na configuração. A arquitetura ilustrada na figura1 apresenta acesso a dados apenas pela Internet. Os dados são movidos para o site através da VPN. Embora isso seja usado com freqüência em pequenas e médias empresas, as empresas grandes geralmente têm acesso dedicado através de uma backdoor de linha dedicada. Por motivos de segurança, você deve incorporar um firewall para que todos os servidores voltados para a Internet estejam em uma rede de perímetro (também conhecida como DMZ, zona desmilitarizada, e sub-rede examinada), que é uma rede fora do roteador ou do firewall que atua como buffer entre a rede externa e a rede interna de segurança. Se o navegador não oferecer suporte a quadros in-line, clique aqui para exibir em uma página separada. Figura 2 Arquitetura do site de referência (cliente gordo) ou cliente magro usando o cluster do Analysis Server para serviços da Web e Analysis Services (acesso corporativo dedicado) Computador AS1 Configuração Windows 2000 Advanced Server com o Network Load Balancing, IIS, Analysis Services, 192.168.18.161, AS2 10.0.0.1 Windows 2000 Advanced Server com o Network Load Balancing,
Slide 18: IIS, Analysis Services, 192.168.18.162, AS3 10.0.0.2 Windows 2000 Advanced Server com o Network Load Balancing, IIS, Analysis Services, 192.168.18.163, Db1 10.0.0.3 Windows 2000 Advanced Server com Windows Clustering, SQL Server 2000 (banco de dados relacional) com Analysis Services (servidor de teste), 10.0.0.52, Db2 11.0.0.1 Windows 2000 Advanced Server com Windows Clustering, SQL Server 2000 (banco de dados relacional) com Analysis Services (servidor de teste), 10.0.0.52, 11.0.0.1 A figura 3 mostra uma terceira opção, que será possível se um dos Analysis Servers puder ser colocado off-line para processamento de cubo. Nesse caso, você poderá eliminar os servidores de teste se as janelas de lotes forem maiores ou se as etapas de processamento de dados não forem tão grandes. Cada servidor usa seu próprio armazenamento para os dados OLAP. Se o navegador não oferecer suporte a quadros in-line, clique aqui para exibir em uma página separada. Figura 3 Arquitetura do site de referência (cliente gordo) ou cliente magro usando o cluster do Analysis Server para serviços da Web e Analysis Services (requisitos de processamento limitado) Computador AS1 Configuração Windows 2000 Advanced Server com o Network Load Balancing,
Slide 19: IIS, Analysis Services, 192.168.18.161, AS2 10.0.0.1 Windows 2000 Advanced Server com o Network Load Balancing, IIS, Analysis Services, 192.168.18.162, AS3 10.0.0.2 Windows 2000 Advanced Server com o Network Load Balancing, IIS, Analysis Services, 192.168.18.163, 10.0.0.3 A VPN e o controlador de domínio/servidor DNS As entradas de host DNS dos servidores individuais da rede 10.0.0.x privada devem ser adicionadas ao banco de dados DNS nos servidores da VPN1 e da VPN2 para que nomes de servidor sejam resolvidos corretamente. Para simplificar, o cenário do site de referência usa um DC principal (VPN1) e um segundo DC (VPN2). Um segundo DC é fornecido para que o controlador de domínio não seja um único ponto de falha possível. Observe que a VPN1 do servidor é apenas uma parte da rede 10.0.0.x privada. Ela não é visível na Internet. Os fornecedores devem providenciar credenciais aos usuários quando eles acessarem os cubos OLAP. Os nomes de usuário e as senhas fornecidas devem corresponder às informações de conta de usuário mantidas nas contas de domínio do DC principal. O cluster do servidor da VPN permite que administradores controlem essas contas e administrem os computadores na rede 10.0.0.x privada. Os administradores podem se encapsular na rede privada e se conectar a qualquer um dos servidores, inclusive o DC principal, para administrar contas de domínio. Serviços de terminal do Windows 2000 estão sendo executados no modo administrativo em todos os servidores do site.
Slide 20: Importante Como esse site é configurado para formar clusters com o Analysis Services, todas as instalações são configuradas de forma idêntica. Por exemplo, cada servidor tem a mesma alocação de memória e os mesmos tamanhos de buffer. Isso permite que você equilibre conexões, pois o Network Load Balancing considera que todos os servidores têm a mesma capacidade. Se as propriedades ou as capacidades desses servidores forem diferentes (por exemplo, mais ou menos memória e velocidade da CPU), ajuste o peso manualmente no Network Load Balancing para compensar. As propriedades do servidor são armazenadas no Registro, não no repositório OLAP. Camadas front-end e back-end O cenário de site de referência abordado neste documento usa uma arquitetura com várias camadas que fornece redundância e failover. Essa arquitetura é fisicamente dividida em duas camadas principais: front-end e back-end. A camada front-end fornece o principal recurso do Analysis Services usando acesso HTTP através do Microsoft Internet Information Services (IIS). A camada back-end fornece armazenamento de dados relacionais e serviços de banco de dados. Os serviços de banco de dados são fornecidos pelo SQL Server 2000 Standard Edition. Se você escolher a abordagem de cliente gordo, os Analysis Servers front-end precisarão do SQL Server Enterprise Edition, pois ele usa o recurso de conexão HTTP (através do IIS) para permitir que os clientes acessem cubos no Analysis Server. Front-end A arquitetura de referência usa três servidores (chamados de AS1, AS2 e AS3) para fornecer ao site acesso à Internet e para responder a solicitações de usuários. Você pode usar mais servidores, mas este documento recomenda que você mantenha o menor número possível, com base na carga de usuário antecipada e nos requisitos de disponibilidade. Isso simplifica o gerenciamento do cluster. Os servidores front-end fornecem o recurso OLAP para computadores clientes que estiverem executando o SQL Server 2000 Enterprise Edition. Computadores clientes acessam os servidores front-end usando os aplicativos OLAP da Microsoft (por exemplo, Microsoft Excel e Microsoft Office Web Components) ou de fornecedores. Aplicativos OLAP usam PivotTable Service nos computadores clientes.
Slide 21: Na maioria dos casos, o PivotTable Service é instalado automaticamente quando um aplicativo OLAP é instalado. No entanto, se desejar instalar ou atualizar diretamente, você poderá encontrar o PivotTable Service no CD-ROM do SQL Server 2000 na subpasta Msolap\Install\Pts. Duas versões estão disponíveis: PTSFull.exe e PTSLite.exe. PTSLite.exe só instala os arquivos do PivotTable Service. PTSFull.exe instala os arquivos do PivotTable Service e o Microsoft Data Access Components (MDAC). Para obter mais informações sobre qual das versões usar e sobre os arquivos que serão instalados, consulte "Distributing SQL Server with Applications" no Books Online do SQL Server. Para instalar o PivotTable Service diretamente, execute um dos arquivos executáveis. Ele desempacota o software e realiza a instalação. O PivotTable Service usa três métodos de acesso para conectar aos Analysis Servers: XML for Analysis, HTTP e TCP/IP cliente-servidor. O XML for Analysis é uma nova tecnologia que usa mensagens de protocolo de acesso a objeto simples (SOAP) de baixa sobrecarga para passar XML contendo dados OLAP entre o servidor e o cliente. O método XML for Analysis é uma plataforma cruzada, que está sendo adotada por vários fornecedores. Devido a essas características, o XML for Analysis está se tornando rapidamente o método de acesso escolhido para muitos aplicativos clientes. Para obter mais informações sobre XML for Analysis, consulte "Localizando mais informações" posteriormente neste documento. O método HTTP usa a porta 80 e transfere dados como mensagens binárias de extensões multipropósito do Internet Mail (MIME) codificadas. As mesmas mensagens são passadas entre o cliente e o servidor como ocorre na técnica TCP/IP (descrita no parágrafo seguinte), mas elas usam um meio de transporte diferente. O PivotTable Service determina qual método será usado (método HTTP ou método TCP/IP) com base na seqüência de conexão. Se o nome do servidor for um URL, o método HTTP será usado. O método TCP/IP se conecta à porta 2725. Geralmente, essa porta não é aceita pela maioria dos firewalls corporativos. A figura de acesso de rede também é complicada, pois você não conhece a arquitetura de rede dos computadores clientes. Por exemplo, eles podem ter seus próprios firewalls para limitar o acesso à Internet. O XML for Analysis e os métodos de acesso HTTP são novos no SQL Server 2000. No SQL Server 7.0, somente o método TCP/IP está disponível. Os métodos de acesso
Slide 22: HTTP e TCP/IP requerem que o PivotTable Service seja usado no cliente. O XML for Analysis é mais superficial. Se você usar o XML for Analysis, o software cliente só será necessário para gerar o XML dentro de uma mensagem SOAP a fim de obter dados do cluster do Analysis Services. Na arquitetura de referência, devido a um firewall, o PivotTable Service é configurado para usar o método de conexão HTTP para o site padrão do IIS (porta 80) ou para o XML for Analysis. Para acessar o recurso, os usuários especificam o nome do servidor usando um URL em vez de um nome de servidor normal. Por exemplo: http://commerce.seudominio.com/commerce/. Isso faz com que o PivotTable Service use o método de conexão HTTP. Como alternativa, o software cliente, usando o XML for Analysis, pode usar esse URL para passar mensagens SOAP e obter dados OLAP como um fluxo de XML. Ambas as técnicas usam HTTP como protocolo subjacente e podem passar facilmente por firewalls e outros recursos da Internet. Observação Nos Serviços OLAP do SQL Server 7.0, o PivotTable Service se conecta ao servidor usando as portas 2393 e 2394; assim, o Analysis Server ainda escuta nessas portas para aceitar conexões de clientes do SQL Server 7.0. No entanto, clientes do PivotTable Service no Analysis Services do SQL Server 2000 sempre se conectam a uma única porta TCP, a porta 2725. Para usar o Network Load Balancing com Serviços OLAP do SQL Server 7.0, você deve usar o parâmetro de afinidade Single para que conexões com várias portas de um único cliente tenham carga equilibrada para o mesmo servidor OLAP. Isso não é um problema para clientes do PivotTable Service no Analysis Services do SQL Server 2000, pois eles usam uma única porta TCP. Função do Network Load Balancing para o front-end Com o Network Load Balancing, até 32 servidores trabalham juntos em um cluster para lidar com a carga resultante do fornecimento de dados a um site. O Network Load Balancing é configurado em todos os servidores do cluster para responder ao mesmo endereço IP virtual e ao nome de domínio totalmente qualificado. O Network Load Balancing fornece escalabilidade e equilíbrio de carga direcionando solicitações de recurso entre os servidores front-end para equilibrar a carga do site. O algoritmo de equilíbrio de carga do Network Load Balancing determina que servidor responderá a uma solicitação de usuário.
Slide 23: Quando o tráfego no site aumenta além de sua capacidade, um novo servidor frontend pode ser definido com as configurações do Network Load Balancing do site e carregado com uma cópia dos dados OLAP mais recentes. Quando o novo servidor front-end é colocado on-line na rede, ele ingressa dinamicamente no cluster existente do Network Load Balancing e logo inicia o compartilhamento da carga com os outros servidores front-end. A disponibilidade no nível do Analysis Server é mantida porque o Network Load Balancing detecta quando um servidor não está respondendo a solicitações da rede e o remove dinamicamente do cluster. Os nós restantes continuam o carregamento do servidor que não está respondendo para manter o site em execução. Quando um nó em um cluster de servidor ingressa no Network Load Balancing ou sai dele, uma entrada no visualizador de eventos registra a alteração. Se o navegador não oferecer suporte a quadros in-line, clique aqui para exibir em uma página separada. Figura 4 Funções da NIC do Network Load Balancing Para fornecer resolução de nome para que usuários externos possam acessar o site, faça uma entrada de host no Internet DNS do endereço IP virtual (do cluster do Network Load Balancing) e do nome de cluster (commerce.seudominio.com). Back-end Os servidores Db1 e Db2 executam o Windows Clustering e fornecem serviços de dados de alta disponibilidade (bancos de dados e compartilhamentos de arquivos) para o site. Os compartilhamentos de arquivos são necessários para a pasta Data dos Analysis Servers. Os bancos de dados são opcionais e só serão expostos como um serviço de todo o cluster se os Analysis Servers usarem o modo de armazenamento OLAP relacional (ROLAP) ou OLAP híbrido (HOLAP). Na maioria dos casos, o modo de armazenamento OLAP multidimensional (MOLAP) é recomendado, pois disponibiliza todos os dados na pasta Data. No entanto, o SQL Server pode ser usado internamente com outras finalidades, como para parte do processamento de cubos OLAP, mas não há necessidade de expô-lo como um serviço de todo o cluster. Para obter mais informações sobre modos de armazenamento, consulte o Books Online do SQL Server.
Slide 24: Esse cluster de dois servidores é chamado de cluster back-end. O cluster back-end é configurado no modo ativo-para-passivo, no qual um servidor fornece todos os serviços e o outro aguarda como um backup de acesso. (No outro modo possível, modo ativo-para-ativo, ambos os servidores fornecem serviços.) Os computadores do cluster do Analysis Server são configurados para sempre se referirem a arquivos (e bancos de dados, se usados) do cluster do banco de dados pelo nome de cluster virtual, e não pelos nomes dos servidores individuais. Para arquivos localizados no compartilhamento de arquivo comum a todo o cluster, um procedimento automatizado executado em segundo plano mantém todos os arquivos de dados atualizados. Usa a criação do arquivo e a data da última modificação para determinar que arquivos devem ser copiados do servidor primário para o backup aquecido. Você pode usar o Robocopy, um programa de transferência de arquivos que é parte do Windows 2000 Server Resource Kit, para essa finalidade. Você também pode agendar scripts simples para serem executados periodicamente e, assim, garantir a sincronização entre as pastas Data nos servidores em espera aquecidos e primários. Disponibilidade O cluster back-end fornece recurso de failover para serviços em execução no cluster. Se um dos servidores tornar-se indisponível devido a uma falha no hardware, à manutenção planejada ou a qualquer outro motivo, o outro cluster de servidor imediatamente ocupa os serviços do servidor que não está disponível. A falha de um servidor não causa a falha dos serviços de dados ou interrupção do serviço. Quando o servidor é colocado on-line novamente, continua a entrega de serviços de dados. Dados de teste O principal objetivo do cluster de banco de dados é fornecer serviços de dados para o banco de dados do Analysis Services localizado em cada um dos Analysis Servers front-end. O processamento de dados ocorre em dois ambientes: tradicional e OLAP. Para obter mais informações, consulte "Creating a Data Warehouse" no Books Online do SQL Server. Dados de teste (tradicional)
Slide 25: Atualizações e exclusões de dados tradicionais são processadas no servidor em espera aquecido. Os dados são copiados do banco de dados transacional do aplicativo da Internet ou disponibilizados pela Internet. São copiados para o servidor em espera aquecido. Dependendo da quantidade de informações novas, atualizadas ou excluídas, esses dados podem ser muitos. Geralmente, são dados transacionais e estão em um esquema altamente normalizado, terceira forma normal (3NF). Além disso, eles normalmente estão em vários formatos de armazenamento, como outros bancos de dados RDBMS, arquivos planos e planilhas do Excel. O SQL Server 2000 inclui DTS, que automatiza o processo de teste de dados. Após a conclusão do processo de atualização de dados, um relatório de reconciliação deve ser executado e seu status deve ser enviado ao grupo de operações para validação. Quando o processamento do fim do dia, da semana, do mês, do trimestre ou do ano é executado, o SQL Server usa os dados das várias fontes mencionadas anteriormente e atualiza os dados transacionais armazenados no servidor de banco de dados primário. Os dados do servidor de banco de dados primário devem estar em um RDBMS de esquema de estrela ou de floco de neve. O processo de teste tradicional inclui as seguintes etapas: • • Extração de dados das fontes de dados transacionais. Transformação de dados (isto é, limpeza e normalização). Isso pode envolver a conversão ou a geração de chaves substitutas, a conversão de dados de vários formatos (como data/hora) e a consolidação de dados (por exemplo, quando centros de custo são mesclados). • Carregamento dos dados no esquema de estrela ou de floco de neve usado como fonte de dados das dimensões e dos cubos OLAP. Dados de teste (OLAP) Após a conclusão do processo de teste tradicional, você precisa executar um processamento OLAP adicional para recriar ou atualizar de forma incremental as dimensões e os cubos OLAP nos cubos de produção. A fonte de dados das dimensões e dos cubos OLAP deve ser o banco de dados de esquema de estrela ou de floco de neve. O destino final desses dados OLAP são os computadores que compõem o cluster
Slide 26: do Analysis Server, mas os dados são processados primeiramente no cluster de banco de dados. Após a conclusão do processamento OLAP, um relatório de reconciliação deve ser executado e seu status deve ser enviado ao grupo de operações para validação. Dependendo da complexidade do processo de validação, talvez você deseje que uma equipe de usuários se conecte aos cubos recém-processados e verifique se os dados estão corretos. O serviço do Analysis Server (MSSQLServerOLAPService) só será executado no servidor de banco de dados primário enquanto o processamento OLAP estiver ocorrendo (ou se a administração do Analysis Manager for necessária). O serviço é iniciado exatamente antes do processamento OLAP e é interrompido imediatamente depois. Os administradores devem iniciar e parar o serviço manualmente antes e depois da execução do Analysis Manager. Isso garante que o repositório Msmdrep.mdb e os arquivos da pasta Data sejam consistentes, estejam disponíveis e sejam fechados durante operações normais. Local de dados OLAP Na arquitetura de referência, uma cópia mestra dos dados OLAP é armazenada no espaço de armazenamento de dados do cluster de banco de dados. Os discos locais dos servidores front-end armazenam as versões operacionais dos dados. Existem várias vantagens nessa abordagem combinada: • Ela usa uma matriz de disco RAID de alta capacidade e velocidade no cluster de banco de dados. Isso significa que os dados podem ser processados mais rapidamente nos sistemas de teste. • Há uma cópia mestra dos dados. Isso significa que o processo de transferência de dados do teste para a produção é mais rápido e que os dados podem ser copiados sem afetar o desempenho dos servidores front-end. Depois que os dados são colocados nos servidores front-end, um trabalho de atualização altera a localização da pasta Data. Você pode copiar os dados OLAP usando vários métodos, como: o o o Comandos COPY ou XCOPY do DOS. Robocopy. Replicação de dados do Microsoft Application Center 2000.
Slide 27: o o Produtos de movimentação de dados de terceiros. Para transferência de dados de alta velocidade, tecnologia SAN. Crie um conjunto de espelhos de disco (com dois ou mais membros), quebre-os e altere a propriedade de dispositivo subjacente. O efeito de rede é que o processo de cópia de disco é executado com muita rapidez. Isso é bastante eficaz, principalmente para bancos de dados grandes de 50 GB ou mais. • Como uma cópia mestra dos dados é mantida no servidor de banco de dados, é fácil adicionar um novo Analysis Server ao cluster front-end. O Analysis Server só é necessário para copiar os dados e adicionar o host ao cluster — em seguida, o servidor fica ativo e funcionando. • Como cada Analysis Server contém seus próprios dados, esses servidores não dependem de nenhum recurso externo. O desempenho é consistente e não existe um único ponto de falha no cluster. Observação Considere a utilização de conjuntos de volumes do Windows 2000 nos Analysis Servers. Esses conjuntos de volumes podem expandir a capacidade do servidor sem exigir que você coloque o sistema off-line. • É mais fácil gerenciar o conteúdo do site e mantê-lo sincronizado quando ele está concentrado em um único lugar e não distribuído entre os discos locais dos servidores front-end. Para manter a concisão, este documento descreve apenas um método de organização de dados. No entanto, há muitas outras opções de arquitetura para a hospedagem de dados, como tecnologia SAN ou dispositivos conectados à rede. Modo de armazenamento Este documento recomenda a utilização do modo de armazenamento MOLAP para dados na arquitetura sugerida. Recomendamos o modo MOLAP porque os dados são auto-contidos na pasta Data do Analysis Services e podem ser facilmente movidos do servidor de processamento para os Analysis Servers. Para garantir 100% de disponibilidade do recurso OLAP, você precisa de um mecanismo que permita que várias versões dos dados sejam distribuídas entre os membros do cluster. Os dados devem ser configurados e controlados independentemente e em conjunto com o servidor que está sendo convergido para o cluster do Network Load Balancing. Se você
Slide 28: usar o modo ROLAP ou HOLAP, um único banco de dados relacional conterá (no mínimo) os dados de fato e possivelmente os agregados. Isso complica a movimentação de dados, pois você precisa copiar os bancos de dados relacionais e também os arquivos de dados no cluster. Independentemente do modo de armazenamento usado, o Analysis Services não oferece suporte a write-back de dados ou dados de dimensão. Para obter mais informações, consulte "Restrições do Analysis Services" posteriormente neste documento. Armazenamento de dados OLAP Os dados OLAP são armazenados nos locais a seguir. Local O repositório (Msmdrep.mdb) Descrição São todos os metadados que constituem as estruturas OLAP de um servidor (cubos, dimensões, fontes de dados, etc.). Em sistemas grandes, você deve migrar o repositório para um banco de dados do SQL A pasta Data e suas subpastas Server. Quando uma dimensão ou um cubo é processado, os dados são armazenados em uma hierarquia de pastas do servidor. Para definir ou determinar onde está a pasta, inicie o Analysis Manager e clique com o botão direito do mouse no servidor. Clique em Properties e, em seguida, clique na guia General. Você também pode especificar a pasta de arquivos temporária. Quando cubos, partições e dimensões são processados, a pasta temporária é usada para manter agregações parciais. Para cubos grandes, certifique-se de que a pasta temporária e a pasta Data estão em unidades físicas diferentes. Segurança
Slide 29: Por motivos de segurança, todos os servidores no exemplo de arquitetura possuem dois adaptadores Ethernet, cada um deles com um endereçamento IP diferente. Todos os servidores se comunicam uns com os outros em uma rede 10.0.0.x privada e apenas os servidores front-end possuem endereços IP publicamente acessíveis (através de um firewall). Para impedir ataques mal-intencionados, essa arquitetura não permite acesso direto a partir da rede pública aos servidores que contêm dados do site. Observe que é possível ter apenas um adaptador Ethernet configurado em todos os servidores front-end; isso fornecerá conectividade aos servidores back-end se os servidores forem configurados com endereços IP publicamente acessíveis. No entanto, isso pode expor os dados do site (nos servidores back-end) a ataques na rede pública. É importante ter um único logon para todos os computadores do site. Dessa forma, o servidor DNS também é um DC principal e os usuários podem usar contas de domínio para autenticação de servidor cruzado. Todos os computadores do site fazem parte desse domínio. Um DC backup é fornecido para eliminar um único ponto de falha no site. Para impedir o acesso entre redes nos servidores com dois adaptadores Ethernet, certifique-se de que o roteamento está desativado para o protocolo TCP/IP. No sistema operacional Windows 2000 Advanced Server, Roteamento e acesso remoto é um snapin do MMC que, por padrão, está desativado. (Para localizar esse snap-in, no menu Start, aponte para Programs e para Administrative Tools e clique em Routing and Remote Access.) O DNS é usado para a resolução de nome; um servidor DNS é executado no site de referência basicamente para lidar com a resolução de nome das interfaces endereçadas de forma privada. É possível usar outro método de resolução de nome nesse tipo de arquitetura, como o serviço de cadastramento na Internet do Windows (WINS) ou a pesquisa de Lmhosts. Para obter simplicidade, o cenário abordado neste documento usa somente o DNS. O único endereço IP que pode ser acessado publicamente nos servidores desse site é o endereço IP virtual para o qual os servidores front-end respondem. É necessária uma entrada de host ao endereço IP virtual e ao nome de cluster (neste exemplo, seudominio.com) no Internet DNS para que a resolução de nome do site seja feita a partir da rede pública.
Slide 30: A única porta TCP/IP aberta nas placas NIC da Internet pública é a porta 80. Para obter acesso a HTTPS, a porta 433 é usada. Todas as outras portas são desativadas. Além das redes, várias configurações do IIS devem ser configuradas para garantir acesso seguro. Para obter mais informações, consulte "Questões de segurança" posteriormente neste documento. Questões operacionais Você deve consultar várias questões administrativas e operacionais na arquitetura de referência antes de implantar o site. Esta seção aborda essas questões detalhadamente e apresenta idéias de soluções. Transição de teste para produção Um dos principais objetivos da criação de clusters do Network Load Balancing é fornecer suporte contínuo. A movimentação de dados do teste para a produção deve ser um processo cuidadosamente coreografado. Certifique-se de adquirir espaço em disco suficiente para cada servidor. Deve haver espaço em disco suficiente para dois conjuntos de dados completos. O primeiro conjunto é usado para o sistema operacional. O segundo é usado quando dados atualizados estão sendo copiados. Há duas abordagens possíveis para os discos locais. Você pode usar subsistemas RAID (5 ou 1+0) de alta qualidade com recursos hotpluggable para a substituição de discos. Isso significa que o subsistema de E/S é robusto, mas de alto custo — provavelmente de custo mais alto do que o resto do servidor. Como alternativa, você pode usar um equipamento mais barato e comprar mais servidores. Se houver falha no subsistema de E/S, outros servidores poderão continuar o carregamento. Contate o fornecedor do hardware para obter recomendações adequadas ao seu orçamento e à sua tolerância a riscos. Para mover dados para a produção, copie o repositório e a pasta Data atualizada para as unidades de disco locais do computador no qual o Analysis Server está sendo executado. Você pode fazer isso através de uma combinação de scripts e cópias de arquivos. Esses scripts são usados para controlar a participação de membros no cluster do Analysis Server e para parar e iniciar serviços. Quando um Analysis Server de teste for atualizado, mova o repositório e a pasta Data para a nova localização nas unidades
Slide 31: de disco locais (alterando as configurações do Registro do Windows). Em seguida, reinicie o serviço MSSQLServerOLAPService. Se houver espaço em disco suficiente para duas cópias dos dados OLAP, você poderá manter o servidor on-line no cluster durante a cópia e colocá-lo off-line apenas quando alternar a localização da pasta Data. Uma abordagem alternativa muito útil quando a quantidade de dados OLAP é desconhecida nos estágios de planejamento é a utilização dos dispositivos SAN. As partes do disco designadas a cada servidor podem aumentar ou diminuir com base na necessidade e não em projeções. Se o Analysis Server só tiver espaço em disco suficiente para uma cópia dos dados OLAP, interrompa gradualmente o servidor (quando ele estiver sendo atualizado da fase de teste), pare o serviço MSSQLServerOLAPService, copie o repositório e a pasta Data antes de alterar as configurações do Registro (geralmente, isso é feito com um script; para obter mais informações, consulte o "Apêndice C") e reinicie o serviço MSSQLServerOLAPService. Isso pode significar que o servidor está off-line no cluster por um considerável período de tempo (limitado pela taxa de transferência de rede). Observação A interrupção gradual é um recurso do Network Load Balancing que permite colocar um servidor off-line gradualmente, sem interromper conexões existentes. Quando um nó é interrompido gradualmente, nenhuma conexão nova é aceita, mas as conexões antigas são mantidas. O servidor se torna disponível quando todas as conexões feitas antes da interrupção gradual do nó são fechadas. Transferência de dados para a produção Depois que os cubos atualizados são disponibilizados no servidor de banco de dados, eles devem ser movidos para a produção. Para mover os cubos para a produção 1. Selecione dois computadores no cluster do Analysis Server como servidores de teste. Interrompa gradualmente ambos os servidores para que eles sejam soltos do cluster.
Slide 32: 2. Quando os dois servidores forem parados e todas as conexões forem fechadas, pare o serviço MSSQLServerOLAPService. Emita um comando net use para que uma letra de unidade de rede conhecida (por exemplo, F) seja redirecionada do compartilhamento de arquivo antigo no cluster do servidor de banco de dados (a pasta Data antiga) para o compartilhamento de arquivo atualizado. Copie o repositório e a pasta Data do Analysis Services do compartilhamento de arquivo de rede para uma pasta conhecida em uma unidade local. Execute um script (para obter mais informações, consulte o "Apêndice C") que altere as configurações do Registro do Windows para o novo local do repositório e da pasta Data do Analysis Services. Reinicie o serviço MSSQLServerOLAPService. 3. Quando os dois servidores estiverem completamente atualizados, adicione o servidor de teste e seu backup ao cluster do Analysis Server. Interrompa gradualmente os outros computadores do cluster. Todas as novas conexões são feitas para o Analysis Server de teste ou seu backup. Agora, os cubos atualizados estão disponíveis. Observação Neste ponto, os cubos atualizados estão disponíveis, mas o site é suscetível a falhas ou sobrecargas, pois apenas dois servidores estão no cluster. Conclua as etapas restantes assim que for possível para fornecer ao cluster capacidade total. 4. Atualize os dados em todos os servidores antigos do cluster do servidor de banco de dados (Db). Pare o serviço MSSQLServerOLAPService, altere o mapeamento da rede da pasta Data do Db, copie o conteúdo da pasta Data e reinicie o serviço MSSQLServerOLAPService. Agora, você pode adicionar o servidor novamente ao cluster do Analysis Server. Cada servidor interrompido pode atualizar dados em paralelo. Uma técnica alternativa (dependendo do número de computadores no cluster do Analysis Server) é selecionar mais de um computador como o Analysis Server de teste. Por exemplo, você pode selecionar metade dos computadores dos Analysis Servers para a primeira atualização. Isso garante que um número significativo de servidores (aproximadamente a metade) estará no cluster a qualquer hora. Application Center 2000
Slide 33: Em vez de tentar controlar o desenvolvimento dos dados OLAP manualmente, considere uma alternativa mais flexível: Microsoft Application Center 2000. O Application Center 2000 é a ferramenta de implantação e gerenciamento da Microsoft para aplicativos da Web de alta disponibilidade. O Application Center 2000 torna o gerenciamento de grupos de servidores tão simples quanto o gerenciamento de um único computador. Você deve considerar a utilização do Application Center 2000 como uma tecnologia complementar, pois: • Ele é baseado no Windows 2000 Server, não no Windows 2000 Advanced Server; portanto, deve haver alguma redução de custos (dependendo da sua configuração). • • Ele inclui capacidade de gerenciamento interno e administração remota do Network Load Balancing. Sua arquitetura é controlada por evento. Isso permite que você crie scripts de seus próprios ganchos antes de replicar os dados (por exemplo, você pode automatizar o início e o término do serviço MSSQLServerOLAPService). • Ele oferece ferramentas internas para a monitoração da integridade do cluster do Network Load Balancing. O Application Center 2000 pode controlar o processo de implantação de dados OLAP de forma rápida e fácil. O processo inteiro pode ser automatizado e executado em um ambiente não monitorado. O Application Center 2000 fornece ferramentas para a monitoração do cluster e de seus servidores. Ele também inclui recursos eficientes que permitem a exibição de dados de log de eventos e de desempenho para um servidor ou para o cluster inteiro. Os administradores podem monitorar aplicativos remotamente usando um console baseado no navegador. Com respostas automatizadas, os custos operacionais são reduzidos devido à eliminação de tarefas manuais. Além disso, respostas automatizadas podem fornecer maior disponibilidade do aplicativo. Principalmente, o uso do Application Center 2000 pode reduzir significativamente o tempo de implantação e os custos da arquitetura de referência. Em primeiro lugar, o Application Center 2000 inclui o Network Load Balancing como um de seus componentes e pode ser instalado em computadores que executem o Windows 2000
Slide 34: Server. Na figura 5, todos os computadores estão executando o Windows 2000 Server, não o Windows 2000 Advanced Server. Portanto, o Application Center 2000 apresenta apenas uma pequena melhoria com o uso do Windows 2000 Advanced Server. Em segundo lugar, a implementação padrão do Network Load Balancing incluída no Windows 2000 Advanced Server requer que todo o gerenciamento seja feito através do prompt de comando ou de uma interface em lotes. Não há console de gerenciamento gráfico. O Application Center inclui um console de gerenciamento gráfico para o gerenciamento, a solução de problemas e o controle dos clusters do Network Load Balancing. O console de gerenciamento gráfico também pode ser útil na arquitetura de site de referência, pois permite que operadores administrem graficamente os clusters do Network Load Balancing. Por fim, como os dados OLAP agora estão distribuídos nos Analysis Servers, não há necessidade de um sistema back-end extenso. O sistema back-end não é mais um único ponto de falha na execução do cluster do Analysis Server. Dessa forma, as alternativas menos dispendiosas são usar um único servidor de teste ou colocar um dos Analysis Servers off-line para o processamento de dados, em vez de usar o Windows Clustering. Talvez haja outros motivos comerciais para a utilização de um back-end do Windows Clustering, de um servidor de backup aquecido ou de um segundo servidor em espera, mas isso não é mais um requisito. Se o navegador não oferecer suporte a quadros in-line, clique aqui para exibir em uma página separada. Figura 5 Arquitetura de site de referência com o Application Center (somente acesso à Internet) Computador VPN1 Configuração Windows 2000 Advanced Server com VPN, DC principal, DNS, Cluster Sentinel, 192.168.18.180, VPN2 10.0.0.41 Windows 2000 Advanced Server com VPN, DC backup, DNS secundário,
Slide 35: Cluster Sentinel, 192.168.18.181, AS1 10.0.0.42 Windows 2000 Server com o Network Load Balancing, IIS, Analysis Services, Application Center, 192.168.18.161, AS2 10.0.0.1 Windows 2000 Server com o Network Load Balancing, IIS, Analysis Services, Application Center, 192.168.18.162, AS3 10.0.0.2 Windows 2000 Server com o Network Load Balancing, IIS, Analysis Services, Application Center, 192.168.18.163, Db 10.0.0.3 Windows 2000 Server, SQL Server 2000 (banco de dados relacional) com Analysis Services (servidor de teste), Application Center, 10.0.0.50, IP Corporativo Observação Todos os servidores membro devem ter estrutura e atribuição de letras de unidade idênticas. O Application Center fornece um subsistema de gerenciamento para o controle do cluster do Network Load Balancing e a movimentação de arquivos no sistema. Além disso, ele simplifica a tarefa de migração de dados do teste para o desenvolvimento. Isso ajuda a garantir a consistência entre os Analysis Servers — todos os servidores do
Slide 36: cluster devem ter os mesmos dados. Automatizando a implantação dos dados OLAP de um servidor para outro, o Application Center diminui o tempo de transferência (ele tem seu próprio recurso de replicação de arquivos de alta velocidade), elimina erros manuais e melhora a qualidade geral do site. Para implementar essa configuração, crie dois aplicativos usando o console de gerenciamento do Application Center. Cada aplicativo representa os recursos, como os arquivos da pasta Data, usados para essa unidade de trabalho. No cenário usado neste documento, esses dois aplicativos representam o repositório e as duas pastas Data do Analysis Services. Todas as funções de gerenciamento do Application Center têm versões de linha de comando para que a implantação possa ser facilmente disparada pelo processo de teste. As ações do Application Center são usadas neste cenário. As ações manipulam os eventos de confirmação e preparação do processo de replicação. Cada aplicativo obtém seu próprio script de manipulação de eventos para cada ação. Você deve configurar os manipuladores de evento de ação que tratam das seguintes situações: • Se houver espaço em disco suficiente para duas cópias da pasta Data, seu script deverá: 1. Determinar se o aplicativo atual está ativo. Em um evento de preparação para replicação, o script deverá gerar um erro se o aplicativo atual estiver ativo. Ele determina se um aplicativo está ativo comparando a chave do Registro da pasta Data do Analysis Services com a pasta que será replicada. Se elas corresponderem, esse script deverá parar o trabalho e gerar um erro. Se forem diferentes, ele deverá iniciar a cópia dos dados. Observação Não interrompa gradualmente o destino quando a implantação for iniciada. 2. Em um evento de compromisso para replicação, interromper gradualmente o membro do Network Load Balancing de destino e parar o serviço MSSQLServerOLAPService. O script deverá alternar os nomes de pasta renomeando-os a partir do local inativo para o local ativo e deverá reiniciar o serviço MSSQLServerOLAPService.
Slide 37: 3. Quando a implantação for concluída, iniciar o membro do Network Load Balancing de destino. • Se houver espaço em disco suficiente apenas para uma cópia da pasta Data, seu script deverá: 1. Interromper gradualmente o destino quando a implantação for iniciada. 2. Em um evento de preparação para replicação, parar o serviço MSSQLServerOLAPService. 3. Em um evento de confirmação para replicação, reiniciar o serviço MSSQLServerOLAPService. 4. Quando a implantação for concluída, iniciar o membro do Network Load Balancing de destino. Use essa técnica para manter o membro do Network Load Balancing de destino off-line pelo menor tempo possível. Isso demonstra por que ter espaço em disco suficiente para duas cópias dos dados OLAP é importante. Failover do Network Load Balancing A não ser que esteja usando o Application Center, você deverá utilizar scripts para fazer o seguinte: colocar um host on-line no cluster (isto é, convergi-lo), pará-lo, interromper gradualmente, examinar o status do cluster e depurar problemas de rede. Para obter informações sobre um programa de linha de comando que possa se usado nos seus scripts, consulte o "Apêndice B". O "Apêndice C" fornece alguns exemplos de scripts para trabalho com o Network Load Balancing e o Analysis Services. Eles executam ações como parar e iniciar o Network Load Balancing e o Analysis Services, alterar a pasta Data do Analysis Services e mover o repositório da pasta Bin para a pasta Data. Monitorando a integridade do cluster O Cluster Sentinel, disponível no Windows 2000 Server Resource Kit, é um programa para monitorar o estado do cluster de Network Load Balancing. A cada trinta segundos, Cluster Sentinel solicita automaticamente uma página de teste especial de cada servidor ativo. O código dessa página ASP realiza vários testes no servidor. Se um teste for bem-sucedido, ele será listado pela página. Se um teste falhar, a página solicitada atingirá o tempo limite, sinalizando ao Cluster Sentinel que houve um erro.
Slide 38: Se a página de teste em um servidor atingir o tempo limite ou retornar o código de erro 500 (o código HTTP para erro do servidor), o Cluster Sentinel testará novamente o servidor para verificar se o erro foi resolvido independentemente. Caso o servidor retorne erros de forma consistente, o Cluster Sentinel suspende-o e o Network Load Balancing redireciona todas as solicitações de páginas para os servidores restantes no cluster. Quando a equipe de produção localizar e corrigir o erro, ela restaurará a operação ativa do servidor. Questões de segurança Além das redes, várias configurações do IIS devem ser configuradas para garantir acesso seguro: 1. O único aplicativo do IIS que deve ser definido nos Analysis Servers é o aplicativo Commerce. O aplicativo deve ser configurado para: o Permitir somente acesso de leitura. Desmarque as caixas de seleção Script source access, Write, Directory browsing, Log visits e Index this resource. o Permitir que somente scripts sejam executados. Defina as permissões de execução como Script Only. 2. O único arquivo na pasta de aplicativo deve ser Msolap.asp (fornecido como parte da instalação do Analysis Services). Nos servidores front-end, todos os serviços do Windows 2000 que não sejam essenciais para o Analysis Services devem ser configurados para inicialização manual. Isso ajuda a evitar o uso desnecessário de recursos e remove possíveis pontos de ataque. Por exemplo, como os serviços de protocolo de transferência de arquivos (FTP) e de protocolo de transferência de correio simples (SMTP) não são fornecidos como parte da oferta de serviços para servidores front-end, eles devem ser desativados ou não instalados nesses servidores. Além disso, a interface NetBIOS deve ser desativada nos servidores front-end para a NIC que lida com todas as solicitações públicas. Isso remove outro ponto comum de ataque. Dependendo da confidencialidade dos dados fornecidos pela Internet, você deve adquirir os certificados X.509 necessários para executar sessões SSL seguras. Isso pode significar que você precise ativar a porta 433 no firewall e na NIC de Internet pública para permitir acesso.
Slide 39: Para ter controle administrativo do site, instale o serviço VPN nos servidores VPN (VPN1 e VPN2). Há diversos protocolos disponíveis para configurar e usar uma VPN. A configuração é diferente para cada um deles. Um cluster de Network Load Balancing é usado com VPN1 e VPN2 para fornecer alta disponibilidade de VPN. Uma discussão detalhada sobre VPN está além do escopo deste documento. Para obter mais informações, consulte "Localizando mais informações" posteriormente neste documento. Lista de verificação de segurança Certifique-se de que as seguintes tarefas foram concluídas: • • • • • • • • • • • Configure o firewall para que somente a porta 80 (e talvez a porta 433, se você estiver usando SSL) seja ativada para 198.168.18.155. Configure o firewall para que somente o acesso VPN seja ativado para 198.168.18.160. Configure as placas NIC em todos os servidores front-end para que somente a porta 80 (e talvez a porta 433, se você estiver usando SSL) seja ativada. Configure as placas NIC em todos os servidores VPN para que as portas apropriadas sejam ativadas. Desative o encaminhamento IP em todos os servidores front-end. Certifique-se de que somente o protocolo TCP/IP é usado; desative o NetBIOS. Certifique-se de que somente o DNS é usado para resolução de nome. Desative todos os serviços desnecessários nos servidores front-end. Certifique-se de que somente as contas de domínio são usadas para todos os serviços apropriados; não deve haver contas de computadores locais. Certifique-se de que somente um aplicativo do IIS (neste cenário, Commerce) é ativado. Para o Commerce, que fornece os dados OLAP, configure a segurança necessária. Por exemplo: o o o • Permitir somente acesso de leitura. Defina as permissões de execução como Script Only. Certifique-se de que o único arquivo na pasta de aplicativo é Msolap.asp. Se você estiver executando SSL, adquira e instale os certificados X.509 necessários para executar sessões seguras.
Slide 40: Restrições do Analysis Services A utilização do Analysis Services na arquitetura de referência descrita anteriormente apresenta algumas restrições. Esta seção aborda essas restrições e apresenta idéias para soluções sempre que possível. Log de consulta para os Usage-Based Design Wizards O Analysis Services registra em log um exemplo das consultas emitidas a um arquivo (Msmdqlog.mdb na pasta Bin). O Usage-Based Optimization Wizard e o Usage Analysis Wizard usam esse arquivo de log para desenvolver e recomendar agregações. Como existem vários Analysis Servers no cluster que executa consultas ao mesmo tempo, o log de uso é distribuído por todos os servidores. Para resolver esse problema, ajuste o tamanho de amostragem para compensar o fato de que vários servidores estão executando as consultas. (O Network Load Balancing torna isso possível através da distribuição uniforme de consultas no cluster.) Para determinar a taxa de amostragem total aproximada, selecione a taxa de amostragem desejada (como se o site estivesse em um servidor) e a divida pelo número aproximado de servidores. Por exemplo, se o tamanho de amostragem for 10 (padrão), toda décima consulta será registrada em log. Se houver cinco Analysis Servers, toda quinta consulta será armazenada em log. Isso significa que, no cluster, toda qüinquagésima consulta será registrada no log de cada servidor (as outras quarenta estarão nos logs dos outros quatro servidores). Portanto, você deve reduzir o tamanho de amostragem para 2. Para alterar o tamanho de amostragem, no painel de árvore do Analysis Manager, clique com o botão direito do mouse no servidor e clique em Properties. Clique na guia Log. Em Log settings, certifique-se de que a caixa de seleção Log queries sent to server está marcada e digite o novo tamanho de amostragem na caixa Write to log once per _ queries. Para usar o arquivo de log, copie qualquer arquivo de Msmdqlog.mdb de um dos Analysis Servers para a pasta Bin do servidor de teste (Db1 ou Db2). Em seguida, execute o assistente apropriado. Dados de write-back
Slide 41: Quando você usa o Network Load Balancing, os usuários não podem fazer write-back para cubos OLAP. Dados multidimensionais devem ser somente leitura. Para obter uma operação normal de um único servidor, o Analysis Services dá suporte à alteração de dados de um cubo. Se você ativar um cubo para gravação, os aplicativos clientes poderão registrar no cubo alterações feitas nos dados. Essas alterações, conhecidas como dados write-back, são armazenadas em uma tabela separada do cubo e de seus dados subjacentes, mas elas são incorporadas em resultados de consulta como se fossem parte dos dados do cubo. Os cubos ativados para gravação permitem que usuários finais explorem cenários através da alteração de valores de células e da análise dos efeitos das alterações em dados do cubo. A alteração de um usuário final é armazenada na tabela de write-back como a diferença entre o valor exibido no momento e o valor original. Por exemplo, se um usuário final alterar o valor de uma célula de 90 para 100, o valor +10 será armazenado na tabela de write-back, juntamente com a hora da alteração e as informações sobre o usuário final que a realizou. O efeito de rede de alterações acumuladas é exibido para aplicativos clientes. O valor original no cubo é preservado e uma faixa de auditoria das alterações é registrada na tabela de write-back. Geralmente, a tabela de write-back é armazenada em uma fonte de dados ROLAP. Mesmo que o RDBMS subjacente ofereça suporte ao acesso compartilhado e simultâneo com transações (por exemplo, se o SQL Server for o banco de dados), ocorrerão problemas se esse recurso for usado em um cluster do Network Load Balancing. O serviço MSSQLServerOLAPService que está sendo executado em cada um dos Analysis Servers mantém bloqueios internos, e problemas simultâneos poderão ocorrer se vários Analysis Servers tentarem atualizar a mesma célula ao mesmo tempo. Para obter uma operação normal de um único servidor, o Analysis Services oferece suporte a dimensões ativadas para gravação. Dimensões ativadas para gravação permitem que usuários finais modifiquem o conteúdo da dimensão e visualizem o impacto no cubo imediatamente. Ao contrário de atualizações feitas em um cubo ativado para gravação, que são armazenadas em uma tabela de write-back que é separada das tabelas de origem do cubo, atualizações feitas em uma dimensão ativada para gravação são registradas diretamente na tabela da dimensão.
Slide 42: Infelizmente, como ocorre com a tabela de write-back, o serviço MSSQLServerOLAPService que está sendo executado em cada um dos Analysis Servers mantém bloqueios internos, e problemas simultâneos ocorrerão se vários Analysis Servers tentarem alterar os membros de uma dimensão ao mesmo tempo. Repositório O repositório do Analysis Services (Msmdrep.mdb, que é armazenado na pasta Bin) é usado somente para programas que usam objetos de suporte de decisão (DSO), incluindo o Analysis Manager. O serviço MSSQLServerOLAPService não usa o repositório para processar consultas. Apesar deste documento incluir instruções para copiar o repositório juntamente com a pasta Data durante a reconfiguração cluster do Analysis Server, isso não é tecnicamente necessário durante o tempo de execução. No entanto, os administradores usam o Analysis Manager para solucionar problemas e fazer manutenção. Para garantir que o repositório corresponda à pasta Data, o repositório deve ser movido de seu local padrão (a pasta Bin) para a pasta Data. Isso garante que, quando a pasta Data for copiada do servidor de teste para os Analysis Servers, o repositório associado também seja copiado. Para mover o repositório de seu local padrão para a pasta Data 1. Pare o serviço MSSQLServerOLAPService. 2. Copie Msmdrep.mdb da pasta Bin em que o Analysis Services está instalado (geralmente, a pasta C:\Arquivos de programas\Microsoft Analysis Services\Bin) para a pasta Data. 3. Altere as seguintes chaves do Registro para que apontem para a pasta Data: o HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \OLAP Server\Server Connection Info\Locks Directory o HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \OLAP Server\Server Connection Info\Repository Connection String 4. Altere o compartilhamento de arquivo MsOLAPRepository$ da pasta Bin para a pasta Data. Como, por padrão, a configuração do Registro RemoteRepositoryConnectionString é baseada nesse compartilhamento de arquivo, ela também é atualizada automaticamente. No entanto, se não mover
Slide 43: o compartilhamento de arquivo, você precisará alterar a configuração do Registro manualmente. 5. Reinicie o serviço MSSQLServerOLAPService. Para obter informações sobre um exemplo de script que faz isso de maneira programática, consulte o "Apêndice C". Outro tópico que é freqüentemente discutido quando um sistema do Analysis Services empresarial é colocado em produção é se o repositório deve ser mantido em seu formato Microsoft Access padrão (Msmdrep.mdb) ou migrado para um banco de dados do SQL Server 2000. Cada fonte de dados tem vantagens e desvantagens. Para a arquitetura de referência, o repositório é mantido no formato Access padrão. Isso permite que você disponibilize várias versões on-line ao mesmo tempo. Se migrar o repositório para uma instância do SQL Server 2000, você precisará desenvolver uma infra-estrutura para manter vários repositórios do Analysis Services (provavelmente por ter diferentes instâncias do SQL Server) e alterar a configuração RepositoryConnectionString do Registro para que aponte para a instância correta do repositório (isto é, a que corresponda à pasta Data que esteja sendo usada no momento). Analysis Manager Como os dados OLAP são centralizados nos sistemas back-end, você não deve executar o Analysis Manager nos Analysis Servers, exceto para solucionar problemas. As alterações devem sempre ser feitas no servidor de banco de dados para que sejam propagadas corretamente para os Analysis Servers. Para usar o Analysis Manager nos Analysis Servers, execute-o no próprio servidor ou conecte-se remotamente usando o nome ou o endereço IP individual do servidor. Você não pode usar o Analysis Manager para se conectar ao nome do cluster virtual. Para obter mais informações, consulte o artigo Q269156 do Microsoft Knowledge Base (KB), "System Error 52 When You Connect to an NLB Cluster Name". No entanto, desde que você visualize o repositório sem fazer alterações, será possível conectar-se ao cluster usando o endereço IP de cluster. As alterações são refletidas em apenas um dos Analysis Servers, não em todos, e você não tem controle nem sabe qual deles está
Slide 44: respondendo. Assim, a abordagem recomendada para fazer alterações em todo o cluster é fazê-las no servidor de banco de dados. Configurações alternativas A arquitetura foi projetada para atender a questões específicas, como acesso à Internet, e várias questões da maioria dos sites. Ela não atende a todas, mas você a adapta facilmente para atender a requisitos específicos. Cliente magro versus cliente gordo A arquitetura oferece suporte a uma abordagem tanto com cliente magro quanto com cliente gordo. A figura 1 mostra a arquitetura de cliente gordo. Os usuários finais acessam o cubo através do PivotTable Service, que é instalado em seus computadores para permitir o processamento OLAP no desktop. O PivotTable Service se comunica com o Analysis Server através de HTTP (porta 80) ou de uma conexão TCP/IP (porta 2725). Como a situação descrita neste documento usa um firewall, suponha que seja usada a porta HTTP 80. Além do PivotTable Service, o computador cliente precisa estar executando um aplicativo OLAP cliente real; por exemplo, o Excel, os Office Web Components ou um aplicativo de terceiros. Assim, uma arquitetura OLAP de cliente gordo tem uma grande base, pois uma parte considerável do aplicativo precisa ser instalada em cada computador cliente. Uma vantagem significativa da abordagem de cliente gordo é que os usuários finais obtêm tempos de resposta rápidos e consistentes para suas respostas, pois grande parte do processamento de exibição e de OLAP pode ser feito no próprio desktop. No entanto, essa abordagem também pode ser ineficiente, pois uma grande quantidade de dados pode ter sido removida do servidor para o desktop. Para atender às questões de largura de banda e de base de desktops, experimente o uso da abordagem de cliente magro. Você pode usar a arquitetura de referência na figura 1 para acesso de cliente magro. Ela tem o hardware e o software necessários para gerenciar um site externo. Cada Analysis Server pode fornecer serviços da Web (usando o IIS) diretamente para clientes na Internet e Analysis Services para as páginas ASP que fazem parte do
Slide 45: aplicativo da Web. Na verdade, você pode oferecer tanto serviços de cliente magro quanto de cliente gordo nos mesmos servidores por meio dessa abordagem. Observação Se você planeja oferecer somente serviços de cliente magro, não instale o diretório virtual de acesso HTTP do Analysis Services e sua interface associada (Msolap.asp). No entanto, os designers de sites preferem colocar o software de acesso a banco de dados e servidor Web em computadores diferentes. Nesse caso, experimente o design mostrado na figura 4. A arquitetura de cliente magro se baseia na arquitetura usada nas figuras 1-3, mas adiciona uma terceira camada no site para permitir processamento adicional. Como os computadores clientes só têm navegadores instalados, eles exigem suporte adicional de servidores Web no site antes de acessarem dados OLAP. O aplicativo da Web usa páginas ASP e Microsoft ActiveX® Data Objects (Multidimensional) (ADO MD) para acessar de maneira programática os Analysis Servers e formatar uma página HTML que é processada no navegador do usuário final. Em vez de fornecer acesso ao cluster de Analysis Servers através de HTTP e do PivotTable Service através do servidor Web, a arquitetura de cliente magro fornece acesso ao cluster por meio da técnica de cliente-servidor para a porta 2725. Isso significa que o cluster de Analysis Servers não exige o SQL Server 2000 Enterprise Edition; ele pode usar o SQL Server Standard Edition (reduzindo o custo). A figura 6 mostra a arquitetura de cliente magro com servidores Web dedicados. Como antes, os endereços IP e as conexões de diferentes partes da rede são mostrados em cores diferentes, desta maneira: • • • • A rede externa é mostrada como uma linha tracejada vermelha. Ela também é a pulsação para o cluster do servidor Web. A rede do Analysis Services interna é mostrada como uma linha azul contínua. Ela também é a pulsação para o cluster do Analysis Server. A rede de banco de dados interna é mostrada como uma linha tracejada verde. A rede de pulsação do agrupamento de bancos de dados interna é mostrada como uma linha tracejada preta.
Slide 46: Se o navegador não oferecer suporte a quadros in-line, clique aqui para exibir em uma página separada. Figura 6 Arquitetura de site de referência (cliente magro) com servidores Web dedicados Computador Web1 Configuração Windows 2000 Advanced Server com Network Load Balancing, IIS, ASP, 192.168.18.161, Web2 12.0.0.1 Windows 2000 Advanced Server com Network Load Balancing, IIS, ASP, 192.168.18.162, Web3 12.0.0.2 Windows 2000 Advanced Server com Network Load Balancing, IIS, ASP, 192.168.18.163, VPN1 12.0.0.3 Windows 2000 Advanced Server com VPN, DC principal, DNS, Cluster Sentinel, 192.168.18.180, 10.0.0.41, VPN2 12.0.0.41 Windows 2000 Advanced Server com VPN, DC backup, DNS secundário, Cluster Sentinel, 192.168.18.181, 10.0.0.42,
Slide 47: AS1 12.0.0.42 Windows 2000 Advanced Server com Network Load Balancing, Analysis Services, 12.0.0.61, 10.0.0.1 Windows 2000 Advanced Server com Network Load Balancing, Analysis Services, 12.0.0.62, 10.0.0.2 Windows 2000 Advanced Server com Network Load Balancing, Analysis Services, 12.0.0.63, 10.0.0.3 Windows 2000 Advanced Server com Windows Clustering, SQL Server 2000 (banco de dados relacional) com Analysis Services (servidor de teste), 10.0.0.51, 11.0.0.1, IP corporativo Windows 2000 Advanced Server com Windows Clustering, SQL Server 2000 (banco de dados relacional) com Analysis Services (servidor de teste), 10.0.0.52, 11.0.0.2, IP corporativo AS2 AS3 Db1 Db2 Produção contínua Usando algumas das técnicas mostradas pela arquitetura de referência, você pode projetar um recurso que possa ser colocado em produção rapidamente. Isso é necessário caso você deseje manter um site de produção on-line ininterruptamente. Em várias aplicações para intranet, também é necessário fornecer um recurso de teste para cubos. O resultado é um subconjunto de dois nós da arquitetura de referência que pode ser usado para colocar cubos em produção com o mínimo de impacto para os usuários finais. A figura 7 mostra o design geral.
Slide 48: Figura 7 Arquitetura de site de referência com dois nós (cliente magro) com servidores Web dedicados Computador ASDb1 Configuração Windows 2000 Advanced Server com Windows Clustering, SQL Server 2000 (banco de dados relacional) com Analysis Services (teste), ASDb2 IP corporativo 2 Windows 2000 Advanced Server com Windows Clustering, SQL Server 2000 (banco de dados relacional) com Analysis Services (teste), IP corporativo 3 Observação Cada servidor tem a mesma configuração de CPU, memória e disco. Em operação normal, o Network Load Balancing é configurado para que a carga seja dividida igualmente entre dois servidores. Cada servidor tem uma cópia idêntica dos dados OLAP; se um deles falhar ou ficar off-line para manutenção preventiva ou outras atividades programadas, o outro servidor assumirá a carga automaticamente. Não há interrupção do serviço para os usuários finais. Para atualizar o cluster do Analysis Services. 1. Selecione o servidor a ser usado como servidor de teste. Ele é o servidor em que você carregará os dados antes de postá-los. 2. Interrompa gradualmente o servidor de teste até que ele não tenha qualquer conexão. 3. Inicie o processo ETL de teste e atualize os dados OLAP. 4. Realize todas as validações necessárias nos novos dados. Após concluir a validação e estar pronto para mover os dados para produção, copie a pasta Data do servidor de teste em uma pasta diferente no outro servidor.
Slide 49: 5. Interrompa gradualmente o outro servidor e adicione o servidor de teste ao cluster. As conexões existentes continuam, mas as novas vão para o servidor de teste e os usuários finais vêem os novos dados. 6. Depois que o outro servidor tiver fechado todas as suas conexões, pare o serviço MSSQLServerOLAPService, altere a pasta Data e reinicie o serviço MSSQLServerOLAPService. 7. Adicione o outro servidor ao cluster. Ambos os Analysis Servers serão executados com os novos dados OLAP, sem interrupção para os usuários finais durante o processo de teste e postagem. Localizando mais informações Os links a seguir contêm mais informações, recursos e material para download relacionados à criação de sites e OLAP de alta disponibilidade. • Site Exploring Windows Clustering Technologies (Windows NT 4 .0 Enterprise Edition) (http://www.microsoft.com/ntserver/ProductInfo/Enterprise/default.asp) (site em inglês) • Site Exploring Windows Clustering Technologies (Windows NT 2000 Advanced Server) (http://www.microsoft.com/windows2000/technologies/clustering/default.asp) (site em inglês) • • • • • Lista de compatibilidade de hardware (http://www.microsoft.com/hcl/) (site em inglês) Home page do Microsoft Internet Explorer 6 (http://www.microsoft.com/windows/ie_intl/br) Lights-Out Operation Guide for Microsoft Windows NT Server (http://www.microsoft.com/serviceproviders/default.asp) (site em inglês) Home page do SQL Server 2000 (http://www.microsoft.com/brasil/sql/) Privacy Protected Network Access: Virtual Private Networking and Intranet Security (http://www.microsoft.com/windows2000/techinfo/howitworks/security/comsec .asp) (site em inglês)
Slide 50: • Tuning IIS for High-Volume Sites (http://www.microsoft.com/windows2000/techinfo/administration/web/tuning.a sp) (site em inglês) • • Home page do Windows 2000 Server (http://www.microsoft.com/brasil/windows2000/server/default.stm) Home page do Microsoft Application Center 2000 (http://www.microsoft.com/applicationcenter/) (site em inglês) As informações a seguir sobre XML for Analysis estão disponíveis: • • XML for Analysis Specification (http://msdn.microsoft.com/library/techart/xmlanalysis.htm) (site em inglês) XML for Analysis SDK Download (http://msdn.microsoft.com/downloads/default.asp?URL=/code/sample.asp? url=/MSDN-FILES/027/001/633/msdncompositedoc.xml) (site em inglês) Os seguintes artigos do KB também são interessantes: • Q232711 - How Cluster Integrity Is Monitored in WLBS (http://support.microsoft.com/support/kb/articles/Q232/7/11.asp) (site em inglês) • Q240997 - Configuring Network Load Balancing (http://support.microsoft.com/support/kb/articles/Q240/9/97.asp) (site em inglês) • Q198496 - How to Configure WLBS Port Rules (http://support.microsoft.com/support/kb/articles/Q198/4/96.asp) (site em inglês) Apêndice A: um guia passo a passo Esta seção fornece instruções passo a passo para configurar o Network Load Balancing em dois servidores (AS1 e AS2) e oferecer suporte a infra-estrutura para a arquitetura de referência. Observação Esta seção supõe que o cluster esteja configurado para distribuição homogênea entre todos os hosts. Dependendo da capacidade dos seus servidores, isso pode não ser apropriado.
Slide 51: Primeiro, instale o Windows 2000 Advanced Server. Configure as duas placas NIC com endereços IP estáticos. Certifique-se de que os servidores DNS ou WINS possam mapear ambos os endereços IP para os servidores. Instale o Analysis Services. Se estiver usando a arquitetura de referência, você precisará usar o SQL Server 2000 Enterprise Edition. 1. Faça logon como administrador no Servidor 1 (AS1) e, em seguida, faça logon como administrador no Servidor 2 (AS2). Para cada servidor, verifique a configuração da NIC e se o Network Load Balancing está instalado. 2. No Control Panel, clique duas vezes em Network and Dial-Up Connections. Deve haver pelo menos duas conexões locais configuradas, uma para cada NIC. Renomeie a NIC externa como Cluster; renomeie a interna como Dedicated. Clique com o botão direito em Cluster e, em seguida, clique em Properties. 3. Se o Network Load Balancing não estiver listado, clique em Install. Na caixa de diálogo Select Network Component Type, clique em Service e, em seguida, clique em Add. Selecione Network Load Balancing e clique em OK. 4. Selecione Internet Protocol (TCP/IP) e clique em Properties. Defina os endereços IP estáticos como: o o 192.168.18.168 (para Servidor 1) 192.168.18.169 (para Servidor 2) 5. Clique em OK para fechar a caixa de diálogo Internet Protocol (TCP/IP) Properties e, em seguida, clique em OK para fechar a caixa de diálogo Cluster Properties. 6. Clique com o botão direito na conexão de rede local chamada Dedicated e, em seguida, clique em Properties. Verifique se a caixa de seleção Network Load Balancing está desmarcada. 7. Clique em Internet Protocol (TCP/IP) e, em seguida, clique em Properties. Defina os endereços IP estáticos como: o o 10.0.0.1 (para Servidor 1) 10.0.0.2 (para Servidor 2) 8. Clique em OK para fechar a caixa de diálogo Internet Protocol (TCP/IP) Properties e, em seguida, clique em OK para fechar a caixa de diálogo Dedicated Properties. Em seguida, configure o Network Load Balancing nos dois Analysis Servers.
Slide 52: Para configurar o Network Load Balancing no Servidor 1 (AS1) 1. No Control Panel, clique duas vezes em Network and Dial-Up Connections. Clique com o botão direito na conexão de rede local chamada Cluster e, em seguida, clique em Properties. 2. Marque a caixa de seleção Network Load Balancing e clique em Properties. A caixa de diálogo Network Load Balancing Properties é exibida. 3. Clique na guia Cluster Parameters. Especifique os valores a seguir. Parâmetro Valor Endereço IP principal 192.168.18.155 Máscara de sub-rede 255.255.255.0 Nome de Internet completo commerce.seudominio.com Suporte de difusão seletiva <desativado> Senha remota <em branco> Controle remoto <desativado> 4. Clique na guia Host Parameters. Especifique os valores nos campos de Host parameters. o Em Priority (ID), especifique 1, pois este é o primeiro host do cluster de Network Load Balancing. Especifique o estado inicial como ativo. o Digite valores para o endereço IP dedicado e a máscara de sub-rede. Esses valores são exclusivos para cada servidor no cluster do Network Load Balancing. No site de referência, adicione um endereço IP igual a 192.168.18.161 (AS1) com uma máscara de sub-rede 255.255.255.0. 5. Clique na guia Port Rules. Nela, é possível modificar as regras de porta a fim de especificar como o Network Load Balancing deve lidar com o tráfego de rede de portas específicas. Neste cenário, configure todas as portas para que sejam as mesmas. Para outros, você poderá selecionar as portas reais que estejam sendo usadas. 6. Clique na regra de porta padrão (0-65535). Defina o modo de filtragem como Multiple hosts; sem afinidade. Clique em Modify e, em seguida, clique em OK. 7. Clique no protocolo TCP/IP e, em seguida, clique em Properties. Clique em Advanced. 8. Clique em Add e inclua o endereço IP do cluster de Network Load Balancing (192.168.18.155) e o computador (se não houver um endereço IP presente). Em seguida, clique em OK. O Servidor 1 está completo. Na etapa seguinte, configure o Servidor 2.
Slide 53: Para configurar o Network Load Balancing no Servidor 2 (AS2) 1. No Control Panel, clique duas vezes em Network and Dial-Up Connections. Clique com o botão direito em Cluster e, em seguida, clique em Properties. 2. Marque a caixa de seleção Network Load Balancing e clique em Properties. A caixa de diálogo Network Load Balancing Properties é exibida. 3. Clique na guia Cluster Parameters e especifique os seguintes valores. Parâmetro Valor Endereço IP principal 192.168.18.155 Máscara de sub-rede 255.255.255.0 Nome de Internet completo commerce.seudominio.com Suporte de difusão seletiva <desativado> Senha remota <em branco> Controle remoto <desativado> 4. Clique na guia Host Parameters. Especifique os valores nos campos de Host parameters. o No campo Priority (ID), especifique um número seqüencial exclusivo. Especifique 2, pois este é o segundo host no cluster de Network Load Balancing. Especifique o estado inicial como ativo. o Digite valores para o endereço IP dedicado e a máscara de sub-rede. Esses valores são exclusivos para cada servidor no cluster do Network Load Balancing. No site de referência, adicione um endereço IP igual a 192.168.18.162 (AS2) com uma máscara de sub-rede 255.255.255.0. 5. Clique na guia Port Rules. Nela, é possível modificar as regras de porta a fim de especificar como o Network Load Balancing deve lidar com o tráfego de rede de portas específicas. Neste cenário, configure todas as portas para que sejam as mesmas. Em outros, você poderá selecionar as portas reais que estejam sendo usadas. 6. Clique na regra de porta padrão (0-65535), defina o modo de filtragem como Multiple hosts; sem afinidade. Clique em Modify e, em seguida, clique em OK. 7. Clique no protocolo TCP/IP e, em seguida, clique em Properties. Clique em Advanced. Clique no botão Add e inclua o endereço IP do computador (se não houver um endereço) e do cluster de Network Load Balancing (192.168.18.155). Clique em OK.
Slide 54: Observe que, novamente, você configurou ambos os servidores da mesma maneira. Quando você usar o Network Load Balancing diretamente, configure cada servidor manualmente. Agora que o Network Load Balancing está sendo executado nos dois nós do cluster, experimente algumas consultas para verificar o equilíbrio entre servidores. Para verificar se o Network Load Balancing está funcionando corretamente 1. Coloque o seguinte arquivo na raiz IIS de AS1: (C:\Inetpub\wwwroot\nlb.asp) <%Response.Expires = -1 %> <head> <title>AS1</title> </head> <body> Página servida por: AS1 </TABLE> </body> 2. Coloque o seguinte arquivo na raiz IIS de AS2: (C:\Inetpub\wwwroot\nlb.asp) <%Response.Expires = -1 %> <head> <title>AS2</title> </head> <body> Página servida por: AS2 </TABLE> </body> 3. Inicie o Internet Explorer aproximadamente 20 vezes com o destino http://192.168.18.155/ (ou o nome do cluster, se houver uma entrada DNS). Você deve ver algumas das instâncias reportarem AS1 e outras reportarem
Slide 55: AS2. É necessário iniciar uma nova instância do Internet Explorer cada vez. A atualização da página não estabelece a conexão IP. Apêndice B: Ferramenta de linha de comando Este apêndice contém o arquivo da Ajuda para wlbs, que é uma ferramenta de linha de comando para gerenciar o cluster de Network Load Balancing. C:\> WLBS /? WLBS Cluster Control Utility V2.3. (c) 1997-99 Microsoft Corporation Uso: WLBS <comando> [<cluster>[:<host>] [/PASSW [<senha>]] [/PORT <porta>]] <comando> help exibe a Ajuda on-line ip2mac <cluster> - converte o IP do cluster em endereço MAC do cluster reload - recarrega parâmetros do Registro query - consulta quais hosts fazem parte do cluster no momento display - exibe parâmetros de configuração, status atual e as últimas mensagens do log de eventos suspend - suspende o controle sobre as operações do cluster resume - inicia o controle nas operações do cluster start - inicia as operações do cluster stop - pára as operações do cluster drainstop - termina todas as conexões existentes e pára as operações do cluster enable <porta> | ALL - ativa o tráfego pela regra da <porta> ou de TODAS as portas disable <porta> | ALL - desativa TODO o tráfego da regra da <porta> ou de TODAS as portas drain <porta> | ALL - desativa o tráfego NOVO da regra da <porta> ou de TODAS as portas Opções remotas: <cluster> - nome do cluster | endereço IP principal do cluster <host> - host dentro do cluster (padrão - TODOS os hosts): nome dedicado | endereço IP | Identificação da prioridade do host (1..32) | 0 para host PADRÃO atual /PASSW <senha> - senha de controle remoto (padrão - NENHUMA)
Slide 56: em branco <senha> para prompt do console /PORT <porta> - porta UDP de controle remoto do cluster Para acessar o arquivo da Ajuda do Network Load Balancing, emita o comando a seguir. Essa é a documentação mais completa disponível para o Network Load Balancing. C:\> WLBS HELP Apêndice C: Exemplo de scripts Este apêndice fornece exemplos de scripts para trabalho com o Network Load Balancing e o Analysis Services. Os scripts realizam funções como parar e iniciar o Network Load Balancing e o Analysis Services, alterar a pasta Data do Analysis Services e mover o repositório da pasta Bin para a pasta Data. Outras fontes excelentes de exemplos de scripts para o Network Load Balancing estão localizadas em: NlbScriptLib.vbs e Nlb.wsf Os scripts a seguir são fornecidos nesta seção: • • • • • Parar e iniciar o Network Load Balancing usando um comando de shell do DOS e uma chamada da instrumentação de gerenciamento do Windows (WMI) Chamar um trabalho DTS para iniciar o processamento no servidor de teste Interromper e iniciar o serviço MSSQLServerOLAPService Alterar a pasta Data do Analysis Services Mover o repositório da pasta Bin para a pasta Data Os três primeiros são fornecidos no Conjunto 1. Os dois restantes são fornecidos no Conjunto 2. Observação O código a seguir faz parte de um sistema muito maior e é fornecido como uma amostra para que você tenha uma idéia dos tipos de scripts que podem ser escritos. O código não é executado diretamente. Segundo, nem todo o código se aplica diretamente ao processamento OLAP e ao Network Load Balancing. Parte do código ilustra práticas recomendadas, como manter um log de aplicativo para quando várias
Slide 57: etapas são executadas, criar uma interface com o log de eventos no Windows 2000, etc. Conjunto 1 '/******************************************************************* 'Arquivo: PostProcess.vbs 'Autor: 'Versão: 'Última modificação: 'OBSERVAÇÃO: precisa ser executado no SQL Server de teste '/******************************************************************* Dim strSQLConnect, strSQL, strErrDesc, strDataDrive Dim strCluster, strServer, strFile, strAggregator, strFilePath Dim strOLAP2 Dim intJobID Dim objArgs, objNW, objFS, objConn Dim rs, rsMon Dim aryDay(7) strOLAP1 = "SERVER1" strOLAP2 = "SERVER2" strOLAP1ID = "2" strOLAP2ID = "1" strOLAPIP = "192.168.18.155" strFolder1 = "\\" & strOLAP2 & "\OLAP\Data" strFolder2 = "\\" & strOLAP2 & "\OLAP\DataNew" 'Se houver erro, continuar '\\próxima criação de objeto Set objConn = CreateObject("ADODB.Connection") Set objShell = WScript.CreateObject("WScript.Shell") Set objConnCS = CreateObject("ADODB.Connection") Set objNW = CreateObject("WScript.NetWork") Set objFS = CreateObject("Scripting.FileSystemObject")
Slide 58: WScript.Echo("Insira PostProcess") If Err.Number <> 0 Then objShell.LogEvent 1, "PostProcess.vbs: não foi possível objetos necessários. Nº do erro:" & _ Err.Number & " Descrição do erro:" & Err.Description WScript.Echo("erro de objeto") Err.Clear WScript.Quit End If '//Obter nome local strLocalMachine = objNW.ComputerName Set objNW = Nothing '//Preenchendo a matriz de dias aryDay(1) = "Sun" aryDay(2) = "Mon" aryDay(3) = "Tue" aryDay(4) = "Wed" aryDay(5) = "Thu" aryDay(6) = "Fri" aryDay(7) = "Sat" intDay = WeekDay(Now()) strSuffix = aryDay(intDay) '\\StatsMon SQL Connect sUID = "sa" sPWD = "password" sDB = "StatsDb" sServer = "MONITOR" strSQLConnect = "Driver={SQL Server};UID=" & sUID & ";PWD=" & sPWD & _ ";LANGUAGE=us_english;DATABASE=" & sDB & ";SERVER=" & sSERVER objConn.Open strSQLConnect
Slide 59: If Err.Number <> 0 Then objShell.LogEvent 1, "PostProcess.vbs: não foi possível conectar ao servidor -" & sServer & " Banco de dados-" & _ sDB & " Número do erro-" & Err.Number & " Descrição do erro -" & Err.Description Err.Clear 'WScript.Quit End If '//Obter contagem de trabalhos que não estão em PostProcess strSQL = "up_getCountPostProcessNotReady" set rsMon = objConn.Execute(strSQL) intCount = rsMon("NotReady") '//Saber se OLAP/PostProcess está sendo executado strSQL = "up_getOLAPRunning" set rsMon = objConn.Execute(strSQL) intRunning = rsMon("Value") If intCount <> 0 OR intRunning = 1 Then WScript.Quit End If objShell.LogEvent 4, "PostProcess.vbs: processo iniciado" strSQL = "up_setOLAPRunning 1" intReturn = objConn.Execute(strSQL) '\\CS SQL Connect strUID = "sa" strPWD = "password" strDB = "Master" strServer = "SERVER1" strSQLConnect = "Driver={SQL Server};UID=" & strUID & ";PWD=" & strPWD & _ ";LANGUAGE=us_english;DATABASE=" & strDB & ";SERVER=" & strSERVER objConnCS.ConnectionTimeOut = 3600
Slide 60: objConnCS.CommandTimeOut = 3600 objConnCS.Open strSQLConnect If Err.Number <> 0 Then objShell.LogEvent 1, "PostProcess.vbs: não foi possível conectar ao servidor -" & strServer & " Banco de dados-" & _ strDB & " Número do erro-" & Err.Number & " Descrição do erro -" & Err.Description Err.Clear 'strSQL = "up_setOLAPRunning 0" 'intReturn = objConn.Execute(strSQL) 'WScript.Quit End If strSQL = "up_getPostProcessToRun" set rs = objConn.Execute(strSQL) '//Remover primeiro servidor OLAP do NETWORK LOAD BALANCING '//Alterar para chamada WMI suspendNLB strOLAP1,strOLAPIP,strOLAP1ID '// ou poderia ser '// strCommand = "WLBS suspend " & strOLAPIP & ":" & strOLAP1ID & " /PASSW Spit2Drive!" '// WScript.Echo strCommand '// IntReturn = objShell.Run(strCommand, 1, TRUE) '//Reiniciar o serviço para limpar eventuais conexões restantes stopOLAPService strOLAP1 startOLAPService strOLAP1 WScript.Sleep(120000) startOLAPService strOLAP1 WScript.Sleep(120000) '//INCREMENTAL WScript.Echo("Início do incremental") objShell.LogEvent 4, "PostProcess.vbs: início do incremental" Do While Not rs.EOF strCluster = rs("Cluster")
Slide 61: intBuildOlap = rs("BuildOlap") strSQL = "exec " & strCluster & ".dbo.PostProcess" WScript.Echo("strSQL: " & strSQL) intReturn = objConnCS.Execute(strSQL) If intBuildOlap = 1 Then strCommand = "cscript c:\scripts\Cubes.vbs " & strCluster WScript.Echo("strCommand: " & strCommand) intReturn = objShell.Run(strCommand, 1, FALSE) End If rs.MoveNext() Loop WScript.Echo("Incremental concluído") objShell.LogEvent 4, "PostProcess.vbs: incremental concluído" '//Concluído strSQL = "up_getCountPostProcessRunning" set rs = objConn.Execute(strSQL) intCount = rs("Count") Do While intCount <> 0 WScript.Sleep(6000) strSQL = "up_getCountPostProcessRunning" set rs = objConn.Execute(strSQL) intCount = rs("Count") Loop '//Parar serviço para liberar arquivos de origem stopOLAPService strOLAP1 '//ARQUIVAMENTO OLAP objShell.LogEvent 4, "PostProcess.vbs: início do arquivamento" strCommand = "robocopy " & Chr(34) & "\\" & strOLAP1 & "\e$\Microsoft Analysis Services\Data" & Chr(34) & _ " " & Chr(34) & "\\" & strOLAP2 & "\MAS\DataNew" & Chr(34) & " /S" WScript.Echo(strCommand) intReturn = objShell.Run(strCommand, 1, TRUE) WScript.Echo("intReurn:" & intReturn)
Slide 62: WScript.Echo("Arquivamento concluído") objShell.LogEvent 4, "PostProcess.vbs: arquivamento concluído" '//Concluído '//Reativar o primeiro servidor OLAP startOLAPService strOLAP1 resumeNLB strOLAP1,strOLAPIP,strOLAP1ID '// ou poderia ser '// WScript.Sleep(120000) '// strCommand = "WLBS resume " & strOLAPIP & ":" & strOLAP1ID & " /PASSW Spit2Drive!" '// WScript.Echo strCommand '// intReturn = objShell.Run(strCommand, 1, TRUE) '// strCommand = "WLBS start " & strOLAPIP & ":" & strOLAP1ID & " /PASSW Spit2Drive!" '// WScript.Echo strCommand '// intReturn = objShell.Run(strCommand, 1, TRUE) '//Remover segundo servidor OLAP e parar o serviço OLAP suspendNLB strOLAP2,strOLAPIP,strOLAP2ID '// ou poderia ser '// strCommand = "WLBS suspend " & strOLAPIP & ":" & strOLAP2ID & " /PASSW Spit2Drive!" '// WScript.Echo strCommand '// intReturn = objShell.Run(strCommand, 1, TRUE) stopOLAPService strOLAP2 '//RESTAURAÇÃO OLAP WScript.Echo("Início da restauração") objShell.LogEvent 4, "PostProcess.vbs: início da restauração" DeleteFolder strFolder1 MoveFolder strFolder2, strFolder1 strCommand = "dtsrun /F C:\scripts\CopyOLAPObjectsTable.dts /L C:\temp\CopyOLAPObjectsTable.txt"
Slide 63: WScript.Echo strCommand intReturn = objShell.Run(strCommand, 1, TRUE) startOLAPService strOLAP2 WScript.Sleep(120000) initOLAP strOLAP2 'Acessa os bancos de dados OLAP objShell.LogEvent 4, "PostProcess.vbs: restauração concluída" WScript.Echo("Restauração concluída") '//Concluída '//Reativar segundo servidor OLAP resumeNLB strOLAP2,strOLAPIP,strOLAP2ID '// ou poderia ser '// strCommand = "WLBS resume " & strOLAPIP & ":" & strOLAP2ID & " /PASSW Spit2Drive!" '// WScript.Echo strCommand '// intReturn = objShell.Run(strCommand, 1, TRUE) '// strCommand = "WLBS start " & strOLAPIP & ":" & strOLAP2ID & " /PASSW Spit2Drive!" '// WScript.Echo strCommand '// intReturn = objShell.Run(strCommand, 1, TRUE) objShell.LogEvent 4, "PostProcess.vbs: PostProcess concluído" set objShell = Nothing set rs = Nothing set objConn = Nothing set objConnCS = Nothing WScript.Quit '//FUNÇÕES Function suspendNLB(strOLAP, strIP,strOrder) Set NLBNode = GetObject("winmgmts:\\" & strOLAP & "\root\MicrosoftNLB:MicrosoftNLB_Node.Name='" & _ strIP & ":" & strOrder & "'") a = NLBNode.suspend()
Slide 64: WScript.Echo(a) End Function Function resumeNLB(strOLAP, strIP,strOrder) Set NLBNode = GetObject("winmgmts:\\" & strOLAP & "\root\MicrosoftNLB:MicrosoftNLB_Node.Name='" & _ strIP & ":" & strOrder & "'") a = NLBNode.resume() WScript.Echo(a) a = NLBNode.start() WScript.Echo(a) End Function Function initOLAP(strOLAP) If err.number > 0 then objShell.LogEvent 1, "PostProcess.vbs: initOLAP Failed Server-" & strOLAP End If Dim dsoServer Dim dsoDatabase Dim sta Set dsoDatabase = CreateObject("DSO.MDStore") Set dsoServer = CreateObject("DSO.Server") dsoServer.Connect strOLAP dsoServer.Refresh For Each dsoDatabase In dsoServer.MDStores sta = dsoDatabase.State WScript.Echo(dsoDatabase.Name) Next End Function Function startOLAPService(strOLAP) Dim objService set objService = GetObject("winmgmts://" & strOLAP & _
Slide 65: "/root/cimv2:Win32_Service.Name='MSSQLServerOLAPService'") WScript.Sleep(6000) b = objService.StartService() set objService = Nothing End Function Function stopOLAPService(strOLAP) Dim objService set objService = GetObject("winmgmts://" & strOLAP & _ "/root/cimv2:Win32_Service.Name='MSSQLServerOLAPService'") WScript.Sleep(6000) b = objService.StopService() set objService = Nothing End Function Function DeleteFolder(folderspec) objFS.DeleteFolder folderspec End Function Function MoveFolder(fldrspec1,fldrspec2) objFS.MoveFolder fldrspec1, fldrspec2 End Function Conjunto 2 Estes scripts precisam ser executados no próprio Analysis Server. Eles não podem ser chamados remotamente. Function changeOLAPDataFolder(strDF) Dim objWSHShell Dim strKey strKey = "HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \OLAP Server\CurrentVersion\RootDir" Set objWSHShell = CreateObject("WScript.Shell") objWSHShell.RegWrite( strKey, strDF, "REG_SZ") End Function
Slide 66: Function moveRepository(strDestFolder) '// OBSERVAÇÃO: é necessário que o arquivo msmdrep.mdf já exista na pasta de destino '// por exemplo, C:\Arquivos de programas \Microsoft Analysis Services\Data (sem "\" final no nome da pasta) Dim strDF Dim objWSHShell Dim strKey ' atualizar o diretório de bloqueios strKey = "HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \OLAP Server\Server Connection Info\" objWSHShell.RegWrite( strKey & "Locks Directory", strDestFolder, "REG_SZ") ' atualizar a seqüência de caracteres de conexão do repositório strDF = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & strDestFolder & "\msmdrep.mdb" objWSHShell.RegWrite( strKey & "Repository Connection String", strDF, "REG_SZ") ' atualizar o compartilhamento de arquivo MsOLAPRepository$ ' a ser definido End Function Apêndice D: Configuração do serviço de cluster Este apêndice fornece as etapas necessárias para configurar o Analysis Services em um cluster de servidores. Como mostrado na arquitetura de referência, não é a abordagem recomendada para a criação de sites OLAP de grande escala e com alta disponibilidade. A técnica recomendada é usar clusters de Network Load Balancing ou uma combinação de clusters de Network Load Balancing e clusters de servidores. No entanto, os clusters de servidores são uma tecnologia usada com freqüência em outras áreas, com destaque para o SQL Server, e podem ser uma alternativa apropriada para alguns sistemas. Importante O Analysis Services não é projetado e testado para uma configuração de servidor em cluster. Apesar de não haver suporte oficial à configuração, os serviços de suporte aos produtos Microsoft se esforçarão ao máximo para oferecerem suporte a uma instalação em cluster. Para pesquisar com detalhes o problema, o serviço de
Slide 67: suporte aos produtos Microsoft poderá solicitar ao cliente que desfaça o cluster dos sistemas para verificar se o problema pode ser reproduzido. Além disso, não há garantia de que as entradas do Registro permanecerão sincronizadas ou que o failover funcionará como um aplicativo que reconhece clusters. Você deve ser comunicar com seu contato dos serviços de suporte aos produtos Microsoft antes de implementar o Analysis Services em um cluster de servidores. Os aplicativos que são executados em um cluster de servidores se enquadram em uma de quatro categorias. • • Aplicativos sem suporte nativo a clusters. Esses aplicativos não interagem com o cluster de servidores, mas ainda assim têm um bom desempenho nele. Aplicativos que reconhecem clusters. Esses aplicativos atingem o melhor desempenho ao implementar a ciência do ambiente de cluster, permitindo que reajam a eventos de cluster. • Aplicativos de gerenciamento de clusters. Esses aplicativos, como o Cluster Administrator e o Cluster.exe, permitem que os administradores gerenciem e configurem clusters. • Tipos de recursos personalizados. Esses aplicativos permitem o gerenciamento personalizado do cluster em relação a aplicativos, serviços e dispositivos. Analysis Services é um aplicativo sem suporte nativo a cluster. No entanto, através do recurso de serviço genérico do serviço de cluster, você pode configurá-los em um ambiente de cluster para obter uma solução de alta disponibilidade para sua configuração OLAP. 1. Instale o Analysis Services localmente em ambos os nós do cluster com as pastas de dados armazenadas na unidade de cluster compartilhada. Você pode especificar as pastas de dados durante a instalação ou alterá-las manualmente na seguinte chave do Registro: HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \OLAP Server\CurrentVersion 2. Mova o repositório do Analysis Services para a unidade de cluster compartilhada. Se o repositório do Analysis Services estiver em Access (o
Slide 68: padrão na instalação), o arquivo de repositório (Msmdrep.mdb) precisará ser movido para um recurso compartilhado. Altere manualmente as chaves do Registro de Repository Connection String e RemoteRepositoryConnectionString em ambos os servidores para apontar para o novo local. Normalmente, a conexão com o arquivo de repositório é feita por meio do compartilhamento MSOLAPRepository$. O compartilhamento MSOLAPRepository$ é criado pelo Analysis Services durante a configuração e aponta para a pasta Bin. Primeiro, descompartilhe a pasta Bin em cada servidor e, em seguida, compartilhe a pasta correspondente como MSOLAPRepository$ no recurso compartilhado. Conceda permissões de controle completas aos membros dos grupos Administradores e Administradores OLAP. Em seguida, modifique as entradas do Registro em HKEY_LOCAL_MACHINE \ SOFTWARE Microsoft\OLAP Server\Server Connection Info, conforme apropriado. As entradas Locks Directory e Remote Locks Directory do Registro devem apontar para o disco de recursos compartilhados. No entanto, em vez de mover a versão Access do repositório para um local diferente, a solução recomendada é migrar o repositório para o SQL Server em uma instância e copiar as chaves do Registro de Repository Connection String e RemoteRepositoryConnectionString do servidor para o qual o repositório foi migrado para o outro nó no cluster de servidores. O SQL Server é o local preferencial para os metadados do Analysis Services em implantações empresariais. 3. No Cluster Administrator, crie um serviço genérico para executar Msmdsrv.exe (o executável de Análise). Crie um novo recurso como tipo Serviço genérico. Ambos os nós devem ser proprietários e devem mover o disco do cluster como uma dependência para o recurso. O nome do serviço deve ser MSSQLServerOLAPService e o parâmetro de inicialização deve ser net start MSSQLServerOLAPService. O Analysis Services agora deve ser controlado através do Cluster Administrator.
Slide 69: 4. Defina o disco de cluster compartilhado com os dados (e o repositório) a serem movidos como parte do mesmo grupo de cluster quando houver failover. Defina o serviço MSSQLServerOLAPService para ser iniciado no outro nó quando houver failover. 5. Defina MSSQLServerOLAPService para ser iniciado manualmente no Windows 2000. Como você pode ver, uma das questões operacionais mais importantes no cluster de servidor é a coordenação de alterações do Registro entre nós. Como o Analysis Services não reconhece clusters, é necessário fazer modificações, como o local do repositório ou outras modificações do Registro, manualmente em todos os servidores. O recurso de serviço genérico pode ser usado para iniciar o processo MSSQLServerOLAPService, mas ele não coordena outras fontes de informação, como as propriedades do servidor que são definidas por meio do Analysis Manager, mas armazenadas no Registro. As informações contidas neste documento representam a posição atual da Microsoft Corporation no que diz respeito às questões abordadas na data de publicação. Como a Microsoft deve responder às condições de mudança de mercado, as informações não devem ser interpretadas como um compromisso por parte da Microsoft, sendo que esta não pode garantir a precisão de qualquer informação apresentada após a data de publicação. Este documento é fornecido apenas para fins informativos. A MICROSOFT NÃO OFERECE QUAISQUER GARANTIAS, EXPLÍCITAS OU IMPLÍCITAS, NESTE DOCUMENTO. Obedecer a todas as leis de direitos autorais aplicáveis é responsabilidade do usuário. Sem limitar os direitos autorais, nenhuma parte deste documento pode ser reproduzida, armazenada ou introduzida em um sistema de recuperação, ou transmitida de qualquer forma por qualquer meio (eletrônico, mecânico, fotocópia, gravação ou qualquer outro), ou para qualquer propósito, sem a permissão expressa, por escrito, da Microsoft Corporation. A Microsoft pode ter patentes ou requisições para obtenção de patente, marcas comerciais, direitos autorais ou outros direitos de propriedade intelectual que abrangem o conteúdo deste documento. A posse deste documento não lhe confere nenhum direito sobre as citadas patentes, marcas comerciais, direitos autorais ou
Slide 70: outros direitos de propriedade intelectual, salvo aqueles expressamente mencionados em um contrato de licença, por escrito, da Microsoft. Salvo indicação em contrário, os exemplos de empresas, organizações, produtos, nomes de domínio, endereços de email, logotipos, pessoas, lugares e eventos aqui mencionados são fictícios e nenhuma associação com qualquer empresa, organização, produto, nome de domínio, endereço de email, logotipo, pessoa, lugar ou evento real é intencional ou deve ser inferida. © 2001 Microsoft Corporation. Todos os direitos reservados. Microsoft, PivotTable, Windows e Windows NT são marcas registradas ou marcas comerciais da Microsoft Corporation nos Estados Unidos e/ou em outros países. Os nomes de empresas e produtos reais aqui mencionados podem ser marcas comerciais de seus respectivos proprietários.