El efecto “noisy neighbor”: problemas de co­n­vi­ve­n­cia en la nube

Todos hemos sufrido en algún momento la in­co­mo­di­dad de tener unos vecinos es­ca­n­da­lo­sos que escuchan música o ven la te­le­vi­sión a un volumen alto, que ponen la lavadora a deshora, que organizan fiestas sin fin o cuyos hijos trotan y gritan in­ca­n­sa­bles a todas horas. Si tales molestias son de especial in­te­n­si­dad o suceden con cierta re­gu­la­ri­dad, entonces se co­n­vie­r­ten en un factor que puede reducir drá­s­ti­ca­me­n­te la comodidad de la vivienda que se ha alquilado. Si su­s­ti­tui­mos “vivienda alquilada” por “recursos co­n­tra­ta­dos”, este problema traspasa las cuatro paredes del hogar para co­n­ve­r­ti­r­se en un fenómeno muy extendido también en el entorno de los se­r­vi­do­res, donde se lo conoce como “efecto noisy neibhbor” o “efecto del vecino ruidoso”.

Cuando se trata de buscar una vivienda se tienen ge­ne­ra­l­me­n­te dos opciones: por un lado, alquilar o comprar una casa propia o, por el otro, un piso en una comunidad de vecinos. Mientras que en el primer caso el contacto con los vecinos requiere un mínimo de voluntad y no es ne­ce­sa­ria­me­n­te frecuente, en un edificio de varios pisos su presencia se percibe constante e in­vo­lu­n­ta­ria­me­n­te de una forma mucho más cercana. Como co­n­tra­pa­r­ti­da, los gastos de ma­n­te­ni­mie­n­to de una casa uni­fa­mi­liar son mucho más elevados que los de un apa­r­ta­me­n­to.

La situación es similar cuando se busca un “hogar” adecuado donde alojar un proyecto web o la es­tru­c­tu­ra in­fo­r­má­ti­ca de una empresa. Un servidor físico propio, alojado por uno mismo o por un proveedor, que satisfaga los re­qui­si­tos de software y de hardware, es la solución sin duda más compleja, pero tiene la ventaja de que tanto los recursos como su gestión recaen ex­clu­si­va­me­n­te en manos de su pro­pie­ta­rio. Cuando se opta por hacer uso de recursos vi­r­tua­li­za­dos, co­m­pa­r­tie­n­do así el fu­n­da­me­n­to técnico del proyecto con otros, puede que el re­n­di­mie­n­to se resienta te­m­po­ra­l­me­n­te.

La causa de ello radica no­r­ma­l­me­n­te en una so­breu­ti­li­za­ción de los recursos por parte de otro “inquilino” que los comparte, de ahí la de­no­mi­na­ción de “efecto del vecino ruidoso” o “noisy neighbor effect”. Hoy en día, el fenómeno de las in­s­ta­n­cias “vecinas” que pe­r­ju­di­can el re­n­di­mie­n­to global de los recursos se observa sobre todo en la flexible co­mpu­tación en la nube, fu­n­da­me­n­ta­da en la de­no­mi­na­da ar­qui­te­c­tu­ra de tenencia múltiple (mu­l­ti­te­na­n­cy o multi-tenant ar­chi­te­c­tu­re), en pa­r­ti­cu­lar en las nubes públicas.

El efecto “vecino ruidoso” no es en absoluto nuevo, sino que es tan antiguo como la po­si­bi­li­dad de compartir recursos, que existía antes incluso del na­ci­mie­n­to de la nube. Ya en el tra­di­cio­nal shared hosting o alo­ja­mie­n­to co­m­pa­r­ti­do, este era uno de los problemas a los que tenían que en­fre­n­tar­se los pro­vee­do­res de alo­ja­mie­n­to. Si uno de los clientes requería, sa­bié­n­do­lo o no, más recursos de los que le co­rre­s­po­n­dían, alguno de los demás “in­qui­li­nos” de la misma máquina se veía pe­r­ju­di­ca­do con alguna li­mi­ta­ción, en especial en lo co­n­ce­r­nie­n­te a la memoria de al­ma­ce­na­mie­n­to, siempre escasa.

Hoy en día, los modernos hi­pe­r­vi­so­res di­s­tri­bu­yen los recursos fu­n­da­me­n­ta­les de hardware de forma tan eficiente entre las máquinas virtuales que ad­mi­ni­s­tran que solo en casos ex­ce­p­cio­na­les se producen re­du­c­cio­nes del re­n­di­mie­n­to oca­sio­na­das por un vecino ruidoso.

Por su parte, el alo­ja­mie­n­to en la nube, cuya principal ventaja radica en una es­ca­la­bi­li­dad muy flexible, tiene a su propio “vecino ruidoso”: a pesar de que la te­c­no­lo­gía de al­ma­ce­na­mie­n­to ha mejorado mucho en cuanto a capacidad y velocidad de acceso en los últimos años, las ne­ce­si­da­des de espacio en el contexto de la nube han crecido de forma ex­po­ne­n­cial. Si varios usuarios están co­ne­c­ta­dos a una nube y uno o más máquinas virtuales so­bre­ca­r­gan la memoria física del servidor con valores muy altos de entrada y salida (I/O), para algunos usuarios puede si­g­ni­fi­car una pérdida de capacidad de al­ma­ce­na­mie­n­to. El al­ma­ce­na­mie­n­to con SSD puede co­n­tra­rre­s­tar este efecto, aunque no forma parte aún del re­pe­r­to­rio estándar de todos los pro­vee­do­res de alo­ja­mie­n­to en la nube.

El efecto “noisy neighbor” de la co­mpu­tación en la nube también resulta de la in­ter­ac­ción de los hi­pe­r­vi­so­res y los pro­ce­sa­do­res. Los hi­pe­r­vi­so­res no tienen acceso al al­ma­ce­na­mie­n­to local ni tampoco a la memoria caché de los pro­ce­sa­do­res y estos, por su lado, tampoco disponen de in­fo­r­ma­ción sobre lo que pasa más allá de la capa de red. Son los al­go­ri­t­mos de caching definidos en el pro­ce­sa­dor los que deciden qué datos se almacenan en la caché. Los modernos pro­ce­sa­do­res multicore, además, asignan a algunas máquinas virtuales la memoria caché L3 (Level 3), que acelera el in­te­r­ca­m­bio de datos. Esto tiene como co­n­se­cue­n­cia que, para el resto de máquinas que dependen asimismo de este pro­ce­sa­dor, la ejecución de ope­ra­cio­nes requiera más tiempo.

Para reducir los efectos de los “noisy neighbors” y optimizar a largo plazo todos los proyectos alojados, algunos pro­vee­do­res de alo­ja­mie­n­to en la nube muestran su pre­fe­re­n­cia por los sistemas all-flash storage o al­ma­ce­na­mie­n­to todo flash. Este concepto se fu­n­da­me­n­ta en la su­s­ti­tu­ción de las unidades de disco rígido (Hard Disc Drive, HDD) por los más potentes y más caros SSD o discos de estado sólido (Solid State Drive), que utilizan memoria no volátil, como la memoria flash, para almacenar los datos. Sin embargo, estos medios de al­ma­ce­na­mie­n­to flash más modernos tampoco pueden evitar co­m­ple­ta­me­n­te el efecto de los “vecinos ruidosos”, a pesar de su tasa de I/O más alta. Esto ha hecho que se co­n­so­li­da­ran los de­no­mi­na­dos all-flash arrays o matrices de discos todo flash, que contienen varias unidades de al­ma­ce­na­mie­n­to flash, a la hora de im­ple­me­n­tar una ar­qui­te­c­tu­ra de al­ma­ce­na­mie­n­to sin HDD. Estas matrices todo flash cuentan con una cuota integrada de al­ma­ce­na­mie­n­to para la entrada y salida de datos, que se gestiona en un nivel de apli­ca­ción que se gestiona in­di­vi­dua­l­me­n­te, de tal forma que el proveedor de la nube o su ad­mi­ni­s­tra­dor pueden su­pe­r­vi­sar y coordinar la tra­n­s­fe­re­n­cia de datos de las di­fe­re­n­tes máquinas virtuales.

En ocasiones, es difícil predecir cómo va a evo­lu­cio­nar un proyecto. Es por esto que, antes de nada, conviene in­fo­r­mar­se bien sobre la hi­po­té­ti­ca po­si­bi­li­dad de aumentar o reducir los recursos co­n­tra­ta­dos, porque, de lo contrario, podría pagarse por unas pre­s­ta­cio­nes de al­ma­ce­na­mie­n­to y CPU que no se necesitan o co­n­ve­r­ti­r­se en el mismo vecino ruidoso que saca de quicio a los demás in­qui­li­nos.

Te interesa un servidor virtual pero quieres evitar el efecto “noisy neighbor”, infórmate aquí sobre el abanico de se­r­vi­do­res IONOS.