El equipo de producto finalmente ha dado a conocer el anuncio, ya es soportado SQL Server 2008 para SharePoint (considerando la aplicación del SP1) RTM announcement of SQL Server 2008.
Pueden ver el detalle Aquí.
Hace unos días tuve que diseñar una arquitectura redundante para un cliente. Revisando si había nueva información al respecto me tope con información en technet, donde se habla de redundancia (disponibilidad) y performance.
Es muy importante definir con el clienre cual o cuáles son sus prioiridades al momento de definir el alcance y objetivo de dicho diseño. El artículo que les recomiendo a continuación maneja de una forma muy sencilla estos conceptos y nos da recomendaciones de como podemos configurar los distintos roles de sharePoint según el hardware con el que se cuente.
A continuación comparto los temas que trata el artículo.
In this article:
About redundancy
Define server redundancy requirements
Plan for a limited server deployment
Plan for a minimum level of server redundancy
Choosing a baseline server farm topology
Plan Web server redundancy
Plan application server redundancy
Plan database server redundancy
Evaluating the risks of application server failures
Select a baseline topology
El artículo empieza explicando los conceptos básicos de redundancia y performance, y comienza a dar recomendaciones empezando con una topología mínima, recomendando por small server farm, y de ahí hacia delante.
Otro punto importante en esta definición fue que el cliente comprendiera de los distintos roles que maneja SharePoint cuales si puede configurarse de forma redundante y cuales no.
Por último y me parece muy valioso, tenemos la información de que pasaría si perdemos temporalmente cada uno de los distintos roles que manejamos con SharePoint y cuál sería el impacto.
Existen también otros whitepapers muy interesantes para planeación de storage por ejemplo en SQL para SharePoint e incluso recomendaciones para SQL Server especialmente para tener un mejor performance para las bases de SharePoint. No olvidemos la información también para recuperación de desastres o distintos escenarios para configurar un ambiente de alta disponibilidad en el backend (Mirroring o Log Shipping), estos son algunos de los whitepapers que también hablan de recomendaciones y mejores prácticas que no debemos de dejar pasar, aunque hay mucha información adicional que también vale la pena tener en cuenta.
Update 18 Agosto, 2008
Otro punto sumamente importante cuando estamos pensando en planear la disponibilidad y/o redundancia requerida para que nuestro ambiente de SharePoint siempre esté arriba . Pero que pasa cuando algo imprevisto sucede y perdemos el acceso o disponibilidad a nuestro contenido, siempre es importante considerar formas, escenarios, posibles maneras o estrategias de recuperar nuestra información. Preguntas tan importantes y necesarias, como ¿Cómo puedo respaldar la información de SharePoint?, ¿Cómo puedo respaldar o generar backups de la información que tengo almacenada en SharePoint? y no solo respaldarla sino restaurarla, ¿Cómo puedo recuperar la información que tengo en SharePoint?, de listas de bibliotecas de documentos, de sites, o sub sites, de site Collections, de bases de datos o a nivel Web Applications, incluso de toda la granja...y de otras variaciones, como ¿Cómo puedo recuperar la información almacenada en Mis Sitios personales o como puedo recuperar Mis Sitios personales?, o ¿Cómo puedo respaldar la información y configuración de mi Shared Servics Provider o Proveedor de Servicios Compartidos?, incluso ¿Qué puedo o como puedo respaldar o guardar lo disponible de mis forms de InfoPath?, Incluso ¿Cómo respaldar la configuración del Single Sign-On?, estas y otras preguntas interesantes pueden ser respondidas en el Resource Center de TechNet para SharePoint 2007, enfocado a BackUp (Respaldos), Restore (Restauración), y planeación de Disponibilidad (Availability), justo aquí.
Referencia del sitio de technet:
http://technet.microsoft.com/en-us/library/cc263467.aspx
Para cuando sea necesario...
Infrastructure Update (KB951695 & KB951297)
12.0.0.6318
Post-SP1 hotfix (KB953137 & KB953138)
12.0.0.6316.500
Post-SP1 hotfix (KB952698 & KB952704)
12.0.0.6315
Post-SP1 hotfix (KB948945)
12.0.0.6303
Post-SP1 hotfix (KB941274)
12.0.0.6301
Post-SP1 hotfix (KB941422)
12.0.0.6300
12.0.0.6219
12.0.0.4518
Referencia:
http://blogs.msdn.com/aaronsaikovski/archive/2008/07/31/quick-field-reference-moss-2007-wss-v3-0-version-guide.aspx
Determinación del enfoque de actualización (Office SharePoint Server)
En este artículo:
Elección de un enfoque de actualización
Casos especiales
Antes de ejecutar cualquier proceso de actualización, debe determinar qué enfoque de actualización va a tomar. Use la información de este artículo para comparar las ventajas y los inconvenientes de cada enfoque y revise la información acerca de casos especiales que pueden afectar al enfoque elegido. Además de la información de este artículo, asegúrese de leer Revisión de rutas de actualización admitidas y no admitidas para entender exactamente qué situaciones de actualización son válidas y tienen resultados correctos.
En la tabla siguiente se muestran y comparan distintos enfoques de actualización.
Actualización inmediata (In-Place Update)
Actualiza el esquema de las bases de datos de contenido ahí mismo sin hacer copias ni replicas de una nueva versión.
Enfoque más sencillo. Los sitios conservan las direcciones URL originales. Actualiza las bases de datos utilizando las rutas y hardware actual.
El entorno está sin conexión mientras se ejecuta, ya que todos los sites se van actualizando uno por uno sin necesidad de especificar el proceso manual o seleccionar cual se desea actualizar. No es posible revertir al sitio original. (No Rollback)
Servidor único o granja de servidores pequeña.
Actualización gradual (Gradual Update)
Instala la nueva versión en paralelo con la versión anterior (en el mismo servidor). El administrador del servidor determina qué colecciones de sitios se actualizarán y cuándo se actualizarán.
Permite usar un enfoque más granular: se actualiza a nivel colección de sitio. Reduce el tiempo durante el que se ve afectado cualquier usuario individual. Ya que se puede seleccionar por site collection individual cual se desea migrar y mientras los demás site collections estarán disponibles para los usuarios. Los sitios nuevos o migrados a la nueva versión automáticamente tomarán la ruta original, y los sitios originales (versión anterior) tomarán una nueva ruta especificada por el administrador durante la migración.Se puede revertir por lo tanto al sitio original. Usa el hardware existente.
Es un método más complejo y usa más recursos. Debe redirigir direcciones URL durante el proceso de actualización, lo cual provoca problemas en el caso de algunas aplicaciones cliente como Microsoft Office. Requiere almacenamiento adicional en SQL Server. No se admite el modo de hospedaje escalable de Microsoft Windows SharePoint Services 2.0.
Granjas de servidores medianas o grandes (sin servicios compartidos) con muchos sitios para las que debe limitar el tiempo de inactividad. Conveniente cuando el entorno tiene numerosas personalizaciones.
Migración de bases de datos (avanzada)
Requiere que el administrador del servidor instale la nueva versión en una granja de servidores separada o en hardware separado y que después migre manualmente las bases de datos (de contenido de las Aplicaciones Web) al nuevo entorno.
Permite la migración a una nueva granja de servidores o nuevo hardware. El entorno de SharePoint Portal Server 2003 está disponible y queda intacto tras la actualización.
Proceso complejo que requiere muchos pasos manuales y conlleva un mayor riesgo de errores. Requiere pasos manuales adicionales para conservar las direcciones URL originales de los sitios. Se deben volver a crear los ámbitos de búsqueda y se debe volver a aplicar la configuración de búsqueda. Requiere una nueva granja de servidores y el doble de espacio de almacenamiento en SQL Server.
Quienes van a pasar a un nuevo hardware o una nueva arquitectura. Quienes necesitan maximizar el rendimiento de la actualización. Este enfoque es necesario para entornos con Windows SharePoint Services 2.0 que usan el modo de hospedaje escalable o el modo de creación de cuentas del servicio de directorio de Active Directory.
Migración de Windows SharePoint Services 2.0 a Microsoft Office SharePoint Server 2007.
Actualización gradual para servicios compartidos
Igual que la actualización gradual, pero con pasos de actualización separados para actualizar sitios de portal primarios y secundarios.
Igual que la actualización gradual, pero podrá actualizar sitios de portal primarios y secundarios de forma individual.
Igual que la actualización gradual, pero además: dos rastreos de búsqueda están activos en el mismo momento para los entornos de Microsoft Office SharePoint Portal Server 2003 y Office SharePoint Server 2007.
Granja de servidores de cualquier tamaño con servicios compartidos.
Enfoque híbrido (avanzado) de actualización gradual más migración de bases de datos
Use un enfoque de actualización gradual para crear un proyecto piloto del proceso de actualización con varias colecciones de sitios y determinar si hay algún problema que necesita resolverse. A continuación, cuando esté seguro de que la actualización se está llevando a cabo sin problemas, use la migración de bases de datos en una copia de las bases de datos para acelerar el proceso de actualización.
Más rápido que usar sólo la actualización gradual.
Le permite probar el proceso de actualización con unos pocos sitios en la actualización gradual, con la opción de revertir los sitios si es necesario.
Sin reversión para la migración de bases de datos, de modo que debe tener una copia de seguridad de las bases de datos originales o realizar la migración en copias de las bases de datos.
Quienes necesitan maximizar el rendimiento de la actualización.
Para obtener más información acerca del funcionamiento de las actualizaciones inmediata y gradual, consulte Funcionamiento del proceso de actualización (Office SharePoint Server).
Es posible que tenga otros requisitos u objetivos adicionales que desea lograr al realizar la actualización. En la siguiente tabla se incluyen casos especiales y se indica qué enfoque de actualización resulta más apropiado para cada caso.
¿Va a cambiar el idioma?
Tiene dos opciones, dependiendo de si va a cambiar de idioma un único sitio o todo el entorno:
Para cambiar el idioma de un sitio específico, realice la actualización en el mismo idioma y luego instale el nuevo paquete de idioma y cambie a ese idioma.
Debe tener los paquetes de idioma adecuados instalados para actualizar cualquier sitio basado en una definición del sitio localizada. Si no tiene el nuevo paquete de idioma, no se podrá tener acceso a los sitios. Espere a que se publiquen los nuevos paquetes de idioma antes de intentar actualizar estos sitios.
Para cambiar el idioma de instalación de los servidores, use el enfoque de migración de bases de datos para migrar los datos desde la versión y el idioma anteriores a la versión y el idioma nuevos.
¿Va a pasar a Windows Server® 2008?
Primero actualice a Office SharePoint Server 2007 mediante una actualización inmediata o gradual y, a continuación, actualice a Windows Server 2008.
¿Va a actualizar desde SharePoint Portal Server 2001?
Actualice a SharePoint Portal Server 2003 y luego actualice a Office SharePoint Server 2007. Para obtener más información acerca de la migración de SharePoint Portal Server 2001 a SharePoint Portal Server 2003, consulte Recursos de migración a SharePoint Portal Server 2003 (http://office.microsoft.com/es-es/sharepointserver/default.aspx). La actualización directa desde SharePoint Portal Server 2001 no es soportada. Sin embargo, puede usar una solución de algún socio de negocio o Partner de Microsoft para actualizar el contenido del sitio directamente. Para obtener más información acerca de los socios de actualización, consulte la página sobre migración y actualizaciones de TechNet (http://technet.microsoft.com/es-es/sharepointserver/bb421259.aspx).
¿Va a actualizar desde SharePoint Team Services?
Actualice a Windows SharePoint Services 2.0 y luego a Windows SharePoint Services 3.0. Después puede instalar Office SharePoint Server 2007 o migrar el contenido a Office SharePoint Server 2007. Para migrar el contenido, use una herramienta (suministrada, creada por usted o usada bajo la licencia de un socio de Microsoft) para importar el contenido a su sitio de Office SharePoint Server 2007. La actualización directa desde SharePoint Team Services no se admite.
¿Va a actualizar desde Windows SharePoint Services 2.0?
Use el método de migración de bases de datos para migrar las bases de datos de contenido de Windows SharePoint Services 2.0 a Office SharePoint Server 2007. Este proceso de migración realiza una actualización inmediata del contenido del sitio. Para obtener más información, consulte Introducción al capítulo: implementación de una granja de servidores nueva y migración de bases de datos (Office SharePoint Server).
¿Va a actualizar desde Microsoft Content Management Server 2002?
Consulte Migración de Microsoft Content Management Server 2002 a Office SharePoint Server 2007 y la página sobre migración y actualizaciones de TechNet (http://technet.microsoft.com/es-es/sharepointserver/bb421259.aspx).
¿Va a actualizar desde SharePoint Portal Server 2003 con el conector SPARK para Microsoft Content Management Server 2002?
Consulte Migración de Microsoft Content Management Server 2002 a Office SharePoint Server 2007 y la página sobre migración y actualizaciones de TechNet (http://technet.microsoft.com/es-es/sharepointserver/bb421259.aspx). Enfoque recomendado: actualice los sitios de portal de SharePoint Portal Server 2003 y luego use las herramientas de migración de MCMS para migrar el contenido de MCMS 2002 a los sitios de portal actualizados.
¿Va a actualizar desde un entorno que incluía Microsoft Office Web Components (http://www.microsoft.com/downloads/details.aspx?displaylang=es&FamilyID=7287252c-402e-4f72-97a5-e0fd290d4b76)?
Estos componentes seguirán funcionando en la nueva versión si usa una actualización inmediata o gradual. Sin embargo, el enfoque de migración de bases de datos no funciona para estos componentes, porque sólo se pueden instalar en un entorno con Windows SharePoint Services 2.0 o SharePoint Portal Server 2003. Si va a actualizar a la Licencia de acceso de cliente (CAL) Enterprise de Office SharePoint Server 2007, considere la posibilidad de usar las capacidades de Excel Services en el nuevo entorno en lugar de Office Web Components.
A cotinuación me gustaría compartir con ustedes una recopilación de ligas interesantes que nos podrían ser de utilidad en un momento dado, respecto a Reporting Services y SharePoint
How to: Add Report Server Content Types to a Library (Reporting Services in SharePoint Integrated Mode)
http://msdn.microsoft.com/en-au/library/bb326289.aspx
Microsoft SQL Server Reporting Services - Installation and Configuration Guide for SharePoint Integration Mode (Important)
http://yasirbutt.spaces.live.com/Blog/cns!A8677D5751E6B4DA!1135.entry
Microsoft SQL Server 2008 Reporting Services Add-in for Microsoft SharePoint Technologies
http://www.microsoft.com/downloads/details.aspx?FamilyID=200fd7b5-db7c-4b8c-a7dc-5efee6e19005&DisplayLang=en
Integración de Reporting Services con SharePoint
http://geeks.ms/blogs/ciin/archive/2007/03/02/integraci-n-de-reporting-services-con-sharepoint-i.aspx
WSS 3.0 & MOSS: ¿Qué pasa con la integración con SSRS 2008?
http://geeks.ms/blogs/ciin/archive/2008/08/10/wss-3-0-amp-moss-191-qu-233-pasa-con-la-integraci-243-n-con-ssrs-2008.aspx
Information Integration: SSRS and MOSS 2007
http://officesharepointpro.com/content/1879/Information-Integration--SSRS-and-MOSS-2007--.aspx
FIX: You receive an error message when you try to access a report after you configure SQL Server 2005 Reporting Services to run under the SharePoint integrated mode
http://support.microsoft.com/kb/939942
Si alguien quiere añadir o compartir otras con gusto lo puede hacer mediante el uso de comentarios a este post.
Ya van algunas veces que la gente me pregunta cuales son las ventajas de usar 64 bits sobre 32 bits para una implemetación de MOSS 2007 (32 bits o 64 bits para SharePoint o MOSS 2007). Por eso decidí compartir con ustedes esta información que se encuentra en TechNet, esperemos les sea de utilidad para apoyarles en tomar una decisión.
This chapter assumes that you have already used the Plan for redundancy (Office SharePoint Server) article to plan for availability requirements. As a result of using the "Plan for availability" article, you will start the capacity planning exercise with a topology that meets your organization's minimum availability requirements. Given the topology you have determined you will deploy, this chapter will help you determine:
If you need to add additional servers to meet your goals for capacity and performance.
If you need to adjust the configuration of application server roles to optimize capacity and performance of the server farm.
If you need to plan for more than one server farm based on your capacity requirements.
In some cases, an organization's requirements for availability can result in a server farm size that provides greater capacity or performance than is otherwise required. If this is the case, your capacity planning process can focus on sizing the server hardware economically, rather than on adding additional server computers (scaling out) or scaling up with higher-performing hardware.
In many cases, the topology that meets an organization's minimum availability requirements is used as a starting point and server computers are added or scaled up to meet capacity and performance goals.
Although Microsoft Office SharePoint Server 2007 can be deployed on 32-bit servers, Microsoft recommends that you employ 64-bit servers in Office SharePoint Server 2007 farm deployments. The guidance presented in this guide is based on testing conducted on 64-bit servers. Therefore, if you are planning to deploy to 32-bit servers, you should perform additional testing on the 32-bit servers in your environment. The best practices and performance trends in this guide will still generally apply to 32-bit environments, but actual results may vary.
The 64-bit system architecture has several characteristics that contribute to superior server scalability and performance:
Memory addressability A 32-bit system can directly address only a 4-GB address space. Windows Server 2003 SP1 running on a 64-bit system architecture supports up to 1,024 gigabytes of both physical and addressable memory.
Larger numbers of processors and more linear scalability per processor Improvements in parallel processing and bus architectures enable 64-bit platforms to support larger numbers of processors (up to 64) while providing close to linear scalability with each additional processor. Server platforms that offer more than 32 CPUs are available exclusively on 64-bit architecture.
Enhanced bus architecture The bus architecture on current 64-bit chipsets is faster and wider than earlier generations. More data is passed to the cache and processor; this is somewhat analogous to the improvement that broadband connections offer over dial-up connections.
For more information on deploying Office SharePoint Server 2007 on 32-bit servers, see Planning recommendations for Web servers (Office SharePoint Server).
Referencia: http://technet.microsoft.com/en-us/library/cc261700.aspx
Si alguien más desea compartir sus comentarios sobre este tema con mucho gusto le invito a que deje sus comentarios.
Les recomiendo estos tres artículos de TechNet en cuanto a respaldos y recuperación de SharePoint se refiere:
Plan for backup and recovery (Office SharePoint Server)
http://technet.microsoft.com/en-us/library/cc261687.aspx
Prepare to back up and restore a farm (Office SharePoint Server 2007)
http://technet.microsoft.com/en-us/library/cc262704.aspx
Backup, Recovery, and Availability Resource Center for SharePoint Server 2007 (Disaster recovery, data protection, and high availability for SharePoint Server)
http://technet.microsoft.com/en-us/office/sharepointserver/bb736212.aspx
Cuando comenzamos a trabajar en planear nuestro DRP (Disaster Recovery Plan) de SharePoint 2007 para considerarlo como parte de nuestro SLA (Service Level Agreement), tenemos que revisar los distintos escenarios, opciones y herramientas disponibles para generar los respaldos de nuestra información y su restauración en un momento necesario.
Ahora, con conocer las distintas opciones que podemos manejar no es suficiente, es importante también estar al tanto de cuando una opción de respaldo es mejor que otra.
A continuación compartimos una tabla que habla de datos puntuales que valen la pena tomar en cuenta.
System Center Data Protection Manager
32-bit systems: 150 data sources
64-bit systems: 300 data sources
For more information, see Data Protection Manager 2007 Frequently Asked Questions (http://go.microsoft.com/fwlink/?LinkId=126629).
SharePoint farm backup and recovery
< 200 GB
VSS Writer
No known limit
SQL Server
Content databases > 200 GB may require additional management
Stsadm site collection backup and recovery
15 GB
Stsadm import and export
100 GB
SharePoint Designer backup
24 MB
MSIT Site Delete Capture tool