Páginas en este Blog:

domingo, 4 de mayo de 2008

Asunto MBA-055: Sistema operativo en el servidor y Trabajo en grupo

Presentamos este asunto todavía sin solución, con el propósito de provocar la discusión de experiencias que puedan ser provechosas para la comunidad de usuarios.

En forma creciente, estamos experimentando problemas de lentitud (ya exasperantes) en el proceso de guardar al archivo central con un proyecto Revit cuyo archivo .rvt ya alcanzó los 180Mb. Un archivo de ese tamaño toma unos 10 a 12 minutos. La consecuencia es que los usuarios dejan de guardar a la central; sólo lo hacen al archivo local, y van dejando elementos tomados que tardan mucho en ceder. A esto debe agregarse el hecho de que cada vez que se modifica un elemento, Revit registra o consulta su estado con el archivo central para evitar que dos usuarios lo editen simultáneamente y con ello se pierda el trabajo del otro. Esta verificación con el archivo central también es lenta y representa una constante demora, a pesar de que el usuario esté evitando grabar a la central sin ceder los elementos reservados.

La situación actual en nuestra oficina en relación con el hardware y software de red ha llegado a ser claramente deficiente con Revit. El servidor dedicado está muy bien, pero corre Netware 4.2 y el switch es 10BaseT. Principalmente este último es un cuello de botella que estrangula el tráfico. Pero también el sistema operativo Netware 4.2 no transfiere paquetes grandes de información.

Sin embargo, la necesidad de instalar un nuevo sistema operativo (SO) en el servidor nos ha hecho descubrir que existe un problema ya conocido de velocidad de grabación al archivo central, independiente del SO del servidor y que se habría desencadenado con Revit 9.1 y que aún hasta Revit Architecture 2008 sigue pendiente. Ver el siguiente foro de AUGI: http://forums.augi.com/showthread.php?t=63786&highlight=Windows+server+2003
que aborda el tema "Guardar en Windows Server 2003 es muy lento" y que concluye en que no sería problema de SO de red.

Novell Netware

En el siguiente link, http://forums.augi.com/showthread.php?t=19440&highlight=Netware, un usuario de AUGI indica una solución para el problema y dice que, cambiando ciertos parámetros en la configuración del servidor y del cliente (relacionados con el cache de archivos), la velocidad de grabación aumenta en 3 veces y la consulta al panel de subproyectos responde instantáneamente. Los parámetros son:

  • en el Servidor, Level 2 Oplocks Enabled debe estar en "ON".
  • en el Cliente, deben estar activas las funciones de Ajustes avanzados "File Caching" y "File Commit".
El parámetro File caching (caché de archivos) controla si el cliente almacenará los archivos localmente o no. File Commit controla si los buffers creados por una aplicación se almacenarán en el servidor. Si se ajusta este valor en Activado, se garantizará la integridad de los datos a costa del rendimiento. Así, se asegura que los buffers de archivo se almacenen en el servidor cuando una aplicación los cree.

Oplocks (Oportunistic locking) está relacionado con el cache de archivos y habilitarlo aumenta sensiblemente el número de veces que una estación de trabajo lee/escribe en el servidor agrupando paquetes pequeños de data y transfiriéndolos agrupados en grandes grupos. las aplicaciones que transfieren datos en pequeños paquetes (¿Revit?) se benefician de esta función. Lamentablemente para nosotros, Netware 4.2 no tiene la función Level 2 Oplocks que existe desde Netare 5.1 (con sp6) en adelante.

Proyecto de solución

Evidentemente, la solución pasa por una actualización de hardware y software. Nos hemos propuesto el siguiente itinerario:

  1. Descartar el problema del cableado y del switch: instalar un nuevo switch 10/100/1000T con el cambio de las correspondientes tarjetas de red en cada estación de trabajo y un cableado de Categoría 5 o 6 para alcanzar el mejor ancho de banda posible.
  2. Instalar un nuevo servidor dedicado de tal manera que, sin interrumpir el trabajo, pueda despejarse la parte del problema que dependa del equipo. El propósito de un segundo servidor es desvincular la red el actual en forma controlada, impidiendo que le imponga a todo el sistema procedimeintos lentos de los que no se pueda prescindir.
  3. Estando la cuestión del hardware despejada, la pregunta pendiente será la de la elección del SO.
Otros sistemas operativos

Windows Server 2003 R2 o 2008

En materia de SO pagados el producto de elección por costo parece ser Windows Server 2003 R2 o el nuevo Windows Server 2008, siendo el primero el más probado y estable. Aparentemente (según foro AUGI antes citado) no hay razones para atribuir el problema de la lentitud de grabación al archivo central atribuibles al SO. Parece ser recomendable que el servidor DHCP y DNS residan en el mismo servidor central y utilizar IP fijas (según foro AUGI).

Linux

Nuestra elección sería Ubuntu Server Edition. Aquí, sin embargo, no hay experiencias que conozcamos y nos encantaría que alguien contara la suya. Una vez que tengamos operativo nuestro segundo servidor, nos proponemos instalar Ubuntu en el primero.


No hay comentarios.: