Policy Management | SQL From Hell.com

De que se trata o artigo:

Neste artigo veremos que com um planejamento orientado por algumas perguntas e checklist é possível adotar soluções com Policy Based-Management respondendo necessidades do cenário, de forma que esta não se torne uma “feature órfã”, por permitir melhorias e acompanhar a evolução e mudanças do cenário.

Para que serve:

O planejamento na adoção do Policy Based-Management permite adequar o cenário às normas organização e às boas práticas de disponibilidade, capacidade, continuidade e segurança.

Em que situação o tema útil:

Mesmo que o Policy Based-Management seja uma feature que demande de pouca complexidade, o seu planejamento permitirá melhor entendimento do cenário, de forma que soluções com esta feature atendam adequadamente contratos de SLA, as normas organização e boas práticas de disponibilidade, capacidade, continuidade e segurança, acompanhando até mesmo a evolução do cenário.

Introdução

O Policy Based-Management (PBM) é uma feature introduzida no SQL Server a partir da versão 2008, a qual permite os administradores de banco de dados obterem o controle dos seus ambientes com a aplicação de regras e padrões sobre uma ou várias instâncias do SQL Server, além da possibilidade de reutilizar estas regras e padrões em outros cenários e versões anteriores do SQL Server (2000/2005).

Mas antes de implementar qualquer solução com esta feature, é necessário planejamento e entendimento do cenário, no qual, respostas a perguntas simples “por que, o que, como” poderão ajudar numa adequada implementação desta feature, de forma que as soluções implementadas não venham proporcionar qualquer resultado positivo ao cenário.

Este artigo vem a oferecer um conjunto de boas práticas tanto para o planejamento e adoção do PBM, como para o desenvolvimento de soluções e monitoramento das mesmas, auxiliando a responder as perguntas “por que, o que, como” desta feature.

Para um melhor entendimento, os termos disponibilidade, capacidade, continuidade e segurança utilizados neste artigo seguem algumas releituras do ITIL (Information Technology Infrastructure Library, http://en.wikipedia.org/wiki/ITIL):

Disponibilidade	Disponibilidade é determinada pela confiabilidade, sustentabilidade, funcionalidade do serviço, desempenho e segurança. Normalmente calculada a partir da medição de transações de negócio geradas por um serviço de TI e a indisponibilidade deste serviço.
Capacidade	O máximo de rendimento que um serviço consegue fornecer. Pode ser calculado a partir de medição de um tamanho ou volume (disco), ou esforço de trabalho que o serviço se limita.
Continuidade	Avaliação dos riscos que podem impactar o serviço. Termo normalmente associado com manutenção.
Segurança	Garantia da confidencialidade, integridade e disponibilidade dos dados e informações.

Estes termos se traduzem como os objetivos da administração de banco de dados, assim como de qualquer serviço da área de TI.

No que se refere à estrutura deste artigo, ela se aproxima a algumas de práticas de resolução de problemas, como o PDCA (Plan-Do-Check-Act), adaptadas para adoção de novas soluções, onde o ciclo planejar, implementar e acompanhar (avaliar e analisar), necessitou somente de uma ênfase na estratégica por traz do planejamento, e na segurança, por questões específicas do PBM.

Por quê? Estratégia

As justificativas para adoção de qualquer feature têm que responder muitos porquês, que podem simplesmente evitar que seja implantada qualquer solução, mas respondendo estes porquês, será possível entender a importância desta feature.

Um das justificativas comuns para adoção do PBM é a importância de adequar o cenário às normas organização ou projeto e boas práticas de disponibilidade, capacidade, continuidade e segurança. Lembrando que todos os cenários existem normas, mesmo quando estas não estão documentadas, elas ainda se fazem presentes.

Também é possível encontrar a organização que se baseiam suas normas em contratos de SLA (Service Level Agreement ou Acordo de nível de serviço, http://en.wikipedia.org/wiki/Service_level_agreement), exigindo um mínimo de requisitos (disponibilidade, capacidade, continuidade e segurança) dos serviços prestados aos seus clientes, e por consequência, exigindo dos administradores de bancos de dados, o uso do PBM e outras ferramentas para monitorar várias instâncias do SQL Server e seus bancos de dados.

Quando a adoção do PBM não é justificada por normas, mudanças e problemas da organização, é interessante pensar se boas práticas de disponibilidade, capacidade, continuidade e segurança recomendadas pelo fornecedor, no caso a Microsoft, estão presentes nas normas do ambiente, pois uma simples adoção do PBM pode ser justificado por perguntas simples como:

O último backup é recente?
Existe espaço de disco para suficiente para os bancos de dados?

Ou até algumas perguntas um pouco mais complexas:

Existe alguma configuração que pode estar comprometendo com o desempenho ou segurança do banco de dados e do servidor? Pelo menos, tem certeza que não existe nenhum login configurado de forma a permitir uma senha fraca?
Existe alguma feature deprecated configurada? Para uma relação destas, é interessante acompanhar: http://msdn.microsoft.com/en-us/library/cc280407.aspx
Existe alguma stored procedures criadas por usuários cuja nomenclatura ofereça problemas de desempenho? Sim, isso pode ocorrer com stored procedures de nomenclatura sp_*, pois o SQL Server procurará stored procedures com esta nomenclatura primeiramente no banco de dados master e depois no banco de dados na qual elas são executadas, até mesmo podem surgir alguns erros inesperados ou algumas stored procedures não serem encontradas quando executadas.

Estas perguntas podem ajudar a identificar algumas boas práticas, mas se estas boas práticas ainda estão claras, é possível encontrar no site do TechNet e MSDN, uma série de boas práticas, sendo algumas genéricas (segurança, backup…) e outras para cenários específicos (virtualização, BI…), que podem ajudar a identificar quais são úteis para cada cenário. Sempre lembrando que as organizações podem adotar práticas que até mesmo violam ou ignoram as boas práticas e recomendações pelo fornecedor, no caso a Microsoft.

Boas práticas, TechNet:
http://technet.microsoft.com/en-us/sqlserver/bb671430.aspx

Boas práticas, MSDN:
http://msdn.microsoft.com/en-us/sqlserver/bb671432.aspx

Na pasta C:\Program Files\Microsoft SQL Server\110\Tools\Policies (em ambientes x64, C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Policies) existem uma série de arquivos XML que podem ser importados pelo PBM em forma de regras, com a finalidade de validar boas práticas para administração do SQL Server. Uma breve descrição de cada um destes arquivos é possível de ser encontrada no seguinte link:
http://msdn.microsoft.com/en-us/library/cc645723.aspx

O que? Planejamento

Ao se pensar no que será feito, é importante entender o que a feature pode oferecer e por outro lado, avaliar se não existe outra solução que responda de forma mais adequada as necessidades do cenário. Esta avaliação é importante, visto que uma feature como o Policy Based-Management ser passível de ser substituída por consultas, relatórios, jobs e triggers, outras ferramentas ou até mesmo solução de terceiros, mas o tempo, custo, flexibilidade e complexidade de desenvolver uma solução do “zero” ou adotar uma solução de terceiros são pontos a serem levados em consideração, já que muitos dos potenciais desta feature esta na praticidade de adotá-la.

Mas o que esta feature pode fazer? Basicamente, o PBM proporciona soluções de automatização com a finalidade de diminuir o tempo que o administrador de banco de dados deveria se dedicar à manutenção, que pode se estender às regras de configuração no nível de servidores até objetos do banco de dados, como tabelas e índices. O PBM oferece algumas soluções para gerenciar as regras implementadas pelo administrador de banco de dados, que ser monitoradas por meio de agendamento ou por demanda (executada pelo SQL Server Management Studio), gerar alertas ou até mesmo prevenir que as regras sejam violadas por algum usuário.

As regras do PBM são compostas por três estruturas básicas:

Target Types, estruturas que representam os tipos de objetos manipulados pelo PBM, exemplo: Tables, Views e Databases.
Management Facets, estruturas que representam grupos de propriedades de determinados Target Types, como por exemplo, Name, Table Options, Database Option e Surface Area, que são utilizadas para criar condições/filtros.
Condition ou Condições/Filtros, estruturas que representam expressões lógicas por meio das Facets, a fim de aplicar filtros e validações.

As possibilidades de criar regras no PBM não estão limitadas ás suas facets, visto que há a possibilidade de customizações com consultas T-SQL e WMI. Mas é importante levar em consideração que estas customizações demandam de bom senso dos envolvidos, para evitar que sejam desenvolvidas soluções muito complexas ou que interfiram na disponibilidade e segurança do servidor.

No blog oficial de PBM, é possível obter uma relação das facets e os target types que elas manipulam:
http://blogs.msdn.com/b/sqlpbm/archive/2008/05/24/facets.aspx

A partir do momento que se entende o potencial da feature, é possível definir um checklist para determinar a solução a ser desenvolvida:

Justificativa: Existem normas ou boas práticas a serem adotadas em relação à disponibilidade, capacidade, continuidade e segurança do SQL Server?
Extensão: Qual a extensão destas normas e boas práticas (Servidores, Instâncias, Bancos de dados, Tabelas…)?
Ferramenta: Existem facets que atendem estas normas ou boas práticas, ou será necessária customização (comandos T-SQL ou WMI)?
Alternativa: Se for necessária uma customização, não existe uma alternativa (uma feature já presente no SQL Server ou feature de terceiros) que não exija esta customização? A atenção a este ponto pode evitar arrependimentos futuros.
Correção: O que deverá ser feito quando for encontrada uma situação que entre em desacordo com as regras estabelecidas? Em um segundo passo, defina os responsáveis e o prazo para as ações corretivas.
Exceções: Existem exceções? Quais? Cuidado, estas exceções podem se tornar a regra, então se a norma deve ser obedecida, exceções devem ser as mínimas possíveis e bem definidas (por que ela existe e quais os critérios para identificá-la?).

Para entender melhor como responder este checklist, segue abaixo alguns exemplos:

Cenário A:

1. Justificativa	Existe uma norma do projeto Icaro, que determina que todos os objetos do banco de dados utilizem a nomenclatura CamelCase (http://en.wikipedia.org/wiki/CamelCase). Para que esta seja respeitada, os novos objetos somente serão criados obedecendo a nomenclatura CamelCase, e os objetos que ainda não obedecem esta nomenclatura serão identificados pelo PBM a fim de serem corrigidos.
2. Extensão	Todos os objetos do banco de dados
3. Ferramenta	Esta norma está relacionada às facet “Multipart Name” e “Name”, mas será necessário criar uma função para testar se esta nomenclatura é utilizada, para tratar esta norma.
4. Alternativa	É possível criar uma consulta sobre os objetos do banco de dados, mas ainda será necessário criar uma função para testar a nomenclatura e a consulta não permitirá a mesma praticidade do PBM de tratar este problema.
5. Correção	Os objetos que estiverem fora do padrão serão relatados à equipe de desenvolvimento para ajustes.
6. Exceções	Alguns objetos não estão no padrão estabelecido por serem de software de terceiros. Uma relação dos objetos que serão mantidos fora do padrão será armazenada em uma tabela do banco de dados, com a finalidade de desconsidera-las nas regras.

Cenário B:

1. Justificativa	Para que seja utilizada a solução de Log Shipping nos bancos de dados do cliente X, é necessário que os bancos de dados deste cliente estejam configurados como “Recovery Mode” diferente de “Simple”. Desta forma, o PBM será utilizado para identificar os bancos de dados que estejam configurados inadequadamente.
2. Extensão	Os bancos de dados das instâncias X\SQL2008 e X\SQL2008R2
3. Ferramenta	Esta definição esta associada à facet “Database”, propriedade “RecoveryMode”, não sendo necessária customização.
4. Alternativa	É possível criar manualmente esta validação, mas demandará mais tempo.
5. Correção	Encontrar um banco de dados fora do padrão, ajustar imediatamente o “RecoveryMode” para “Bulk-logged”.
6. Exceções	O banco de dados BRCEP é somente leitura e não precisará ser replicado. Uma relação dos objetos que serão mantidos fora do padrão será armazenada em uma tabela do banco de dados, com a finalidade de desconsidera-las nas regras.

Nos cenários apresentados, todos apresentam possibilidades simples de adotar o PBM, e uma das vantagens permitidas por esta feature, é capacidade reutilizar estas regras em outros ambientes quando se fizer necessário, visto que elas podem ser exportadas e importadas por meio de arquivos XML.

Como? Implementação

Na criação de qualquer estrutura no PBM, não pode deixar de lado questões de nomenclatura e uma boa descrição das condições e regras criadas. Cenários robustos podem favorecer até mesmo na criação de regras que validam a nomenclatura e a existência de descrição das regras e condições do PBM, assim como versionamento destas regras.

Infelizmente, não existe uma solução de versionamento nativa para o PBM, mas é possível utilizar SharePoint Server, Visual Studio Team Foundation Server ou outra solução de SVN para manter um histórico dos arquivos XML das regras desenvolvidas.

Quando se pensar nas regras além de uma boa nomenclatura e descrição, é recomendado que estas sejam devidamente categorizadas, para o entendimento do que estas regras estão monitorando (servidor, banco de dados, tabelas, usuários…), saber quem será responsável por estas regras e onde/quando elas são aplicadas (verificações periódicas ou em tempo real, servidores/bancos de dados de clientes, ambientes de produção, de homologação ou de desenvolvimento).

A tabela abaixo, obtida de forma resumida do blog oficial de PBM, é possível identificar as facets que podem ser utilizadas de forma preventiva (de forma a evitar que alguma ação que burle a regra seja executada) ou que sejam “logáveis” quando sofrem alterações:

Facets	Preventiva	Log
Application Role	X	X
Asymmetric Key	X	X
Database Option		X
Database Role	X	X
Endpoint	X	X
Login Options	X	X
Multipart Name	X	X
Resource Pool	X	X
Schema	X	X
Server Configuration		X
Stored Procedure	X	X
Surface Area		X
Table Options	X	X
User Defined Function	X	X
User Options	X	X
View Options	X	X
Workload Group	X	X

A partir dos cenários do tópico anterior e uma análise de como será implantado, é possível detalhar a implementação desta solução a partir de um checklist simples, como demonstrado abaixo:

Cenário A:

Categoria	ProjetoIcaro
Ambientes	Servidor de desenvolvimento
Regras	1: NomenclaraCamelCase1 2: NomenclaraCamelCase2
Descrição da regra	1: Validação preventiva da norma do projeto que determina que todos os objetos do banco de dados utilizem a nomenclatura CamelCase (http://en.wikipedia.org/wiki/CamelCase). 2: Validação periódica (1 vez por semana) da norma do projeto que determina que todos os objetos do banco de dados utilizem a nomenclatura CamelCase (http://en.wikipedia.org/wiki/CamelCase).
Responsáveis	Responsável pela criação e manutenção das regras: João da Silva, DBA da organização. Responsável por orientar as correções e informar exceções das regras: José da Silva, Analista do projeto.
Eventualidade	1: Verificação executada de forma preventiva, por meio da facet “Multipart Name”. 2: Verificação executada de forma periódica, por meio da facet “Name”.
Descrição da implementação	Criada a função dbo.ValidaCamelCase, que permite validar qualquer texto de acordo com a nomenclatura CamelCase. 1: Utilizada a facet Multipart Name, permite execução preventiva, mas possui uma abrangência limitada (Sequence, StoredProcedure, Synonym, Table, UserDefinedFunction, UserDefinedType, View, XmlSchemaCollection). 2: Criada para encontrar objetos fora do padrão já existentes e de forma mais abrangente. Utilizada a facet Name, não permite execução preventiva, mas possui uma abrangência maior que a facet Multipart Name (ApplicationRole, AsymmetricKey, Certificate, DatabaseRole, Default, Index, Rule, Schema, Sequence, SqlAssembly, StoredProcedure, SymmetricKey, Synonym, Table, Trigger, User, UserDefinedFunction, UserDefinedType, View, XmlSchemaCollection).

Cenário B:

Categoria	Manutencao
Ambientes	Servidor de produção
Regras	RequisitosLogShipping
Descrição da regra	Para que seja utilizada a solução de Log Shipping no SQL Server do cliente X, é necessário que os bancos de dados deste cliente estejam configurados como “Recovery Mode” diferente de “Simple”.
Responsáveis	Criação e manutenção das regras, e ajustes que no servidor: José Lins, DBA do cliente X.
Eventualidade	Verificação periódica (1 vez do dia).
Descrição da implementação	Utilizada a facet “Database Option’, para que se necessário seja adaptada para “logar” as alterações.

Segurança

Após a implementação do PBM, algumas questões de segurança devem ser analisadas, visto que com um usuário com acesso indevido para criar/modificar regras e condições do PBM, é possível desde adulterar e burlar regras ou até mesmo criar regras e condições nocivas ao ambiente, dada a possibilidade executar comandos T-SQL por meio do PBM.

Assim, não permita que usuários indevidos se tornem membros da Database Role PolicyAdministratorRole do banco de dados msdb (role que permite a criação e edição de regras e condições do PBM), ou que sejam dadas permissões/senhas indevidas aos logins do PBM (##MS_PolicyEventProcessingLogin##, ##MS_PolicyTsqlExecutionLogin##).

Caso seja necessário executar alguma consulta que o PBM não tenha permissão, dê somente as permissões que se fizerem necessárias ao login ##MS_PolicyTsqlExecutionLogin##, que é o responsável pela execução de consultas T-SQL do PBM.

Acompanhamento

Depois de implantado o PBM, adequadas as questões de segurança, criadas as soluções de regras e condições de acordo com o que foi planejado, estabeleça com os responsáveis pelo ambiente, uma agenda para avaliar os resultados obtidos e identificar/analisar melhorias. Para orientar esta agenda, busque responder algumas perguntas, como:

Esta solução realmente tem atendido adequadamente o que foi estabelecido e com o cenário atual? Caso não esteja atendendo adequadamente, verifique se a feature realmente respondeu as justificativas de sua implantação, pois o escopo da solução é facilmente esquecido com o tempo.
A implementação desta feature trouxe algum problema para o cenário? Tanto processualmente e tecnicamente, a implementação do PBM pode criar problemas, como a geração de conflito com a cultura da organização ou complexidade da solução criar gargalos de desempenho ou conflitos com outras soluções.
As regras e condições são seguidas corretamente? Caso não tenha sido acompanhado este ponto pelo responsável, é possível verificar pelo próprio PBM, alguma views ou até mesmo algumas ferramentas de terceiros (EPM Framework) se as regras e condições implementadas são seguidas corretamente e a evolução destas em determinado período. Se as regras e condições não são seguidas ou não houve correções no cenário, verifique se elas realmente estão de acordo com o cenário atual e se o processo de correção pode ser realizado de acordo com o planejado.
Existem exceções se tornado regra? Exceções, como informado anteriormente, podem se tornar a regra, então se a norma deve ser obedecida, exceções devem ser as mínimas possíveis.
Alguma melhoria para o cenário atual? Melhorias também devem responder as mesmas perguntas que definem a implantação da feature (“por que, o que, como”), pois adaptações mal planejadas podem tornar o cenário demasiadamente complexo em comparação ao retorno obtido e esperado, além de gerar problemas técnicos e/ou processuais em muitos casos.
Alguma melhoria para o cenário futuro? Ao se pensar no cenário futuro, esteja atento ás estratégias da organização ou projeto, pois a escalabilidade na área de TI tem tendências mais reativas do que proativas quando se trata de estratégia, desta forma, metas da organização devem estar ao lado de métricas e metas de TI. Exemplo disso, uma organização que planeja triplicar o número de clientes em um ano, precisa que sua infraestrutura esteva preparada a este mesmo crescimento, como, servidores suportando o triplo dos dados, backups e transações que os atuais.
Existe alguma solução ou mudança que possa justificar a substituição desta feature? Features também sofrem depreciação, como por exemplo, a feature utilizada na sua solução pode não estar presentes nas próximas versões do SQL Server ou podem surgir features que atendam de forma mais adequada o cenário. Procure deixar de lado um pouco do paternalismo para com as soluções que você e sua equipe implantou, para que se necessário sejam adotadas outras soluções que venha a substituir parcialmente ou completamente a feature atual.

Uma ferramenta muito útil para acompanhar a evolução do PBM é o EPM Framework, disponível gratuitamente no CodePlex (http://epmframework.codeplex.com), que permite relatórios bem úteis do dados históricos e correntes das regras do PBM:

Também é possível criar sua própria solução para acompanhar o PBM, utilizando as views do PBM (http://technet.microsoft.com/en-us/library/bb510742.aspx).

Em relação ao acompanhamento do PBM pela própria Microsoft, apesar de existir algumas sugestões de melhorias relacionadas a esta feature no Microsoft Connect, o CTP1 do SQL Server “Denali” (ou SQL Server 2011) não apresentou resposta a estas sugestões e também não foram divulgadas mudanças nesta feature. Mas pelo grande potencial desta feature, é até difícil pensar em melhorias que podem ser grandemente relevantes para futuras versões.

Conclusão

Este artigo tratou de permitir um entendimento de como por meio de um planejamento orientado por algumas perguntas e checklist, é possível adotar soluções com o a feature PBM, respondendo de forma adequada as necessidades do cenário, devidamente justificada, contando até mesmo com exceções e permitindo que a solução depois implantada não se torne uma feature órfã, por permitir melhorias e acompanhar a evolução e mudanças do cenário.

Com apoio de outras features nativas do SQL Server 2008+, como o Resource Governor e o Management Data Warehouse, é possível rapidamente aumentar o arsenal do administrador de banco de dados, oferecendo maior controle da disponibilidade dos recursos do SQL Server e relatórios para acompanhar da evolução dos cenários, tendo cada vez mais controle sobre o ambiente e recursos para entender como responder de forma adequada questões de disponibilidade, capacidade e continuidade dos cenários. Mas apesar da praticidade de adotar qualquer features, nunca deixe de lado o planejamento antes de adotá-las.