Share via


Microsoft SharePoint 2010: Simplifique o SharePoint com o RBS

Armazenamento BLOB remoto (RBS) pode melhorar o desempenho e a funcionalidade do SharePoint.

Iqbal Khan

Organizações de todos os tamanhos estão usando Microsoft SharePoint como um gerenciamento de documentos e sistema de repositório, entre outras coisas. Como resultado, SharePoint é armazenar um grande número de documentos, com números muitas vezes chegar em milhões.

No banco de dados do SQL Server, o SharePoint armazena todos estes documentos como objetos binários grandes (BLOBs). Como outros bancos de dados relacionais, SQL Server não foi projetado para armazenar BLOBs dessa magnitude. Como resultado, ela pode sufocar a vários níveis. Isso degrada o desempenho do SharePoint e torna doloroso a administração de banco de dados.

Para resolver este problema, a Microsoft introduziu um modelo de provedor de armazenamento de BLOB externo baseado em COM (EBS) no SharePoint 2007. EBS permite-lhe descarregar BLOBs para armazenamento externo e reduzir significativamente o tamanho do banco de dados. Isso resolveu o problema de tamanho do banco de dados, mas não tendo um nativo.NET provedor tinha sobrecarga de desempenho e não era uma "integração limpa" com o SharePoint. Assim, esta solução não era realmente considerada completa.

Em 2010 de SharePoint e SQL Server 2008 R2, a Microsoft lançou um nativo.Baseados na NET interface de armazenamento de BLOB remoto (RBS) como um substituto para o EBS. RBS também ajuda a reduzir o tamanho do banco de dados SharePoint 2010 grandemente. Ele faz isso ao descarregar todos os BLOBs de banco de dados de conteúdo do SharePoint em um armazenamento externo especificado pelo usuário. Stubs e metadados para estes BLOBs ainda são mantidos no banco de dados de conteúdo. Como resultado, SharePoint ainda acha estes BLOBs são parte do SharePoint e podem acessá-los da mesma maneira. Os usuários não sinto qualquer diferença porque todos os BLOBs ainda logicamente são parte do banco de dados de conteúdo.

Agora a Microsoft fornece uma implementação padrão chamada o Filestream do RBS. No entanto, isso é bastante básico e não fornece muita flexibilidade para os usuários do SharePoint graves. Embora ele descarregar BLOBs, ele não permite que você especificar filtros para quais BLOBs descarregar e quais manter no banco de dados. Você acaba transferindo todos os BLOBs, se você quer ou não. Além disso, ele não permite que você especifique um local de armazenamento remoto e armazena BLOBs somente em um armazenamento local na máquina do SQL Server. Ele também não tem administração ou ferramentas de monitoramento.

Se você é um usuário do SharePoint levemente grave, você muito mais controle e flexibilidade sobre o armazenamento e manipulação de BLOB. Há algumas implementações de terceiros bastante decentes de EDR que funciona perfeitamente bem e resolver problemas de tamanho de banco de dados do SharePoint. Você precisará Certifique-se de qualquer implementação de terceiros que você usar é 100 por cento nativo.NET e não uma manta de retalhos de Java e.NET, que pode causar problemas de compatibilidade.

Uma das vantagens do modelo de provedor de EDR é como ele abriu SharePoint para fornecedores adicionar mais recursos por meio de suas implementações de EDR. Alguém implementar um provedor de EDR tiver controle sobre onde os BLOBs são armazenados. Eles podem usar esse Controlarar para fornecer aos usuários do SharePoint mais características relacionadas com o BLOB para além de reduzir o tamanho do banco de dados e aumentando o desempenho. A este respeito, há quatro áreas principais de aprimoramentos do SharePoint:

  • Reduz os custos de armazenamento por meio de armazenamento BLOB em várias camadas
  • Arquivamento e retenção de BLOBs para fins de conformidade
  • Vinculação de bibliotecas de documentos não são do SharePoint para o SharePoint
  • Incorporando na memória cache de BLOB

Armazenamento em várias camadas

Um dos principais benefícios da RBS é a capacidade para armazenar BLOBs em vários níveis de armazenamento em vez de todos em um único local. Isso ajuda a reduzir significativamente os custos de armazenamento. Sem RBS, todos os BLOBs são mantidos no banco de dados do SQL Server. Mesmo RBS Filestream usa o SQL Server para armazenamento BLOB. Esse único ponto de armazenamento geralmente é algo bastante caro, tal como um disco de SAN/NAS.

BLOBs normalmente compõem cerca de 90 por cento de todos os dados no SharePoint, e você não precisa de freqüente acesso a todos eles. Assim quando todos os BLOBs são armazenados em uma matriz de disco de SAN/NAS cara apesar de apenas exigindo referenciando pouco frequente, você acaba gastando muito em armazenamento que é usado de forma ineficiente.

Uma estratégia mais razoável seria armazenar apenas os documentos novos e ativos (BLOBs) em armazenamento dispendioso porque os usuários precisam acessar aqueles mais frequentemente e rapidamente. Você pode armazenar o resto das gotas mais velhos e menos freqüentemente usados em níveis de armazenamento mais baratos. Isso significa que você não precisa de grandes quantidades de armazenamento dispendioso. Você pode reduzir sua capacidade de armazenamento caro e usar armazenamento menos dispendioso para lidar com o resto dos encargos de armazenamento.

Um exemplo de armazenamento em várias camadas é onde você tem novos active documentos armazenados em um disco de SAN caro. Então você tem um servidor de arquivo normal como o armazenamento de nível e nuvem segundo para a terceira divisão. SAN é o mais rápido e mais caro. Nuvem é o mais lento e o mais barato e um servidor de arquivos está em algum lugar in-between. Como resultado, você já reduziu seu custo total de armazenamento. Agora tanto quanto 80% a 85% de seus BLOBs já não é mantida em armazenamento SAN caro. Você não precisa de freqüente acesso e, portanto, não precisa de armazenamento de alta disponibilidade, alto desempenho, como SAN.

Agora que você tem armazenamento em várias camadas, a próxima pergunta é como determinar quais BLOBs para armazenar em quais níveis de armazenamento. Você pode determinar isso em vários pontos com base em critérios inteligentes. Determinar um BLOB do local quando ele é primeiro criado (ou, da mesma forma, quando ele primeiro é descarregado do banco de dados SQL Server). Em seguida, você verificar periodicamente e determinar como tornou-se velho um BLOB e freqüência de uso.

Isto é onde alguns provedores RBS lhe dão a opção de filtros BLOB. Geralmente há um ou mais filtros BLOB associados com um nível de armazenamento. Eles indicam que apenas BLOBs esses filtros correspondentes devem ser armazenados em um nível de armazenamento específico. Todos os outros BLOBs devem ser avaliados em relação a outros níveis de armazenamento e armazenados onde o BLOB correspondente filtros de correspondência.

Se um BLOB não coincidir com filtros BLOB de qualquer nível de armazenamento, você pode armazená-lo na base de dados de conteúdo do SQL Server. Filtros de BLOB normalmente incluem o nome do documento, tamanho, idade, autor e tipo de mesmo conteúdo. Você pode basear esses filtros em meta-tags personalizadas que você adicionou ou no tipo de arquivo (como autores, artista, álbum e assim por diante).

Alguns provedores RBS permitem que você alterar os filtros no armazenamento BLOB existente. Eles automaticamente vão reajustar os BLOBs e movê-los de um nível de armazenamento para outro com base em novos filtros BLOB. Outros provedores RBS somente avaliam filtros BLOB no momento da criação.

Para verificação periódica, alguns provedores de RBS usam idade-, baseada em versão ou uso de arquivamento. Uma tarefa de SharePoint é executado em segundo plano e inspeciona todos os BLOBs para idade, versão e uso padrão. Embora idade e versão informações são mantidas dentro do banco de dados de conteúdo do SharePoint, informações de uso padrão são mantidas pelo provedor de EDR em tabelas separadas ou em um banco de dados.

Se mais velhos BLOB ou qualquer documento de repente se torna popular e requer acesso mais freqüente, alguns (não todos) destes RBS provedores moverá automaticamente o BLOB volta para armazenamento mais caro, com base no uso. Dessa forma, você não vai perder nada no desempenho. Quanto mais caro o armazenamento é, quanto mais rápido o tempo de resposta. Geralmente, menos caro o armazenamento é, mais lento o tempo de resposta.

Arquivamento de BLOBs

Outro fator importante é a capacidade de arquivar e reter certos documentos e BLOBs em um arquivo separado para um período predeterminado e, em seguida, tê-los automaticamente excluídos do SharePoint.

BLOBs de arquivamento para fins de conformidade assegura que estão não acidentalmente excluídos do SharePoint por qualquer usuário. Muitos provedores de EDR não tem retenção BLOB. Eles usam "arquivo" para significar movendo BLOBs de nível de um armazenamento para outro. Mas alguns provedores RBS possuem recursos de retenção BLOB.

Em muitas situações, você terá documentos você deve preservar para um período especificado de tempo quer para legal ou motivos de conformidade de política da empresa. Por exemplo, muitas indústrias preservam acordos e contratos para um período de cinco anos. Esse cumprimento é popular no financeiras, seguros e outras indústrias similares. Isso poderia, no entanto, aplicável para quase qualquer empresa.

Nessas situações de conformidade, você deve ter uma maneira de manter uma cópia do documento separadamente. Dessa forma, mesmo se ele é excluído do SharePoint, você pode restaurá-lo do arquivo de retenção. Mesmo se um usuário tentar excluir esse documento, você tem uma cópia preservada da mesma para um número de anos por razões de política de empresa ou conformidade legal.

Pode haver outras razões de conformidade que requerem determinados documentos serem excluídos automaticamente após um certo período de tempo. Por exemplo, pode haver informações financeiras que você não deseja manter por razões legais. Esses documentos podem ser excluídos automaticamente com base nas regras existentes.

Qualquer provedor de EDR que você dá retenção arquivamento permite especificar armazenamento, que é um arquivo principalmente para a retenção de documentos distintos. Este arquivo está off-line para todas as operações regulares do SharePoint. No entanto, não é realmente off-line, mas sim protegidos contra acesso regular. Só você, como administrador do SharePoint pode acessar um arquivo de retenção.

Agora, você não quer colocar todos os seus documentos do SharePoint em um arquivamento de retenção. É por isso que um bom provedor de EDR deve dar-lhe a capacidade de especificar filtros para quais documentos deseja colocar em arquivo morto de retenção. Esses filtros poderiam basear-se no nome do documento, extensão de documento, documento tamanho, tipo de conteúdo, propriedade de usuário e mais. A idéia é proporcionar o controle real sobre especificando quais os documentos que você deseja arquivar.

Bibliotecas de documentos não - SharePoint

Bibliotecas de documentos do SharePoint não pode ser praticamente qualquer variedade — de um compartilhamento de arquivo simples para outros sistemas de gerenciamento de documentos. Você pode vincular com eficiência esses documentos no SharePoint. O rastreador do SharePoint indexa-los, permitindo que você e outros usuários de SharePoint Pesquisar, localizar, abrir, ler e editar qualquer documento.

Normalmente, esse recurso não existe no SharePoint. Por ter um provedor de EDR, você imediatamente tem esse recurso Turbo onde você pode usar o SharePoint para compartilhar e acessar os documentos que não são documentos do SharePoint.

Na maioria das médias e grandes empresas, o SharePoint não é o único sistema de gerenciamento de documentos. Mesmo que alguns departamentos ou divisões mover para o SharePoint, toda a gente não vai mover uma vez. Você vai ter uma situação onde há documentos em vários outros sistemas de gerenciamento de documentos, e os proprietários desses sistemas de gerenciamento de documentos não estão ainda prontos para mover tudo para SharePoint.

Os usuários do SharePoint adoraria ser capaz de acessar esses documentos no SharePoint. A alternativa é ter os usuários de SharePoint fazer logon separadamente cada sistema de gerenciamento de documentos, os documentos da pesquisa, abri-los para editar e independentemente verificá-los e sair.  Isso é altamente inconveniente, para dizer o mínimo.

Uma maneira mais conveniente é ter tudo acessível a partir de dentro do SharePoint. Mesmo se os documentos são pertencentes a outro sistema de gerenciamento de documentos, você pode acessá-los com o SharePoint. Provedores de RBS executam esta operação enganando SharePoint em pensar que estas externas ou bibliotecas de documentos do SharePoint não são parte do SharePoint.

RBS provedores permitem que você especifique os locais dessas bibliotecas de documento externo. Então iterar esses documentos e criar metadados para cada documento no SharePoint. Provedores de RBS faça SharePoint acho que estas são documentos do SharePoint, mas o documento real do BLOB é armazenado no armazenamento exterior.

Quando o rastreador do SharePoint indexa todos os documentos com base em palavras-chave, encontra também estes documentos como documentos do SharePoint normais (no que respeita o metadados). É por isso que o rastreador pode indexá-los como todos os outros documentos do SharePoint.

Quando os usuários do SharePoint pesquisarem dentro do SharePoint, eles encontram estes documentos também. Os usuários do SharePoint podem abrir os documentos para a leitura ou a edição e, em seguida, podem verificá-los novamente. O que eles não percebem é que quando eles o check in novamente, o documento atualizado é armazenado para o local original — dessas bibliotecas de documento externo ou não são do SharePoint.

As alterações também estão disponíveis para outros sistemas de gerenciamento de documento porque o provedor de EDR salvas essas alterações no local de origem. Ele é capaz de fazer isso porque o provedor de EDR mantém informações extras ao redor para todos os documentos não são do SharePoint para que ele sabe o que fazer com eles. Essas bibliotecas de documentos podem ser um compartilhamento de arquivo, um banco de dados ou qualquer armazenamento personalizado.

Um bom provedor de EDR permite que você implementar armazenamento personalizado conectável para estes documentos não são do SharePoint. Se você já tem um sistema de gerenciamento de documento personalizado que armazena todos os documentos em um banco de dados Oracle e você sabe o esquema de banco de dados, você pode implementar um personalizado plug-in para este armazenamento externo.

Implementar um personalizado plug-in geralmente envolve escrever alguns.NET código e registrar seu.NET assembly com servidores do SharePoint Web front-end (WFE). Este plug-in dá SharePoint a capacidade para iterar armazenamento, check-out e check-in de documentos e buscar documentos para leitura.

Na memória cache de BLOB

Provedores de RBS podem também incorporar na memória cache de BLOB. Sempre que BLOBs são obtidos a partir do banco de dados de conteúdo, banco de dados SQL Server ou armazenamento BLOB externo mesmo, eles estão armazenados em cache no servidor WFE em cache na memória. Na próxima vez que um usuário quer o mesmo documento, ele pode buscá-lo este cache na memória. Isso é muitas vezes mais rápido do que ir para o armazenamento BLOB. O cache é feito possível pelos provedores de EDR que estão controlando os BLOBs.

Uma vez que você tem na memória cache obturador em, você pode armazenar em cache BLOBs, listas do SharePoint e ViewState, assim como o ASP.NET estado da sessão que, por vezes, o SharePoint usa. Cache de listas e BLOBs significativamente aumenta seu tempo de resposta porque o SharePoint já não está a fazer estas viagens de armazenamento de banco de dados ou dados caras. Cache de ViewState reduz a carga retornada por servidores WFE a seu navegador. Isso reduz o consumo de largura de banda e também melhora o tempo de resposta do SharePoint — especialmente se os usuários estiverem acessando o SharePoint na WAN. Cache de sessão de estado permite que você replique Estados de sessão e evitar perda de dados, além de melhorar o desempenho e a escalabilidade.

Armazenamento em cache também melhora a escalabilidade. Com o cache, como você adiciona mais usuários, desempenho continua a ser elevado. Que não é o caso contrário. O SharePoint é um aplicativo de banco de dados intensivos. Ele faz muitas viagens de banco de dados que à medida que aumentar o número de usuários, aumenta a carga do banco de dados.

O SharePoint é uma plataforma extremamente valiosa. Ele não é perfeito, mas está certamente aberto a melhoria. RBS foi originalmente concebido apenas para ajudar a reduzir o tamanho do banco de dados e melhorar o desempenho do SharePoint. No entanto, ele abriu as portas para um monte de inovação.

Iqbal Khan

**Iqbal Khan**é o Presidente e tecnologia divulgador da Alachisoft (alachisoft.com). Alachisoft fornece NCachePoint e NCache. NCachePoint é produto de escalabilidade e desempenho do SharePoint líder do setor, e o NCache é um popular.NET distribuídos cache. Você pode alcançar Khan no iqbal@alachisoft.com.

Conteúdo relacionado