Hay una serie de criterios que determinan si una aplicación puede convertirse o no en servicio escalable. Para determinar si su aplicación puede convertirse en servicio escalable, consulte Análisis de la validez de la aplicación de Sun Cluster: Guía del desarrollador de los servicios de datos del sistema operativo Solaris. Este conjunto de criterios se resume a continuación.
Primero, el servicio se compone de una o varias instancias de servidor, cada una de las cuales se ejecuta en un nodo distinto del clúster. Dos o más instancias del mismo servicio no pueden ejecutarse en el mismo nodo.
Segundo, si el servicio proporciona un almacén de datos lógico externo, deberá actuar con precaución. El acceso simultáneo a este almacén desde varias instancias de servidor debe estar sincronizado para evitar que se pierdan actualizaciones o datos de lectura mientras se estén modificando. Observe que se usa “externo” para distinguir este almacén del estado en memoria. El término “lógico” indica que el almacén aparece como una única entidad, aunque puede que esté replicado. Además, este almacén de datos lógico tiene la propiedad de que cada vez que una instancia de servidor actualiza el almacén, las demás instancias pueden “ver” la actualización de forma inmediata.
El sistema de Sun Cluster proporciona un almacén externo a través de su sistema de archivos en clúster y sus particiones sin formato globales. Como ejemplo, supongamos que un servicio escribe datos nuevos a un archivo de registro cronológico externo o modifica los datos que haya. Cuando se ejecutan varias instancias de este servicio, cada instancia tiene acceso a su registro externo y cada una de ellas puede acceder simultáneamente a este registro. Cada instancia debe sincronizar su acceso a este registro o de lo contrario se interferirán entre ellas. El servicio puede usar normalmente el bloqueo de archivos de Solaris mediante fcntl(2) y lockf(3C) para lograr la sincronización necesaria.
Otro ejemplo de este tipo de almacén es una base de datos de fondo (back-end), como pueda ser una instalación de Oracle Real Application Clusters Guard de alta disponibilidad para clústeres basados en SPARC o en Oracle. Este tipo de servidores de bases de datos de fondo (back-end) proporcionan sincronización integrada utilizando una consulta de base de datos o transacciones de actualización. En consecuencia, varias instancias de servidor no necesitan implementar su propia sincronización.
El servidor Sun IMAP es un ejemplo de servicio que no es escalable. El servicio actualiza un almacenamiento, pero es privado y cuando varias instancias de IMAP escriben en él, se sobrescriben porque las actualizaciones no están sincronizadas. El servidor IMAP debe volver a escribirse para que se sincronice el acceso simultáneo.
Por último, tenga en cuenta que las instancias pueden tener datos privados que no tengan nada que ver con los datos de otras instancias. En estos casos, el servicio no necesita un acceso simultáneo sincronizado porque los datos son privados y sólo puede gestionarlos la propia instancia. En estas circunstancias, deberá tener cuidado de no almacenar estos datos privados en el sistema de archivos en clúster porque estarían accesibles globalmente.