Hace ya unos cuantos meses de la Parte 1 y creo que es ya hora de terminar esta serie de artículos. De hecho por este artículo y su continuación ya me habéis contactado varias personas para pedir mas información.
En la primera parte empecé a hablar de la arquitectura en cuanto al concepto pero sin entrar en materia.
En todo proyecto se debe tener muy clara el objetivo de a que se quiere dar solución. Lo más típico con MOSS es entorno Intranet únicamente.
Los proyectos de plataformas punta a punta (Internet/Intranet/Extranet) son más bien escasos. Y también los más complejos.
Lo principal será determinar a qué vamos a llamar a cada cosa.
Internet e Intranet serán en casi todos los sentidos siempre fijos. Es decir Internet será la zona anónima e Intranet la zona para usuarios internos.
El problema viene con Extranet. Según se mire la Extranet puede ser más parecido a Internet que a Intranet. Mi definición de Extranet viene por quién vaya a usarla en cada momento. Es decir si el cliente llama Extranet al acceso de los usuarios de la empresa a la Intranet de zona remota, entonces Intranet=Extranet..Si se trata de una zona solo para colaboradores/clientes/proveedores entonces Internet=Extranet.
Es decir podríamos tener estas dos organizaciones de sitios y granjas diferentes:
Organización en donde Intranet y Extranet es lo mismo, puede valer tanto para implantaciones donde Extranet se define como la zona a la que acceden los usuarios internos desde ubicaciones remotas. O bien también para Extranet colaborativas con colaboradores. Es decir zona extranet de colaboración para dar acceso a por ejemplo despachos de asesoría a las zona colaborativas de administración y finanzas.
Este último sería el típico diseño en el que se diseña una zona extranet de acceso a clientes, en la cual se puede tanto publicar zonas colaborativas o colgar aplicaciones u otro tipo de servicio que se ofrece a clientes o proveedores.
Bueno, una vez que se dispone del diseño ya realizado el siguiente paso será necesario determinar la arquitectura física, en el que ya entra aquí el presupuesto y el caracter que se le quiera dar a la plataforma. Es decir si se trata de un single server sin tolerancia a fallos o estamos hablando de entornos de al menos 4 servidores por zona (2 MOSS + 2 SQL, el mínimo para disponer de alta disponibilidad).
Para ello lo mejor es comenzar con herramientas de dimensionamiento como la que tiene HP para entornos MOSS o utilizar la que acaba de sacar Microsoft.
SharePoint Capacity Planning ToolSystem Center Capacity Planner 2007
El tema del dimensionamiento físico dependerá mucho de la arquitectura actual de la empresa, del presupuesto, de las necesidades de la plataforma y de nuevo del presupuesto. Al estar hablando de MOSS el coste es de licencias no de servidores hardware, al menos en proporción.
Por último una vez tengamos el típico diseño de red:
Bueno quizás se deba hacer más específico con esquemas de red, ip, nombre servidores, servicios detallados, configuraciones específicas,etc.
Lo último a definir y detallar será el dimensionamiento por colección de sitios, sito, librería, lista, etc. Es decir entrar en detalle de cuanto espacio y ancho de banda va a necesitar la plataforma. Dando por supuesto que ya en la Parte 1 tenemos claro las url de cada coleccíón de sitio, sitio, etc.
De esta manera ya será un trabajo de definir luego la arquitectura de canales de cada zona e ir construyendo la solución.
Con este artículo creo que podemos dar por cerrado este post. Quedaría una variación que sería con entornos multi idioma, que lo dejo para más adelante ya que necesitaría al menos entrar antes en flujos de publicación y en arquitecturas sencillas multi idioma y eso es más de 2 post :).
Espero que os sirva.
0 comentarios:
Publicar un comentario