Load Balance Disk Migração por Balanceamento ASM em RAC estendido Movimentação de Datafile entre ASM e Filesystem Ponto de montagem ACFS

Transcrição

1 1. O que é ASM? 1.1 Overview 1.2 Arquitetura e Internals 2. Por que usar e Como usar ASM? Componentes do ASM Stripe e Mirror ASM Process ACFS - Oracle Automatic Storage Management Cluster File System Método SAME 2.1. Abordagens praticas: Load Balance Disk Migração por Balanceamento ASM em RAC estendido Movimentação de Datafile entre ASM e Filesystem Ponto de montagem ACFS Pequeno Glossário para iniciarmos. ASM: Automatic Storage Management ASM Diskgroup: É um pool de armazenamento ou unidade ou ponto de montagem que contém uma coleção (1 ou mais) de discos do sistema operacional (exemplo: /dev/sdb). Manager Path: Software que faz o gerenciamento dos devices em sistemas Unix e Linux, tais como EMC PowerPath, DM-Multipath, MPIO, mknod, Oracle ASM support, entre outros. SAME: Stripe And Mirror Everywhere - Principio do ASM: sempre tende a distribuir e deixar redundante as "cargas" entre os discos.

2 1. O que é ASM? 1.1 Overview Segundo as documentações oficiais, ASM (Automatic Storage Management) é um sistema de arquivos (File system) e gerenciador de volumes para arquivos do banco de dados da Oracle, tais como controlfile, datafile, parameter file, backupset rman, etc. Está solução é suportável em ambientes Single-Instance e RAC. Nas versões legadas (11gR1 ou inferior) ASM e Clusterware eram coisas distintas, hoje uma só chamada Grid Infrastructure. Assim, para ter um ASM em Single-Instance, o Clusterware é instalado e o ASM torna-se um recurso integrado a ele. Porém, não haverá failover de recursos por não existir nodes associados a essa solução (Não é um cluster). Quando tive os primeiros contato com ASM confesso que tive quebrar alguns preconceitos e entender bem a fundo suas vantagens e desvantagens. Concluí que ASM é uma ótima solução sobre 3 condições: 1. Usando sistema operacional Unix 2. Usando um bom Manager Path, que nada mais é que um software que faz o gerenciamento dos devices (discos) em sistemas Unix e Linux: Se Unix, recomendo: PowerPath, MPIO, multipath ou mknod. Se Linux, utilizar o manager path e "Oracle ASM support" ou somente OracleASM lib. O problema aqui reside numa possível troca de nomenclatura gerada pelo SO para os discos brutos. Caso aquele que era /dev/sdc se tornar /dev/sdd, teremos problemas com no startup do ASM. 3. Tendo um bom alinhamento com o storage Não adianta ter uma separação de diskgroup para Index e Data se, no storage, eles estão em um mesmo array (de disco ou controladora). Uma boa configuração arquitetônica do ASM é intrinsicamente dependente de como os discos estão distribuídos. Afinal, é lá que os blocos serão lidos e escritos. Assim, é de extrema importância conhecimentos básicos em storage e obrigatória a leitura da documentação funcional feito pelo fabricante. Resumindo: ASM = Gerenciador de Volumes + FileSystem 1.2 Arquitetura e Internals Componentes do ASM Antes de iniciarmos o estudo de alguns mecanismos de arquitetura é necessário entendimento da relação entre as estruturas de arquivos referente ao banco de dados Oracle e as estruturas do FileSystem ASM.

3 É denominado Oracle Database, todos os arquivos necessários para o funcionamento do banco de dados, exceto binário de instalação, esses arquivos são: Datafile Controlfile Redo Log File Archive Parameter File (spfile e/ou pfile) Imagem retirada da documentação oficial da oracle. É possível armazená-los em qualquer sistema de arquivo (homologado pela Oracle). Cada um tem sua característica e os arquivos acima citados, são hospedados sobre este em função dessas propriedades, que também podemos as definir como arquitetura de baixo nível do sistema de arquivo. No momento, discutiremos a hospedagem desses arquivos que compõem o Oracle Database sobre o ASM. Estes arquivos são armazenados sobre o ASM como um Oracle ASM File. Um ASM File pertence a um ASM Disk Group (DG), que por sua vez é uma coleção de discos oriundos do sistema operacional. O DG é considerado pelo FileSystem ASM como uma unidade de armazenamento. Trecho retirado da documentação oficial Oracle Database can store a data file as an Oracle ASM file in an Oracle ASM disk group, which is a collection of disks that Oracle ASM manages as a unit. Within a disk group, Oracle ASM exposes a file system interface for database files. Um DG, conforme dito anteriormente, é composto por 1 ou mais discos. O intuito desta estrutura é permitir o funcionamento do mecanismo de Stripe e Mirror, que nas documentações oficiais é citado como método SAME (veremos mais detalhes adiante).

4 É denominado Oracle ASM Disk, um disco oriundo do sistema operacional que faz (ou poderá fazer) parte de um ASM Disk Group. Os Oracle ASM Files residem nos discos em forma de pedaços uniformes, denominados Oracle ASM Extents (também conhecidos como ASM Extents Files ou simplesmente File Extents). Adiante veremos que essa estrutura ira orquestrar o mecanismo Stripe e Mirror. Por fim, temos a menor estrutura residente no FileSystem ASM o Oracle ASM Allocation Units (AU), que é uma unidade fundamental de alocação do ASM Diskgroup, ela irá compor um Oracle ASM. Assim: Oracle ASM Extents são pedaços uniformes que formam um Oracle ASM File e estão espalhados sobre todos os Oracle ASM Disk que fazem parte de um Oracle ASM Disk Group. A existência do Oracle ASM Extents permite o mecanismo de Stripe e Mirror. Imagem retirada da documentação oficial da oracle. Referência bibliográficas: Stripe e Mirror O ASM Diskgroup (DG) é um pool de armazenamento, ou unidade, ou ponto de montagem que contém uma coleção (1 ou mais) de discos do sistema operacional (exemplo: /dev/sdb). É a unidade de armazenamento do ASM.

5 No momento da criação é mandatório a escolha do tipo de redundância (Redundancy), que pode ser: EXTERNAL, NORMAL e HIGH. Estas opções controlam a quantidade de cópias que os ASM Files terão distribuído pelos discos. Na realidade, o ASM faz cópias das unidades que o compõem. Estas unidades são chamadas de Physical Extents, porém não são a mesma coisa que os extents do DB. Daqui para frente, quando falarmos em Extents estamos nos referindo ao ASM. Na criação do diskgroup define-se também as dimensões do allocation unit (AU), que se refere a espessura (uniforme) dos segmentos sobre os discos. Uma coleção de allocation unit (AU) forma o Extent, que por sua vez formará um ASM File. O valor default do AU é de 1MB e sendo escolhido este, os extents terão tamanho múltiplo de 1MB. Nas versões mais novas, o ASM faz uso de Extents formado por quantidades variáveis de AUs. Esta técnica é especialmente útil para ASM Files muito grandes. Nos primeiros extents, seu tamanho é igual ao AU. Nos próximos 20000, cada extent terá tamanho de 4*AU e a partir do será igual a 16*AU, para a 11gR2. Imagem retirada da documentação oficial da oracle. Uma outra entidade importante é o Virtual Extent, que são cópias fieis de um Physical Extend. Exatamente um espelho e por isso chamado de Mirror. A existência do Virtual Extent permite que ASM File seja capaz de se reconstruir em caso de perda de um dos Physical Extend. É importante frisar que se o tipo de redundância for EXTERNAL, o ASM não faz espelhos do Physical extent (acreditando que há redundância a nível de hardware) e, por isso, a perda de um disco neste tipo de redundância será irrecuperável. Obs.: Mesmo em redundância EXTERNAL o Virtual Extent existe, porém o Physical Extend é também um Virtual Extent, não existindo assim o Mirror.

6 Além das cópias, é possível que o ASM divida a carga (stripe) entre os discos em um DG, se houver mais de um disponível. Desta forma, um DG composto por dois discos terá aproximadamente metade dos extents em cada disco.

7 Stripe = Distribuição uniforme dos ASM Extent File entre os discos do Diskgroup. Mirror = Copia redundante dos ASM Extent File

8 Referência bibliográficas: ASM Process Segundo a Oracle, é denominado instance, um conjunto de estruturas de memória e processos de background a fim de gerenciar o banco de dados. Ha dois tipos de instance, são elas: Database Instance ou Instance RDBMS ASM Instance Uma ASM Instance é composta pelos seguintes componentes: 1. Processos background básicos Os mais relevantes são: Database writer (DBWn) Log writer (LGWR) Checkpoint (CKPT) System monitor (SMON) Process monitor (PMON) 2. Processos background específicos p/ ASM Instance Os mais relevantes são: ASM Background ou ASM Bridge (ASMB) ASM Rebalance Master (RBAL) ASM Rebalance (ARBn) 3. Estrutura de memoria SGA Os processos background da ASM Instance possui prefixo "asm_", já a database seu prefixo é "ora_", veja um exemplo:

9 ASM Instance: asm_pmon_+asm Database Instance: ora_pmon_orcl É importante ressaltar que alguns processos existentes na ASM Instance, também existem na Database Instance, contudo não necessariamente desempenham a mesma função. Analisaremos a seguir os principais processos background que orquestram o funcionamento do ASM. ASM Background ou ASM Bridge (ASMB) Instance onde atua: Somente na Database Instance, em caso de standalone Em ambas as instance, em caso de RAC Atividade de atuação: Comunicador (Ponte) entre ASM Instance (ASM) e Database Instance (RDBMS). Detalhes: O processo ASMB é atuante quando é necessário a interação entre ASM Instance (ASM) e Database Instance (RDBMS), com finalidade de gerenciar o armazenamento e fornecer estatística sobre a atividade realizada ou em realização, pode-se citar dois exemplos clássicos desta interação, são eles: 1. Execução do comando cp (copy) disparado sobre o prompt ASMCMD 2. Acesso ao SPFILE do Database Instance (RDBMS) quando o mesmo é armazenado no ASM. Esta interação se dá pela abertura de uma sessão na instance ASM, cujo responsável pela abertura é o processo background ASMB. Standalone RAC

10 ASM Rebalance Master (RBAL) Instance onde atua: Database Instance ASM Instance Atividade de atuação: Depende da instance em questão, veremos mais detalhes a seguir Detalhes: Em parágrafos anteriores foi ressaltado que alguns processos existentes na ASM Instance, também existem na Database, contudo não necessariamente desempenham a mesma função. Isso ocorre com o processo background RBAL, este não tem a mesma atividade de atuação na ASM instance e Database instance, ou seja, o processo backup "ora_rbal_sid" não exerce a mesma função do "asm_rbal_sid". Na ASM Instance o processo background RBAL desempenha uma função de coordenação da atividade de rebalanceamento quando um disco é adicionado ou dropado. Imediatamente após um disco ser adicionado ou deletado o processo é acionado para traçar um plano de rebalanceamento (movimentação dos ASM File Extents - Strip) com estimativa de tempo e custo de trabalho, este plano deve ser executado pelo também processo background ARBn. Na Database Instance o processo background RBAL é responsável por acessar o disco do diskgroup (acessar = Abertura e Fechamento - I/O), esta atividade não tem relação com a atividade do processo background RBAL da ASM Instance. ASM Rebalance (ARBn) Instance onde atua: ASM Instance

11 Atividade de atuação: Execução do plano de rebalanceamento traçado pelo RBAL da ASM Instance Detalhes: O ARBn é um processo "operário", sua função é simplesmente executar um plano de rebalanceamento que foi criado pelo RBAL da ASM Instance. ARBn sempre atua de forma reativa, ou seja, sua atuação depende de uma ação de adição, deleção ou perda de um disco no diskgroup com isso ele inicia uma movimentação dos ASM File Extents, entre os discos do diskgroup, baseando-se no plano de rebalanceamento traçado pelo RBAL da ASM Instance. Na ASM instance ARBn é dependente de RBAL. RBAL é responsável pela coordenação das atividades de ARBn. ARBn é um processo reativo a uma ação de adição, deleção ou perda de um disco no ASM diskgroup. Processo de rebalanceamento consiste nos seguintes passos 1. Ao adicionar ou remover um disco localizado em um diskgroup, uma trigger action de balanceamento de ASM Extent File é acionada. 2. Processo RBAL é acionado para criar um plano de rebalanceamento a ser executado e coordená-lo. 3. RBAL entrega um plano de rebalanceamento, com estimativa de tempo e custo de trabalho para ARBn executar as atividades. 4. Os metadados são atualizados para refletir uma atividade de rebalanceamento. 5. Cada ASM Extent File a ser realocado é atribuído a um processo ARBn. O ASM Extent File é lockado, movido (realocado de disco ou posição no disco) e deslockado pelo processo ARBn. ACFS - Oracle Automatic Storage Management Cluster File System ACFS é um cluster file system que usa a estrutura do ASM para gerar um volume montável no sistema operacional, ele amplia a arquitetura do Oracle ASM e pode ser usado para armazenar arquivos que normalmente são mantidos fora do ASM Diskgroup, como por exemplo, binário de aplicação de terceiros (SAP por exemplo), Oracle trace files, arquivos texto, entre outros. Arquitetura ACFS O Oracle ASM Diskgroup é a entidade que hospeda os Oracle ASM File, o ACFS nada mais é que um volume criado sobre o Oracle ASM Diskgroup, considerado um Oracle ASM File, cujo tipo é ASMVOL, ou seja, este volume para o sistema operacional será um device que, após formatado, pode ser montado e usado como um FileSystem visível e utilizável na camada de sistema operacional.

12 Imagem retirada do blog Idevelopment do ACE Jeffrey M. Hunter. Fornecendo uma camada de suporte para o sistema operacional, o ADVM é a base de sustentação entre o ASM Volume localizado no ASM Diskgroup e o ponto de montagem localizado no sistema operacional. Os volumes criados sobre um Diskgroup, também podem ser titulados como Dynamic Volume. Ao criar um Dynamic Volume (também chamado de ASM Volume) um device file (exemplo: /dev/asm/acfsvol3-301) é criado no sistema operacional.

13 Imagem retirada da documentação oficial da oracle. Em síntese, é correto afirmar: Gestão de volume shared FileSystem. Interface dos volumes com o sistema operacional. Drive via modulo em Kernel. Device files em /dev/asm/ representam os Dynamic Volume criados no Diskgroup e uma vez formatados é possível ser montados no SO. Imagem retirada da documentação oficial da oracle.

14 ACFS process oracle :22? 00:00:00 asm_vdbg_+asm1 oracle :22? 00:00:00 asm_vbg1_+asm1 oracle :22? 00:00:00 asm_vbg2_+asm1 oracle :22? 00:00:00 asm_vmb0_+asm1 oracle :22? 00:00:00 asm_acfs_+asm1 1. Volume Drive Background Process - VDBG Responsável por encaminhar as solicitações do ASM para o Drive ADVM, em caso de Lock ou Unlock de ASM Extent File durante operação de rebalanceamento ou operações de gestão do volume (Redimensionamento por exemplo). VDBG é um processo background vital do Clusterware, ou seja, ele é considerando um fatal background process, a morte acidental desde processo causara a queda da instance ASM. oracle :22? 00:00:00 asm_vdbg_+asm1 2. Volume Background Process - VBGn É um processo background que é representado por um pool de work process, usado para gerenciar de solicitações que dependem da relação drive ADVM x Instance ASM, podemos citar como exemplo a montagem e desmontagem do device file ACFS em /dev/asm/. oracle :22? 00:00:00 asm_vbg1_+asm1 oracle :22? 00:00:00 asm_vbg2_+asm1 3. Volume Membership Process VMBn VMBn implementa um mecanismos de I/O barrier (garantia de sincronismo de gravação em um determinando ponto da trajetória da operação de escrita) e I/O fencing (Método de prevenção contra corrupção de dados em ambiente clusterizados, consiste no isolamento do node que apresentou falha). Isso garante que o processo de instance recovery no ASM não é executado até que todas as operações de I/O oriundas do ADVM sejam completadas. oracle :22? 00:00:00 asm_vmb0_+asm1 4. ASM Cluster File System CSS Process ACFS ACFS é responsável por rastrear membros do cluster e informar o File System sobre eventuais. É um processo necessário para manter a integridade dentro do cluster. oracle :22? 00:00:00 asm_acfs_+asm1 Referência bibliográficas: How to Mount an ACFS FileSystem through NFS. [Doc ID ]

15 New Background Processes introduced by ACFS [Doc ID ] ACFS Technical Overview and Deployment Guide [ID ] shtml 2. Por que usar ASM? Nos momentos em que tenho oportunidade em fazer trocas de entendimentos com outros DBAs, percebo que alguns tem certa resistência ao ASM, assim como tive um dia, e os motivos são: a complexidade e o desconhecimento. Vejamos o caso do conceito de rebalanceamento, que parece ser simples. Não é raro ver alguém associando o balanceamento ao tipo de redundância do diskgroup. Há uma relação de dependência, mas, por exemplo, redundância EXTERNAL não implica não existir rebalanceamento. Tive oportunidades de acompanhar do zero implementações de storages (fisicamente e logicamente) e notei que o ASM tem certa peculiaridades em seus conceitos, tais como diskgroup, mirror, striping. Do lado storage, se tomarmos como base alguns disponíveis no mercado, é possível perceber que tais conceitos são tratados de forma nem sempre equivalente. Portanto, acredito que o ASM veio com o propósito de transparecer a relação entre os discos apresentados para o host e o Storage. E assim, fica evidente que o ASM tem grandes benefícios para o banco de dados Oracle. Principais vantagens quando usamos ASM: 1. Permite stripe dos dados sobre os discos contidos no Diskgroup. Nada mais que distribuir os dados entre os discos de um DG visando divisão de carga. 2. Permite a adição e remoção de discos em tempo de execução (Online), uma vez que o rebalanceamento (movimentação de dados afim de distribuir os blocos entre todos os discos pertencente ao diskgroup) é implícito nessas 2 operações. Imagine que você tenha um diskgroup com 2 discos e 300GB de dados cada e redundância EXTERNAL. Caso você adicione um novo disco ao DG, o ASM se encarrega de distribuir os 600GB entre os 3 discos, ficando agora com 200GB cada. Se você removesse um dos discos da nova configuração, o rebalanceamento novamente faria com que tivéssemos 300GB em cada disco. Veremos este exemplo a frente na migração por balanceamento. 3. Permite mirror em 2 níveis de redundância. Forma de manter seus dados espelhados em mais de um disco (caso a redundância não seja EXTERNAL). Vale enfatizar que o mirror do ASM não é a mesma coisa que o do RAID. O método SAME

16 Resumidamente é uma combinação de um mecanismo de distribuição linear de cargas entre os discos e um mecanismo de proteção das cargas por meio de técnica de espelhamento. (Stripe And Mirror Everywhere) A técnica de stripe consiste em um princípio de engenharia, denominada "distribuição linear de cargas". Quando exercidas forças sobre uma estrutura, nenhuma parte deveria sofrer mais que outra, em uma situação normal de trabalho. No ASM, a carga em questão são os Extents. Na prática, a técnica de stripe consiste na distribuição dos ASM Extent linearmente sobre todos os discos residentes no DG, com isso as operações de escrita e leitura (operação de I/O) não se concentram em um único ponto. A técnica de stripe é feito sobre um diskgroup, que possui uma coleção de discos (1 ou mais ASM Disk), exemplificando: O diskgroup +DATA é formado por N ASM Disk são eles /dev/xxxx, /dev/yyyy e /dev/zzzz, a unidade de medida allocation unit tem a espessura de 1MB (1MB é o default), a coleção de allocation unit (1 ou mais) forma ASM Extent Files, que estão distribuídos sobre os ASM disk do diskgroup, garantindo a técnica de stripe, que finalmente da vida a um ASM File +DATA/datafile/undo Com base nisso, pode-se concluir que as operações de I/O aplicado ao diskgroup, consiste no acesso a todos os discos, evitando possíveis stress sobre um ponto da estrutura. Imaginemos que uma operação de leitura ocorra sobre um disco para recuperação de blocos de um datafile e uma operação de escrita esteja ocorrendo neste mesmo disco, neste caso o throughput I/O será intenso sobre ele. O stripe evita essa situação, se os ASM Extent Files estão distribuídos, isso quer dizer que um ASM File está espalhado sobre todos os disco, e caso ocorra uma "leitura

17 full" de um datafile é necessário acessar todos os discos, o que evita uma força sobre um único ponto. O conceito de redundancy pode muitas vezes induzir DBAs pouco experientes ao erro. O problema é que muitos associam o ASM com RAID. A ideia é similar, porém o funcionamento e o entendimento são diferentes. Primeiramente, vamos entender o que é a redundancy para o ASM e tiraremos essa resposta no utilitário ASMCA. Redundancy is achieved by storing multiple copies of the data on different failure groups.

18 Traduzindo, a redundancy é obtida através do armazenamento de múltiplas cópias dos dados em diferentes failure groups. Agora, vamos explicar essa frase: Para existir em qualquer situação onde o conceito de redundância se faz presente é necessário uma "referência" que constrói o cenário de redundância (o que contingenciar), ou seja, é necessário 2 respostas para 2 perguntas: 1. O que será redundante? 2. O que espelhar para atingir o objetivo (a redundância)? Essa pergunta, deve ser respondia com base na frase retirada do asmca, "a redundancy é obtida através do armazenamento de múltiplas cópias dos dados em diferentes failure groups". O que será redundante? R: Os dados (ASM File Extent) O que espelhar para atingir o objetivo (a redundância)? R: Múltiplas cópias dos dados (mirror do ASM File Extent) Diferentemente do RAID, onde a referência que constrói o cenário de redundância é o disco, no ASM são os dados, ou seja a referência que constrói o cenário de redundância é o mirror dos ASM Extent Files, em outras palavras haverá um Physical extent file (original) e uma cópia para ser usado em caso de perda, denominada Virtual extent file. Com essa explicação é possível tirar uma conclusão: Se haver uma redundância é possível retirar fisicamente um disco da storage que pertence ao ASM. Desta forma, faz sentido pensar: Se neste disco existisse um Physical extent file, o Virtual extent file assumirá seu posto e o ambiente continuará disponível. Se existisse um Virtual extent file, o ambiente continuará disponível com o Physical Extent. Conforme citado anteriormente, as cópias redundantes, que titulamos de espelhos ou mirror servem para proteger o diskgroup caso uma perda ou falha de um disco aconteça. A referência do cenário de redundância no ASM é o mirroring dos ASM Extent Files, conforme abordado nos últimos parágrafos. Baseado nisso, a configuração de um diskgroup com tolerância a falha (Redundancy NORMAL ou HIGH) é feita com base no que chamamos de Failure Group (FG).

19 Os Fail Groups são pontos que compartilham um risco de falha. Pode ser um disco, uma controladora ou mesmo um storage. No caso mais simples, de redundância NORMAL, um diskgroup formado por dois discos, cada disco é um ponto sujeito a falha. Este conceito só é claramente entendido quando o DBA consegue ter um visibilidade clara da infra-estrutura. Sem isso, esse conceito pode ser aplicado de forma errada ou desnecessária, portanto a criação do Diskgroup deve ser casado e bem alinhado com a infra-estrutura dos discos apresentados para sua criação. Um exemplo de criação de diskgroup especificando os FailGroups: CREATE DISKGROUP data NORMAL REDUNDANCY FAILGROUP controller1 DISK '/devices/diska1' NAME diska1, '/devices/diska2' NAME diska2, '/devices/diska3' NAME diska3, '/devices/diska4' NAME diska4 FAILGROUP controller2 DISK '/devices/diskb1' NAME diskb1, '/devices/diskb2' NAME diskb2, '/devices/diskb3' NAME diskb3,

20 '/devices/diskb4' NAME diskb4 ATTRIBUTE 'au_size'='4m', 'compatible.asm' = '11.1', 'compatible.rdbms' = '11.1'; Quando o ASM Diskgroup é criado com redundância do tipo NORMAL isso significa que o ASM File está protegido contra falhas na camada ASM, de modo que os ASM file extents são espelhados em: Physical extents (copia original primaria) residentes no Failure Group controller1 e Virtual extent (copia redundante secundária) residentes no Failure Group controller2. Os Failure Group são os pontos de falha definidos e com isso o próprio ASM decide em que disco do Failure Group estará os Physical extents e Virutal extent, mas certamente estarão em Failure Group distintos. Mesmo que não se defina os Failure Group (FG), o ASM automaticamente os cria: 1 FG para cada disco. É importante sempre observar: 1. Cada disco em um DG pode pertencer a apenas um FG. 2. Failure Group (FG) devem ser do mesmo tamanho (independentemente do número de discos). Com tamanhos diferentes podem comprometer a disponibilidade. 3. ASM precisa de pelo menos 2 FG para um DG de redundância NORMAL e pelo menos 3 para HIGH. 4. Em cenários de RAC extended cluster, o uso do Failure Group (FG) é vital para o funcionamento da solução e uma configuração errada pode comprometer o ambiente. Este (Failure Group) define referência delimitadora entre Physical extent e Virutal extent. Segunda a Oracle, o Failure Group é um subconjunto dos discos de um diskgroup que, em caso

21 de falha não deve provocar a queda do diskgroup, ou seja, o diskgroup é tolerante quanto a uma possível perda deste subconjunto dos discos. Portanto, se tivermos uma Redundancy Normal com 2 Failure Group, denominados de A e B, o ASM decidirá em qual Failure Group o Physical extent estará, feito isso o Virtual extent estará no Failure Group oposto ao Physical extent. Physical extent no Failure Group A Virtual extent no Failure Group B Em caso de um Redundancy High é necessário 3 Failure Groups (A, B e C), tendo 2 copias espelhadas do Physical extent, ou seja, Virtual extent primário e Virtual extent secundário.

22 Physical extent no Failure Group A Virtual extent no Failure Group B Virtual extent no Failure Group C Resumindo a parte de Redundancy: Atualmente o Oracle ASM suporta 3 tipos de redundância External Neste tipo de redundância você assume que a redundância do seus dados está sendo feita de forma externa, ou seja, no storage. (RAID 1, 10...) Normal Neste tipo de redundância 1 cópia do file extent original (Physical extent) é mantida no Failure Group oposto ao que hospeda o file extent espelho (Virtual extent). Este tipo de redundância é para implementação de RAC Estendido (Oracle RAC on Extended Distance Clusters). O uso de CPU é mais intenso que o normal, devido ao trabalho de mirroring e striping. High

23 Neste tipo de redundância 2 copias do file extent original (Physical extent) é mantida em 3 Failure Group, 1 para o file extent original (Physical extent), 1 para o file extent mirror primário (Virutal extent primário) e 1 para o file extent mirror secundário (Virutal extent secundário) Referência bibliográficas: A9todo+SAME+asm&source=bl&ots=0iiPMfVi1O&sig=6VbydBy1eptvNFmqeR2EWecMjPc&hl =pt- BR&sa=X&ei=LbhNU9Q6ruOwBLSjgrAM&ved=0CC0Q6AEwAA#v=onepage&q=m%C3%A9t odo%20same%20asm&f=false Esses tópicos são encontramos de forma similar em outros blogs ou mesmo na documentação oficial, mas para entendermos plenamente cada um, vamos levá-lo para situações práticas. Abordagem 1) É melhor ter os datafiles residentes em 1 só disco ou tê-los segregados? Se os datafiles estão em um só disco, entraremos em um situação a qual o throughput de I/O (quantidade de dados processados em um determinado espaço de tempo) é mais intenso, ou seja, haverá muitos dados sendo escritos em um mesmo destino e também muitos sendo lidos em uma mesma origem. Escrita - Gravação de dados oriundo da memória principal Leitura - Transmissão de dados oriundo do disco para memoria principal Conclusão: Neste cenário, haverá uma intensidade de leitura e gravação concentrados em 1 único disco ou array de disco. Resultado: Gargalo do mecanismo de I/O Possíveis soluções: 1. Aumentar a quantidade de memória principal do host, reduzindo ou evitando algumas leituras físicas (Physical Reads - Acesso a disco e envio de blocos de dados para memoria) e as

24 convertendo para leituras lógicas (Logical Reads - Acesso ao buffer cache do Oracle). Com isso a demanda ou trabalho requisitado ao disco diminuirá, com relação a escrita, não teríamos ganho. 2. Aumentar a quantidade de cache memory da controladora do storage, se possível (alguns são engessados quanto a isso). Há storages que utilizam de métodos de assincronismo para gravação. O host conectado a ele envia uma requisição de escrita, dos blocos a serem armazenados, estes são enviados (transportado) até o cache memory da controladora. Neste ponto é feita a confirmação de recebimento e para o solicitante a escrita está concluída. Contudo, internamente no storage outro processo se inicia: o arquivamento desses blocos recebidos para discos propriamente dito, seja ele mecânico ou SSD. [A computação clássica define essa técnica como "assincronismo sobre múltiplas camadas"] 3. Em engenharia, a construção de uma estrutura, seja ela qual for é imprescindível a distribuição linear de cargas (nenhuma parte desta estrutura pode sofrer mais que a outra em uma situação normal de trabalho (força sobre a estrutura)), a aplicação deste princípio produz um equilíbrio geométrico da estrutura em questão. Trazendo essa realidade a estrutura do storage analisaremos a distribuição de cargas entre os discos e controladoras, ou seja, é possível fazer uma fragmentação da atividade de I/O entre os discos e as controladoras disponíveis. Na abordagem em questão, a distribuição linear de cargas é denominada striping, com isso o equilíbrio geométrico da estrutura ASM se faz presente, ou seja, os blocos contidos no diskgroup são distribuídos entre todos os discos residente nele. Esse cenário só é vantajoso, caso o número de disco visíveis no ASM Diskgroup corresponda fisicamente na storage como um disco propriamente dito, por exemplo: Disco /dev/sdb no unix seja um disco físico na storage e não uma partição avulsa de um disco físico.

25 Lembre-se, a atividade real de I/O está no storage e não no ASM, não adianta de nada o ASM ter 500 discos e no storage esses 500 disco visíveis, representar 1 disco com 500 partições, neste caso não haverá balanceamento. Resumindo: A atividade de striping deve ser bem alinha com a estrutura do storage.

26

27 O desenho mostra de forma genérica, uma possível estrutura ASM x Storage, no contexto é possível visualizar um diskgroup (+DATA) com uma coleção de 9 discos associados, veja que na camada do ASM, não é possível ter uma visibilidade clara da estrutura existente no storage (Local onde efetivamente vai ocorrer o I/O). Na camada de storage as LUNs foram distribuídas entre as controladoras existe (3 no caso), isso permite o stripe entre as LUNs (de 1 a 9) e o balanceamento de carga sobre as controladoras existentes no storage. Caso tivermos somente 1 controladora o risco de gargalo da "queue I/O" (fila de requisição de I/O da controladora) é grande, em sistemas do tipo I/O bound (sistemas com leitura e escrita intensa) a formação de "queue I/O" é natural, devido ao fato do disco sempre ser a parte mais lenta do sistema computacional, contudo é possível diminuir o tamanho da queue I/O, paralelizando o atendimento das requisições de I/O (como é feito nos caixa de supermercado), ou seja, distribuindo os discos apresentados para o ASM em diversas controladoras. No exemplo é possível atender 3 requisições de I/O ao mesmo tempo, é obvio que o acesso ao disco mecânico ou solido (SSD) é feito de forma serial (se 2 controladora requisitarem dados ao mesmo disco a recuperação é feita de forma sequencial, primeiro um depois o outro), contudo diversos mecanismos é beneficiado nesta arquitetura como por exemplo o uso de cache (se dados estiverem em cache não é necessário o acesso ao disco, neste cenário temos 3 áreas de cache) e escritas assíncronas. Vantagem destas implementação: Maior flexibilidade para em caso de reconfiguração ou manutenção do storage ou ASM. Eficiência na realocação dos ASM File Extent em caso de rebalanceamento do ASM Eliminação de tuning manual no storage em situação de lentidão. Abordagem 2) O ASM é uma poderosa ferramenta de transporte de dados entre estruturas físicas. Essa abordagem é pouco confusa: como um FileSystem pode ser uma ferramenta de transporte de dados? A explicação técnica é simples! A atividade de striping no ASM, nada mais é que a distribuição do total de blocos existentes no ASM Diskgroup sobre todos os discos, sob seu domínio, esse fenômeno é denominado balanceamento. Cenário: Diskgroup +DATA (disco 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 oriundo do storage A) 1. Vou adicionar 10 discos oriundos do storage B

28 2. O processo de balanceamento é implicitamente iniciado. Assim o total de blocos existente no Diskgroup, antes era dividido entre 10 discos oriundo do storage A, com a adição dos novos discos, os blocos existente no Diskgroup passa a ser distribuído entre 20 discos, onde 10 são oriundo do storage A e 10 oriundo do storage B. Agora temos: Diskgroup +DATA (Disco 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 oriundo do storage A) (Disco 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 oriundo do storage B) 3. Vou dropar 10 discos oriundos do storage A 4. O processo de balanceamento é implicitamente iniciado. Assim o total de blocos existente no Diskgroup, antes era dividido entre 20 discos oriundo do storage A e B, com a deleção dos 10 discos, os blocos existente no Diskgroup passa a ser distribuído entre 10 discos oriundo do storage B. 5. Dados migrados entre os storages O que ocorre na adição? Os dados e metadados do asm são distribuídos igualmente entre todos discos (incluindo o adicionado), ou seja, é feito um cálculo matemático baseado em algoritmos heurísticos para divisão dos blocos de dados e metadados, o objetivo é a equilíbrio na divisão dos blocos, agora com o novo disco pertencente ao diskgroup. O que ocorre na deleção? Os dados e metadados do ASM estão distribuídos igualmente entre todos os discos, ao fazer o drop de um disco, este não é eliminado instantaneamente, pois caso isso ocorra com certeza haverá perda de dados, a solução para isso é dividir o drop em 2 passos: 1. Rebalanceamento dos blocos de dados e metadados tendo em base a quantidade total de disco menos 1 disco (devido ao drop), por exemplo, os blocos divididos entre 20 discos, com a deleção de 1, devem agora ser divididos entre 19 discos. 2. Exclusão do disco marcado para ser dropado do ASM Diskgroup, após o rebalanceamento. Exemplo prático de migração por balanceamento

29 Em /proc/scsi/scsi é possível visualizar os devices atachados no host, existe 2 storages ligados no host, o destacado em vermelho é um storage "IET Virtual-Disk", já o verde é um "OPNFILER Virtual-Disk". Importante: No storage "IET Virtual-Disk" existe 2 LUNs apresentadas 01 e 02 No storage "OPNFILER Virtual-Disk" existe 1 LUN apresentada 00 No fdisk é possível verificar os devices já reconhecidos. Os discos ASM01 e ASM02 pertencem a storage "IET Virtual-Disk", já o disco STG_OPENFILER_ASM01 pertence a storage "OPNFILER Virtual-Disk.

30 Na instance no +ASM é possível ter uma visibilidade dos discos existentes e em qual estrutura de Diskgroup ele pertente. O disco /dev/oracleasm/disks/asm02 pertence a um diskgroup (não sabemos qual, pois não é possível saber nesta view), seu nome para o ASM é DATA_0001, já o disco /dev/oracleasm/disks/asm01 não pertence a nenhuma estrutura de diskgroup, ele está disponível para ser adicionado a qualquer estrutura de diskgroup. Nesta query é possível visualizar uma intersecção entre discos e diskgroup, por meio de um sql join entre v$asm_diskgroup x v$asm_disk No utilitário ASMCA é visível o diskgroup, cujo nome é DATA e está montado nos 2 nodes do RAC (MOUNTED 2 of 2)

31 No utilitário ASMCA vou adicionar o disco da storage "OPNFILER Virtual-Disk", o disco está localizado em /dev/oracleasm/disks/stg_openfiler_asm01, vou chama-lo de OPENFILER_DISK01, ele possui um tamanho de MB.

32

33 Após adicionado o processo de balanceamento é implicitamente iniciado com grau de potência definida no parâmetro asm_power_limit, que por default é 1, a escala é de 1 até 11. Pode-se aumentar o grau de potência do rebalanceamento, mas isso pode causar uma lentidão momentânea, devido à grande intensidade de I/O provocado por esta ação. Essa potência nada mais é que o número de processos background ARBn trabalhando em paralelo, sob supervisão do processo background RBAL (da instance ASM).

34 Ao terminar o balanceamento após a adição do disco OPENFILER_DISK01, vamos deletar o disco DATA_0001. Este processo consiste em 2 ações por parte do ASM, já citadas anteriormente: 1. Re-balanceamento dos blocos de dados e metadados devido ao drop. Ou seja, todos os blocos antes divididos entre 2 discos (1 da storage IET Virtual-Disk e 1 da storage OPNFILER Virtual- Disk), agora residirão em um único disco, cujo seu nome é STG_OPENFILER_ASM Exclusão do disco DATA_0001, que agora não mais pertencente ao ASM Diskgroup +DATA, após o re-balanceamento.

35 Assim temos os dados e metadados migrados de storages. Abordagem 3) Como usar o ASM em RAC estendido

36 A tecnologia de cluster database da Oracle, Real Applications Cluster ou RAC, possui 2 vertentes de implementação, são elas: Oracle Real Applications Cluster (RAC) : Single physical datacenter (Nodes em 1 DC) Oracle RAC on Extended Distance (Stretched) : Multiple physical datacenter (Nodes em múltiplos DC + 3rd Site) Abordaremos o uso do ASM em RAC estendido (Oracle RAC on Extended Distance). O mecanismo de stripe permite a distribuição dos ASM File Extent entre os storages residentes em cada site (physical datacenter) e o mecanismo de mirror permite o redundância dos ASM File Extents entre os storages residentes em cada site, o uso do Failure Group é extremamente vital e o ponto chave na implementação do RAC estendido. O grande segredo da implementação é a criação do(s) Diskgroup(s) usado(s) pelos arquivos de banco de dados, tais como: Datafile Controlfile Parameter File Redo Log Files

37 E a criação do diskgroup usado pelos arquivos de cluster: Votedisk OCR Como devem ser criados os diskgroups para os arquivos de banco de dados: Tipo de redundância NORMAL. 2 Failure Group, onde o Failure Group represente 1 storage de cada site. CREATE DISKGROUP DATA NORMAL REDUNDANCY FAILGROUP STORAGE_A1 DISK '/dev/asm_disk01_sitea' NAME diska1, '/dev/asm_disk02_sitea' NAME diska2, '/dev/asm_disk03_sitea' NAME diska3, '/dev/asm_disk04_sitea' NAME diska4 FAILGROUP STORAGE_B2 DISK '/dev/asm_disk01_siteb' NAME diskb1, '/dev/asm_disk02_siteb' NAME diskb2, '/dev/asm_disk03_siteb' NAME diskb3, '/dev/asm_disk04_siteb' NAME diskb4 ATTRIBUTE 'compatible.asm' = ' ';

38 Este comando é um exemplo para criar um DG para arquivos de banco de dados, no exemplo um diskgroup chamado DATA com redundância NORMAL que possui 2 FAILGROUP, que representa 2 storages (1 em cada site). Como deve ser criados os diskgroups para os arquivos de cluster: DG PARA VOTEDISK Tipo de redundância Normal. 2 Failure Group, onde o Failure Group represente 1 storage de cada site. 1 Quorum Failure Group para representar o 3rd site CREATE DISKGROUP VTDISK NORMAL REDUNDANCY FAILGROUP STORAGE_A1 DISK '/dev/asm_disk01_sitea' NAME Votedisk01 FAILGROUP STORAGE_B2 DISK '/dev/asm_disk01_siteb' NAME Votedisk02 QUORUM FAILGROUP 3rd_site DISK '/votedisk/quorum_disk.vtd' NAME QUORUM_DISK ATTRIBUTE 'compatible.asm' = ' ';

39 DG PARA OCR Tipo de redundância Normal. 2 Failure Group, onde o Failure Group represente 1 storage de cada site. CREATE DISKGROUP OCR NORMAL REDUNDANCY FAILGROUP STORAGE_A1 DISK '/dev/asm_disk01_sitea' NAME OCR01 FAILGROUP STORAGE_B2 DISK '/dev/asm_disk01_siteb' NAME OCR02 ATTRIBUTE 'compatible.asm' = ' ';

40 Referência bibliográficas: pdf Abordagem 4) Como migrar datafiles entre ASM - Filesystem e Filesystem - ASM Transporte de datafile em File System para ASM (File System to ASM) via RMAN

41 1. Criar uma tablespace de teste chamada FStoASM 2. Verificar status da tablespace e path do(s) datafile(es) correspondentes a ela 3. Alterar status tablespaces para OFFLINE 4. Executar copy datafile via RMAN 5. Alterar o path do datafile no controlfile

42 6. Alterar status tablespaces para ONLINE Transporte de datafile em ASM para File System (ASM to File System) via ASMCMD (11gR2 Somente) 1. Criar uma tablespace de teste chamada FStoASM 2. Alterar status tablespaces para OFFLINE 3. Verificar status da tablespace e path do(s) datafile(es) correspondentes a ela

43 4. Executar cp do datafile via ASMCMD 5. Alterar o path do datafile no controlfile 6. Alterar status tablespaces para ONLINE 7. Validação

44 Abordagem 5) Criando volume ACFS e ponto de montagem no SO 1. Verificando se módulos ADVM/ACFS está instalado no Kernel. 2. Executando o load do ADVM/ACFS. 3. Criando o volume ACFS sobre um diskgroup. alter diskgroup <NOME DO DISKGROUP> add volume <NOME DO VOLUME> size <TAMANHO EXPRESSO EM GIGABYTES USANDO G>; 4. Validando criação do volume ACFS.

45 5. Validando existência do disco criado no Linux. 6. Formatação do disco criado no Linux. 7. Montagem e validação