Planeación de un ambiente redundante para SharePoint
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:
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.