# Stackscale - Full Content > Expertos en Cloud Privado e infraestructura | Stackscale --- ## Licenciamiento de VMware en 2026: qué ha cambiado de verdad y qué decisión te pone delante 2027 URL: https://www.stackscale.com/blog/vmware-licensing-2026/ El cambio de licenciamiento de VMware bajo Broadcom lleva casi tres años generando titulares, y a estas alturas cuesta distinguir lo que está vigente de lo que se anunció, se retiró y sigue circulando como si siguiera en pie. Ese deslinde conviene hacerlo antes de tomar cualquier decisión de infraestructura, porque las dos cosas que de verdad aprietan no son las que más ruido han hecho. En corto: lo que ha cambiado de forma estructural es el modelo de compra —suscripción obligatoria, licenciamiento por núcleo y catálogo reducido a dos paquetes—; lo que sigue vigente como mínimo de licenciamiento son 16 núcleos por socket físico, no los 72 por pedido que tanto se citan y que se retiraron a los pocos días de anunciarse; y la fecha que de verdad manda es el **11 de octubre de 2027**, cuando vSphere 8 llega a fin de vida sin camino soportado para las ediciones Standard y Enterprise Plus, con la particularidad de que los contratos a tres años firmados en 2024 y 2025 vencen agrupados justo antes. ## Lo que dice Gartner, y lo que no dice El dato que ha circulado más esta semana viene de un informe de Gartner recogido por The Register el 22 de septiembre de 2026: **el 55 % de las empresas usuarias de VMware habrán iniciado pruebas de concepto con alternativas antes de 2029**, frente al 25 % que lo está haciendo en 2026. Es una previsión, no una medición de cuota, y esa distinción importa: no dice que el 55 % vaya a migrar, dice que más de la mitad va a evaluar. La diferencia entre evaluar y migrar es precisamente donde se juega la decisión. Una prueba de concepto cuesta semanas y no compromete nada; una migración compromete la plataforma durante años. Que el número de empresas dispuestas a hacer la primera se duplique en tres años es relevante por lo que revela del clima, no porque anuncie un éxodo. ## Cronología del licenciamiento, con fechas Los hechos, ordenados. Las marchas atrás van incluidas, porque contarlas es lo que permite separar la condición vigente del anuncio que se quedó en anuncio. FechaQué pasóNoviembre de 2023Broadcom cierra la compra de VMware.Finales de 2023Fin de la venta de licencias perpetuas. Las ya compradas siguen funcionando; no se venden nuevas.Finales de 2023El catálogo pasa de más de 160 productos a dos paquetes: vSphere Foundation y VMware Cloud Foundation. Se retiran los kits Essentials.Finales de 2023El licenciamiento pasa de socket a núcleo, con un mínimo de 16 núcleos por socket físico.Principios de 2024Se retira el ESXi gratuito.2024Reorganización del canal: la mayoría de clientes pasa a contratar a través de distribuidor autorizado.28 de marzo de 2025Se comunica al canal un mínimo de **72 núcleos por línea de pedido**, con efecto el 10 de abril.~10 de abril de 2025**Se retira ese mínimo de 72 núcleos** tras la reacción del canal. Vuelve a regir el mínimo de 16 por socket.Abril de 2025Vuelve el ESXi gratuito con vSphere 8.0 Update 3e, limitado a uso no productivo: sin vCenter, máximo 8 vCPU por máquina virtual y sin soporte.~Mayo de 2025Empiezan los requerimientos a titulares de licencias perpetuas con soporte vencido para que retiren parches aplicados después del vencimiento.31 de julio de 2025Fin de venta de vSphere Standard.Diciembre de 2025Broadcom retira vSphere Foundation de varios países de EMEA y deja disponible solo Cloud Foundation.vSphere 9Se distribuye únicamente dentro de los paquetes de suscripción. No existe edición independiente.Septiembre de 2026Se informa de que Broadcom prepara la vuelta de vSphere Standard, por suscripción y licenciado por núcleo con el mínimo de 16 por procesador. No se han publicado precio, disponibilidad ni condiciones comerciales.11 de octubre de 2027Fin de vida de vSphere 8. Standard y Enterprise Plus no tienen continuidad soportada. ## Qué sigue vigente y qué se quedó en anuncio De todo lo anterior, esto es lo que condiciona un presupuesto hoy: - **Suscripción obligatoria**: no hay vuelta a la licencia perpetua. Dejar de pagar deja de gestionar los hosts. - **16 núcleos por socket físico** como mínimo de licenciamiento. Es el que aplica. - **Dos paquetes**, y en varios países de EMEA solo uno, Cloud Foundation, desde diciembre de 2025. - **El mínimo de 72 núcleos por pedido no está en vigor.** Se anunció y se retiró en abril de 2025, y además era un mínimo por línea de pedido, no por socket. Aparece citado a menudo como si fuera una condición viva. - **El ESXi gratuito existe pero no sirve para producción**: 8 vCPU por máquina, sin vCenter y sin soporte. Es un laboratorio, no una plataforma. - **La vuelta de vSphere Standard es un anuncio, no una oferta.** A septiembre de 2026 no hay precio, disponibilidad ni condiciones publicadas, así que todavía no se puede meter en un presupuesto. Merece la pena verificar en el propio presupuesto lo que se ha leído en prensa. Varias de estas condiciones se han aplicado de forma distinta según canal, región y estructura de la oferta, así que la única versión fiable es la que figura por escrito en la oferta concreta. ## Los dos hechos que aprietan en Europa El debate público se ha centrado en los precios y en las marchas atrás, pero para una empresa europea de tamaño medio lo que cambia la planificación es otra cosa. ### La retirada de vSphere Foundation en países de EMEA Desde diciembre de 2025, en varios países de EMEA el catálogo se reduce a VMware Cloud Foundation. Para un entorno que encajaba en el paquete intermedio, eso no es una subida de precio: es un salto de categoría de producto, con lo que implica en coste y en funciones que no se van a usar. Es el punto que más afecta a quien tiene entre dos y diez hosts y no necesita una plataforma de nube completa. ### La ola de renovaciones de 2026 y 2027 Los contratos a tres años que se firmaron en 2024 y 2025, cuando se cerró la puerta a las perpetuas, vencen agrupados en 2026 y 2027. Y coinciden con el fin de vida de vSphere 8 el 11 de octubre de 2027, que deja sin continuidad soportada a Standard y Enterprise Plus. Quien renueve sin haber evaluado alternativas se compromete otros tres años; quien quiera evaluarlas necesita empezar con margen, porque una prueba de concepto seria no se monta en dos semanas. En Stackscale lo vemos en la práctica: las conversaciones de migración que llegan con tiempo se resuelven bien, y las que llegan con la renovación encima se convierten en una negociación de precio sin alternativa real sobre la mesa. ## Qué implica migrar de verdad Aquí es donde el debate suele quedarse en generalidades, y es la parte que más condiciona la decisión. Una migración de VMware a Proxmox VE no es un problema de herramientas: es un problema de planificación y de pruebas previas. Con esas dos cosas hechas, el corte se mide en minutos. ### El corte es corto, y el orden importa El procedimiento habitual consiste en apagar en origen y encender en destino, con la conversión del formato de disco de VMware a Proxmox completada después, ya en caliente. Esa es la razón de que la ventana de parada sea breve: no se espera a convertir para arrancar. Según el entorno y según el trabajo adicional que requiera cada máquina, el corte puede ser de pocos minutos o algo más, pero el impacto va de casi nulo a muy bajo. ### Con alta disponibilidad, RTO y RPO a cero Cuando el entorno de origen ya tiene alta disponibilidad, la migración puede hacerse en caliente. Se migra una de las patas del clúster y se mantiene una **alta disponibilidad mixta entre VMware y Proxmox** durante la transición, con lo que el tiempo de corte es RTO = 0 y el de pérdida de datos, RPO = 0. Que eso sea posible depende menos del hipervisor que de lo que hay debajo. En Stackscale lo sostienen la red real, sin dependencia de la capa de virtualización, el almacenamiento en red y la replicación síncrona entre nodos, que es lo que permite mantener las dos plataformas en marcha a la vez sin perder el estado. ### Dónde se va el tiempo, y qué pasa si algo sale mal El tiempo no está en el corte, está antes: en el inventario, en la preparación y en las pruebas de cada tipo de máquina. Esas pruebas previas son exactamente la preparación para las incidencias, y por eso el día de la migración hay pocas sorpresas. Cuando aparece alguna, la vuelta atrás es igual de rápida que el paso adelante, porque el entorno de origen sigue ahí hasta que la validación en destino está cerrada. Nuestros clientes han migrado ya miles de máquinas virtuales, y en todos los casos el acompañamiento ha ido donde hacía falta, desde el diseño del clúster hasta la validación final. ## Qué hacer según el punto en que estés ### Contrato vigente con renovación lejana Es la situación cómoda, y la que conviene aprovechar. Un inventario real de máquinas, consumo y dependencias, más una prueba de concepto sin prisa, deja la decisión tomada antes de que llegue la renovación. La ventaja de evaluar con margen es que se negocia desde otra posición, con independencia de cuál sea el resultado. ### Renovación en los próximos doce meses Aquí el orden se invierte: primero hay que saber qué cuesta la alternativa y cuánto tarda, y después sentarse a renovar. Sin ese dato, la negociación no tiene contrapeso. Doce meses son suficientes para una prueba de concepto completa y una migración por fases, pero no para empezar a pensarlo en el último trimestre. ### Licencias perpetuas con soporte vencido Es la posición más expuesta, y no por el coste sino por los parches: aplicar actualizaciones de seguridad después del vencimiento del soporte es lo que ha motivado los requerimientos de 2025. Un entorno en producción sin parches de seguridad es un problema distinto y más urgente que el de licenciamiento, y conviene tratarlo como tal. ## Preguntas frecuentes ### ¿Sigue siendo obligatorio el mínimo de 72 núcleos por pedido? No. Se comunicó al canal el 28 de marzo de 2025 con efecto el 10 de abril, y se retiró en torno a esa misma fecha tras la reacción del canal. El mínimo que aplica es el de 16 núcleos por socket físico, que es anterior y distinto: uno era por línea de pedido y el otro es por procesador. ### ¿Puedo seguir usando mis licencias perpetuas de VMware? Las licencias perpetuas ya compradas siguen funcionando. Lo que no se puede es comprar nuevas ni, con el soporte vencido, aplicar los parches publicados después del vencimiento. Desde mayo de 2025 se han enviado requerimientos en ese sentido a titulares en esa situación. ### ¿El ESXi gratuito sirve para un entorno pequeño de producción? No. La versión reinstaurada en abril de 2025 con vSphere 8.0 Update 3e está limitada a uso no productivo: sin vCenter, un máximo de 8 vCPU por máquina virtual y sin soporte. Es válida para laboratorio y pruebas. ### ¿Qué pasa el 11 de octubre de 2027? vSphere 8 llega a su fin de vida. Las ediciones Standard y Enterprise Plus no tienen continuidad soportada, porque vSphere 9 se distribuye únicamente dentro de los paquetes de suscripción. Quien esté en esas ediciones tiene que decidir antes de esa fecha. ### ¿Cuánto dura el corte en una migración a Proxmox VE? Con planificación y pruebas previas, el corte se mide en minutos: se apaga en origen, se enciende en destino y la conversión del disco se completa después en caliente. Si el entorno de origen ya tiene alta disponibilidad, puede hacerse sin corte, manteniendo alta disponibilidad mixta entre las dos plataformas durante la transición, con RTO y RPO a cero. ### ¿Se puede volver atrás si la migración no sale como se esperaba? Sí, y en el mismo plazo. El entorno de origen se mantiene disponible hasta que la validación en destino está cerrada, así que la vuelta atrás es tan rápida como el paso adelante. ### ¿Migrar a Proxmox VE es solo una forma de ahorrar en licencias? El ahorro es la razón por la que muchas empresas abren la conversación. Esa lectura se queda corta: lo que se decide en una migración es sobre qué plataforma se va a operar los próximos años, quién la mantiene y qué dependencias de proveedor se asumen. ## Dónde encaja Stackscale Las migraciones de VMware a Proxmox VE que salen bien se parecen todas: inventario honesto, pruebas por tipo de máquina y una ventana de parada corta porque el trabajo pesado ya está hecho antes. Lo que aporta la infraestructura es la posibilidad de mantener las dos plataformas en marcha a la vez, y eso depende de la red, del almacenamiento y de la replicación, no del hipervisor. En Stackscale desplegamos y operamos Proxmox VE en producción sobre infraestructura dedicada en nuestros data centers de Madrid y Ámsterdam, con red propia, almacenamiento en red y replicación síncrona. Si estás evaluando qué hacer antes de tu próxima renovación, habla con nosotros sobre tu proyecto de cloud privado y lo dimensionamos con tus datos. ## Para seguir leyendo - VMware vs Proxmox VE: cómo elegir (de verdad) para tu plataforma de virtualización, la comparativa técnica entre las dos plataformas. - Migrar de VMware a Proxmox VE: lo que CIO y CTO preguntan de verdad. - Cómo migrar de VMware a Proxmox VE con Stackscale, el procedimiento paso a paso. - Proxmox en 2025: el salto definitivo del «alternativo» al estándar. - Proxmox Backup Server, copias de nivel enterprise para entornos Proxmox. ## Fuentes - Gartner, vía The Register (22 de septiembre de 2026), para la previsión del 55 % antes de 2029. - SDxCentral, sobre el mismo informe y el movimiento de los competidores. - Revista Cloud: Gartner ve un cambio en VMware y Cambios en el licenciamiento de Broadcom VMware y alternativas a la vista, cobertura en castellano. - Cloud News: Broadcom brings back VMware vSphere Standard (9 de septiembre de 2026), para la vuelta anunciada de vSphere Standard y las condiciones que siguen sin publicarse. - Broadcom y VMware, notas de producto y avisos de fin de venta y fin de vida, para las fechas del apartado de cronología. --- ## VMware licensing in 2026: what has actually changed and the decision 2027 puts in front of you URL: https://www.stackscale.com/blog/vmware-licensing-2026/ VMware licensing under Broadcom has been generating headlines for almost three years, and by now it is hard to tell what is actually in force from what was announced, withdrawn, and still circulates as if it were standing. Making that distinction is worth doing before any infrastructure decision, because the two things that really put pressure on a budget are not the ones that made the most noise. The short version: what changed structurally is the purchasing model, with mandatory subscription, per-core licensing, and a catalog reduced to two bundles. What remains in force as a licensing floor is 16 cores per physical socket, not the 72 per order that get quoted so often and that were withdrawn days after being announced. And the date that really matters is **October 11, 2027**, when vSphere 8 reaches end of life with no supported path for the Standard and Enterprise Plus editions, with the added twist that the three-year contracts signed in 2024 and 2025 expire together just before it. ## What Gartner says, and what it does not The figure that circulated most this week comes from a Gartner report covered by The Register on September 22, 2026: **55 % of enterprise VMware users will have started proof-of-concept work with alternatives before 2029**, up from the 25 % doing so in 2026. It is a forecast rather than a market-share measurement, and that distinction matters. It does not say 55 % will migrate, it says more than half will evaluate. The gap between evaluating and migrating is exactly where the decision sits. A proof of concept costs weeks and commits nothing; a migration commits the platform for years. That the number of companies willing to do the first should double in three years is significant for what it reveals about the climate, not because it announces an exodus. ## Licensing timeline, with dates The facts, in order. The reversals are included, because listing them is what makes it possible to separate a condition that applies from an announcement that never took effect. DateWhat happenedNovember 2023Broadcom closes the VMware acquisition.Late 2023Perpetual licenses stop being sold. Those already purchased keep working; no new ones are issued.Late 2023The catalog goes from more than 160 products to two bundles: vSphere Foundation and VMware Cloud Foundation. The Essentials kits are retired.Late 2023Licensing moves from socket to core, with a minimum of 16 cores per physical socket.Early 2024Free ESXi is withdrawn.2024Channel restructuring: most customers move to buying through an authorized reseller.March 28, 2025Partners are told of a minimum of **72 cores per order line**, effective April 10.~April 10, 2025**That 72-core minimum is withdrawn** after the channel reaction. The 16-core per socket floor applies again.April 2025Free ESXi returns with vSphere 8.0 Update 3e, limited to non-production use: no vCenter, a maximum of 8 vCPU per virtual machine, and no support.~May 2025Notices begin reaching holders of perpetual licenses with expired support, asking them to remove patches applied after expiry.July 31, 2025vSphere Standard reaches end of sale.December 2025Broadcom withdraws vSphere Foundation from several EMEA countries, leaving only Cloud Foundation available.vSphere 9Ships exclusively inside the subscription bundles. There is no standalone edition.September 2026Broadcom is reported to be preparing a return of vSphere Standard, subscription-based and licensed per core with the 16-core per processor floor. Price, availability and commercial terms have not been published.October 11, 2027vSphere 8 end of life. Standard and Enterprise Plus have no supported continuation. ## What applies today and what never took effect Of everything above, this is what shapes a budget today: - **Mandatory subscription**: there is no route back to a perpetual license. Stop paying and the hosts stop being managed. - **16 cores per physical socket** as the licensing floor. This is the one that applies. - **Two bundles**, and in several EMEA countries only one, Cloud Foundation, since December 2025. - **The 72-core per order minimum is not in force.** It was announced and withdrawn in April 2025, and it was a per order line floor rather than a per socket one. It still gets quoted as though it were a live condition. - **Free ESXi exists but is useless in production**: 8 vCPU per machine, no vCenter, no support. It is a lab, not a platform. - **The return of vSphere Standard is an announcement, not an offer.** As of September 2026 there is no published price, availability or commercial terms, so it cannot be put into a budget yet. It is worth checking the actual quote against what has been reported. Several of these conditions have been applied differently depending on channel, region, and how the offer was structured, so the only reliable version is the one written into the specific quote. ## The two facts that bite in Europe Public debate has focused on pricing and on the reversals, but for a mid-sized European company what changes the planning is something else. ### vSphere Foundation withdrawn in EMEA countries Since December 2025, in several EMEA countries the catalog narrows to VMware Cloud Foundation. For an environment that fit the middle bundle, that is not a price increase, it is a jump to a different product category, with everything that implies in cost and in features that will go unused. It is the point that hits hardest for anyone running between two and ten hosts who does not need a full cloud platform. ### The 2026 and 2027 renewal wave The three-year contracts signed in 2024 and 2025, once the door to perpetual licenses closed, expire together across 2026 and 2027. They coincide with the end of life of vSphere 8 on October 11, 2027, which leaves Standard and Enterprise Plus without a supported continuation. Renewing without having evaluated alternatives commits another three years; evaluating them requires starting with room to spare, because a serious proof of concept does not get built in a fortnight. At Stackscale we see this in practice: migration conversations that arrive with time work out well, and the ones that arrive with the renewal already due turn into a price negotiation with no real alternative on the table. ## What migrating actually involves This is where the debate usually stays general, and it is the part that weighs most on the decision. Migrating from VMware to Proxmox VE is not a tooling problem, it is a planning and prior testing problem. With those two things done, the cutover is measured in minutes. ### The cutover is short, and the order matters The usual procedure is to power off at the source and power on at the destination, with the disk format conversion from VMware to Proxmox completed afterward, while the machine is already running. That is why the maintenance window stays short: nothing waits for the conversion in order to boot. Depending on the environment and on the extra work each machine needs, the cutover can run to a few minutes or somewhat longer, but the impact ranges from almost none to very low. ### With high availability, RTO and RPO at zero When the source environment already runs high availability, the migration can happen live. One leg of the cluster is migrated and **mixed high availability between VMware and Proxmox** is maintained through the transition, which puts the cutover at RTO = 0 and data loss at RPO = 0. Whether that is possible depends less on the hypervisor than on what sits underneath. At Stackscale it rests on real networking with no dependency on the virtualization layer, on network storage, and on synchronous replication between nodes, which is what allows both platforms to stay up at once without losing state. ### Where the time goes, and what happens when something breaks The time is not in the cutover, it comes before: in the inventory, in the preparation, and in testing each type of machine. Those prior tests are precisely the preparation for incidents, which is why migration day holds few surprises. When one does come up, rolling back is as fast as moving forward, because the source environment stays in place until validation at the destination is closed out. Our customers have already migrated thousands of virtual machines, and in every case the support went wherever it was needed, from cluster design through to final validation. ## What to do depending on where you stand ### Current contract with a distant renewal This is the comfortable position, and the one worth using. A real inventory of machines, consumption, and dependencies, plus an unhurried proof of concept, settles the decision before the renewal arrives. The advantage of evaluating early is that the negotiation happens from a different position, whatever the outcome turns out to be. ### Renewal within the next twelve months Here the order reverses: first find out what the alternative costs and how long it takes, then sit down to renew. Without that figure the negotiation has no counterweight. Twelve months is enough for a full proof of concept and a phased migration, but not if the thinking starts in the final quarter. ### Perpetual licenses with expired support This is the most exposed position, and not because of cost but because of patching: applying security updates after support has expired is what prompted the 2025 notices. A production environment without security patches is a different and more urgent problem than a licensing one, and it deserves to be treated as such. ## Frequently asked questions ### Is the 72-core per order minimum still mandatory? No. It was communicated to the channel on March 28, 2025, effective April 10, and withdrawn around that same date after the channel reaction. The floor that applies is 16 cores per physical socket, which is earlier and different: one was per order line, the other is per processor. ### Can I keep using my perpetual VMware licenses? Perpetual licenses already purchased keep working. What is no longer possible is buying new ones or, with support expired, applying patches released after that expiry. Since May 2025 notices to that effect have gone out to holders in that situation. ### Is free ESXi usable for a small production environment? No. The version reinstated in April 2025 with vSphere 8.0 Update 3e is limited to non-production use: no vCenter, a maximum of 8 vCPU per virtual machine, and no support. It is fine for a lab and for testing. ### What happens on October 11, 2027? vSphere 8 reaches end of life. The Standard and Enterprise Plus editions have no supported continuation, because vSphere 9 ships exclusively inside the subscription bundles. Anyone on those editions has to decide before that date. ### How long is the cutover in a migration to Proxmox VE? With planning and prior testing, the cutover is measured in minutes: power off at the source, power on at the destination, and the disk conversion completes afterward while the machine runs. If the source environment already runs high availability, it can be done with no cutover at all, keeping mixed high availability across both platforms through the transition, with RTO and RPO at zero. ### Can we roll back if the migration does not go as expected? Yes, and in the same timeframe. The source environment stays available until validation at the destination is closed out, so rolling back is as fast as moving forward. ### Is migrating to Proxmox VE only a way to save on licensing? Savings are why many companies open the conversation. That reading falls short: what gets decided in a migration is which platform the business will operate on for the next few years, who maintains it, and which vendor dependencies come with it. ## Where Stackscale fits VMware to Proxmox VE migrations that go well all look alike: an honest inventory, testing by machine type, and a short maintenance window because the heavy work was done beforehand. What the infrastructure contributes is the ability to keep both platforms running at once, and that depends on networking, storage, and replication rather than on the hypervisor. At Stackscale we deploy and operate Proxmox VE in production on dedicated infrastructure in our data centers in Madrid and Amsterdam, with our own network, network storage, and synchronous replication. If you are working out what to do before your next renewal, talk to us about your private cloud project and we will size it with your data. ## Further reading - VMware vs Proxmox VE: how to choose (for real) for your virtualization platform, the technical comparison between both platforms. - Migrating from VMware to Proxmox VE: what CIOs and CTOs really ask. - How to migrate from VMware to Proxmox VE with Stackscale, the step-by-step procedure. - Proxmox in 2025: the definitive leap from “alternative” to standard. - Proxmox Backup Server, enterprise-grade backups for Proxmox environments. ## Sources - Gartner, via The Register (September 22, 2026), for the 55 % forecast before 2029. - SDxCentral, on the same report and how competitors are positioning. - Cloud News: Two years after Broadcom: VMware is no longer the sole center of virtualization (June 26, 2026) and Why Broadcom’s VMware shakeup is pushing IT teams toward Proxmox (September 11, 2026). - Broadcom brings back VMware vSphere Standard (September 9, 2026), for the reported return of vSphere Standard and the terms still missing from it. - Broadcom and VMware product notes and end-of-sale and end-of-life notices, for the dates in the timeline section. --- ## Proxmox Backup Server in depth: deduplication, verification and retention in a private cloud URL: https://www.stackscale.com/blog/proxmox-backup-server-deduplication-verification-retention/ Almost nobody looks at their backups until the day they need them. Then every question arrives at once: does the copy exist? Is it intact? How old is it? How long does a restore take? Is it sitting in the same place as the system that just went down? And the worst one of all: has anyone ever proved that this actually works? In Proxmox VE environments, **Proxmox Backup Server (PBS)** answers those questions better than most alternatives in the open source ecosystem. We already published an introduction to Proxmox Backup Server and how it fits with Stackscale’s Archive storage. This article goes one step further into the mechanics: what deduplication actually does, why verification is not optional, how *prune* and *garbage collection* differ, how one server can serve several customers without mixing anything up, how to recover a single file without touching the whole machine, and how all of that turns into design decisions when the infrastructure lives in a private cloud with storage in two Madrid zones more than 10 kilometres apart. ## PBS is not “just another backup tool” Proxmox Backup Server is a Debian-based Linux distribution, written largely in Rust and released under the GNU AGPLv3 licence. It is built for one job: storing and returning data from virtual machines, containers and physical servers. Version **4.2**, released in April 2026, is based on Debian 13.4 “Trixie”, Linux kernel 7.0 and ZFS 2.4, and adds official support for S3-compatible object backends, encryption in sync jobs and concurrent processing of backup groups. The practical difference compared with a traditional dump to disk or to a NAS comes down to three mechanisms working together: **deduplication** (how much space it takes), **verification** (whether it is usable) and **retention** (how long copies are kept and when space is actually released). Teams that understand those three size their environment properly. Teams that don’t end up with a full repository, backups nobody has ever checked and a restore that turns into an experiment. ## Deduplication: why 30 copies don’t take 30 times the space PBS does not store monolithic backup files. It splits data into blocks —*chunks*, averaging around 4 MiB—, calculates the SHA-256 digest of each one and stores it only once within the *datastore*. If that same block shows up again tomorrow, the backup simply records a reference to it. Three consequences are worth having clear before sizing anything: - **Every backup is incremental, yet restores like a full one.** After the first copy, each run only adds new blocks. When restoring there is no chain of incrementals to rebuild: any *snapshot* stands on its own. - **Deduplication is global within the datastore.** It is not limited to a single VM: ten machines running the same operating system share the common part only once. And since *namespaces* live inside the same datastore, you can separate environments (production, staging, customers) without losing that saving. - **The “VM size × number of copies” calculation is useless.** It is the sum everyone does in the first meeting, and it always produces an absurd number. Real consumption is a fraction of it, because what grows is not the number of copies but the volume of data that changes between them. That last point changes the conversation. The useful question is not “how much does each backup take?”, but **“how much data changes per day on this platform?”**. A transactional database and a file server holding documents that barely move can be a similar size on disk and have very different backup storage needs. On the hypervisor side there is a detail that speeds things up considerably: Proxmox VE uses QEMU *dirty bitmaps* to know which blocks of a VM have changed since the last copy, without re-reading the whole disk. That map lives in memory, so it is lost when the machine is shut down or migrated; on the next run PBS will read the full disk again, although it will only transfer and store what is genuinely new. An occasionally slower backup after a maintenance window is not a sign of trouble. ## Verification: finding corruption while it still doesn’t matter The problem with *bit rot* is that it gives no warning. A block can degrade on the media, a hardware or software failure can damage data that was already written, and nothing in the dashboard turns red. The backup still shows up in the list, with its date and its size. The day you need it, it doesn’t open. PBS addresses this with **schedulable verification jobs**: they re-read the stored blocks, recalculate their digests and compare them with the originals. What this achieves is not preventing corruption, but **bringing forward the moment it is discovered**: from the middle of the night during a disaster to an ordinary Tuesday, while a good copy still exists somewhere else and there is room to react. Two operational details make a real difference in large repositories: - Verification can be configured to **skip snapshots already verified** in the last N days, so each pass focuses on what is new instead of re-reading the entire repository every week. - A snapshot that fails verification is flagged. Make sure that flag reaches a person and not just a log entry: a backup marked as faulty and left unattended is exactly as useful as not having one. That said, two things should not be confused. **Verification proves the blocks are intact; it does not prove the service boots.** Whether a database comes up, the application connects and the business can operate is only proven by an actual restore. Verification is the necessary condition; a periodic restore test is the sufficient one. ## Retention and garbage collection: two different things everyone mixes up Here lies the most common misunderstanding about PBS, and the one that fills repositories: ***prune* does not free space**. - **Prune** applies the retention policy and decides which snapshots are no longer needed. It removes the reference to the backup, but it does not touch the blocks: they are deduplicated and very likely still in use by another copy. - **Garbage collection (GC)** is what reclaims space. It walks the datastore, marks the blocks still referenced and removes the orphans. It works with a time safety margin so it never deletes blocks belonging to a backup being written at that moment, which is why freed space does not appear instantly. Both processes are scheduled separately and both must be scheduled. An environment with a retention policy in place but no periodic GC keeps growing until somebody gets a disk-full alert, usually at the weekend. As for the policy itself, PBS lets you build a pyramid with several levels: last N, daily, weekly, monthly and yearly. A reasonable starting point for a production platform: LevelExampleWhat it is forLast3 copiesUndoing a recent mistake (a deployment, a deletion)Daily7Going back to any day in the last weekWeekly4Covering the month with few restore pointsMonthly6-12History and business requirementsYearly1-5Legal or contractual obligations, where they apply The temptation to keep everything “just in case” is understandable, but retention is not a technical decision: it is a business decision and, in some sectors, a regulatory one too. It is worth agreeing it in writing with whoever is accountable for the data, rather than leaving it to whoever configures the job. We cover this in more detail in our article on the difference between backup and data retention. ## Client-side encryption: what makes the remote copy viable PBS encrypts on the client side, on the Proxmox node itself, **before** the data leaves the network, using AES-256-GCM. The backup server stores information it cannot read. That has two practical readings: - It allows you to send copies to a remote location or to an object backend without the destination having to be a point of trust. The data travels encrypted and stays encrypted. - **Lose the key and you lose the backups.** There is no recovery path. The key must be looked after like a critical asset: a copy outside the environment it protects, a printed version in a safe place and a written procedure covering who can access it. One technical detail often catches people out: deduplication still works with encryption enabled, but **only between backups sharing the same key**. Using a different key per customer or per environment is a legitimate isolation decision; you simply need to know that it reduces the space saving, because those sets no longer share blocks. Since version 4.2, sync jobs also handle encryption: *push* jobs encrypt before sending and *pull* jobs can decrypt remote data, with key management centralised alongside tape. ## Taking the copy further away: sync jobs between locations A single repository, however well verified, is still a single point of failure. PBS handles distribution with **sync jobs** between servers or *datastores*: in *pull* mode the destination collects, in *push* mode the source sends. Either way only the missing blocks travel, which makes a daily replica between locations perfectly manageable even with large volumes. Version 4.2 adds concurrent processing of several groups, which is especially noticeable when latency is involved. ## One PBS for several customers: what namespaces are for *Namespaces* are hierarchical subdivisions inside a single datastore, and they are the piece that turns a backup server into a multi-tenant platform. With them, one PBS instance can serve several customers, several business units or several clusters without anything getting mixed up. - **Isolation through permissions.** Each namespace has its own ACLs. A customer, a partner or an internal team only sees its branch of the tree, and API tokens are issued with that scope: there is no way to list, restore or delete what sits next door. - **Policies of their own.** Retention, verification and sync are configured per namespace. A customer keeping seven days of backups and another required to keep years can live in the same repository without one imposing its rules on the other. - **No extra storage cost.** Deduplication remains global within the datastore, so separating customers does not multiply storage. If each customer encrypts with their own key, isolation is stronger but blocks are only shared within each set: that is the price of the separation. - **A target for sync jobs.** A sync job can land each remote source in a specific namespace. That is the usual pattern when several clusters, branches or customers are centralised into a single PBS. This is the architecture used by managed providers and partners offering backup as a service: one repository, many tenants, separate accounts. With two practical caveats. First, there are no hard quotas per namespace: growth is controlled through the retention policy and through monitoring, not by a limit that stops a customer who overshoots. Second, space reclamation (GC) applies to the whole datastore, so maintenance windows are planned globally rather than customer by customer. In 4.2, groups and namespaces can also be moved between locations, which helps when the initial structure falls short —a customer that grows, an environment that needs splitting off— and things need reorganising without redoing backups. ## Backups from inside the machine: proxmox-backup-client and single files So far we have talked about whole-machine backups, which is what you launch from Proxmox VE. But PBS is not limited to that: there is **proxmox-backup-client**, a client installed **inside** the VM, the container or a physical Linux server, which backs up the directories you tell it to, with its own schedule, its own encryption and its own namespace. That changes what can be recovered, and how quickly: - **Recovering a single file** —an attachment deleted by mistake, a configuration file, an application’s data directory— without restoring the whole machine or spinning up a parallel copy just to pull one folder out of it. - **Protecting specific paths at a different frequency.** An application’s data directory can be backed up hourly while the full machine backup stays daily. - **Covering servers outside that cluster:** physical machines, legacy systems or hosts running elsewhere that send their data to the same repository, with the same encryption and the same retention. The workflow is straightforward: install the client, point it at the repository and back up the chosen paths, which travel in *pxar* format and are deduplicated and encrypted like everything else. ``` proxmox-backup-client backup data.pxar:/var/www --repository backup@pb*@*bs.internal:store --ns customer-a ``` Those archives can then be listed or mounted to extract only what is needed, without pulling down the whole set. Think of it as a complement rather than a replacement. The whole-machine backup is what brings the service back after a disaster; the client inside the machine is what solves the “I’ve just wiped a file” moment on a Tuesday morning. For VM backups, Proxmox VE also offers **file-level restore** from the interface itself and **live restore**, which boots the machine while the restore continues in the background; between the three routes, almost every real incident is covered. ## How this lands on a Proxmox private cloud at Stackscale All the theory above boils down to one very concrete question: **where do the blocks live**. At Stackscale we build backup for Proxmox environments on **Archive** storage, accessible over **NFS** or through an **S3-compatible API**, and available in physically separate locations: **two zones in Madrid, more than 10 kilometres apart**, plus a third in **Amsterdam**. That distance is not a brochure detail. It is what keeps two data centres out of the same physical incident —a fire, a flood, a power outage affecting one area— while maintaining metropolitan latencies, low enough that a daily sync, or several a day, never becomes a problem. It is the difference between “we have a copy in another rack” and “we have a copy in another risk zone”. ### Reference architecture LayerWherePurposePrimary datastoreArchive in Madrid, zone A (NFS or S3)Reference copy. Every backup job writes hereReplicaArchive in Madrid, zone B (>10 km) or AmsterdamDaily sync job. Survival if a whole location is lostFast layer (optional)All-flash network storageMost recent copies, for frequent restores and low RTOLocal disk on the PBS hostBackup serverA temporary buffer at most. Never the only repository The design principle is simple: **the reference copy always lives on Archive**, not on the disk of the server running the backups. A local repository depends on the health of one specific machine and adds no redundancy; if that server is lost in the same incident as the cluster, so is the ability to recover. Fast layers are a cache to speed up restores, not the source of truth. With this setup, the 3-2-1 rule stops being a slogan: three copies (production plus two repositories), on different media and systems, with at least one outside the primary location. And all of it with the data in European data centres, something that has moved from a technical preference to a contractual requirement in quite a few sectors. ### An operational calendar that works More important than the architecture is having someone keep it alive. This is a sensible starting calendar for a production platform: TaskIndicative frequencyNoteVM and container backupDaily, in a low-load windowWith bandwidth limits if it shares the network with productionSync to the second locationDaily, after the backup windowOnly new blocks travelVerificationWeekly, skipping what is already verifiedWith an alert to a person, not just to the logPruneDailyApplies the policy; does not free spaceGarbage collectionWeeklyThis is what actually reclaims spaceRestore testQuarterly, and after significant changesRestore and boot, not just verify ## Five mistakes that keep coming up - **Sizing by multiplication.** Calculating storage as size times number of copies leads to unrealistic budgets and to retention policies that are far too short. - **Scheduling prune and forgetting GC.** Space does not come back on its own. - **Confusing verification with a restore test.** They are different controls and neither replaces the other. - **Keeping the encryption key inside the environment it protects.** If the incident takes out the cluster, it takes the key with it. - **Designing only for the big disaster.** Most real restores involve one file or one directory, not an entire data centre; without proxmox-backup-client or file-level restore, every minor incident means bringing up a full VM. - **Leaving the only copy in the same building.** A replica to a second location kilometres away is what turns a backup into a disaster recovery plan. ## Frequently asked questions ### How much space do I really need for 30 days of backups? It depends on how much data changes, not on the total size of the machines. Because deduplication is global within the datastore and backups are incremental, keeping 30 days does not multiply consumption by 30: it is much closer to the size of the first copy plus the accumulated daily change. The sensible approach is to measure the real change rate for a few weeks before finalising the sizing. ### What is the difference between prune and garbage collection? Prune applies the retention policy and removes snapshots from the list, but it does not delete blocks, since they are usually shared with other copies. Garbage collection identifies the blocks no backup references any more and removes them, which is when space is reclaimed. Both need to be scheduled. ### If I verify my backups, do I still need to test restores? Yes. Verification checks that the stored blocks are intact; it does not check that the system boots, that the database is consistent or that the application works. A periodic restore test, with the service actually starting up, is the only control that validates the whole chain. ### Is it safe to keep backups in a remote location? With client-side encryption, yes: data is encrypted with AES-256-GCM on the Proxmox node before it leaves and the destination cannot read it. The trade-off is key custody: without the key there is no restore, so it must be stored outside the environment it protects. ### Why does it matter that the two Madrid zones are more than 10 km apart? Because it keeps both locations out of the same physical incident —fire, flood, an area-wide power cut— while maintaining metropolitan latencies. It allows copies to be synced daily, or several times a day, with no operational penalty, and it meets the geographic separation requirements of a continuity plan without leaving Spain. ### Can I serve several customers from a single Proxmox Backup Server? Yes, using namespaces. Each customer works in its own branch of the datastore, with independent permissions, API tokens, retention and verification, while deduplication stays global so you pay no storage penalty for separating them. Bear in mind that there are no hard quotas per namespace and that space reclamation affects the whole datastore. ### Can I recover a single file without restoring the whole machine? Yes, in two ways. On a VM backup, Proxmox VE offers file-level restore straight from the interface. And if you install proxmox-backup-client inside the machine, you can back up the paths you care about on their own schedule and then list or mount them to extract only what you need. ## In short Proxmox Backup Server does the hard part well: storing little, catching corruption in time and returning data quickly. What it cannot decide for us is how long things are kept, where the second copy lives, who holds the keys and how often a real restore is tested. Those four decisions are what separate a backup that gives peace of mind from one that only looks like it does. At Stackscale we design the whole set —Proxmox cluster, PBS and Archive storage across several locations— as a single piece. If you are building or reviewing the backup strategy of your Proxmox environment, let’s talk it through. Request information form EN Notify NameEmailPhoneI am interested in:Cloud solutionsBare Metal solutionsManaged ServicesBackup and Disaster Recovery solutionsColocation servicesCDN solutionsTell us more about your needs I give my consent to receiving customized commercial communications about Stackscale products and services (including the newsletter), by any channel, including electronic ones. I have read and accept the privacy policy. Submit The Stackscale Group processes the information you provide in order to respond to your request regarding the services we deliver and the products we provide. The data provided will be stored while we stay in contact and deleted when the request is closed, unless you consent to receiving sales communications, in which case your data will be stored until the previously given consent is revoked. As part of the Group to which Stackscale belongs, we inform you that your data will be communicated to the companies of Grupo Aire for corporate reasons. You can consult the companies integrating Grupo Aire at: https://grupoaire.es. You can exercise your rights of access, rectification, erasure, disagreement, limitation of the processing and, when legally appropriate, portability, by sending a request to Stackscale to the address dp*@********le.com, indicating the right you exercise and providing a double-sided photocopy of your identification. Additionally, you will be able to present a complaint to the Dutch Data Protection Authority, especially when you are not content with the exercise of your rights, via https://autoriteitpersoonsgegevens.nl/en. --- ## Proxmox Backup Server a fondo: deduplicación, verificación y retención en un cloud privado URL: https://www.stackscale.com/blog/proxmox-backup-server-deduplication-verification-retention/ Casi nadie mira los backups hasta el día en que hacen falta. Ese día llegan todas las preguntas de golpe: ¿existe la copia?, ¿está íntegra?, ¿de cuándo es?, ¿cuánto tarda en restaurar?, ¿está en el mismo sitio que el sistema que acaba de caer? Y la peor de todas: ¿alguien ha probado alguna vez que esto funciona? En entornos Proxmox VE, **Proxmox Backup Server (PBS)** responde a esas preguntas mejor que la mayoría de alternativas del ecosistema open source. Ya publicamos una introducción a Proxmox Backup Server y a su encaje con el almacenamiento Archive de Stackscale. Este artículo va un paso más allá y entra en la mecánica: qué hace exactamente la deduplicación, por qué la verificación no es opcional, en qué se diferencian *prune* y *garbage collection*, cómo un mismo servidor puede dar servicio a varios clientes sin mezclar nada, cómo recuperar un fichero suelto sin tocar la máquina entera, y cómo se traduce todo eso en decisiones de diseño cuando la infraestructura vive en un cloud privado con almacenamiento en dos zonas de Madrid separadas por más de 10 kilómetros. ## PBS no es «otro software de copias» Proxmox Backup Server es una distribución Linux basada en Debian, escrita en gran parte en Rust y publicada bajo licencia GNU AGPLv3. Está pensada para una sola cosa: guardar y devolver datos de máquinas virtuales, contenedores y servidores físicos. La versión **4.2**, publicada en abril de 2026, se apoya en Debian 13.4 «Trixie», kernel Linux 7.0 y ZFS 2.4, e incorpora soporte oficial para backends de objetos compatibles con S3, cifrado en los trabajos de sincronización y procesamiento concurrente de grupos. La diferencia práctica frente a un volcado tradicional a disco o a un NAS está en tres mecanismos que trabajan juntos: **deduplicación** (cuánto ocupa), **verificación** (si sirve) y **retención** (cuánto tiempo se guarda y cuándo se libera el espacio de verdad). Quien entiende esos tres, dimensiona bien. Quien no, acaba con un repositorio lleno, copias que nadie ha comprobado y una restauración que se convierte en experimento. ## Deduplicación: por qué 30 copias no ocupan 30 veces PBS no guarda ficheros de backup monolíticos. Trocea los datos en bloques —*chunks*, de unos 4 MiB de media—, calcula el resumen criptográfico SHA-256 de cada uno y lo almacena una única vez dentro del *datastore*. Si mañana ese mismo bloque vuelve a aparecer, el backup solo anota una referencia. Tres consecuencias que conviene tener claras antes de dimensionar nada: - **Todos los backups son incrementales, pero se restauran como completos.** Después de la primera copia, cada ejecución solo añade los bloques nuevos. Al restaurar no hay cadenas de incrementales que reconstruir: cualquier *snapshot* se recupera por sí mismo. - **La deduplicación es global dentro del datastore.** No se limita a una VM: diez máquinas con el mismo sistema operativo comparten la parte común una sola vez. Y como los *namespaces* viven dentro del mismo datastore, se pueden separar entornos (producción, preproducción, clientes) sin perder ese ahorro. - **El cálculo «tamaño de la VM × número de copias» no sirve.** Es la cuenta que todo el mundo hace en la primera reunión y siempre sale un número desproporcionado. El consumo real es una fracción, porque lo que crece no es el número de copias sino el volumen de datos que cambia entre ellas. Ese último punto cambia la conversación. La pregunta útil no es «¿cuánto ocupa cada backup?», sino **«¿cuántos datos cambian al día en esta plataforma?»**. Una base de datos transaccional y un servidor de ficheros con documentos que casi no se tocan tienen tamaños parecidos en disco y necesidades de almacenamiento de backup muy distintas. En la parte del hipervisor hay un detalle que acelera mucho el proceso: Proxmox VE usa los *dirty bitmaps* de QEMU para saber qué bloques de una VM se han modificado desde la última copia, sin releer el disco entero. Ese mapa vive en memoria, así que se pierde cuando la máquina se apaga o migra; en la siguiente ejecución PBS releerá el disco completo, aunque solo transferirá y almacenará lo que realmente sea nuevo. Un backup ocasionalmente más lento después de un mantenimiento no es un síntoma de avería. ## Verificación: descubrir la corrupción cuando todavía no importa El problema del *bit rot* es que no avisa. Un bloque puede degradarse en el soporte, un fallo de hardware o de software puede dañar datos que ya estaban escritos, y nada en el panel se pone en rojo. El backup sigue apareciendo en la lista, con su fecha y su tamaño. El día que se necesita, no abre. PBS resuelve esto con **trabajos de verificación programables**: releen los bloques almacenados, recalculan sus resúmenes y los comparan con los originales. Lo que consigue no es evitar la corrupción, sino **adelantar el momento en que se descubre**: de la madrugada de un desastre a un martes cualquiera, cuando todavía existe la copia buena en otro sitio y hay margen para reaccionar. Dos matices operativos que marcan la diferencia en repositorios grandes: - La verificación se puede configurar para **saltar los snapshots ya verificados** en los últimos N días, de forma que cada pasada se centre en lo nuevo en lugar de releer el repositorio entero cada semana. - Un snapshot que falla la verificación queda marcado. Conviene tener una alerta que llegue a alguien y no solo un registro en la interfaz: un backup marcado como defectuoso y no atendido es exactamente igual de útil que no tenerlo. Ahora bien, conviene no confundir dos cosas. **Verificar demuestra que los bloques están íntegros; no demuestra que el servicio arranque.** Que una base de datos levante, que la aplicación conecte y que el negocio pueda operar solo lo demuestra una restauración real. La verificación es la condición necesaria; la prueba de restauración periódica es la suficiente. ## Retención y garbage collection: dos cosas distintas que todo el mundo mezcla Aquí está el malentendido más frecuente con PBS, y el que llena repositorios: **el *prune* no libera espacio**. - **Prune** aplica la política de retención y decide qué snapshots dejan de ser necesarios. Elimina la referencia al backup, pero no toca los bloques: están deduplicados y muy probablemente los siga usando otra copia. - **Garbage collection (GC)** es quien recupera el espacio. Recorre el datastore, marca los bloques que siguen referenciados y elimina los huérfanos. Trabaja con un margen de seguridad temporal para no borrar bloques de un backup que se esté escribiendo en ese momento, así que el espacio liberado no aparece de forma instantánea. Los dos procesos se programan por separado y los dos deben estar programados. Un entorno con retención configurada y sin GC periódica crece hasta que alguien recibe un aviso de disco lleno, normalmente en fin de semana. Sobre la política en sí, PBS permite construir una pirámide con varios niveles: últimos N, diarios, semanales, mensuales y anuales. Un punto de partida razonable para una plataforma de producción: NivelEjemploPara qué sirveÚltimos3 copiasDeshacer un error reciente (un despliegue, un borrado)Diarios7Volver a cualquier día de la última semanaSemanales4Cubrir el mes con pocos puntosMensuales6-12Histórico y requisitos de negocioAnuales1-5Obligaciones legales o contractuales, cuando existan La tentación de guardarlo todo «por si acaso» es comprensible, pero la retención no es una decisión técnica: es una decisión de negocio y, en algunos sectores, también normativa. Merece la pena pactarla por escrito con quien responde de los datos, y no dejarla al criterio de quien configura el trabajo. Lo explicamos con más detalle en este artículo sobre la diferencia entre retención de datos y copias de seguridad. ## Cifrado en cliente: la pieza que hace viable la copia remota PBS cifra en el lado del cliente, en el propio nodo Proxmox, **antes** de que los datos salgan por la red, con AES-256-GCM. El servidor de backup guarda información que no puede leer. Esto tiene dos lecturas prácticas: - Permite enviar copias a una ubicación remota o a un backend de objetos sin que el destino sea un punto de confianza. El dato viaja cifrado y se queda cifrado. - **Quien pierde la clave, pierde los backups.** No hay recuperación posible. La clave hay que custodiarla como un activo crítico: copia fuera del entorno que protege, versión impresa en un sitio seguro y un procedimiento escrito de quién puede acceder a ella. Un detalle técnico que suele sorprender: la deduplicación sigue funcionando con cifrado activo, pero **entre backups que comparten la misma clave**. Usar una clave distinta por cliente o por entorno es una decisión legítima de aislamiento; simplemente hay que saber que reduce el ahorro de espacio, porque ya no se comparten bloques entre esos conjuntos. Desde la versión 4.2, además, los trabajos de sincronización también manejan cifrado: los *push* cifran antes de enviar y los *pull* pueden descifrar datos remotos, con la gestión de claves centralizada junto a la de cinta. ## Llevar la copia lejos: sync jobs entre ubicaciones Un repositorio único, por bien verificado que esté, sigue siendo un único punto de fallo. PBS resuelve la distribución con **trabajos de sincronización** entre servidores o *datastores*: en modo *pull*, el destino recoge; en modo *push*, el origen empuja. En ambos casos solo viajan los bloques que faltan, con lo que una réplica diaria entre ubicaciones es perfectamente asumible incluso con volúmenes grandes. La 4.2 añade procesamiento concurrente de varios grupos, lo que se nota especialmente cuando hay latencia de por medio. ## Un solo PBS para varios clientes: para qué sirven los namespaces Los *namespaces* son subdivisiones jerárquicas dentro de un mismo datastore, y son la pieza que convierte un servidor de backup en una plataforma multicliente. Con ellos, un único PBS puede dar servicio a varios clientes, a varias unidades de negocio o a varios clústeres sin que nada se mezcle. - **Aislamiento por permisos.** Cada namespace tiene sus propias ACL. Un cliente, un partner o un equipo interno solo ve su rama del árbol, y los tokens de API se emiten con ese alcance: no hay forma de listar, restaurar ni borrar lo que hay al lado. - **Políticas propias.** Retención, verificación y sincronización se configuran por namespace. Un cliente con siete días de copias y otro con obligación de conservar años conviven en el mismo repositorio sin que uno imponga sus reglas al otro. - **Sin coste extra de espacio.** La deduplicación sigue siendo global dentro del datastore, así que separar clientes no multiplica el almacenamiento. Si cada cliente cifra con su propia clave, el aislamiento es mayor pero los bloques ya solo se comparten dentro de cada conjunto: es el precio de esa separación. - **Destino de sincronizaciones.** Un sync job puede volcar cada origen remoto en un namespace concreto. Es el patrón habitual cuando se centralizan varios clústeres, varias delegaciones o varios clientes en un único PBS. Es la arquitectura que usan proveedores gestionados y partners que ofrecen backup como servicio: un repositorio, muchos inquilinos, cuentas separadas. Con dos avisos prácticos. El primero, que no existen cuotas duras por namespace: el crecimiento se controla con la política de retención y con monitorización, no con un límite que frene al cliente que se pase. El segundo, que la recuperación de espacio (GC) es del datastore completo, así que las ventanas de mantenimiento se planifican globalmente y no cliente a cliente. En la 4.2, además, los grupos y namespaces pueden moverse de ubicación, algo útil cuando la estructura inicial se queda corta —un cliente que crece, un entorno que se separa— y hay que reorganizar sin rehacer backups. ## Copias dentro de la máquina: proxmox-backup-client y ficheros sueltos Hasta aquí hemos hablado de copias de la máquina completa, que es lo que se lanza desde Proxmox VE. Pero PBS no se limita a eso: existe **proxmox-backup-client**, un cliente que se instala **dentro** de la propia VM, del contenedor o de un servidor físico Linux, y que copia los directorios que tú le indiques, con su propio calendario, su propio cifrado y su propio namespace. Eso cambia qué se puede recuperar y con qué rapidez: - **Recuperar un fichero suelto** —un adjunto borrado por error, un fichero de configuración, el directorio de datos de una aplicación— sin restaurar la máquina entera ni levantar una copia en paralelo para sacar de ella una carpeta. - **Proteger rutas concretas con otra frecuencia.** El directorio de datos de una aplicación puede copiarse cada hora mientras la copia completa de la máquina sigue siendo diaria. - **Cubrir servidores que no están en ese clúster:** equipos físicos, sistemas heredados o máquinas alojadas en otro sitio que envían sus datos al mismo repositorio, con el mismo cifrado y la misma retención. La operativa es sencilla: se instala el cliente, se define el repositorio y se lanza la copia de las rutas elegidas, que viajan en formato *pxar*, se deduplican y se cifran igual que el resto. ``` proxmox-backup-client backup datos.pxar:/var/www --repository backup@pb*@*bs.interno:almacen --ns cliente-a ``` Después, esos archivos se pueden listar o montar para extraer solo lo que hace falta, sin descargar el conjunto. Conviene verlo como un complemento, no como un sustituto. La copia de la máquina completa es la que devuelve el servicio tras un desastre; el cliente instalado dentro es el que resuelve el «me he cargado un fichero» de un martes por la mañana. Para las copias de VM, Proxmox VE también permite **recuperación a nivel de fichero** desde la propia interfaz y **live restore**, que arranca la máquina mientras la restauración sigue por detrás; entre las tres vías se cubren casi todos los incidentes reales. ## Cómo se aterriza esto en un cloud privado Proxmox en Stackscale Toda la teoría anterior se traduce en una pregunta muy concreta: **dónde viven los bloques**. En Stackscale trabajamos el backup de entornos Proxmox sobre almacenamiento **Archive**, accesible por **NFS** o por **API compatible con S3**, y disponible en ubicaciones físicamente separadas: **dos zonas en Madrid, a más de 10 kilómetros de distancia entre sí**, y una tercera en **Ámsterdam**. Esa distancia no es un detalle de folleto. Es lo que separa dos centros de datos de un mismo incidente físico —un incendio, una inundación, un corte de suministro en una zona— manteniendo a la vez latencias metropolitanas, suficientemente bajas como para que una sincronización diaria, o incluso varias al día, no se convierta en un problema. Es la diferencia entre «tenemos una copia en otro rack» y «tenemos una copia en otra zona de riesgo». ### Arquitectura de referencia CapaDóndePara quéDatastore principalArchive en Madrid, zona A (NFS o S3)Copia de referencia. Todos los trabajos de backup escriben aquíRéplicaArchive en Madrid, zona B (>10 km) o ÁmsterdamSync job diario. Supervivencia ante la pérdida completa de una ubicaciónCapa rápida (opcional)Almacenamiento en red all-flashÚltimos días de copias, para restauraciones frecuentes y RTO bajoDisco local del PBSServidor de backupBuffer temporal como mucho. Nunca como repositorio único El principio de diseño es simple: **la copia de referencia vive siempre en Archive**, no en el disco del servidor que hace los backups. Un repositorio local depende de la salud de una máquina concreta y no aporta redundancia; si ese servidor se pierde en el mismo incidente que el clúster, se pierde también la capacidad de recuperar. Las capas rápidas son una caché para acelerar restauraciones, no la fuente de verdad. Con este esquema, la regla 3-2-1 deja de ser un eslogan: tres copias (producción más dos repositorios), en soportes y sistemas distintos, con al menos una fuera de la ubicación primaria. Y todo ello con los datos en centros de datos europeos, un punto que ha dejado de ser una preferencia técnica para convertirse en un requisito contractual en bastantes sectores. ### Un calendario operativo que funciona Más importante que la arquitectura es que alguien la mantenga viva. Este es un calendario de partida razonable para una plataforma de producción: TareaFrecuencia orientativaNotaBackup de VMs y contenedoresDiario, en ventana de baja cargaCon límites de ancho de banda si comparte red con producciónSync a la segunda ubicaciónDiario, tras la ventana de backupSolo viajan bloques nuevosVerificaciónSemanal, saltando lo ya verificadoCon alerta a una persona, no solo al logPruneDiarioAplica la política; no libera espacioGarbage collectionSemanalEs la que recupera espacio de verdadPrueba de restauraciónTrimestral, y tras cambios relevantesRestaurar y arrancar, no solo verificar ## Cinco errores que se repiten - **Dimensionar multiplicando.** Calcular el almacenamiento como tamaño por número de copias lleva a presupuestos irreales y a decisiones de retención demasiado cortas. - **Programar prune y olvidar GC.** El espacio no vuelve solo. - **Confundir verificación con prueba de restauración.** Son controles distintos y ninguno sustituye al otro. - **Guardar la clave de cifrado dentro del entorno que protege.** Si el incidente se lleva el clúster, se lleva la clave. - **Diseñar solo para el desastre grande.** La mayoría de las restauraciones reales son de un fichero o un directorio, no de un centro de datos entero; sin proxmox-backup-client o recuperación a nivel de fichero, cada incidente menor obliga a levantar una VM completa. - **Dejar la única copia en el mismo edificio.** Una réplica a una segunda ubicación separada por kilómetros es lo que convierte un backup en un plan de recuperación ante desastres. ## Preguntas frecuentes ### ¿Cuánto espacio necesito realmente para 30 días de copias? Depende del volumen de datos que cambie, no del tamaño total de las máquinas. Como la deduplicación es global dentro del datastore y los backups son incrementales, mantener 30 días no multiplica por 30 el consumo: se acerca mucho más al tamaño de la primera copia más el cambio diario acumulado. Lo prudente es medir el cambio real durante unas semanas antes de cerrar el dimensionamiento. ### ¿Qué diferencia hay entre prune y garbage collection? El prune aplica la política de retención y elimina snapshots de la lista, pero no borra bloques porque suelen estar compartidos con otras copias. La garbage collection identifica los bloques que ya no referencia ningún backup y los elimina, que es cuando se recupera espacio. Hay que programar las dos. ### Si verifico los backups, ¿hace falta probar restauraciones? Sí. La verificación comprueba que los bloques almacenados están íntegros; no comprueba que el sistema arranque, que la base de datos sea consistente ni que la aplicación funcione. Una prueba de restauración periódica, con arranque real del servicio, es el único control que valida el conjunto. ### ¿Es seguro guardar backups en una ubicación remota? Con cifrado en cliente, sí: los datos se cifran con AES-256-GCM en el nodo Proxmox antes de salir y el destino no puede leerlos. La contrapartida es la custodia de la clave: sin ella no hay restauración posible, así que debe guardarse fuera del entorno que protege. ### ¿Por qué importa que las dos zonas de Madrid estén a más de 10 km? Porque separa ambas ubicaciones de un mismo incidente físico —incendio, inundación, corte eléctrico de zona— manteniendo latencias metropolitanas. Permite sincronizar copias a diario, o varias veces al día, sin penalización operativa, y cumplir los requisitos de separación geográfica de un plan de continuidad sin salir de España. ### ¿Puedo dar servicio a varios clientes con un único Proxmox Backup Server? Sí, mediante namespaces. Cada cliente trabaja en su propia rama del datastore, con permisos, tokens de API, retención y verificación independientes, mientras la deduplicación sigue siendo global y no se paga espacio por separarlos. Hay que tener en cuenta que no existen cuotas duras por namespace y que la recolección de espacio afecta al datastore completo. ### ¿Puedo recuperar un fichero suelto sin restaurar toda la máquina? Sí, por dos vías. Sobre una copia de la VM, Proxmox VE permite recuperación a nivel de fichero desde la interfaz. Y si instalas proxmox-backup-client dentro de la máquina, puedes copiar las rutas que te interesen con su propio calendario y luego listarlas o montarlas para extraer solo lo que necesitas. ## En resumen Proxmox Backup Server hace bien la parte difícil: almacenar poco, detectar la corrupción a tiempo y devolver los datos rápido. Lo que no puede hacer por nosotros es decidir cuánto tiempo se guardan las cosas, dónde vive la segunda copia, quién custodia las claves y cada cuánto se prueba una restauración de verdad. Esas cuatro decisiones son las que separan un backup que tranquiliza de uno que solo lo parece. En Stackscale diseñamos ese conjunto —clúster Proxmox, PBS y almacenamiento Archive en varias ubicaciones— como una sola pieza. Si estás montando o revisando la estrategia de copias de tu entorno Proxmox, hablamos y la revisamos contigo. Request information form ES Updates NombreEmailTeléfonoEstoy interesado/a en:Soluciones cloudSoluciones Bare MetalServicios gestionadosSoluciones de Disaster Recovery y backupServicios de housingSoluciones de CDNCuéntanos más sobre tus necesidades Acepto el envío de comunicaciones comerciales personalizadas sobre los productos y servicios de Stackscale (incluida la newsletter), por cualquier medio, incluidos los electrónicos. He leído y acepto la política de privacidad. Enviar El Grupo Stackscale trata la información que nos facilita con el fin de dar respuesta a la solicitud realizada en relación con los servicios que prestamos y los productos que suministramos. Los datos proporcionados se conservarán mientras se mantenga el contacto siendo eliminados una vez finalizada la solicitud, a no ser que consienta el envío de comunicaciones comerciales, donde sus datos se conservarán hasta la revocación del consentimiento previamente otorgado. En el marco del Grupo al que pertenece Stackscale, se le informa de que sus datos serán comunicados a las empresas de Grupo Aire por motivos corporativos. Puede consultar las empresas que forman parte del Grupo Aire en: https://grupoaire.es. Usted puede ejercitar sus derechos de acceso, rectificación, supresión, oposición, limitación del tratamiento y, cuando legalmente proceda, portabilidad, mediante el envío a Stackscale de una solicitud a la dirección dp*@********le.com, indicando el derecho que ejercita y aportando una fotocopia por las dos caras de su DNI o documento legal de identificación de su identidad. Igualmente, podrá presentar una reclamación ante la Agencia Española de Protección de Datos, especialmente cuando no haya obtenido la satisfacción en el ejercicio de sus derechos, a través de la sede electrónica en www.aepd.es. --- ## 4 aspectos clave al elegir una solución de Disaster Recovery URL: https://www.stackscale.com/blog/key-aspects-choosing-disaster-recovery-solution/ **Elegir una solución de Disaster Recovery (o recuperación ante desastres) en lugar de otra es una decisión importante** para cualquier empresa, teniendo en cuenta el fuerte impacto que un ataque o desastre puede tener en los beneficios de un negocio. A medida que cada vez más organizaciones y servicios se digitalizan, y que el número de ciberataques a nivel mundial sigue creciendo, la planificación de la recuperación ante desastres se ha convertido en algo **indispensable para garantizar la continuidad del negocio**. Así que, entre tantas soluciones de DR, es útil tener algunos aspectos clave en mente para decantarse por la más adecuada para cada negocio. La elección se decide antes de lo que parece, porque casi todo lo que viene después depende de dos cifras que fija el negocio y no el proveedor: cuánto tiempo puede estar parada la actividad, que es el RTO, y cuántos datos se puede permitir perder desde la última copia, que es el RPO. Los cuatro aspectos que recorre este artículo —el sitio de recuperación, la georedundancia, el tipo de replicación y la escalabilidad— son las palancas con las que se construye una arquitectura capaz de sostener esas dos cifras. Fijarlas antes de elegir tecnología evita la conversación más cara del sector, que es descubrir el RTO real el día del incidente. Pero lo primero es lo primero. ## ¿Por qué es importante contar con una solución de DR? El **aumento del número de desastres y ciberataques**, así como la aceleración de los procesos de transformación digital entre las organizaciones ha puesto el foco en las soluciones de Disaster Recovery, ya que son esenciales para **garantizar las operaciones de negocio normales en todo momento** independientemente de que un incidente o ataque pueda afectar al sitio principal de la empresa. Sin embargo, la mayoría de las organizaciones suelen prestarle atención cuando ya es demasiado tarde. Las siguientes cifras subrayan la importancia de las soluciones de DR. Según el informe de ciberseguridad 2026 de Check Point Research, las organizaciones sufrieron **una media de 1.968 ciberataques por semana en 2025, un 70 % más que en 2023**. El mismo informe señala a la inteligencia artificial como acelerador del panorama de amenazas, tanto en el volumen de ataques como en su sofisticación. ## Aspectos clave a tener en cuenta al elegir una solución de Disaster Recovery Elegir una solución de Disaster Recovery adaptada a las necesidades del negocio, es esencial para **construir una estrategia de DR**. Aquí van algunos aspectos importantes a tener en cuenta para que sea un éxito. * ### Sitio de recuperación Empecemos por algo tan simple como contar con un **sitio en el que recuperar servicios** en caso de incidente. Es decir, un entorno o centro de datos secundario en el que **mantener las operaciones en marcha en caso de fallo**. Al elegir un sitio de recuperación ante desastres, las organizaciones suelen tener que decidir entre **optar por un sitio caliente, un sitio templado o un sitio frío**, según sus objetivos de recuperación, presupuesto, etc. #### Cold sites* o sitios fríos En primer lugar, **un *****cold site***** consiste en un espacio alquilado en el que poder restaurar las operaciones** en caso de desastre en el entorno principal de la empresa. Sin embargo, esta opción no incluye ni hardware ni software. La **configuración de los sitios fríos para restaurar las operaciones** desde el entorno productivo al de respaldo conlleva más tiempo. No solo es necesario restaurar los backups sino que también hay que instalar hardware. De modo que también requiere de más personal técnico disponible para poner en funcionamiento la infraestructura en caso de emergencia. Esta es la **opción más barata pero también la más limitada** de las tres, ya que su puesta en marcha podría llevar días o incluso semanas. Puede ser una opción básica de DR para empresas que mantengan su entorno de TI *on-premise* y deseen contar con una solución de Disaster Recovery en remoto a modo de housing. #### *Warm sites* o sitios templados En segundo lugar, **un *****warm site***** consiste en tener un entorno de respaldo disponible y configurado en el que conmutar **las aplicaciones y sistemas en caso de fallo en el CPD principal. Por lo tanto, es una solución intermedia entre un *cold site* y un *hot site*. Este entorno de respaldo preconfigurado puede estar tanto encendido como apagado. En este caso, sigue siendo necesario restaurar los backups y réplicas en la infraestructura reservada para Disaster Recovery. Sin embargo, requiere de menos personal técnico para hacerlo. Los sitios templados ofrecen **un equilibrio entre tolerancia y costes razonables**. Además, los negocios pueden mejorar aún más sus objetivos de recuperación combinándolos con snapshots de almacenamiento georeplicado automáticamente. #### *Hot sites* o sitios calientes Por último, **un *hot site* es una copia del entorno productivo en una infraestructura diferente y que funciona de forma simultánea**. Esta opción proporciona el mayor grado de alta disponibilidad y tolerancia a fallos, ya que los sistemas están replicados para que el entorno de respaldo empiece a funcionar sin interrupciones en caso de fallo en el sistema principal. Esta configuración también se conoce como «clúster activo-activo». * Esta es la opción óptima para la continuidad del negocio pero también la más costosa, porque requiere de redundancia completa en el hardware y el software. Por el contrario, cuando los sistemas conmutan por error al datacenter de recuperación, solo es necesario verificar que todo funciona correctamente. Los sitios calientes son **ideales para aplicaciones de misión crítica que no permiten ningún tiempo de inactividad** para recuperar datos. Son especialmente recomendables para aquellas compañías que necesiten un RTO por debajo de 1 hora. En resumen, en lo que concierne a los sitios de recuperación, los costes son inversamente proporcionales a la tolerancia. A medida que la tolerancia disminuye, los costes aumentan. De modo que la mejor opción para cada empresa dependerá de la evaluación de riesgos y objetivos definidos en su plan de Disaster Recovery. TipoCómo está preparadoRecuperación habitualCoste**Frío — cold site***Solo copias de seguridad, imágenes, infraestructura mínima o código para reconstruir el entornoHoras, días o másBajo**Templado — *warm site***Entorno parcialmente desplegado o reducido, con datos replicados o copias recientesMinutos u horasMedio**Caliente — *hot site***Réplica completa funcionando de forma continua y, normalmente, sincronizadaSegundos o minutosAlto Ninguna de las tres es la respuesta correcta por defecto. La combinación adecuada depende del RTO y del RPO que el negocio necesite sostener, y de cuánto de eso justifica el coste. En Stackscale ese dimensionado se hace por proyecto, sobre una solución gestionada de Disaster Recovery y backup diseñada para las cifras acordadas con cada cliente. ### Georedundancia Asimismo, a la hora de elegir la solución más adecuada en cuanto al sitio de recuperación, la georedundancia es otro aspecto clave a tener en cuenta para mejorar la disponibilidad, la resiliencia y la tolerancia a fallos. Optar por un **entorno de respaldo remoto**, en un datacenter cruzado, mejora considerablemente el RTO en caso de contingencia grave en el datacenter principal. ** Contar con centros de datos distribuidos geográficamente contribuye a construir una estrategia de continuidad del negocio más sólida**. Ya que proporciona protección adicional frente a desastres que afecten al centro de datos principal. Asimismo, en lo que respecta a las **soluciones de DR a nivel de almacenamiento**, la redundancia geográfica tampoco debe pasarse por alto. Tener backups en una ubicación remota es recomendable para **evitar perder datos y mejorar el RPO del negocio**. La georeplicación de datos proporciona una capa extra de seguridad. Por eso los volúmenes de almacenamiento en red de Stackscale —Flash Premium, Flash Plus y Standard— se georeplican por defecto en un datacenter diferente. ### Replicación síncrona o asíncrona Según los requisitos del negocio, otro aspecto a considerar al elegir una solución de Disaster Recovery es la necesidad de replicar los datos de forma síncrona o asíncrona a una ubicación remota. Por un lado, la **replicación síncrona** escribe los datos de forma simultánea en el almacenamiento principal y en la réplica. Es decir, la replicación tiene lugar en tiempo real y, por lo tanto, el RPO es igual a 0. Esta configuración permite disponer de failover a la solución de Disaster Recovery con **prácticamente ningún tiempo de inactividad**. Por eso se usa principalmente para aplicaciones transaccionales de gama alta que requieren una tolerancia a fallos instantánea. Es más cara que la replicación asíncrona porque requiere mayor ancho de banda e incluso hardware especializado. Por otro lado, la **replicación asíncrona** escribe los datos en la réplica en base a una programación; por ejemplo, cada hora, cada 6 horas o diaria. Por lo tanto, aunque puede hacerse casi en tiempo real, no es simultáneo. Esta configuración está **diseñada especialmente para funcionar en largas distancias**, ya que puede tolerar cierta degradación en la conectividad. Se suele usar para copias de seguridad y snapshots de datos, y en máquinas virtuales. En entornos Proxmox, esta es la capa que cubre Proxmox Backup Server, con copias incrementales y deduplicadas que mantienen corta la ventana de replicación sin saturar el enlace entre ubicaciones. No suele necesitar hardware especializado y **requiere considerablemente menos ancho de banda**. Así que su coste es menor que el de la replicación síncrona. No obstante, existe el riesgo de pérdida de datos entre la última réplica programada y un posible incidente. ### Escalabilidad También es sensato pensar en la escalabilidad para garantizar que la solución de Disaster Recovery de la empresa pueda **crecer junto con las necesidades del negocio**. Las organizaciones nunca deberían encontrarse en la posición de elegir entre qué datos pueden respaldar y cuáles no, por cuestiones de capacidad. En Stackscale ayudamos a las empresas a elegir una solución gestionada de Disaster Recovery y backup adaptada a sus objetivos y necesidades. No dudes en contactar con nuestro equipo para más información. --- ## 4 Key aspects when choosing a Disaster Recovery solution URL: https://www.stackscale.com/blog/key-aspects-choosing-disaster-recovery-solution/ **Choosing a Disaster Recovery solution over another is an important decision** for any company, considering the serious impact an attack or disaster has on business profits. Since more and more organizations and services are digitized, and the number of cyberattacks worldwide continue to rise, Disaster Recovery planning has become **indispensable for ensuring business continuity**. Therefore, as DR solutions come in many shapes, it is useful to keep some key aspects in mind to opt for the right one for each business. The choice is settled earlier than it looks, because almost everything that follows depends on two figures the business sets rather than the provider: how long operations can stay down, which is the RTO, and how much data can be lost since the last copy, which is the RPO. The four aspects covered in this article, the recovery site, geo-redundancy, the type of replication and scalability, are the levers used to build an architecture capable of sustaining those two figures. Setting them before choosing technology avoids the most expensive conversation in the industry, which is discovering the real RTO on the day of the incident. But first things first! ## Why is it important to have a DR solution? The **rise in the amount of disasters and cyberattacks**, and the acceleration of digital transformation processes among organizations brings Disaster Recovery solutions into focus. As they are essential to **guarantee normal business operations at all times** regardless of any incident or attack that might impact a company’s main site. However, most organizations usually pay attention to it when it is too late. The following numbers highlight the importance of DR solutions. According to Check Point Research’s 2026 Cyber Security Report, organizations faced **an average of 1,968 cyberattacks per week in 2025 — a 70% increase since 2023**. The same report points to artificial intelligence as an accelerator of the threat landscape, both in the volume of attacks and in their sophistication. ## Key aspects to consider when choosing a Disaster Recovery solution Choosing a Disaster Recovery solution adapted to the business needs is essential when **building a DR strategy**. Here are some important aspects to consider for success. ### Recovery site Let’s start with something as simple as having a **site for recovering services** in case of incident. It is to say, a secondary environment or data center where **keeping operations uninterrupted in case of failure**. When choosing a disaster recovery site, organizations must usually decide if **opting for a cold site, a warm site or a hot site**, depending on their recovery objectives, budget, etc. #### Cold sites Firstly, **a cold site consists of a rented space where operations can be restored** in case of a disaster in the company’s primary environment. However, this option does not include any hardware or software.  Cold sites entail **longer setup times to restore normal operations** from the production to the recovery environment. Not only is it necessary to restore backups but also to install hardware. That is why it also requires a higher number of technical staff available to set the infrastructure up in case of emergency. This is **the cheapest but also the most limited option** of all three, since setting it up can take days and even weeks. It can be a basic DR choice for companies that still have their IT environment on-premise and wish to have a remote Disaster Recovery solution on a colocation facility. #### Warm sites Secondly, **a warm site consists of having a recovery environment available and set up to failover** applications and systems in case of an emergency in the primary datacenter. Thus, it is a halfway solution between a cold and a hot site. This pre-configured recovery environment can remain either on or off. In this case, backups and replicas must still be restored in the infrastructure reserved for Disaster Recovery. However, it requires a lower number of technical staff to do so. Warm sites offer **a balance between tolerance and affordable costs**. Besides, businesses can further improve their recovery objectives by combining it with automatically geo-replicated storage snapshots. #### Hot sites Finally, **a hot site is a copy of the production environment in a different infrastructure, running simultaneously** with it. This option provides the highest degree of High Availability and fault tolerance, as systems are mirrored so that the recovery system takes over without any downtime in case of failure in the primary system. This configuration is also known as “active-active cluster”. This is the optimal option for business continuity but also the most expensive one, because it requires complete redundancy in hardware and software. On the contrary, it is only necessary to check everything is running properly when systems failover to the recovery datacenter. Hot sites are **ideal for mission-critical applications that do not allow any downtime** for data recovery. It is highly recommended for those companies requiring a RTO below 1 hour. To sum up, regarding recovery sites, costs are inversely proportional to tolerance. As tolerance decreases, costs increase. So, the best choice for each company will depend on the risk assessment and objectives defined in their Disaster Recovery plan. TypeHow it is preparedTypical recoveryCost**Cold site**Backups, images, minimal infrastructure or code to rebuild the environmentHours, days or moreLow**Warm site**Partially deployed or reduced environment, with replicated data or recent copiesMinutes to hoursMedium**Hot site**Full replica running continuously and usually synchronizedSeconds to minutesHigh None of the three is the right answer by default. The suitable combination depends on the RTO and the RPO the business needs to sustain, and on how much of that justifies the cost. At Stackscale that sizing is done per project, on a managed Disaster Recovery and backup solution designed around the figures agreed with each customer. ### Geo-redundancy Furthermore, when choosing the proper site recovery solution, geo-redundancy is another key feature to take into account to improve availability, resilience and fault tolerance. Opting for a **remote, cross-datacenter recovery environment** considerably improves the RTO in case of severe contingency in the main datacenter. ** Relying on geographically distributed data centers contributes to building a stronger business continuity strategy**. As it provides additional protection against disasters affecting the main data center. Furthermore, regarding **DR solutions at storage level**, geographical redundancy must not to be neglected either. Having off-site backups is recommended to **avoid data losses and improve businesses’ RPO**. Data geo-replication provides an extra security layer. That is why Stackscale’s network storage volumes — Flash Premium, Flash Plus and Standard — are geo-replicated by default in a different data center. ### Synchronous or Asynchronous replication Depending on the business requirements, another aspect to consider when choosing a Disaster Recovery solution is whether it is necessary to replicate data synchronously or asynchronously to the remote location. On the one hand, **synchronous replication** writes data to the primary storage and the replica simultaneously. It is to say, replication is done in real time and, therefore, the RPO equals 0. This configuration enables a failover to the Disaster Recovery solution with **virtually zero downtime**. That is why it is mainly used for high-end transactional applications requiring instant failover. It is more expensive than asynchronous replication because it requires a higher amount of bandwidth and even specialized hardware. On the other hand, **asynchronous replication** writes data to the replica on a scheduled basis; for example, every hour, every 6 hours or daily. So, although it can occur in near real time, it is not simultaneous. This configuration is **particularly intended for working over long distances**, as it can tolerate some degradation in connectivity. It is commonly used for data backups and storage snapshots, and in virtual machines. In Proxmox environments, this is the layer covered by Proxmox Backup Server, with incremental and deduplicated backups that keep the replication window short without saturating the link between sites. It does not usually require specialized hardware and it **requires significantly less bandwidth**. Thus, its cost is lower than that of synchronous replication. However, there is a risk of data loss between the last scheduled replica and a potential incident. ### Scalability Considering scalability is also wise to ensure the company’s Disaster Recovery solution can **grow along with the business needs**. Organizations should never find themselves in the position to choose between which data they can back-up and which data can be left at risk, for capacity reasons. At Stackscale we help businesses choose a managed Disaster Recovery and backup solution adapted to their goals and requirements. Do not hesitate to contact our team for further information. --- ## Proxmox VE Now Supports ARM64: What It Means, Which Hardware Is Compatible, and Why It Matters for the Future of Virtualization URL: https://www.stackscale.com/blog/proxmox-ve-supports-arm64/ Enterprise virtualization has been closely tied to Intel and AMD processors for decades. However, the rapid growth of Artificial Intelligence, high-performance computing (HPC), and the push for greater energy efficiency in data centers are driving interest in new processor architectures. Against this backdrop, **Proxmox VE 9.2 introduces official support for ARM64 (AArch64)**, marking a significant milestone for one of the most widely adopted open-source virtualization platforms. For organizations already using Proxmox VE or evaluating alternatives to VMware, this does not mean they need to migrate to ARM servers immediately. The real significance is that **Proxmox has evolved into a virtualization platform officially capable of supporting both x86-64 and ARM64 infrastructures**, aligning itself with a market that is steadily becoming more diverse. ## Proxmox VE for ARM64 in 20 Seconds - **Proxmox VE 9.2 introduces official support for the ARM64 (AArch64) architecture.** - It shares the same codebase, documentation, repositories, and support lifecycle as the x86-64 edition. - At launch, **two platforms are officially certified: NVIDIA Grace Hopper and NVIDIA Vera.** - Support is designed for enterprise servers, not development boards such as the Raspberry Pi. - ARM64 support positions Proxmox for future cloud, Artificial Intelligence, and HPC deployments. This release does not change Proxmox’s core philosophy. It remains an open-source virtualization platform built around technologies such as KVM and LXC, offering high availability, clustering, software-defined storage, backup capabilities, and centralized management. These features have made it an increasingly attractive choice for organizations looking to reduce dependence on proprietary virtualization platforms. ## From Community Builds to Official Support Until now, it was possible to run Proxmox on certain ARM systems through community-maintained projects. While valuable for testing and laboratory environments, these unofficial builds came with clear limitations: they followed separate development cycles, required additional maintenance, and lacked official support. With Proxmox VE 9.2, that changes completely. ARM64 is no longer a side project. It is now part of the main Proxmox codebase, receiving the same level of attention as the traditional x86-64 version. That includes: - Enterprise repositories; - Official updates; - Commercial support; - Unified documentation; - The same release and maintenance schedule. For system administrators, this means they can manage both architectures using virtually the same tools, workflows, and operational experience. The ARM edition also shares the same technology stack as the x86 version: - Debian 13.5 “Trixie”; - Linux Kernel 7.0; - QEMU 11; - LXC 7; - ZFS 2.4. The familiar web interface, REST API, command-line tools, storage management, clustering capabilities, and most of the documentation remain unchanged. ## Which Hardware Is Officially Supported? One of the most significant aspects of this announcement is that **Proxmox now publishes an official list of supported ARM platforms** for the first time. At launch, the certified systems are: - **NVIDIA Grace Hopper** - **NVIDIA Vera** This is far from accidental. NVIDIA’s Grace processors are becoming key components in next-generation Artificial Intelligence and HPC infrastructures, combining high-core-count ARM CPUs with tight integration alongside NVIDIA GPUs. They are increasingly being deployed in AI training, inference, scientific computing, and supercomputing environments. Proxmox also states that it is working with additional hardware vendors to expand the list of supported ARM platforms in future releases, suggesting that the enterprise ARM ecosystem will continue to grow. ## Not Every ARM Device Can Run Proxmox One common misconception following the announcement is that Proxmox can now be installed on any ARM-based device. That is not the case. Official support targets **enterprise-class servers**, not low-cost development boards. Current requirements include: - UEFI boot support; - ACPI-based hardware description; - ARMv9-A processors, while ARMv8-A is supported on a best-effort basis. As a result, popular boards such as the Raspberry Pi, Orange Pi, RockPro, and most Device Tree-based single-board computers are **not officially supported**. Proxmox continues to focus on enterprise infrastructure and professional data center deployments. ## How Does It Differ from the x86 Version? From an operational perspective, the experience is almost identical. However, some architectural differences remain. Among the most important: - Virtual machines boot exclusively through UEFI using AAVMF; - SeaBIOS is not available; - Intel- and AMD-specific technologies such as Intel GVT-g and AMD SEV remain exclusive to x86 platforms; - Virtual machines can only run on hosts using the same processor architecture; - Live migration between ARM and x86 hosts is not supported. In other words, ARM servers are not drop-in replacements for existing x86 clusters. Each architecture maintains its own capabilities and limitations, even though both can be managed through the same Proxmox interface. ## A Sign of Where Enterprise Infrastructure Is Heading Beyond the technical announcement, this release reflects a broader industry trend. For many years, enterprise data centers relied almost exclusively on x86 processors. Today, the rise of Artificial Intelligence workloads, increasing energy costs, and the search for better performance per watt are accelerating the adoption of ARM-based server processors. Major cloud providers already offer ARM-based instances for selected workloads, while companies such as NVIDIA are investing heavily in ARM-powered AI and supercomputing platforms. In this context, having a virtualization platform that officially supports multiple processor architectures reduces operational complexity and gives organizations greater flexibility as new hardware becomes available. ## What This Means for Organizations Using Proxmox For most businesses, **this announcement does not require an immediate infrastructure change**. The overwhelming majority of enterprise virtualization deployments continue to run on x86 servers, a mature ecosystem with broad hardware compatibility and decades of software optimization. However, official ARM64 support provides an important level of future readiness. Organizations that standardize on Proxmox VE can be confident that their virtualization platform will evolve alongside the market, without forcing them to adopt a different hypervisor if ARM servers become attractive for specific workloads in the future. At Stackscale, we continue to provide **private cloud, bare-metal servers, and managed Proxmox VE platforms based on enterprise-class x86 hardware**, which remains the best fit for the vast majority of production environments today. Nevertheless, official ARM64 support highlights the flexibility of the Proxmox ecosystem and reinforces its position as an open virtualization platform capable of adapting to the next generation of enterprise infrastructure. As heterogeneous data centers become more common, where multiple processor architectures coexist depending on workload requirements, having a virtualization platform prepared for that evolution may become an increasingly valuable advantage. ## Frequently Asked Questions ### Is Proxmox VE for ARM64 an experimental release? No. ARM64 is officially supported starting with Proxmox VE 9.2 and follows the same development, update, and commercial support lifecycle as the x86-64 edition. ### Which ARM servers are officially supported? At launch, Proxmox officially certifies **NVIDIA Grace Hopper** and **NVIDIA Vera**. Additional enterprise ARM platforms are expected to be added over time. ### Can I install Proxmox VE on a Raspberry Pi? No. Official support requires servers that implement UEFI and ACPI. Most development boards, including Raspberry Pi, rely on Device Tree and are therefore not supported. ### Does this mean organizations should migrate to ARM now? Not necessarily. Most enterprise virtualization environments continue to rely on x86 servers. ARM64 support simply ensures that Proxmox is ready as enterprise ARM adoption continues to grow. ### Could Stackscale offer Proxmox on ARM in the future? Today, Stackscale provides Proxmox VE platforms on high-performance x86 enterprise servers. Official ARM64 support expands the possibilities of the Proxmox ecosystem and creates opportunities to evaluate ARM-based infrastructure as enterprise hardware matures and adoption increases. --- ## Proxmox VE ya soporta ARM64: qué cambia para la virtualización empresarial y el cloud URL: https://www.stackscale.com/blog/proxmox-ve-supports-arm64/ La virtualización empresarial ha estado ligada durante décadas a servidores basados en procesadores Intel y AMD. Sin embargo, el crecimiento de la Inteligencia Artificial, la computación de alto rendimiento (HPC) y la necesidad de mejorar la eficiencia energética de los centros de datos están impulsando el interés por nuevas arquitecturas. En ese contexto, **Proxmox VE 9.2 incorpora por primera vez soporte oficial para ARM64 (AArch64)**, un movimiento que marca una nueva etapa para uno de los hipervisores open source más utilizados en entornos profesionales. Para organizaciones que ya utilizan Proxmox VE o que están evaluando alternativas a VMware, esta novedad no implica que deban migrar inmediatamente a servidores ARM. Lo realmente importante es que **Proxmox pasa a convertirse en una plataforma de virtualización oficialmente preparada para gestionar tanto infraestructuras x86-64 como ARM64**, acompañando una evolución del mercado que ya está en marcha. ## Proxmox VE para ARM64 en 20 segundos - **Proxmox VE 9.2 añade soporte oficial para la arquitectura ARM64 (AArch64).** - Comparte el mismo código fuente, documentación, repositorios y ciclo de soporte que la versión para servidores x86-64. - Actualmente existen **dos plataformas certificadas oficialmente: NVIDIA Grace Hopper y NVIDIA Vera**. - El soporte está orientado a servidores empresariales, no a placas de desarrollo como Raspberry Pi. - La incorporación de ARM64 prepara a Proxmox para futuros despliegues de cloud, Inteligencia Artificial y HPC sobre nuevas arquitecturas. La llegada de ARM64 tampoco cambia el enfoque habitual de Proxmox: sigue siendo una plataforma basada en tecnologías abiertas como KVM y LXC, con capacidades de alta disponibilidad, clustering, almacenamiento definido por software, copias de seguridad y una gestión centralizada que la han convertido en una alternativa cada vez más considerada por empresas que buscan reducir la dependencia de soluciones propietarias. ## De los proyectos comunitarios al soporte oficial Hasta ahora era posible ejecutar Proxmox sobre algunos servidores ARM mediante proyectos mantenidos por la comunidad. Eran iniciativas muy valiosas para pruebas o laboratorios, pero presentaban limitaciones evidentes: no seguían el mismo calendario de versiones, requerían adaptaciones adicionales y no contaban con soporte oficial. Con Proxmox VE 9.2 esa situación cambia completamente. ARM64 deja de ser una adaptación paralela y pasa a formar parte del desarrollo principal del proyecto. Eso significa que recibe el mismo tratamiento que la versión tradicional para x86-64: - repositorios Enterprise; - actualizaciones oficiales; - soporte comercial; - documentación unificada; - mismo calendario de desarrollo y mantenimiento. Para los administradores de sistemas, esto supone poder trabajar sobre ambas arquitecturas utilizando prácticamente las mismas herramientas, procedimientos y experiencia de administración. La edición para ARM mantiene además la misma base tecnológica que caracteriza a Proxmox VE: - Debian 13.5 “Trixie”; - Kernel Linux 7.0; - QEMU 11; - LXC 7; - ZFS 2.4. La interfaz web, la API REST, la línea de comandos, la gestión del almacenamiento, el clustering y gran parte del ecosistema permanecen sin cambios. ## ¿Qué hardware es compatible? Uno de los aspectos más importantes del anuncio es que **Proxmox define por primera vez una lista oficial de plataformas ARM compatibles**, algo que hasta ahora no existía. En esta primera versión, los sistemas certificados son: - **NVIDIA Grace Hopper** - **NVIDIA Vera** No se trata de una selección casual. Los procesadores Grace forman parte de la estrategia de NVIDIA para infraestructuras de Inteligencia Artificial y supercomputación, combinando un elevado número de núcleos ARM con una integración muy estrecha con las GPU de la compañía. Se están incorporando progresivamente en centros de datos destinados a entrenamiento e inferencia de modelos de IA, simulaciones científicas y cargas HPC. Proxmox también indica que está colaborando con otros fabricantes para ampliar la lista de plataformas soportadas en futuras versiones, por lo que es razonable esperar que el ecosistema ARM empresarial continúe creciendo durante los próximos años. ## No significa que cualquier equipo ARM sea compatible Uno de los malentendidos más habituales tras el anuncio es pensar que ahora será posible instalar Proxmox VE en cualquier dispositivo basado en ARM. No es así. El soporte oficial está pensado para **servidores profesionales**, no para placas de desarrollo o equipos de bajo coste. Entre los requisitos se encuentran: - arranque mediante UEFI; - descripción del hardware mediante ACPI; - procesadores ARMv9-A, aunque ARMv8-A puede funcionar bajo un modelo de soporte “best effort”. Esto deja fuera dispositivos muy populares en entornos domésticos y de laboratorio como Raspberry Pi, Orange Pi, RockPro o la mayoría de placas que dependen de Device Tree. El objetivo de Proxmox continúa siendo el mercado profesional y los centros de datos. ## Qué diferencias existen respecto a la versión para x86 Desde el punto de vista operativo, la experiencia resulta muy similar. No obstante, existen algunas diferencias derivadas de la propia arquitectura. Por ejemplo: - el arranque de las máquinas virtuales se realiza únicamente mediante UEFI utilizando AAVMF; - SeaBIOS no está disponible; - tecnologías específicas de Intel o AMD, como Intel GVT-g o AMD SEV, siguen limitadas a plataformas x86; - las máquinas virtuales solo pueden ejecutarse sobre nodos de la misma arquitectura; - la migración en caliente entre servidores ARM y x86 no está soportada. Esto significa que un clúster ARM no sustituye automáticamente a uno basado en procesadores Intel o AMD. Cada arquitectura mantiene sus propias limitaciones y capacidades, aunque la gestión desde Proxmox resulte prácticamente idéntica. ## Un movimiento que refleja hacia dónde evoluciona el mercado Más allá de la novedad técnica, el anuncio resulta interesante porque refleja una tendencia más amplia del sector. Durante años los centros de datos se construyeron casi exclusivamente sobre arquitecturas x86. Sin embargo, el crecimiento de la Inteligencia Artificial, el aumento del consumo energético y la necesidad de mejorar el rendimiento por vatio están impulsando el desarrollo de nuevos procesadores ARM para servidores. Grandes proveedores cloud ya ofrecen instancias basadas en ARM para determinados tipos de cargas de trabajo, mientras que fabricantes como NVIDIA están apostando por esta arquitectura en plataformas de IA y supercomputación. En ese escenario, disponer de un hipervisor capaz de ofrecer soporte oficial para ambas arquitecturas reduce la complejidad operativa y facilita que las organizaciones puedan incorporar nuevos tipos de hardware cuando realmente aporten valor. ## Qué significa para las empresas que utilizan Proxmox Para la mayoría de organizaciones, esta novedad **no implica un cambio inmediato en su infraestructura**. La inmensa mayoría de los despliegues empresariales continúan realizándose sobre servidores x86, una plataforma madura, ampliamente soportada y con un enorme ecosistema de hardware. Sin embargo, el soporte oficial para ARM64 ofrece una garantía importante de cara al futuro. Las empresas que han apostado por Proxmox VE saben que la plataforma está preparada para evolucionar junto al mercado sin obligarlas a cambiar de herramienta de virtualización si, en algún momento, deciden incorporar servidores ARM a determinados proyectos. En Stackscale seguimos ofreciendo **infraestructura cloud privada, servidores bare-metal y plataformas Proxmox VE sobre hardware x86 empresarial**, una arquitectura que continúa siendo la opción adecuada para la inmensa mayoría de cargas de producción actuales. No obstante, la incorporación del soporte oficial para ARM64 demuestra la capacidad de evolución del ecosistema Proxmox y refuerza su posición como una plataforma abierta preparada para responder a las necesidades de los centros de datos de próxima generación. La evolución hacia infraestructuras heterogéneas, donde convivan diferentes arquitecturas de procesador según el tipo de carga de trabajo, parece cada vez más probable. Contar con una plataforma de virtualización capaz de acompañar esa transición puede convertirse en una ventaja para muchas organizaciones durante los próximos años. ## Preguntas frecuentes ### ¿Proxmox VE para ARM64 es una versión experimental? No. ARM64 forma parte oficialmente de Proxmox VE desde la versión 9.2 y dispone del mismo ciclo de desarrollo, actualizaciones y soporte que la edición para servidores x86-64. ### ¿Qué servidores ARM son compatibles actualmente? En el momento del lanzamiento, Proxmox certifica oficialmente dos plataformas: **NVIDIA Grace Hopper** y **NVIDIA Vera**. La compañía prevé ampliar esta lista conforme nuevos fabricantes validen sus plataformas. ### ¿Se puede instalar Proxmox VE en una Raspberry Pi? No. El soporte oficial requiere servidores que utilicen UEFI y ACPI. La mayoría de placas de desarrollo basadas en Device Tree, como Raspberry Pi, no forman parte de las plataformas soportadas. ### ¿Significa esto que las empresas deberían migrar ya a ARM? No necesariamente. La mayoría de infraestructuras empresariales siguen desplegándose sobre servidores x86. La incorporación de ARM64 prepara a Proxmox para futuras arquitecturas y ofrece más opciones a medida que el mercado evolucione. ### ¿Podría Stackscale ofrecer Proxmox sobre ARM en el futuro? Actualmente Stackscale ofrece plataformas Proxmox VE sobre servidores x86 de alto rendimiento. La llegada del soporte oficial para ARM64 amplía las posibilidades del ecosistema Proxmox y permitirá valorar nuevas opciones conforme el hardware empresarial ARM madure y aumente su disponibilidad. --- ## ASML, the European company making AI chips possible URL: https://www.stackscale.com/blog/asml-the-european-company-making-ai-chips-possible/ The race for Artificial Intelligence is usually explained through names such as NVIDIA, TSMC, Microsoft, Google and Amazon. Some design accelerators, others manufacture them, while the major cloud providers install thousands of them in data centres. Yet all this computing capacity depends on an earlier and far less visible technology: the machines capable of transferring increasingly small circuits onto a silicon wafer. **Much of this technology comes from Veldhoven, in the Netherlands (Europe), where ASML is headquartered.** The company does not manufacture chips or develop Artificial Intelligence models, but it supplies the lithography systems used by leading manufacturers to produce the most advanced semiconductors. Its position helps explain why digital infrastructure begins long before the server, the data centre or the cloud. ## ASML: the key facts in 20 seconds - ASML was founded in 1984 as a joint venture between Philips and ASM International. - It manufactures lithography systems that project circuit patterns onto silicon wafers. - It is the only supplier of extreme ultraviolet lithography systems, known as EUV, used in high-volume manufacturing. - Its equipment is installed in semiconductor plants operated by companies such as TSMC, Samsung, Intel and SK hynix. - It also manufactures DUV systems, which are required for many chip layers and a wide range of semiconductor products. - In 2025, it reported net sales of €32.7 billion and net income of €9.6 billion. - During the first quarter of 2026, it generated sales of €8.8 billion, net income of €2.8 billion and a gross margin of 53%. - ASML expects to close 2026 with revenue of between €36 billion and €40 billion. - Its next-generation technology, High-NA EUV, increases numerical aperture from 0.33 to 0.55 and can print smaller structures. - Its strategic importance has also placed it at the centre of export controls and technological competition between the United States, China, Europe and Asia. These figures reveal an industrial company in a highly unusual position. In 2025, ASML invested €4.7 billion in research and development. It also generated €8.2 billion from services, maintenance and upgrades for equipment already installed, 26.2% more than in the previous year. ASML does not depend solely on selling new machines: it maintains technical relationships that can last for decades with the factories using its systems. Demand linked to Artificial Intelligence has strengthened this business. Large models require accelerators, but also high-bandwidth memory, processors, networking components and high-speed interconnects. To increase production, logic and memory manufacturers must expand their fabrication plants, install new machines and upgrade existing equipment. This does not mean that every chip used for Artificial Intelligence is manufactured exclusively with EUV equipment. Semiconductor production combines numerous processes and technologies. ASML maintains an extensive DUV portfolio based on deep ultraviolet light, which remains essential for many chip layers, mature process nodes and components where using the most advanced tool would make little economic sense. EUV and DUV will coexist for many years. A semiconductor plant may use EUV for its most complex structures while relying on DUV for many other exposures. This combination explains why ASML’s position extends beyond the latest processors to memory, industrial electronics, automotive systems, communications and many everyday devices. ## How EUV lithography works and why it is so difficult to replicate Lithography can be compared to an extraordinarily precise form of photographic printing. The process begins with a silicon wafer covered in a light-sensitive material. The machine projects the pattern corresponding to one circuit layer onto the wafer. Chemical and physical processes are then applied to etch, deposit or alter materials. This operation is repeated many times. A modern chip consists of successive layers that must be aligned with extreme precision. A minor error can affect the yield of the entire wafer and reduce the percentage of chips that function correctly. Complete semiconductor production involves hundreds of steps and may take several months. Lithography is only one of them, but it directly influences feature size, transistor density and the economic viability of the manufacturing process. ASML’s EUV machines use light with a wavelength of 13.5 nanometres. To produce it, a carbon dioxide laser fires two pulses at tiny droplets of tin moving through the system. The tin is converted into plasma and emits extreme ultraviolet radiation. The machine can repeat this operation up to 50,000 times per second. This creates another difficulty. EUV light is absorbed by almost every material, including air. It cannot pass through conventional glass lenses, so the entire optical path must operate in a vacuum and use highly precise multilayer mirrors. These mirrors are supplied by ZEISS Semiconductor Manufacturing Technology, one of ASML’s most important partners. The optical systems must direct and focus the light while the wafer and mask move at high speed. At the same time, the machine uses sensors and software to correct vibration, temperature changes, positioning and potential deviations. The illumination optics of a conventional EUV system already contain around 15,000 components and weigh approximately 1.5 tonnes. In High-NA EUV, the illumination system includes more than 25,000 components and weighs over six tonnes. Its mirrors are manufactured with atomic-level precision, and some can take about a year to produce. ASML therefore acts as the integrator of an international technological system. In addition to ZEISS, the platform depends on laser sources, vacuum systems, metrology, materials, software and components developed by a network of specialist suppliers. ASML controls the overall architecture and coordinates the system’s operation inside its customers’ semiconductor plants. This specialisation explains why its position is so difficult to replicate. A competitor would not merely have to copy a single machine. It would need to rebuild decades of expertise in optics, plasma generation, mechanics, materials, motion control, manufacturing and software. It would also have to create a network of suppliers and work for years with semiconductor manufacturers to turn prototypes into reliable tools for continuous production. The development of EUV required more than two decades, thousands of professionals and billions of euros in research. ASML estimates that it invested more than €6 billion in the technology over 17 years before it reached the level of maturity required for large-scale manufacturing. The company also acquired Cymer, a specialist in light sources, to accelerate progress in one of the system’s most complex areas. The next stage is High-NA EUV. The term refers to a higher numerical aperture, which improves the optical system’s ability to collect and focus light. ASML’s EXE platform increases this value from 0.33 to 0.55. According to the manufacturer’s specifications, the TWINSCAN EXE:5000 achieves a resolution of eight nanometres. It can print features 1.7 times smaller than NXE platforms in a single exposure and potentially increase transistor density by up to 2.9 times. The first machine was shipped to Intel at the end of 2023, and ASML recognised revenue associated with four EXE systems during 2025. Adoption will not be automatic or identical for every manufacturer. Each company must assess the cost of the machine, its productivity, the number of exposures it can eliminate, process maturity and the resulting wafer yield. A more advanced technology is useful only when it improves the economics of the complete fabrication process. ## From Veldhoven to the data centre The connection between ASML and cloud infrastructure may appear distant, but it links two ends of the same chain. Lithography systems make it possible to manufacture processors, accelerators and memory. These components are then integrated into servers, storage platforms and networking equipment. Finally, data centres turn that hardware into computing capacity that companies and users can consume. When a new manufacturing generation increases transistor density, improves performance or reduces energy consumption per operation, the effect eventually reaches the data centre. Providers can install more capacity within the same physical space, offer more powerful servers or run certain workloads with a better balance between performance and electricity consumption. The process is not immediate, however. Between a lithography advance and its arrival in business infrastructure lie chip design, process validation, manufacturing, packaging, server integration and commercial availability. Announcements about new semiconductor nodes should therefore not be confused with capacity that can be deployed immediately. Demand also flows in the opposite direction. Growth forecasts for Artificial Intelligence are leading data centre operators and hyperscalers to reserve large volumes of accelerators. Chip designers pass that demand on to foundries, which increase their investment in capacity and manufacturing equipment. ASML benefits from this cycle without selling servers or cloud services directly. For companies consuming infrastructure, this supply chain has practical consequences. The availability and price of certain processors may depend on bottlenecks located thousands of kilometres away from the data centre. There can also be substantial differences between hardware generations in power consumption, density, performance per core and memory capacity. In private cloud and bare-metal environments, hardware selection directly affects platform design and total cost of ownership. A company does not always need the newest CPU or the most powerful accelerator. It must choose the architecture that best matches its databases, virtualisation requirements, Artificial Intelligence workloads, storage, latency and expected growth. Bare-metal environments allow the processor, memory, storage and network to be dedicated to a single organisation. This provides isolation, predictable performance and direct control of the hardware. Private cloud adds a layer of virtualisation, automation and management that makes it easier to distribute these resources among virtual machines and internal services. From the perspective of a European provider such as Stackscale, semiconductor innovation is one part of the challenge, but it does not solve enterprise infrastructure requirements on its own. High availability, private networks, backups, storage, monitoring, disaster recovery and day-to-day operations must also be designed properly. A new CPU may reduce processing times, but it does not replace a business continuity plan. An accelerator may run Artificial Intelligence models quickly, but it does not determine where the data is stored, who operates the platform or which jurisdiction governs the provider. Performance, resilience and sovereignty are related but distinct considerations. ASML also helps to put European technological sovereignty into perspective. The company retains in the Netherlands a capability that no other supplier has managed to reproduce commercially. Europe therefore holds a strategic position within the global semiconductor manufacturing industry. However, ASML does not represent a completely autonomous European supply chain. Its machines incorporate technology and components from several countries. Its main customers manufacture in Taiwan, South Korea and the United States. The company relies on ZEISS in Germany, US specialists and an international network of suppliers. Its strength comes precisely from this cooperation. At the same time, this structure exposes the company to export controls, trade tensions and political decisions made outside the Netherlands. Restrictions affecting certain advanced tools show that lithography is no longer regarded solely as an industrial activity. It has become part of foreign policy and national security. **The European Union is seeking to strengthen its position through the European Chips Act and other initiatives related to semiconductors, cloud, Artificial Intelligence and open-source technology. The objective is not simply to manufacture more chips, but to retain research, design, production and digital operating capabilities within Europe.** ASML demonstrates that Europe can occupy positions that are extremely difficult to replace when it combines long-term research, advanced industry, specialist suppliers and cooperation with customers. It also shows that these advantages take decades to build and that sovereignty does not mean isolation. European digital infrastructure must take the entire chain into account. This includes semiconductors, servers, connectivity, data centres, software, virtualisation, cloud platforms and data control. A company can benefit indirectly from ASML’s technology while keeping its workloads on a European private cloud or bare-metal platform to maintain greater control over jurisdiction, performance and costs. ASML does not manufacture Artificial Intelligence, nor does it control the future of semiconductors by itself. Without designs from companies such as NVIDIA, AMD and Intel, the fabrication plants operated by TSMC, Samsung and other manufacturers, and the work of thousands of suppliers, its machines would have no practical value. Its importance comes from the position it occupies in this chain: it provides one of the hardest-to-replace tools required to turn a digital design into silicon. ## **Frequently asked questions about ASML** **What exactly does ASML manufacture?** ASML manufactures photolithography equipment, as well as software, metrology systems, services and upgrades. Its machines project circuit patterns onto silicon wafers during semiconductor production. **Why is ASML important to NVIDIA and other chip designers?** NVIDIA, AMD and other companies design processors, but they rely on manufacturers such as TSMC and Samsung to produce them. These fabrication plants use ASML equipment at different stages of their manufacturing processes. **Does ASML have a monopoly on lithography?** Not on all forms of lithography. Nikon and Canon also manufacture certain types of systems. However, ASML is the only supplier of EUV technology used to manufacture the most advanced semiconductors. **What is the connection between ASML and cloud computing?** ASML supplies the technology used to manufacture many of the processors, accelerators and memory products installed in servers. Its advances eventually influence the performance, energy consumption and availability of hardware deployed in data centres and cloud platforms. Sources: - ASML, financial results for the 2025 financial year. - ASML, financial results for the first quarter of 2026. - ASML, technical documentation on EUV and High-NA EUV lithography. - ASML, company history and the development of EUV. - ZEISS Semiconductor Manufacturing Technology, EUV and High-NA EUV optics. - European Commission, the European Chips Act and technological sovereignty. --- ## ASML, la empresa europea que hace posibles los chips de la Inteligencia Artificial URL: https://www.stackscale.com/blog/asml-the-european-company-making-ai-chips-possible/ La carrera por la Inteligencia Artificial suele explicarse a través de nombres como NVIDIA, TSMC, Microsoft, Google o Amazon. Unos diseñan aceleradores, otros los fabrican y los grandes proveedores cloud los instalan por miles en centros de datos. Pero toda esa capacidad de computación depende de una tecnología anterior y mucho menos visible: las máquinas capaces de trasladar circuitos cada vez más pequeños a una oblea de silicio. **Buena parte de esa tecnología procede de Veldhoven, en Países Bajos (Europa), donde tiene su sede ASML**. La compañía no fabrica chips ni desarrolla modelos de Inteligencia Artificial, pero suministra los sistemas de litografía con los que los grandes fabricantes producen los semiconductores más avanzados. Su posición permite entender por qué la infraestructura digital empieza mucho antes del servidor, del centro de datos y del cloud. ## ASML: las claves en 20 segundos - ASML nació en 1984 como una empresa conjunta de Philips y ASM International. - Fabrica sistemas de litografía que proyectan los patrones de los circuitos sobre obleas de silicio. - Es el único proveedor de sistemas de litografía ultravioleta extrema, EUV, utilizados en fabricación de gran volumen. - Sus equipos forman parte de las fábricas de semiconductores de compañías como TSMC, Samsung, Intel y SK hynix. - También produce sistemas DUV, necesarios para numerosas capas y para una gran variedad de chips. - En 2025 registró unas ventas netas de 32.700 millones de euros y un beneficio neto de 9.600 millones. - Durante el primer trimestre de 2026 alcanzó unas ventas de 8.800 millones de euros, un beneficio neto de 2.800 millones y un margen bruto del 53 %. - ASML prevé cerrar 2026 con una facturación de entre 36.000 y 40.000 millones de euros. - Su siguiente generación tecnológica, High-NA EUV, eleva la apertura numérica de 0,33 a 0,55 y permite imprimir estructuras de menor tamaño. - Su importancia estratégica también la sitúa en el centro de los controles de exportación y de la competencia tecnológica entre Estados Unidos, China, Europa y Asia. Las cifras muestran una empresa industrial con una posición muy poco habitual. En 2025 destinó 4.700 millones de euros a investigación y desarrollo. Además, obtuvo 8.200 millones mediante servicios, mantenimiento y actualizaciones de equipos ya instalados, un 26,2 % más que el año anterior. ASML no depende únicamente de vender máquinas nuevas: mantiene una relación técnica que puede durar décadas con las fábricas que utilizan sus sistemas. La demanda relacionada con la Inteligencia Artificial ha reforzado esta actividad. Los grandes modelos necesitan aceleradores, pero también memorias de alto ancho de banda, procesadores, componentes de red e interconexiones de alta velocidad. Para aumentar su producción, los fabricantes de lógica y memoria deben ampliar fábricas, incorporar nuevas máquinas y actualizar las existentes. Eso no significa que cada chip para Inteligencia Artificial necesite exclusivamente una máquina EUV. La fabricación de un semiconductor combina numerosos procesos y tecnologías. ASML mantiene una amplia oferta DUV, basada en ultravioleta profundo, que continúa siendo imprescindible para muchas capas del chip, para nodos maduros y para componentes donde no tiene sentido utilizar la herramienta más avanzada. EUV y DUV convivirán durante años. Una fábrica puede utilizar EUV para las estructuras más complejas y recurrir a DUV en muchas otras exposiciones. Esta combinación explica por qué la posición de ASML se extiende más allá de los procesadores de última generación y alcanza memorias, electrónica industrial, automoción, comunicaciones y numerosos dispositivos de uso cotidiano. ## Cómo funciona la litografía EUV y por qué es tan difícil de replicar La litografía puede compararse con una impresión fotográfica de extraordinaria precisión. El proceso comienza con una oblea de silicio cubierta por un material sensible a la luz. La máquina proyecta sobre ella el patrón correspondiente a una de las capas del circuito. Después se aplican procesos químicos y físicos que permiten grabar, depositar o modificar materiales. La operación se repite muchas veces. Un chip moderno está formado por capas sucesivas que deben quedar alineadas con una precisión extrema. Un pequeño error puede afectar al rendimiento de toda la oblea y reducir el porcentaje de chips que funcionan correctamente. * La fabricación completa comprende cientos de pasos y puede prolongarse durante varios meses. La litografía es uno de ellos, aunque condiciona directamente el tamaño de las estructuras, la densidad de transistores y la viabilidad económica del proceso. Las máquinas EUV de ASML utilizan luz con una longitud de onda de 13,5 nanómetros. Para producirla, un láser de dióxido de carbono dispara dos pulsos contra diminutas gotas de estaño en movimiento. El estaño se convierte en plasma y emite radiación ultravioleta extrema. El sistema puede repetir esta operación hasta 50.000 veces por segundo. A partir de ahí aparece otra dificultad. La luz EUV es absorbida por prácticamente cualquier material, incluido el aire. No puede atravesar lentes convencionales de cristal, por lo que todo el recorrido óptico debe funcionar en vacío y mediante espejos multicapa de enorme precisión. Estos espejos proceden de ZEISS Semiconductor Manufacturing Technology, uno de los socios más importantes de ASML. Los sistemas ópticos deben dirigir y enfocar la luz mientras la oblea y la máscara se desplazan a gran velocidad. Al mismo tiempo, la máquina corrige vibraciones, temperatura, posición y posibles desviaciones mediante sensores y software. La óptica de iluminación de un sistema EUV convencional ya contiene alrededor de 15.000 piezas y pesa cerca de 1,5 toneladas. En High-NA EUV, el sistema de iluminación supera las 25.000 piezas y las seis toneladas. Los espejos se fabrican con precisión atómica y algunos pueden necesitar aproximadamente un año de producción. ASML actúa, por tanto, como integrador de un conjunto tecnológico internacional. Además de ZEISS, la plataforma depende de fuentes láser, sistemas de vacío, metrología, materiales, software y componentes desarrollados por una red de proveedores especializados. La compañía controla la arquitectura general y coordina el funcionamiento del sistema dentro de las instalaciones del fabricante de chips. Esta especialización explica por qué su posición resulta tan difícil de replicar. Un competidor no tendría que copiar una sola máquina, sino reconstruir décadas de conocimiento en óptica, plasma, mecánica, materiales, control de movimiento, fabricación y software. También necesitaría crear una red de proveedores y trabajar durante años con los fabricantes de semiconductores para convertir los prototipos en herramientas fiables para producción continua. El desarrollo de EUV necesitó más de dos décadas, miles de profesionales y miles de millones de euros en investigación. ASML estima que invirtió más de 6.000 millones de euros en esta tecnología durante 17 años antes de alcanzar la madurez necesaria para la fabricación a gran escala. La compañía también adquirió Cymer, especializada en fuentes de luz, para acelerar una de las partes más complejas del sistema. La siguiente etapa es High-NA EUV. El término hace referencia a una apertura numérica superior, que mejora la capacidad del sistema óptico para captar y enfocar la luz. La plataforma EXE de ASML aumenta este valor desde 0,33 hasta 0,55. Según las especificaciones del fabricante, el sistema TWINSCAN EXE:5000 alcanza una resolución de ocho nanómetros. Puede imprimir en una sola exposición estructuras 1,7 veces menores que las plataformas NXE y elevar hasta 2,9 veces la densidad potencial de transistores. El primer equipo se envió a Intel a finales de 2023 y ASML reconoció ingresos asociados a cuatro sistemas EXE durante 2025. La adopción no será automática ni idéntica para todos los fabricantes. Cada empresa debe valorar el coste de la máquina, la productividad, el número de exposiciones que puede evitar, la madurez del proceso y el rendimiento obtenido por oblea. Una tecnología más avanzada solo resulta útil cuando mejora la economía completa de la fábrica. ## De Veldhoven al centro de datos La relación entre ASML y la infraestructura cloud puede parecer distante, pero conecta dos extremos de la misma cadena. Los sistemas de litografía permiten fabricar procesadores, aceleradores y memorias. Esos componentes se integran después en servidores, cabinas de almacenamiento y equipos de red. Finalmente, los centros de datos convierten el hardware en capacidad de computación disponible para empresas y usuarios. Cuando una nueva generación de fabricación consigue aumentar la densidad de transistores, mejora el rendimiento o reduce el consumo por operación, el efecto termina llegando al centro de datos. Los proveedores pueden instalar más capacidad dentro del mismo espacio, ofrecer servidores más potentes o ejecutar determinadas cargas con una mejor relación entre rendimiento y energía. Pero el proceso no es inmediato. Entre el avance de la litografía y su llegada a una infraestructura empresarial intervienen el diseño del chip, la validación del proceso, la fabricación, el encapsulado, la integración del servidor y la disponibilidad comercial. Por eso los anuncios sobre nuevos nodos no deben confundirse con capacidad utilizable de forma inmediata. La dependencia también funciona en sentido contrario. Las previsiones de crecimiento de la Inteligencia Artificial llevan a los operadores de centros de datos y a los hiperescalares a reservar grandes volúmenes de aceleradores. Los diseñadores de chips trasladan esa demanda a las fundiciones, y las fundiciones aumentan sus inversiones en capacidad y equipamiento. ASML se beneficia de ese ciclo sin vender directamente servidores ni servicios cloud. Para las empresas que consumen infraestructura, esta cadena tiene consecuencias prácticas. La disponibilidad y el precio de determinados procesadores pueden depender de cuellos de botella que se encuentran a miles de kilómetros del centro de datos. También pueden surgir diferencias importantes entre generaciones de hardware en consumo, densidad, rendimiento por núcleo o capacidad de memoria. En cloud privado y bare-metal, la selección del hardware afecta directamente al diseño de la plataforma y al coste total de propiedad. Una empresa no siempre necesita la CPU más reciente ni un acelerador de máxima gama. Debe elegir la arquitectura que mejor se ajuste a sus bases de datos, virtualización, Inteligencia Artificial, almacenamiento, latencia y crecimiento previsto. Los entornos bare-metal permiten dedicar el procesador, la memoria, el almacenamiento y la red a una organización concreta. Esto aporta aislamiento, rendimiento predecible y control directo del hardware. El cloud privado añade una capa de virtualización, automatización y gestión que facilita distribuir esos recursos entre máquinas virtuales y servicios internos. Desde la perspectiva de un proveedor europeo como Stackscale, la innovación del semiconductor es una parte del problema, pero no resuelve por sí sola la infraestructura empresarial. También hay que diseñar la alta disponibilidad, las redes privadas, los backups, el almacenamiento, la monitorización, la recuperación ante desastres y la operación diaria. Una nueva CPU puede reducir tiempos de proceso, pero no sustituye un plan de continuidad. Un acelerador puede ejecutar modelos de Inteligencia Artificial con rapidez, pero no determina dónde se almacenan los datos, quién administra la plataforma o bajo qué jurisdicción opera el proveedor. Rendimiento, resiliencia y soberanía son dimensiones relacionadas, aunque diferentes. ASML también sirve para matizar el concepto de soberanía tecnológica europea. La compañía conserva en Países Bajos una capacidad que ningún otro proveedor ha logrado reproducir comercialmente. Europa dispone así de una posición estratégica dentro de la fabricación mundial de semiconductores. Pero ASML no representa una cadena europea completamente autónoma. Sus máquinas integran tecnología y componentes de distintos países. Sus principales clientes fabrican en Taiwán, Corea del Sur y Estados Unidos. La empresa depende de ZEISS en Alemania, de especialistas estadounidenses y de una red internacional de proveedores. Su fortaleza procede precisamente de esa cooperación. Al mismo tiempo, esa estructura la expone a controles de exportación, tensiones comerciales y decisiones políticas tomadas fuera de Países Bajos. Las restricciones aplicadas a determinadas herramientas avanzadas muestran que la litografía ya no se considera únicamente una actividad industrial: forma parte de la política exterior y de seguridad. **La Unión Europea intenta reforzar su posición mediante el Reglamento Europeo de Chips y otras iniciativas relacionadas con semiconductores, cloud, Inteligencia Artificial y código abierto. El objetivo no consiste solo en fabricar más chips, sino en conservar capacidades de investigación, diseño, producción y operación digital dentro de Europa.** ASML demuestra que Europa puede ocupar posiciones difíciles de sustituir cuando combina investigación a largo plazo, industria avanzada, proveedores especializados y cooperación con clientes. También demuestra que estas ventajas necesitan décadas para construirse y que la soberanía no equivale a aislamiento. La infraestructura digital europea necesita actuar sobre toda la cadena. Incluye semiconductores, servidores, conectividad, centros de datos, software, virtualización, cloud y control de los datos. Una empresa puede beneficiarse indirectamente de la tecnología de ASML y, al mismo tiempo, mantener sus cargas en una plataforma europea de cloud privado o bare-metal para controlar mejor la jurisdicción, el rendimiento y los costes. ASML no fabrica la Inteligencia Artificial ni controla por sí sola el futuro de los chips. Sin los diseños de compañías como NVIDIA, AMD o Intel, las fábricas de TSMC, Samsung y otros fabricantes, y el trabajo de miles de proveedores, sus máquinas no tendrían utilidad. Su importancia nace del lugar que ocupa en esa cadena: proporciona una de las herramientas más difíciles de sustituir para convertir un diseño digital en silicio. ## **Preguntas frecuentes sobre ASML** **¿Qué fabrica exactamente ASML?** ASML fabrica equipos de fotolitografía, además de software, sistemas de metrología, servicios y actualizaciones. Sus máquinas proyectan los patrones de los circuitos sobre obleas de silicio durante la producción de semiconductores. **¿Por qué ASML es importante para NVIDIA y otros diseñadores de chips?** NVIDIA, AMD y otras compañías diseñan procesadores, pero recurren a fabricantes como TSMC o Samsung para producirlos. Estas fábricas utilizan equipos de ASML en distintas etapas de sus procesos. **¿ASML tiene el monopolio de la litografía?** No de toda la litografía. Nikon y Canon también fabrican determinados sistemas. Sin embargo, ASML es el único proveedor de tecnología EUV utilizada en la producción de los semiconductores más avanzados. **¿Qué relación existe entre ASML y el cloud?** ASML suministra la tecnología con la que se fabrican muchos de los procesadores, aceleradores y memorias utilizados en servidores. Sus avances terminan influyendo en el rendimiento, el consumo y la disponibilidad del hardware desplegado en centros de datos y plataformas cloud. Fuentes: - ASML, resultados financieros del ejercicio 2025. - ASML, resultados del primer trimestre de 2026. - ASML, documentación técnica sobre litografía EUV y High-NA EUV. - ASML, historia de la compañía y desarrollo de EUV. - ZEISS Semiconductor Manufacturing Technology, óptica EUV y High-NA EUV. - Comisión Europea, Reglamento Europeo de Chips y soberanía tecnológica. - Imágenes de ASML de su media library* público. --- ## Cloud sovereignty: which laws govern your company’s data? URL: https://www.stackscale.com/blog/cloud-sovereignty-which-laws-govern-your-companys-data/ On 8 July 2026, Aire, the group Stackscale belongs to, held the first webinar in its **Despeja tu Cloud** series. The sessions aim to explain the regulatory, technical and geopolitical changes reshaping how companies procure infrastructure. Zigor Gaubeca, CIO at Aire, and David Aibar Carretero, Head of Sales, raised a question that should reach every boardroom: if a judge asked today which jurisdiction governs the company’s critical data, would there be a clear and documented answer? The answer does not depend solely on the country where the data centre is located. A workload may run physically in Madrid, Paris or Frankfurt and still be exposed to the laws of a third country because of the provider’s nationality, corporate structure or effective control. This is why cloud sovereignty is increasingly becoming part of business continuity planning, alongside cybersecurity, backups, high availability and Disaster Recovery. ## Cloud sovereignty: the key points in 20 seconds - Hosting data in Europe does not in itself guarantee that it is governed exclusively by European law. - Jurisdiction also depends on the company providing the service, its parent company, its subcontractors and who possesses, holds or controls the information. - The US CLOUD Act may apply to data stored outside the United States when it is controlled by a provider subject to US jurisdiction. - This does not allow arbitrary access to any information. There must be a valid and specific legal request linked to a legal proceeding. - The European Data Act, generally applicable since 12 September 2025, requires providers to reduce contractual, commercial and technical barriers to switching cloud providers. - From 12 January 2027, providers will no longer be allowed to charge the switching fees defined by the Data Act, although migrations will still involve technical and operational costs. - On 3 June 2026, the European Commission presented the proposal for the Cloud and AI Development Act, CADA, which introduces a common framework for assessing different levels of cloud and Artificial Intelligence sovereignty. - Sovereignty does not require companies to abandon hyperscalers. It requires them to understand their dependencies, diversify where a real risk exists and maintain a viable alternative. - An exit plan that has never been tested is not yet an operational plan. ## The location of the data centre does not determine the whole jurisdiction For years, many infrastructure decisions were considered complete once the provider confirmed that it offered a European region. This was a reasonable criterion: keeping data within the European Union brings it closer to users and corporate systems, can reduce latency and helps meet certain data residency requirements. But physical location only answers part of the question. It is also necessary to understand which legal entity signs the contract, where its parent company is incorporated, from which countries the service can be administered, who controls the encryption keys, which subcontractors are involved and which laws apply to the corporate group. The CLOUD Act, approved in the United States in 2018, establishes that providers of electronic communication services or remote computing services must preserve, back up or disclose information under their “possession, custody or control”, regardless of whether it is stored inside or outside the United States. This does not mean that an authority can access all data hosted by a provider without cause. There must be a valid order, request or legal procedure relating to specific information. Providers may also challenge certain requests and use the legal remedies available under the applicable legislation. The risk for a European company appears where different jurisdictions overlap. On the one hand, the company must comply with the General Data Protection Regulation, rules on international transfers and its contractual obligations. On the other, it may depend on a provider that is subject to requests from a third country. European data residency remains important, but it is not enough to describe the legal exposure of a platform. A complete assessment should answer at least the following questions: AreaQuestion the company must answerLocationIn which countries and data centres is the data stored, processed and replicated?ProviderWhich legal entity signs the contract, and where are its parent company and relevant subsidiaries incorporated?JurisdictionWhich foreign laws may affect the service or the provider?OperationsFrom which countries can support and administration staff access the platform?EncryptionWho generates, controls, stores and can recover the encryption keys?SubcontractingWhich third parties are involved in the service and from which territories do they operate?Government accessHow does the provider respond to requests from domestic or foreign authorities?PortabilityWhich data, images, configurations, logs and metadata can be exported?ExitWhich deadlines, costs, formats and restrictions apply when the service ends? The answer should not be scattered across contracts, technical appendices, privacy policies and sales presentations. Technology, security, compliance, procurement and management teams need a common map that explains where the data is, who can administer it and what would happen if it had to be moved. ### What changes under the European Data Act The Data Act introduces specific obligations to make it easier to switch between providers of data processing services. These include IaaS services, cloud platforms and other models in which a company processes or stores information using resources contracted from a third party. The regulation requires providers to remove commercial, technical, contractual and organisational obstacles that prevent customers from switching to another provider, moving data to their own infrastructure or using several providers simultaneously. Contracts must specify the categories of data and digital assets that can be transferred, the available formats, known technical limitations and the period during which the information can still be retrieved after the transition has ended. They must also provide for the source provider to cooperate in maintaining continuity and supporting the customer’s exit strategy. As a general rule, the maximum transition period is 30 calendar days once the contractual notice period has ended, which itself cannot exceed two months. If that deadline is technically unfeasible, the provider must justify this and propose an alternative period that may not exceed seven months. On 12 January 2027, so-called switching charges will disappear. These are the fees imposed by the source provider for actions that the Data Act requires it to perform during the switch. That does not make a cloud migration free. The company will still have to bear the costs of consulting, engineering, data transfer, bandwidth, application adaptation, parallel operations, testing, new licences and training. Nor does the regulation automatically eliminate early termination penalties or the cost of additional work that falls outside the regulated switching process. The Data Act reduces barriers, but it cannot by itself undo an architecture built around services that are exclusive to a single platform. The greater the use of proprietary databases, serverless functions, identity tools, queues, APIs or provider-specific managed services, the more complex the exit will be. The regulation also requires providers to publish the jurisdiction governing the infrastructure used for each service and a general description of the technical, organisational and contractual measures adopted to prevent international government access that conflicts with European law. At this point, it is useful to distinguish between different types of information. The Data Act provisions on international government access focus on non-personal data. Personal data remains subject to the GDPR and the rest of the European privacy framework. ### CADA and Europe’s new sovereignty levels On 3 June 2026, the European Commission presented the proposal for the Cloud and AI Development Act. CADA aims to expand European capacity in data centres, cloud and Artificial Intelligence, make it easier to deploy new infrastructure and reduce dependencies considered risky. The proposal introduces a European sovereignty framework with four assurance levels. The first is based on data being processed and stored on infrastructure located within the European Union. The higher levels add requirements relating to independence from third countries, transparency across the software supply chain, European ownership and control, and the absence of external interference. The distinction between these levels reflects a central idea: location still matters, but it is not the same as control. CADA also provides for common criteria in public procurement, stronger support for open source technologies and measures to accelerate the deployment of cloud and data centre infrastructure. The Commission also proposes at least tripling Europe’s data centre capacity over the next five to seven years. It is still a legislative proposal. Its content may change during negotiations in the European Parliament and the Council. Even so, the political direction is clear: dependence on infrastructure and providers from third countries is no longer viewed solely as an issue of competition or privacy, but also as a risk to the resilience of public administrations, hospitals, banks, industrial organisations and essential services. Cloud providers will increasingly be assessed against a combination of criteria: security, portability, interoperability, jurisdiction, operational control, sustainability and the ability to maintain service during legal or geopolitical change. ## Operational sovereignty: design the exit before it is needed One of the most useful ideas discussed during the webinar was the distinction between sovereignty as an institutional concept and the **operational sovereignty** a company needs. Operational sovereignty can be measured. An organisation has greater control when it can decide where each application runs, knows who administers its data and maintains a viable alternative if conditions change. Such a change may be triggered by an outage, a cyberattack, a price increase, a corporate acquisition, a change in licensing model, a new regulatory requirement or a geopolitical decision. As David Aibar explained during the session, many companies calculate in detail how much it costs to move into the cloud, but few estimate how much it would cost to leave. The comparison used was that of renting an office: in addition to the rent and the initial fit-out, a company should anticipate the cost of leaving the premises and returning them in the agreed condition. In cloud infrastructure, the exit cost may include extracting data, converting virtual machines, rebuilding networks, replacing managed services, carrying out performance tests, running two platforms in parallel and validating applications. Not all workloads present the same level of difficulty. A virtual machine based on common formats may be moved with a reasonable amount of effort. An application built around numerous platform-specific services will require more engineering, testing and code changes. Sovereignty does not mean avoiding every proprietary technology. It means understanding the cost of dependency and consciously deciding where it is acceptable. ### A hybrid strategy, not migration for its own sake Sovereignty does not require organisations to move every workload away from AWS, Microsoft Azure or Google Cloud. Hyperscalers offer global coverage, advanced services, on-demand capacity and rapid access to analytics and Artificial Intelligence technologies. They may be a good option for global applications, temporary environments, projects with highly variable demand or workloads whose sensitivity and level of dependency have been assessed in advance. Other systems require greater control: customer databases, transactional platforms, intellectual property, essential internal services, backups, systems subject to sector-specific regulation or applications with stable and predictable usage. A hybrid model allows each workload to be placed according to its requirements: Workload typePossible approachDevelopment, testing and temporary projectsFlexible public cloudGlobal applications with variable demandHyperscaler or multicloud architectureBusiness systems with stable usagePrivate cloud with dedicated resourcesSensitive or regulated dataInfrastructure with clearly defined jurisdiction and operationsResource-intensive databasesBare-metal or dedicated infrastructureBackups and recoveryProvider or location independent from productionCritical workloadsHigh availability, replication and tested procedures Using several platforms does not in itself create sovereignty. A multicloud environment without proper design may duplicate tools, increase costs and make security harder to manage. Diversification should respond to specific risks and rely on shared procedures, identities, networks, monitoring and policies. ### Stackscale’s role in an operational sovereignty strategy Stackscale can serve as dedicated European infrastructure within a hybrid or multicloud model. Its private cloud solutions combine exclusive hardware, network storage, private connectivity, specialised support and virtualisation based on Proxmox VE or VMware. Proxmox VE makes it possible to build virtualisation platforms using open source technologies such as KVM and LXC. For many companies, it can provide an alternative that reduces dependence on certain licensing models and gives them greater control over total cost of ownership. The decision should be based on an assessment of compatibility, availability, backups, networking, storage and operational capabilities, not solely on the price of the hypervisor. Bare-metal is suitable for workloads that require dedicated performance, low latency, isolation, direct access to hardware or more predictable behaviour. Private cloud adds a virtualisation and management layer over allocated resources, allowing applications to be consolidated without sharing physical capacity with other customers. For mission-critical environments, Stackscale provides storage with synchronous geo-replication between two Madrid data centres located more than ten kilometres apart. According to the published service specifications, it is designed for zero RPO and zero RTO, with independent and redundant storage systems, snapshot-based backups and 24/7 technical support. The strategy can be complemented with reserved infrastructure for Disaster Recovery. This model allows a cold spare to be maintained at a remote location, activated during periodic tests and used to restore applications after a hardware failure, cyberattack or other emergency. These capabilities fit a range of designs: production on private cloud with backups in another location, workloads running on a hyperscaler with recovery at Stackscale, Proxmox VE clusters with network storage, VMware platforms requiring a second site, or gradual migrations from on-premise and public cloud environments. The objective should not be to move all infrastructure to a single destination. The priority is to build an alternative that can be used when needed. ### A 90-day cloud exit plan An initial assessment does not require a full migration. It can be organised over three months: PhaseRequired workOutcomeInventoryIdentify machines, data, services, networks and dependenciesUp-to-date platform mapClassificationRank workloads by criticality, sensitivity and regulationClear prioritiesJurisdictionReview the provider, parent company, subcontractors and countries involvedLegal exposure mapPortabilityDocument formats, APIs, images and export toolsKnown technical barriersCostsCalculate transfer, engineering, licensing and parallel operationInitial exit budgetDestinationSelect alternative infrastructureAvailable recovery capacityPilotMigrate or restore a representative workloadTested procedureContinuityDefine RTO, RPO and tolerance for disruptionMeasurable targetsSecurityReview identities, keys, encryption and logsControl during transitionTestingRepeat exports, restores and failoversCurrent and verifiable plan During the first month, the company can complete the inventory and classify its workloads. In the second, it can select a representative system, prepare the destination and carry out an initial migration or restore. The third month should be used to measure timings, document exceptions and present the identified costs and risks to management. The result does not have to be an immediate migration. Knowing that an alternative exists, how much it costs, how long it takes and which dependencies must be resolved already improves the organisation’s ability to make decisions. Cloud sovereignty becomes useful when it stops being a political concept and is translated into architecture, contracts, procedures and tests. Moving into a platform is a technical and financial decision. Retaining the freedom to choose how and when to leave is a business continuity decision. ### Frequently asked questions **Does hosting data in a European region prevent the CLOUD Act from applying?** Not necessarily. Physical location is relevant, but companies must also check whether the provider is subject to US jurisdiction and whether it possesses, holds or controls the information. **Does the Data Act make cloud migration free of charge?** No. From 12 January 2027, it removes the switching charges defined by the regulation, but companies will still bear the costs of engineering, adaptation, transfer, testing and operations. **Does a sovereignty strategy require companies to abandon hyperscalers?** No. It can combine public cloud, private cloud, bare-metal, European providers and an independent location for backups or recovery. Each workload should be placed according to its risk, criticality and technical dependencies. **What is the first step towards reducing dependence on a provider?** Create an inventory of workloads and dependencies, review the applicable jurisdiction and carry out a real export, migration or recovery test on an alternative infrastructure. Sources: - **Despeja tu Cloud** webinar held by Aire on 08/07/2026. - Regulation (EU) 2023/2854, Data Act, in particular Articles 23 to 32. - United States Code, Title 18, Section 2713, on the territorial scope of the CLOUD Act. - European Commission proposal for the Cloud and AI Development Act, presented on 03/06/2026. - Stackscale, private cloud solutions with Proxmox VE and VMware. - Stackscale, storage with synchronous geo-replication. - Stackscale, reserved infrastructure for Disaster Recovery. --- ## Soberanía cloud: ¿bajo qué ley están los datos de tu empresa? URL: https://www.stackscale.com/blog/cloud-sovereignty-which-laws-govern-your-companys-data/ Aire, grupo al que pertenece Stackscale, celebró el 8 de julio de 2026 el primer webinar de **Despeja tu Cloud**, una serie de sesiones dedicada a explicar los cambios regulatorios, técnicos y geopolíticos que están modificando la forma de contratar infraestructura. Zigor Gaubeca, CIO de Aire, y David Aibar Carretero, Head of Sales, plantearon una pregunta que debería llegar a cualquier comité de dirección: si un juez preguntase hoy bajo qué jurisdicción se encuentran los datos críticos de la empresa, ¿habría una respuesta clara y documentada? La respuesta no depende únicamente del país donde esté ubicado el centro de datos. Una carga puede ejecutarse físicamente en Madrid, París o Fráncfort y seguir expuesta a normas de terceros países por la nacionalidad, la estructura societaria o el control efectivo del proveedor. Por eso la soberanía cloud empieza a formar parte de la continuidad de negocio, junto con la ciberseguridad, los backups, la alta disponibilidad y el Disaster Recovery. ## Soberanía cloud: las claves en 20 segundos - Alojar los datos en Europa no garantiza por sí solo que estén sometidos únicamente a legislación europea. - La jurisdicción también depende de la empresa que presta el servicio, su matriz, los subcontratistas y quién posee, custodia o controla la información. - El CLOUD Act estadounidense puede alcanzar datos almacenados fuera de Estados Unidos cuando están bajo el control de un proveedor sujeto a esa legislación. - Esto no permite un acceso arbitrario a cualquier información. Debe existir una solicitud legal válida, específica y vinculada a un procedimiento. - El Data Act europeo, aplicable con carácter general desde el 12 de septiembre de 2025, obliga a reducir barreras contractuales, comerciales y técnicas al cambio de proveedor cloud. - Desde el 12 de enero de 2027 no podrán cobrarse los gastos de cambio definidos por el Data Act, aunque las migraciones seguirán teniendo costes técnicos y operativos. - La Comisión Europea presentó el 3 de junio de 2026 la propuesta del Cloud and AI Development Act, CADA, que introduce un marco común para evaluar diferentes niveles de soberanía cloud y de Inteligencia Artificial. - La soberanía no exige abandonar los hiperescalares. Exige conocer las dependencias, diversificar cuando exista un riesgo real y disponer de una alternativa viable. - Un plan de salida que nunca se ha probado todavía no es un plan operativo. ## La ubicación del centro de datos no determina toda la jurisdicción Durante años, muchas decisiones de infraestructura se han cerrado después de comprobar que el proveedor ofrecía una región europea. Era un criterio razonable: mantener los datos dentro de la Unión Europea facilita su proximidad a usuarios y sistemas, puede reducir la latencia y ayuda a cumplir determinados requisitos de residencia. Pero la ubicación física solo responde a una parte de la pregunta. También importa qué sociedad firma el contrato, dónde está constituida su matriz, desde qué países puede administrarse el servicio, quién controla las claves de cifrado, qué subcontratistas participan y a qué legislaciones está sometido el grupo empresarial. El CLOUD Act, aprobado en Estados Unidos en 2018, establece que los proveedores de servicios de comunicaciones electrónicas o computación remota deben preservar, respaldar o entregar la información que se encuentre bajo su «posesión, custodia o control», con independencia de que esté almacenada dentro o fuera del territorio estadounidense. Esto no significa que una autoridad pueda acceder sin causa a todos los datos alojados por un proveedor. Debe existir una orden, un requerimiento o un procedimiento jurídico válido referido a información concreta. Los proveedores también pueden impugnar determinadas solicitudes y recurrir a los mecanismos previstos en la legislación aplicable. El riesgo para una compañía europea aparece en el cruce entre jurisdicciones. Por una parte, debe cumplir el Reglamento General de Protección de Datos (RGPD), las normas sobre transferencias internacionales y sus obligaciones contractuales. Por otra, puede depender de un proveedor sujeto a requerimientos procedentes de un tercer país. La residencia europea sigue siendo importante, pero no basta para describir la exposición jurídica de una plataforma. Una evaluación completa debería responder, como mínimo, a estas preguntas: ÁreaPregunta que debe responder la empresaUbicación¿En qué países y centros de datos se almacenan, procesan y replican los datos?Proveedor¿Qué sociedad firma el contrato y dónde están constituidas su matriz y sus filiales relevantes?Jurisdicción¿Qué legislaciones extranjeras pueden afectar al servicio o al proveedor?Operación¿Desde qué países puede acceder el personal de soporte y administración?Cifrado¿Quién genera, controla, almacena y puede recuperar las claves?Subcontratación¿Qué terceros participan en la prestación y desde qué territorios operan?Acceso público¿Cómo responde el proveedor ante solicitudes de autoridades nacionales o extranjeras?Portabilidad¿Qué datos, imágenes, configuraciones, registros y metadatos pueden exportarse?Salida¿Qué plazos, costes, formatos y limitaciones se aplican al finalizar el servicio? La respuesta no debería estar fragmentada entre contratos, anexos técnicos, políticas de privacidad y presentaciones comerciales. Tecnología, seguridad, cumplimiento, compras y dirección necesitan un mapa común que permita conocer dónde están los datos, quién puede administrarlos y qué ocurriría si fuera necesario moverlos. ### Qué cambia con el Data Act europeo El Data Act introduce obligaciones concretas para facilitar el cambio entre proveedores de servicios de procesamiento de datos. Entre ellos se incluyen servicios IaaS, plataformas cloud y otros modelos en los que una empresa procesa o almacena información mediante recursos contratados a un tercero. La norma exige eliminar obstáculos comerciales, técnicos, contractuales y organizativos que impidan cambiar a otro proveedor, trasladar los datos a una infraestructura propia o utilizar varios proveedores simultáneamente. Los contratos deben especificar las categorías de datos y activos digitales que pueden portarse, los formatos disponibles, las limitaciones técnicas conocidas y el periodo durante el cual la información podrá recuperarse después de finalizar la transición. También deben contemplar la colaboración del proveedor de origen para mantener la continuidad y apoyar la estrategia de salida del cliente. Como regla general, el periodo máximo de transición es de 30 días naturales, una vez concluido el preaviso contractual, que no puede superar los dos meses. Si ese plazo resulta técnicamente inviable, el proveedor debe justificarlo y proponer un periodo alternativo que no exceda de siete meses. El 12 de enero de 2027 desaparecerán los denominados *switching charges*: los gastos que el proveedor de origen impone por las actuaciones que el Data Act le obliga a realizar durante el cambio. Eso no convierte una migración cloud en gratuita. La empresa seguirá asumiendo los costes de consultoría, ingeniería, transferencia, ancho de banda, adaptación de aplicaciones, doble operación, pruebas, nuevas licencias y formación. La norma tampoco elimina automáticamente las penalizaciones por terminar anticipadamente un contrato ni el precio de trabajos adicionales que queden fuera del proceso regulado. El Data Act reduce barreras, pero no puede deshacer por sí solo una arquitectura construida sobre servicios exclusivos de una plataforma. Cuanto mayor sea el uso de bases de datos propietarias, funciones serverless, herramientas de identidad, colas, APIs o servicios gestionados específicos, más compleja será la salida. La norma también obliga a los proveedores a publicar la jurisdicción a la que está sometida la infraestructura utilizada para cada servicio y una descripción general de las medidas técnicas, organizativas y contractuales adoptadas frente a accesos gubernamentales internacionales que entren en conflicto con el Derecho europeo. En este punto conviene distinguir entre tipos de información. Las disposiciones del Data Act sobre accesos gubernamentales internacionales se centran en los datos no personales. Los datos personales siguen sujetos al RGPD y al resto de la normativa europea de privacidad. ### CADA y los nuevos niveles de soberanía europea La Comisión Europea presentó el 3 de junio de 2026 la propuesta del Cloud and AI Development Act. CADA busca ampliar la capacidad europea de centros de datos, cloud e Inteligencia Artificial, facilitar el desarrollo de nueva infraestructura y reducir dependencias consideradas de riesgo. La propuesta introduce un marco europeo de soberanía con cuatro niveles de aseguramiento. El primero se basa en que los datos sean tratados y almacenados en infraestructura situada dentro de la Unión. Los niveles superiores añaden requisitos sobre independencia respecto a terceros países, transparencia de la cadena de suministro de software, propiedad y control europeos o ausencia de interferencias externas. La diferencia entre esos niveles refleja una idea central: la localización sigue siendo relevante, pero no equivale al control. CADA también prevé criterios comunes para la contratación pública, un mayor apoyo a tecnologías open source y medidas para acelerar el despliegue de infraestructura cloud y de centros de datos. La Comisión plantea, además, triplicar al menos la capacidad europea de centros de datos durante los próximos cinco a siete años. Se trata todavía de una propuesta legislativa. Su contenido puede modificarse durante la tramitación en el Parlamento Europeo y el Consejo. Sin embargo, la dirección política está definida: la dependencia de infraestructuras y proveedores de terceros países ya no se analiza únicamente como una cuestión de competencia o privacidad, sino también como un riesgo para la resiliencia de administraciones, hospitales, bancos, industrias y servicios esenciales. El proveedor cloud deberá evaluarse cada vez más por una combinación de criterios: seguridad, portabilidad, interoperabilidad, jurisdicción, control operativo, sostenibilidad y capacidad para mantener el servicio ante cambios legales o geopolíticos. ## Soberanía operativa: diseñar la salida antes de necesitarla Una de las ideas más útiles del webinar fue separar la soberanía como concepto institucional de la **soberanía operativa** que necesita una empresa. La soberanía operativa puede medirse. Una organización dispone de mayor control cuando puede decidir dónde ejecuta cada aplicación, conoce quién administra sus datos y mantiene una alternativa viable si cambian las condiciones. Ese cambio puede deberse a una interrupción, un ciberataque, una subida de precios, una adquisición empresarial, una modificación del modelo de licencias, un nuevo requisito regulatorio o una decisión geopolítica. Como explicó David Aibar durante la sesión, muchas empresas calculan con detalle cuánto cuesta entrar en el cloud, pero pocas estiman cuánto costaría salir. La comparación utilizada fue la del alquiler de una oficina: además de la renta y la adaptación inicial, conviene prever el coste de abandonar el espacio y entregarlo en las condiciones acordadas. En infraestructura cloud, el coste de salida puede incluir la extracción de datos, la conversión de máquinas virtuales, la reconstrucción de redes, la sustitución de servicios gestionados, las pruebas de rendimiento, la operación simultánea de dos plataformas y la validación funcional de las aplicaciones. No todas las cargas presentan la misma dificultad. Una máquina virtual basada en formatos comunes puede trasladarse con un esfuerzo razonable. Una aplicación construida con numerosos servicios exclusivos de una plataforma exigirá más ingeniería, pruebas y cambios en el código. La soberanía no consiste en evitar toda tecnología propietaria. Consiste en conocer el coste de la dependencia y decidir de forma consciente dónde resulta aceptable. ### Una estrategia híbrida, no una migración por principios La soberanía tampoco obliga a sacar todas las cargas de AWS, Microsoft Azure o Google Cloud. Los hiperescalares ofrecen presencia internacional, servicios avanzados, capacidad bajo demanda y acceso rápido a tecnologías de analítica e Inteligencia Artificial. Pueden ser una buena opción para aplicaciones globales, entornos temporales, proyectos con demanda muy variable o cargas cuyo nivel de sensibilidad y dependencia se haya evaluado previamente. Otros sistemas requieren más control: bases de datos de clientes, plataformas transaccionales, propiedad intelectual, servicios internos esenciales, backups, sistemas sujetos a regulación sectorial o aplicaciones con un consumo estable y predecible. Un modelo híbrido permite asignar cada carga según sus necesidades: Tipo de cargaPosible enfoqueDesarrollo, pruebas y proyectos temporalesCloud público flexibleAplicaciones globales con demanda variableHiperescalar o arquitectura multicloudSistemas empresariales con consumo estableCloud privado con recursos dedicadosDatos sensibles o sujetos a regulaciónInfraestructura con jurisdicción y operación claramente definidasBases de datos con uso intensivo de recursosBare-metal o infraestructura dedicadaBackups y recuperaciónProveedor o ubicación independiente de la producciónCargas críticasAlta disponibilidad, replicación y procedimientos probados Utilizar varias plataformas tampoco genera soberanía por sí solo. Un multicloud sin diseño puede duplicar herramientas, aumentar costes y complicar la seguridad. La diversificación debe responder a riesgos concretos y apoyarse en procedimientos, identidades, redes, monitorización y políticas comunes. ### El papel de Stackscale en una estrategia de soberanía operativa Stackscale puede actuar como infraestructura europea dedicada dentro de un modelo híbrido o multicloud. Sus soluciones de cloud privado combinan equipamiento exclusivo, almacenamiento en red, conectividad privada, soporte especializado y virtualización con Proxmox VE o VMware. Proxmox VE permite construir plataformas de virtualización sobre tecnologías open source como KVM y LXC. Para muchas empresas puede ser una alternativa con la que reducir la dependencia de determinados modelos de licenciamiento y mantener un mayor control sobre el coste total de propiedad. La decisión debe partir de una evaluación de compatibilidad, disponibilidad, backups, red, almacenamiento y capacidades operativas, no solo del precio del hipervisor. El bare-metal resulta adecuado cuando una carga necesita rendimiento dedicado, baja latencia, aislamiento, acceso directo al hardware o un comportamiento más predecible. El cloud privado añade una capa de virtualización y gestión sobre recursos asignados, lo que facilita consolidar aplicaciones sin compartir la capacidad física con otros clientes. En entornos de misión crítica, Stackscale dispone de almacenamiento con georreplicación síncrona entre dos centros de datos de Madrid separados por más de diez kilómetros. El servicio publicado está diseñado con RPO y RTO iguales a cero, sistemas de almacenamiento independientes y redundantes, backups basados en snapshots y soporte técnico 24/7. La estrategia puede completarse con infraestructura reservada para Disaster Recovery. Este modelo permite mantener un *cold spare* en una ubicación remota, activarlo durante pruebas periódicas y utilizarlo para restaurar aplicaciones después de un fallo de hardware, un ciberataque u otra emergencia. Estas capacidades encajan en diferentes diseños: producción en cloud privado y backups en otra ubicación, servicios desplegados en un hiperescalar con recuperación en Stackscale, clústeres Proxmox VE con almacenamiento en red, plataformas VMware que necesitan una segunda localización o migraciones progresivas desde entornos on-premise y cloud público. El objetivo no debería ser trasladar toda la infraestructura a un único destino. La prioridad es construir una alternativa que pueda utilizarse cuando sea necesaria. ### Un plan de salida cloud en 90 días Una primera evaluación no requiere iniciar una migración completa. Puede organizarse en tres meses: FaseTrabajo necesarioResultadoInventarioIdentificar máquinas, datos, servicios, redes y dependenciasMapa actualizado de la plataformaClasificaciónOrdenar las cargas por criticidad, sensibilidad y regulaciónPrioridades de actuaciónJurisdicciónRevisar proveedor, matriz, subcontratistas y países implicadosMapa de exposición jurídicaPortabilidadDocumentar formatos, APIs, imágenes y herramientas de exportaciónBarreras técnicas conocidasCostesCalcular transferencia, ingeniería, licencias y doble operaciónPresupuesto inicial de salidaDestinoSeleccionar una infraestructura alternativaCapacidad de recuperación disponiblePilotoMigrar o restaurar una carga representativaProcedimiento probadoContinuidadDefinir RTO, RPO y tolerancia a interrupcionesObjetivos mediblesSeguridadRevisar identidades, claves, cifrado y registrosControl durante la transiciónPruebasRepetir exportaciones, restauraciones y conmutacionesPlan vigente y verificable Durante el primer mes, la empresa puede completar el inventario y clasificar las cargas. En el segundo, seleccionar un sistema representativo, preparar el destino y ejecutar una primera migración o restauración. El tercer mes debe servir para medir tiempos, documentar excepciones y presentar a dirección los costes y riesgos detectados. El resultado no tiene que ser una migración inmediata. Saber que existe una alternativa, cuánto cuesta, cuánto tarda y qué dependencias deben resolverse ya mejora la capacidad de decisión. La soberanía cloud se vuelve útil cuando deja de ser un concepto político y se traduce en arquitectura, contratos, procedimientos y pruebas. Entrar en una plataforma es una decisión técnica y económica. Conservar la capacidad de elegir cómo y cuándo salir es una decisión de continuidad de negocio. ### Preguntas frecuentes **¿Alojar los datos en una región europea evita la aplicación del CLOUD Act?** No necesariamente. La ubicación física es relevante, pero también debe comprobarse si el proveedor está sujeto a la jurisdicción estadounidense y si posee, custodia o controla la información. **¿El Data Act obliga a que una migración cloud sea gratuita?** No. Desde el 12 de enero de 2027 elimina los gastos de cambio definidos por el reglamento, pero la empresa seguirá asumiendo costes de ingeniería, adaptación, transferencia, pruebas y operación. **¿Una estrategia de soberanía obliga a abandonar los hiperescalares?** No. Puede combinar cloud público, cloud privado, bare-metal, proveedores europeos y una ubicación independiente para backups o recuperación. Cada carga debe situarse según su riesgo, criticidad y dependencia técnica. **¿Cuál es el primer paso para reducir la dependencia de un proveedor?** Inventariar las cargas y sus dependencias, revisar la jurisdicción aplicable y realizar una prueba real de exportación, migración o restauración en una infraestructura alternativa. Fuentes: - Webinar **Despeja tu Cloud**, celebrado por Aire el 08/07/2026. - Reglamento (UE) 2023/2854, Data Act, especialmente sus artículos 23 a 32. - Código de Estados Unidos, título 18, sección 2713, sobre el alcance territorial del CLOUD Act. - Comisión Europea, propuesta del Cloud and AI Development Act, presentada el 03/06/2026. - Stackscale, soluciones de cloud privado con Proxmox VE y VMware. - Stackscale, almacenamiento con georreplicación síncrona. - Stackscale, infraestructura reservada para Disaster Recovery. --- ## World Cup streaming puts Internet infrastructure to the test URL: https://www.stackscale.com/blog/world-cup-streaming-puts-internet-infrastructure-to-the-test/ The **Portugal-Spain match at the 2026 World Cup** left more than sporting tension behind. It also set a **new all-time traffic record in DE-CIX’s global interconnection ecosystem: 28.4 Tbit/s, registered on 06/07/2026 at 19:35 UTC, 21:35 Spanish peninsular time**. The figure confirms a trend that has been building for years: major live events are no longer just a television matter, but a stress test for networks, data centers, cloud platforms, CDNs and interconnection operators. The data has a clear technical reading. Internet traffic does not grow only through the gradual accumulation of users, devices and applications. Increasingly, it also grows through highly concentrated peaks in time. Millions of people connect almost simultaneously, from smart TVs, smartphones, tablets and computers, to consume the same live content. That synchronization changes the way infrastructure is designed: it is no longer enough to support a reasonable average traffic load; platforms must be ready to absorb massive bursts without degrading the user experience. ## Live streaming changes traffic patterns For years, much of the growth in Internet traffic has been linked to predictable trends: more remote working, more video calls, more e-commerce, more on-demand audiovisual content and more cloud services. Stackscale had already analyzed this growth in previous articles on the rise in global Internet traffic between 2020 and 2021 and on the increase in global traffic in 2024. But sports streaming introduces a different variable: simultaneity. A series watched on demand, a software update or an enterprise backup spreads the load more evenly over time. A World Cup knockout match does not. The peak appears within minutes, often just before kick-off, during key plays or at half-time, when searches for statistics, social media activity, highlights, chats and second-screen applications also surge. DE-CIX also points to a factor that will gain weight in the coming years: content generated or enriched by Artificial Intelligence. Automated highlights, personalized recommendations, real-time statistics and interactive experiences add new layers of traffic on top of the main broadcast. Video remains the major consumer of bandwidth, but a whole set of services is growing around it, also requiring low latency, availability and responsiveness. For companies, the lesson goes beyond sport. Any digital business with campaigns, launches, sales periods, online events, live broadcasts, auctions, ticket sales or data-intensive services may face similar patterns, even if at a different scale. Infrastructure must be designed with the real peak hour in mind, not just the monthly average. ## Internet exchanges, CDNs and latency: the invisible side of streaming When a user clicks “watch live”, they expect the stream to load quickly, remain stable and have low delay. But behind that action lies a complex chain: access providers, backbone networks, cloud platforms, data centers, CDNs, streaming operators and Internet Exchange Points. Internet Exchange Points, or IXPs, allow different networks to exchange traffic directly, without forcing data to travel through unnecessary routes. Stackscale had already explained in its article on Internet Exchange Points how this direct interconnection helps improve latency and bandwidth. It also published specific pieces on DE-CIX, one of the world’s largest Internet Exchange Point operators, and on AMS-IX, the Amsterdam Internet Exchange. The logic is simple: the closer content is to the user and the fewer hops it has to cross, the better the experience. That is why CDNs distribute copies of content across multiple locations, and why well-connected data centers are so important. In a global event such as the World Cup, it is not only about having powerful servers, but about placing capacity in the right locations and connecting it to the right networks. Latency, also analyzed on the Stackscale blog, is one of the factors that most affects perceived quality. In traditional video streaming it may seem less critical than in gaming, trading or industrial applications, but in live broadcasting it makes a difference: delay compared with the original feed, buffering, quality changes, start-up times and synchronization with statistics or interactive experiences. The physical infrastructure of the Internet also comes into play. Submarine cables, metropolitan networks, fiber optics, meet-me rooms in data centers and links with operators are all part of an architecture the user does not see, but which sustains the digital experience. Massive streaming does not live in “the cloud” as an abstract concept: it lives in racks, routers, switches, fiber links, interconnection ports, storage systems and distributed computing platforms. ## What companies should learn from these traffic peaks The 28.4 Tbit/s record does not mean that every company has to size its platform like a global streaming operator. But it does leave a useful idea: peaks do not forgive poorly designed architectures. In e-commerce, digital media, SaaS, education platforms, gaming, fintech or B2B services with high-demand windows, infrastructure must combine several layers. The first is computing capacity: enough CPU, memory and storage to handle the load. The second is networking: bandwidth, routing, redundant connectivity and low latency. The third is application architecture: caching, load balancing, queues, properly sized databases, separation of critical services and observability. Stackscale recently published a guide on how to prepare infrastructure for traffic peaks without the website going down, with a very practical idea: before adding resources without a clear plan, it is worth reviewing the frontend, database, media, caches, physical limits and bottlenecks. More servers do not always solve a poor design. Sometimes the problem lies in an inefficient query, storage saturated by IOPS, a poorly configured CDN or a database concentrating too much load. This is where private cloud and bare-metal play a relevant role. For critical workloads, latency-sensitive services or applications with intensive and predictable consumption, dedicated resources help reduce the risk of noisy neighbors and provide greater control over CPU, memory, network and storage. It is not always the right option for every workload, but it fits scenarios where sustained performance, cost predictability and isolation matter. In European environments, data sovereignty is also part of the equation. Hosting infrastructure in data centers within Europe, with the right connectivity and close operational support, makes technical, contractual and regulatory control easier. This is especially important in sectors that work with sensitive data, critical services, intellectual property or compliance requirements. High availability must also be approached realistically. It is not enough to replicate virtual machines. RPO, RTO, service dependencies, backup strategy, disaster recovery, monitoring and regular testing must all be defined. A traffic peak can expose failures that remain hidden for weeks: connection limits, firewall saturation, insufficient load balancer capacity, slow storage or network paths that are not ready to absorb sustained traffic. The World Cup shows the Internet at its most demanding: millions of users, simultaneous consumption, high-quality video and added services around the broadcast. For companies, the lesson is closer than it might seem. Infrastructure should not be designed only to work when everything is calm, but to keep responding when many users do the same thing at the same time. ## Frequently asked questions What does a 28.4 Tbit/s Internet traffic peak mean?It means that, at a specific moment, DE-CIX’s global interconnection ecosystem moved 28.4 terabits per second. It is a measure of aggregated traffic and reflects the pressure that massive live events can place on Internet infrastructure. Why does sports streaming generate such large traffic peaks?Because it concentrates millions of users connecting at the same time. Unlike on-demand video, a live match does not spread consumption over hours or days, but concentrates demand in very specific time windows. What role do Internet Exchange Points play?Internet Exchange Points allow the direct exchange of traffic between networks, operators, CDNs, cloud providers and digital platforms. They help reduce unnecessary routes, improve latency and increase network efficiency. How can a company prepare for traffic peaks?It should review the full architecture: application, database, cache, load balancing, network, storage, monitoring, backups and scaling capacity. For critical workloads, a private cloud or bare-metal environment can provide dedicated performance, control and predictability. --- ## El streaming del Mundial pone a prueba la infraestructura de Internet URL: https://www.stackscale.com/blog/world-cup-streaming-puts-internet-infrastructure-to-the-test/ El **partido Portugal-España del Mundial de 2026** dejó algo más que tensión deportiva. También **marcó un nuevo máximo histórico de tráfico en el ecosistema global de interconexión de DE-CIX: 28,4 Tbit/s registrados el 6/07/2026 a las 19:35 UTC, 21:35 en horario peninsular español**. La cifra confirma una tendencia que llevaba años gestándose: los grandes eventos en directo ya no son solo un asunto de televisión, sino una prueba de estrés para redes, centros de datos, plataformas cloud, CDN y operadores de interconexión. El dato tiene una lectura técnica clara. Internet no crece únicamente por acumulación progresiva de usuarios, dispositivos y aplicaciones. Cada vez más, también lo hace mediante picos muy concentrados en el tiempo. Millones de personas se conectan casi a la vez, desde televisores inteligentes, móviles, tablets y ordenadores, para consumir el mismo contenido en directo. Esa sincronización cambia la forma de diseñar infraestructura: ya no basta con soportar una media razonable de tráfico, hay que estar preparado para absorber ráfagas masivas sin degradar la experiencia. ## El directo cambia el patrón del tráfico Durante años, buena parte del crecimiento del tráfico de Internet ha estado asociado a tendencias previsibles: más teletrabajo, más videollamadas, más comercio electrónico, más consumo audiovisual bajo demanda y más servicios cloud. Stackscale ya analizaba este crecimiento en artículos anteriores sobre el aumento del tráfico mundial de Internet entre 2020 y 2021 y sobre el incremento del tráfico global en 2024. Pero el streaming deportivo introduce una variable distinta: la simultaneidad. Una serie bajo demanda, una actualización de software o una copia de seguridad empresarial distribuyen mejor la carga en el tiempo. Un partido de octavos del Mundial no. El pico aparece en minutos, muchas veces justo antes del saque inicial, durante jugadas importantes o en el descanso, cuando se disparan también las consultas a estadísticas, redes sociales, resúmenes, chats y aplicaciones de segunda pantalla. DE-CIX apunta además a un factor que irá ganando peso: los contenidos generados o enriquecidos por Inteligencia Artificial. Resúmenes automáticos, recomendaciones personalizadas, estadísticas en tiempo real y experiencias interactivas añaden capas de tráfico sobre la emisión principal. El vídeo sigue siendo el gran consumidor de ancho de banda, pero alrededor del vídeo crece todo un conjunto de servicios que también necesitan baja latencia, disponibilidad y capacidad de respuesta. Para las empresas, la enseñanza va más allá del deporte. Cualquier negocio digital con campañas, lanzamientos, rebajas, eventos online, retransmisiones, subastas, venta de entradas o consumo intensivo de datos puede encontrarse con patrones parecidos, aunque a otra escala. La infraestructura debe diseñarse pensando en la hora punta real, no solo en el promedio mensual. ## Puntos neutros, CDN y latencia: la parte invisible del streaming Cuando un usuario pulsa “ver en directo”, espera que la imagen cargue rápido, que no se corte y que el retardo sea bajo. Pero detrás hay una cadena compleja: proveedores de acceso, redes troncales, plataformas cloud, centros de datos, CDN, operadores de streaming y puntos de intercambio de Internet. Los puntos neutros o IXPs permiten que distintas redes intercambien tráfico de forma directa, sin obligar a los datos a recorrer rutas innecesarias. Stackscale ya explicaba en su artículo sobre puntos neutros que esta interconexión directa ayuda a mejorar la latencia y el ancho de banda. También dedicó una pieza específica a DE-CIX, uno de los mayores operadores de puntos de intercambio de Internet del mundo, y otra a AMS-IX, el punto neutro de Ámsterdam. La lógica es sencilla: cuanto más cerca esté el contenido del usuario y menos saltos tenga que atravesar, mejor será la experiencia. Por eso las CDN distribuyen copias del contenido en múltiples ubicaciones y por eso los centros de datos bien conectados son tan relevantes. En un evento global como el Mundial, no se trata solo de tener servidores potentes, sino de colocar la capacidad en los lugares adecuados y conectarla con las redes adecuadas. La latencia, analizada también en el blog de Stackscale, es uno de los factores que más condicionan la percepción de calidad. En streaming de vídeo tradicional puede parecer menos crítica que en videojuegos, trading o aplicaciones industriales, pero en directo marca diferencias: retardo frente a la emisión, cortes, cambios de calidad, tiempos de arranque y sincronización con estadísticas o experiencias interactivas. También entra en juego la infraestructura física de Internet. Los cables submarinos, las redes metropolitanas, la fibra óptica, las salas meet me room de los centros de datos y los enlaces con operadores forman parte de una arquitectura que el usuario no ve, pero que sostiene la experiencia digital. El streaming masivo no vive en “la nube” como concepto abstracto: vive en racks, routers, switches, fibras, puertos de interconexión, sistemas de almacenamiento y plataformas de computación distribuidas. ## Qué deben aprender las empresas de estos picos de tráfico El récord de 28,4 Tbit/s no significa que una empresa tenga que dimensionar su plataforma como un operador global de streaming. Pero sí deja una idea útil: los picos no perdonan una arquitectura mal diseñada. En ecommerce, medios digitales, SaaS, plataformas educativas, gaming, fintech o servicios B2B con ventanas de alta demanda, la infraestructura debe combinar varias capas. La primera es la capacidad de cómputo: CPU, memoria y almacenamiento suficientes para soportar la carga. La segunda es la red: ancho de banda, rutas, conectividad redundante y baja latencia. La tercera es la arquitectura de aplicación: caché, balanceo, colas, bases de datos bien dimensionadas, separación de servicios críticos y observabilidad. Stackscale publicó recientemente una guía sobre cómo preparar la infraestructura para picos de tráfico sin que el sitio se caiga, con una idea muy práctica: antes de añadir recursos sin criterio, conviene revisar frontend, base de datos, medios, cachés, límites físicos y cuellos de botella. Más servidores no siempre resuelven un mal diseño. A veces el problema está en una consulta ineficiente, un almacenamiento saturado de IOPS, una CDN mal configurada o una base de datos que concentra demasiada carga. Aquí el cloud privado y el bare-metal tienen un papel relevante. Para cargas críticas, sensibles a la latencia o con consumo intensivo y predecible, disponer de recursos dedicados permite reducir el riesgo de vecinos ruidosos y tener mayor control sobre CPU, memoria, red y almacenamiento. No siempre es la opción adecuada para todo, pero sí encaja en escenarios donde el rendimiento sostenido, la previsibilidad de costes y el aislamiento importan. En entornos europeos, además, entra la variable de soberanía de datos. Alojar infraestructura en centros de datos dentro de Europa, con conectividad adecuada y operación cercana, facilita el control técnico, contractual y normativo. Esto es especialmente importante en sectores que trabajan con datos sensibles, servicios críticos, propiedad intelectual o requisitos de cumplimiento. La alta disponibilidad también debe plantearse con realismo. No basta con replicar máquinas virtuales. Hay que definir RPO, RTO, dependencias entre servicios, estrategia de backups, recuperación ante desastres, monitorización y pruebas periódicas. Un pico de tráfico puede descubrir fallos que permanecen ocultos durante semanas: límites de conexiones, saturación de firewalls, falta de capacidad en balanceadores, almacenamiento lento o rutas de red no preparadas para absorber tráfico sostenido. El Mundial muestra Internet en su versión más exigente: millones de usuarios, consumo simultáneo, vídeo en alta calidad y servicios añadidos alrededor de la emisión. Para las empresas, la lección es más cercana de lo que parece. La infraestructura no debe diseñarse solo para funcionar cuando todo va bien, sino para seguir respondiendo cuando muchos usuarios hacen lo mismo al mismo tiempo. ## Preguntas frecuentes ¿Qué significa un pico de 28,4 Tbit/s en Internet?Significa que, en un momento concreto, el ecosistema global de interconexión de DE-CIX llegó a mover 28,4 terabits por segundo. Es una medida de tráfico agregado y refleja la presión que pueden generar eventos masivos en directo. ¿Por qué el streaming deportivo genera tantos picos de tráfico?Porque concentra a millones de usuarios conectándose al mismo tiempo. A diferencia del vídeo bajo demanda, un partido en directo no reparte el consumo durante horas o días, sino que concentra la demanda en ventanas muy concretas. ¿Qué papel tienen los puntos neutros de Internet?Los puntos neutros permiten el intercambio directo de tráfico entre redes, operadores, CDN, proveedores cloud y plataformas digitales. Ayudan a reducir rutas innecesarias, mejorar la latencia y aumentar la eficiencia de la red. ¿Cómo puede prepararse una empresa para picos de tráfico?Debe revisar la arquitectura completa: aplicación, base de datos, caché, balanceo, red, almacenamiento, monitorización, backups y capacidad de escalado. En cargas críticas, un entorno cloud privado o bare-metal puede aportar rendimiento dedicado, control y previsibilidad. --- ## Offensive AI forces companies to rethink continuous security URL: https://www.stackscale.com/blog/offensive-ai-forces-companies-to-rethink-continuous-security/ The new BP/36 guide from Spain’s CCN-CERT, published in June 2026, gives a name to a reality that many security teams were already noticing: the traditional model of one-off audits, annual penetration tests and patching cycles planned weeks in advance is falling short against attackers that use Artificial Intelligence to accelerate reconnaissance, exploitation, social engineering and offensive decision-making. The central point is not that Artificial Intelligence has invented every attack from scratch. The change lies in speed, scale and automation. Well-known techniques such as phishing, exposed attack surface analysis, malicious code generation, vulnerability exploitation, credential abuse or manipulation of systems based on language models can now be executed with less effort and in less time. For companies, this shifts the focus from periodic security checks to continuous validation, resilience by design and operational response capability. ## From annual pentesting to continuous validation For years, many organisations have used the annual penetration test as a reasonable proof of security. They commissioned an assessment, received a report, fixed the priority findings and kept evidence for audit, compliance or internal improvement. That model still has value, but it is no longer enough if it is used as the only offensive security validation. CCN-CERT refers to a “collapse of the vulnerability cycle”: identification and exploitation can happen almost at the same time. In practical terms, an exposed vulnerability in a critical service can no longer wait for the next change committee, the next monthly report or the end-of-year audit. If an attacker can automate reconnaissance, correlate public information, test vectors in parallel and prioritise targets by exploitability, defence needs to operate at a different pace. This changes vulnerability management. Priority should not depend only on the CVSS score, but also on real exploitability, the KEV catalogue of known exploited vulnerabilities, EPSS and the criticality of the affected asset. A dashboard full of “high” vulnerabilities does not say enough unless it is cross-referenced with Internet exposure, business function, associated access, data handled and the possibility of lateral movement. It also changes the role of the penetration test. It stops being the big annual exam and becomes part of a broader model: permanent vulnerability management, recurring offensive validation, attack simulations, continuous code review and detection controls capable of reacting in minutes or hours. The goal is not to live in a permanent state of emergency, but to reduce the distance between what the company believes it controls and what is actually exposed. In private cloud, bare-metal or hybrid infrastructures, this approach requires more architectural discipline. The asset inventory must be alive. Networks must be properly segmented. Administrative access must be protected with phishing-resistant authentication, ephemeral credentials and least privilege. Backups must be isolated, immutable where appropriate and tested at a realistic frequency. Without these foundations, adding defensive Artificial Intelligence tools does not solve the underlying problem. ## AI agents are also a new attack surface BP/36 devotes significant attention to Artificial Intelligence agents, and this is one of its most important signals for CIOs, CTOs and CISOs. An agent that queries data, executes actions, calls APIs, modifies configurations or interacts with internal systems is not just a conversational assistant. It is an operational identity with permissions, context and impact capacity. That nuance completely changes AI governance in the enterprise. An agent can be manipulated through prompt injection, access information that should not be part of its context, exfiltrate data through apparently legitimate responses or chain together wrong decisions if it has too much autonomy. When it is also connected to internal tools, document repositories, ticketing systems, code repositories, cloud platforms or administration consoles, it becomes part of the attack surface. The answer is not to block all use of agents, but to govern it. Each agent should have its own identity, minimum permissions, clear limits of action, full traceability, secure credential management, input and output validation, separation of capabilities and human supervision for critical actions. The guide also mentions the need for a kill switch to stop activity if anomalous behaviour is detected. This point is especially important for organisations that are integrating AI assistants into internal processes without involving security, architecture or compliance teams. Shadow AI may reproduce a well-known shadow IT problem, but with greater exposure capacity: sensitive data loaded into unapproved tools, automations without traceability, connectors with excessive permissions and decisions that are difficult to audit. In a serious enterprise environment, defensive AI must be treated like any other critical system. It can help detect anomalies, prioritise events, summarise alerts, accelerate response or assist in code review, but it needs operational control. Speed without governance can create new risks. Governance without speed leaves defenders behind attackers. ## Infrastructure, resilience and operations: the less visible side of security CCN-CERT’s guide insists on going back to basics: identity, segmentation, continuous monitoring, access control, protection of critical assets, backups and disaster recovery. These are not new recommendations, but offensive Artificial Intelligence reduces the margin for error. What could previously be reviewed quarterly or annually now requires more dynamic management. This is where infrastructure matters more than is often recognised. Security does not depend only on SOC, EDR, XDR or vulnerability scanning tools. It also depends on how the platform running critical workloads is designed: isolation between environments, private networks, route control, separation of management planes, hypervisor hardening, resilient storage, backups outside the production domain, 24/7 monitoring and tested recovery procedures. In private cloud environments, a well-designed architecture makes it possible to combine control, performance and predictability with security measures better aligned with the company’s reality. For workloads that require isolation, low latency, dedicated performance or hardware control, bare-metal remains a solid option, especially when integrated into a broader strategy of continuity, segmentation and managed operations. Operational sovereignty is also gaining relevance. Keeping infrastructure in Europe, with clear control over data location, providers, access, support and the regulatory framework, facilitates compliance and risk management decisions. This does not remove the need for good practices, but it reduces dependencies and allows architectures to be defined in a way that is better aligned with internal, regulatory and sector-specific requirements. In virtualisation platforms, prior design is decisive. Migrating from VMware, on-premise environments or public clouds to Proxmox VE, KVM, bare-metal or private cloud should not be approached only as a licensing or cost decision. Network, storage, high availability, backups, recovery, segmentation, permissions, monitoring, workload compatibility and day-to-day operations must all be assessed. Proxmox VE, with KVM, LXC, HA, backups and storage options such as Ceph, can be part of a strategy aimed at reducing dependency and gaining better control over TCO, but it requires technical planning. The same applies to incident response. BP/36 recommends adapting response times to the pace of AI-assisted threats. This means preauthorised procedures for critical scenarios, rapid isolation capability, credential revocation, malicious traffic blocking, tested restoration and clear communication between security, systems, business and providers. Resilience is not improvised during an incident; it is designed beforehand. For companies running critical services, the message is clear: security stops being a snapshot and becomes a continuous operation. It is not enough to pass an audit. Organisations need to know which assets are exposed, which vulnerabilities really matter, which agents can act, which providers have access, which backups can be restored and how long the organisation needs to contain an attack. Offensive AI accelerates a transformation that was already under way. Companies need less calendar-based security and more operational security: updated inventory, resilient architecture, frequent validation, agent governance, rapid response and providers capable of supporting day-to-day operations. The annual penetration test will still have a place, but as part of a broader system. Using it as the only security check will become increasingly hard to defend against a threat that no longer waits twelve months. ## Frequently asked questions **Is the annual penetration test no longer useful against offensive AI?****No. It is still useful for assessing controls, detecting weaknesses and meeting audit requirements. The problem arises when it is used as the only security validation. Against automated attacks, it must be complemented with continuous vulnerability management, monitoring and recurring testing. What is offensive AI in cybersecurity?****It is the use of Artificial Intelligence systems, including generative models and autonomous agents, to support or execute phases of an attack: reconnaissance, phishing, malicious code generation, vulnerability exploitation or operational decision-making. Why do AI agents introduce a new risk?****Because they can have permissions, memory, access to tools and the ability to execute actions. If they are not properly governed, they can be manipulated, leak information or perform operations outside their intended function. What should companies prioritise?**Continuous asset inventory, patching based on real exploitability, phishing-resistant authentication, segmentation, isolated and immutable backups, continuous monitoring, AI agent governance and tested response procedures. Source: CCN-CERT, BP/36, “Guía de buenas prácticas frente al modelo de IA ofensiva”, June 2026. --- ## La IA ofensiva obliga a replantear la seguridad continua en empresas URL: https://www.stackscale.com/blog/offensive-ai-forces-companies-to-rethink-continuous-security/ La nueva guía BP/36 del CCN-CERT, publicada en junio de 2026, pone nombre a una realidad que muchos equipos de seguridad ya estaban percibiendo: el modelo clásico de auditorías puntuales, pentests anuales y ciclos de parcheo planificados con semanas de margen se está quedando corto frente a atacantes que usan Inteligencia Artificial para acelerar reconocimiento, explotación, ingeniería social y toma de decisiones ofensivas. La idea central no es que la Inteligencia Artificial haya inventado todos los ataques desde cero. El cambio está en la velocidad, la escala y la automatización. Técnicas conocidas como phishing, análisis de superficie expuesta, generación de código malicioso, explotación de vulnerabilidades, abuso de credenciales o manipulación de sistemas basados en modelos de lenguaje pueden ejecutarse ahora con menos esfuerzo y en menos tiempo. Para las empresas, esto desplaza el foco desde la seguridad periódica hacia la validación continua, la resiliencia por diseño y la capacidad de respuesta operativa. ## Del pentest anual a la validación continua Durante años, muchas organizaciones han utilizado el pentest anual como una prueba razonable de seguridad. Se contrataba una evaluación, se recibía un informe, se corregían los hallazgos prioritarios y se dejaba constancia para auditoría, cumplimiento o mejora interna. Ese modelo sigue teniendo valor, pero ya no basta si se utiliza como única verificación ofensiva. El CCN-CERT habla de un “colapso del ciclo de vulnerabilidades”: la identificación y explotación pueden producirse casi al mismo tiempo. Dicho de forma práctica, una vulnerabilidad expuesta en un servicio crítico ya no puede esperar al siguiente comité de cambios, al próximo informe mensual o a la auditoría de final de año. Si un atacante puede automatizar el reconocimiento, correlacionar información pública, probar vectores en paralelo y priorizar objetivos por explotabilidad, la defensa necesita operar con otra cadencia. Esto cambia la gestión de vulnerabilidades. La prioridad no debería depender solo de la puntuación CVSS, sino también de la explotabilidad real, del catálogo KEV de vulnerabilidades conocidas explotadas, del EPSS y de la criticidad del activo afectado. Un panel lleno de vulnerabilidades “altas” no dice suficiente si no se cruza con exposición a Internet, función de negocio, accesos asociados, datos tratados y posibilidad de movimiento lateral. También cambia el papel del pentest. Deja de ser el gran examen anual y pasa a formar parte de un modelo más amplio: gestión permanente de vulnerabilidades, validación ofensiva recurrente, simulaciones de ataque, revisión continua de código y controles de detección capaces de reaccionar en minutos u horas. El objetivo no es vivir en emergencia constante, sino reducir la distancia entre lo que la empresa cree tener controlado y lo que realmente está expuesto. En infraestructuras cloud privadas, bare-metal o híbridas, este enfoque exige más disciplina de arquitectura. El inventario de activos debe estar vivo. Las redes deben segmentarse con criterio. Los accesos administrativos tienen que estar protegidos con autenticación resistente al phishing, credenciales efímeras y mínimo privilegio. Las copias de seguridad deben estar aisladas, ser inmutables cuando proceda y probarse con frecuencia realista. Sin estas bases, añadir herramientas de Inteligencia Artificial defensiva no resuelve el problema de fondo. ## Los agentes de IA también son una nueva superficie de ataque La BP/36 dedica una parte relevante a los agentes de Inteligencia Artificial, y es una de las señales más importantes para CIOs, CTOs y CISOs. Un agente que consulta datos, ejecuta acciones, llama a APIs, modifica configuraciones o interactúa con sistemas internos no es un simple asistente conversacional. Es una identidad operativa con permisos, contexto y capacidad de impacto. Ese matiz cambia por completo el gobierno de la IA en la empresa. Un agente puede ser manipulado mediante prompt injection, puede acceder a información que no debería estar en su contexto, puede exfiltrar datos a través de respuestas aparentemente legítimas o puede encadenar decisiones erróneas si tiene demasiada autonomía. Cuando además se conecta a herramientas internas, bases documentales, sistemas de ticketing, repositorios, plataformas cloud o consolas de administración, pasa a formar parte de la superficie de ataque. La respuesta no consiste en bloquear todo uso de agentes, sino en gobernarlo. Cada agente debería tener identidad propia, permisos mínimos, límites claros de actuación, trazabilidad completa, gestión segura de credenciales, validación de entradas y salidas, separación de capacidades y supervisión humana en acciones críticas. La guía también menciona la necesidad de un interruptor de apagado, o kill switch, para detener su actividad si se detecta un comportamiento anómalo. Este punto es especialmente importante para organizaciones que están integrando asistentes de IA en procesos internos sin pasar por seguridad, arquitectura o cumplimiento. El llamado shadow AI puede reproducir un problema conocido del shadow IT, pero con más capacidad de exposición: datos sensibles cargados en herramientas no aprobadas, automatizaciones sin trazabilidad, conectores con permisos excesivos y decisiones difíciles de auditar. En un entorno empresarial serio, la IA defensiva debe tratarse como cualquier sistema crítico. Puede ayudar a detectar anomalías, priorizar eventos, resumir alertas, acelerar la respuesta o asistir en la revisión de código, pero necesita control operativo. Velocidad sin gobierno puede crear nuevos riesgos. Gobierno sin velocidad deja a la defensa por detrás del atacante. ## Infraestructura, resiliencia y operación: la parte menos visible de la seguridad La guía del CCN-CERT insiste en volver a lo básico: identidad, segmentación, monitorización continua, control de accesos, protección de activos críticos, copias de seguridad y recuperación ante desastres. No son recomendaciones nuevas, pero la Inteligencia Artificial ofensiva reduce el margen de error. Lo que antes podía revisarse con periodicidad trimestral o anual ahora necesita una gestión más dinámica. Aquí la infraestructura importa más de lo que suele reconocerse. La seguridad no depende solo de herramientas SOC, EDR, XDR o escáneres de vulnerabilidades. Depende también de cómo está diseñada la plataforma donde corren las cargas críticas: aislamiento entre entornos, redes privadas, control de rutas, separación de planos de gestión, bastionado de hipervisores, almacenamiento resiliente, backups fuera del dominio de producción, monitorización 24/7 y procedimientos probados de recuperación. En entornos de cloud privado, una arquitectura bien planteada permite combinar control, rendimiento y previsibilidad con medidas de seguridad más ajustadas a la realidad de la empresa. Para cargas que requieren aislamiento, baja latencia, rendimiento dedicado o control del hardware, el bare-metal sigue siendo una opción sólida, especialmente cuando se integra dentro de una estrategia más amplia de continuidad, segmentación y operación gestionada. También gana relevancia la soberanía operativa. Mantener infraestructura en Europa, con control claro sobre ubicación de datos, proveedores, accesos, soporte y marco regulatorio, facilita decisiones de cumplimiento y gestión del riesgo. Esto no elimina la necesidad de buenas prácticas, pero reduce dependencias y permite definir arquitecturas más alineadas con requisitos internos, regulatorios y sectoriales. En plataformas de virtualización, el diseño previo es decisivo. Migrar desde VMware, entornos on-premise o nubes públicas hacia Proxmox VE, KVM, bare-metal o cloud privado no debería plantearse solo como un cambio de coste o licencias. Hay que evaluar red, almacenamiento, alta disponibilidad, backups, recuperación, segmentación, permisos, monitorización, compatibilidad de cargas y operación diaria. Proxmox VE, con KVM, LXC, HA, backups y opciones de almacenamiento como Ceph, puede formar parte de una estrategia de menor dependencia y mayor control del TCO, pero requiere planificación técnica. El mismo criterio aplica a la respuesta ante incidentes. La BP/36 recomienda adaptar los tiempos de respuesta al ritmo de amenazas asistidas por IA. Eso implica procedimientos preautorizados para escenarios críticos, capacidad de aislamiento rápido, revocación de credenciales, bloqueo de tráfico malicioso, restauración probada y comunicación clara entre seguridad, sistemas, negocio y proveedores. La resiliencia no se improvisa durante el incidente; se diseña antes. Para empresas con servicios críticos, el mensaje es claro: la seguridad deja de ser una fotografía y pasa a ser una operación continua. No basta con pasar una auditoría. Hay que saber qué activos están expuestos, qué vulnerabilidades importan de verdad, qué agentes pueden actuar, qué proveedores tienen acceso, qué copias pueden recuperarse y cuánto tiempo necesita la organización para contener un ataque. La IA ofensiva acelera una transformación que ya estaba en marcha. Las empresas necesitan menos seguridad de calendario y más seguridad operativa: inventario actualizado, arquitectura resistente, validación frecuente, gobierno de agentes, respuesta rápida y proveedores capaces de acompañar la operación diaria. El pentest anual seguirá teniendo espacio, pero como parte de un sistema más amplio. Usarlo como única comprobación será cada vez más difícil de defender ante una amenaza que ya no espera doce meses. ## Preguntas frecuentes **¿El pentest anual deja de ser útil frente a la IA ofensiva?****No. Sigue siendo útil para evaluar controles, detectar debilidades y cumplir requisitos de auditoría. El problema aparece cuando se usa como única validación de seguridad. Frente a ataques automatizados, debe complementarse con gestión continua de vulnerabilidades, monitorización y pruebas recurrentes. ¿Qué es la IA ofensiva en ciberseguridad?****Es el uso de sistemas de Inteligencia Artificial, incluidos modelos generativos y agentes autónomos, para apoyar o ejecutar fases de un ataque: reconocimiento, phishing, generación de código malicioso, explotación de vulnerabilidades o toma de decisiones operativas. ¿Por qué los agentes de IA suponen un riesgo nuevo?****Porque pueden tener permisos, memoria, acceso a herramientas y capacidad para ejecutar acciones. Si no se gobiernan bien, pueden ser manipulados, filtrar información o realizar operaciones fuera de su función prevista. ¿Qué deberían priorizar las empresas?**Inventario continuo de activos, parcheo basado en explotabilidad real, autenticación resistente al phishing, segmentación, backups aislados e inmutables, monitorización continua, gobierno de agentes de IA y procedimientos de respuesta probados. Fuente: CCN-CERT, BP/36, “Guía de buenas prácticas frente al modelo de IA ofensiva”, junio de 2026. --- ## The World’s Most Powerful Supercomputers in 2026: LineShine Takes the Lead URL: https://www.stackscale.com/blog/the-worlds-most-powerful-supercomputers-in-2026-lineshine-takes-the-lead/ The June 2026 TOP500 list marks an important shift in the recent history of supercomputing. Two years after Stackscale’s article on the world’s 500 most powerful supercomputers and Linux’s absolute dominance in this field, the debate is no longer only about the operating system. The new picture of the sector points to exascale computing, technological sovereignty, energy efficiency, heterogeneous architectures and a competition increasingly linked to Artificial Intelligence. The main headline from the 67th edition of the TOP500 is the direct entry of LineShine into first place. The system, installed at the National Supercomputing Centre in Shenzhen, China, displaces El Capitan and becomes the world’s most powerful supercomputer according to the High Performance Linpack (HPL) benchmark. Its sustained performance reaches 2.198 Exaflop/s, above El Capitan’s 1.809 Exaflop/s, which moves down to second place. ## LineShine and China’s Return to Number One LineShine does more than return China to the top of the TOP500 for the first time since Sunway TaihuLight in 2017. It also introduces a technically interesting nuance: it exceeds two sustained exaflops on HPL with a CPU-based architecture, without relying on GPU accelerators like those that dominate much of today’s Artificial Intelligence infrastructure debate. The system uses the LingKun platform, 304-core LX2 processors running at 1.55 GHz, the proprietary LingQi interconnect and Kylin OS. In total, it includes 13,789,440 cores and draws approximately 42.2 MW of power. The figure is huge, but it helps explain the kind of scale involved: modern supercomputing is no longer measured only by the number of processors, but by the relationship between compute, power consumption, networking, cooling, system software and the real ability to run scientific workloads in a sustained way. There is another important detail. LineShine also ranks first on the HPCG benchmark, with 22.00 HPCG-Petaflop/s. HPCG does not replace HPL, but it provides a view that is closer to real-world application patterns, with greater emphasis on memory access, communications and system behaviour under less ideal workloads than a pure LINPACK test. This result does not automatically mean that LineShine is the most advanced system for every Artificial Intelligence workload. In HPL-MxP, a benchmark focused on mixed-precision performance, El Capitan remains the leader with 16.7 Exaflop/s, followed by Aurora and Frontier. LineShine ranks fourth, with 7.92 Exaflop/s. That difference matters because many modern training and inference workloads benefit from accelerators designed for mixed precision and massive matrix operations. The TOP500 remains an essential reference, but it needs to be read carefully: it measures high-performance scientific computing capacity, not every possible kind of performance in Artificial Intelligence, cloud or private hyperscale platforms, many of which are not submitted to this ranking. ## Five Exascale Systems and a More Diverse Top 10 The June 2026 edition raises the number of systems capable of exceeding one sustained exaflop on HPL to five. That threshold, which for years was a laboratory objective, is now starting to consolidate as a real category of scientific infrastructure. RankSupercomputerCountryHPL Performance1LineShineChina2.198 Exaflop/s2El CapitanUnited States1.809 Exaflop/s3FrontierUnited States1.353 Exaflop/s4AuroraUnited States1.012 Exaflop/s5JUPITER BoosterGermany1.000 Exaflop/s6HPC7Italy571.5 Petaflop/s7EagleUnited States561.2 Petaflop/s8HPC6Italy477.9 Petaflop/s9FugakuJapan442.01 Petaflop/s10AlpsSwitzerland434.9 Petaflop/s The table shows more than a race for first place. The United States retains three exascale systems among the top four, Germany keeps Europe’s first system above the exaflop threshold with JUPITER Booster, Italy strengthens its position with HPC7 and HPC6, Japan keeps Fugaku in the Top 10 and Switzerland enters with Alps. The diversity of architectures is also notable. LineShine relies on Chinese silicon and a CPU-only design. El Capitan and Frontier combine AMD EPYC processors with AMD Instinct accelerators. Aurora represents the Intel path with Xeon CPU Max and Data Center GPU Max. JUPITER Booster and Alps are based on NVIDIA Grace Hopper. Eagle, deployed on Microsoft Azure, combines Intel Xeon with NVIDIA H100. Fugaku remains a distinctive case with Fujitsu A64FX processors based on Arm. The business reading is clear: there is no single winning architecture for every workload. Infrastructure is designed according to the type of computing, latency, networking, power consumption, cooling, available software, technological sovereignty and operating cost. That same logic, at a different scale, applies to the design of private cloud, bare-metal platforms and enterprise virtualisation environments. An organisation running critical databases, virtual desktops, analytics platforms, private Artificial Intelligence models or latency-sensitive applications should not choose infrastructure based only on the number of vCPUs or raw capacity. Prior architecture matters: CPU, memory, storage, networking, isolation, licensing, backups, high availability, observability and day-to-day operations. ## Linux, Energy Efficiency and Infrastructure Sovereignty Stackscale’s 2024 article focused on a fact that remains central: Linux dominates supercomputing. The new list does not change that conclusion. LineShine uses Kylin OS; JUPITER Booster appears with Red Hat Enterprise Linux; HPC7 and HPC6 use RHEL; other Top 10 systems run HPE Cray OS, TOSS or environments derived and adapted for large HPC installations. The exact form varies, but the pattern is the same: open, modifiable systems prepared to be tuned to the hardware. Linux fits supercomputing for reasons very similar to those that explain its importance in cloud, bare-metal and enterprise infrastructure: it allows teams to control the system, remove unnecessary components, tune the kernel, integrate specific drivers, automate deployments, work with high-performance networks and operate highly specialised environments without depending on a black box. It is not only a licensing cost issue; it is technical control. Energy efficiency adds another layer to the debate. The TOP500 measures power, but the Green500 ranks systems by performance per watt. In June 2026, KAIROS, installed at CALMIP / University of Toulouse-CNRS, retains first place with 73.28 Gigaflops/Watt. It is followed by ROMEO-2025, also in France, and the Levante GPU extension in Germany. All three share a BullSequana XH3000 architecture with NVIDIA Grace Hopper and NVIDIA InfiniBand NDR200 interconnect. Efficiency is not a secondary issue. As systems grow, the limit is no longer only the purchase of hardware. It also appears in available energy, cooling, data centre space, electrical design, heat reuse, rack density and the ability to keep the system running in a stable way. In enterprise data centres, something similar happens, although at another scale: poor architecture can end up generating more cost, more power consumption and more operational complexity than the problem it was supposed to solve. Spain maintains a relevant presence with MareNostrum 5 ACC, the accelerated partition of the Barcelona Supercomputing Center’s supercomputer, ranked 16th in the June 2026 TOP500 with 175.30 Petaflop/s of HPL performance. Although it has left the Top 10 it occupied in previous lists, it remains one of Europe’s most important scientific infrastructures and a key asset for research, simulation, biomedicine, climate, engineering and Artificial Intelligence. Public and scientific supercomputing is not the same as the private cloud infrastructure a company uses for its critical applications, but both share several lessons. The first is that real performance depends on the complete system, not on an isolated component. The second is that technological sovereignty is built through architectural, operational and location decisions. The third is that efficiency starts before buying hardware: it starts with design. In enterprise environments, this means assessing when it makes sense to use public cloud, when a private cloud platform is preferable, when a workload needs dedicated bare-metal and when an open alternative such as Proxmox VE can help reduce licensing dependency, improve TCO control and avoid vendor lock-in. Not every workload needs the same infrastructure, but critical workloads do require an architecture designed before migration. Stackscale works precisely in that middle ground between traditional enterprise infrastructure and modern requirements for performance, control and sovereignty. Private cloud, bare-metal, private networks, storage, backups, high availability and managed operations are part of a conversation that is no longer only technical. For CIOs, CTOs and financial decision-makers, the question is how to sustain critical workloads with predictable costs, operational control and data hosted in Europe. The new TOP500 2026 list should not be read only as a ranking of giant machines. It is a signal of where infrastructure is heading: more specialisation, more importance for networking, more energy pressure, more debate around sovereignty, more Linux and a greater need to choose the right architecture. Exascale remains far from most companies, but its principles already influence much closer decisions: where to host data, how to isolate critical workloads, which platform to use, how to protect backups, how to scale without losing control and how to prevent infrastructure costs from becoming unpredictable. ### Frequently Asked Questions **What is the world’s most powerful supercomputer in 2026?****According to the June 2026 TOP500 list, the world’s most powerful supercomputer is LineShine, installed at the National Supercomputing Centre in Shenzhen, China, with 2.198 Exaflop/s on the HPL benchmark. What does it mean for a supercomputer to be exascale?****An exascale system is capable of exceeding one exaflop of performance, meaning at least one quintillion floating-point operations per second. In June 2026, five systems surpassed that threshold on HPL. Why does Linux dominate supercomputing?****Linux makes it possible to adapt the operating system to the hardware, remove unnecessary components, tune performance, integrate high-performance networks and work with very specific architectures. That is why it remains the usual foundation for major HPC systems. What does supercomputing have to do with enterprise private cloud?**Although the scale is different, they share core principles: architectural design, dedicated performance, efficiency, data control, low-latency networks, reliable storage and secure operations. For many companies, these ideas translate into private cloud, bare-metal and open virtualisation platforms. Source: TOP500, June 2026 TOP500 List and Highlights --- ## Los superordenadores más potentes del mundo en 2026: LineShine lidera URL: https://www.stackscale.com/blog/the-worlds-most-powerful-supercomputers-in-2026-lineshine-takes-the-lead/ La **lista TOP500 de junio de 2026** marca un cambio relevante en la historia reciente de la supercomputación. Dos años después del artículo de Stackscale sobre los 500 superordenadores más potentes del mundo y el dominio absoluto de Linux, el debate ya no gira solo en torno al sistema operativo. La nueva fotografía del sector habla de exaescala, soberanía tecnológica, eficiencia energética, arquitecturas heterogéneas y una competencia cada vez más ligada a la Inteligencia Artificial. El gran titular de la edición número 67 del TOP500 es la entrada directa de LineShine en el primer puesto. El sistema, instalado en el National Supercomputing Centre in Shenzhen, en China, desplaza a El Capitan y se convierte en el superordenador más potente del mundo según el benchmark High Performance Linpack (HPL). Su rendimiento sostenido alcanza 2,198 Exaflop/s, por encima de los 1,809 Exaflop/s de El Capitan, que pasa al segundo lugar. ## LineShine y el regreso de China al número 1 LineShine no solo recupera para China el liderazgo del TOP500 por primera vez desde Sunway TaihuLight en 2017. También introduce un matiz técnico muy interesante: alcanza más de dos exaflops sostenidos en HPL con una arquitectura basada en CPU, sin depender de aceleradores GPU como los que dominan gran parte del discurso actual sobre Inteligencia Artificial. El sistema utiliza la plataforma LingKun, procesadores LX2 de 304 núcleos a 1,55 GHz, la interconexión propietaria LingQi y Kylin OS. En total, suma 13.789.440 núcleos y un consumo aproximado de 42,2 MW. La cifra es enorme, pero ayuda a entender el tipo de escala del que hablamos: la supercomputación moderna ya no se mide solo por número de procesadores, sino por la relación entre cómputo, consumo, red, refrigeración, software de sistema y capacidad real para ejecutar cargas científicas de forma sostenida. Hay otro detalle importante. LineShine también se sitúa en el primer puesto del benchmark HPCG, con 22,00 HPCG-Petaflop/s. HPCG no sustituye a HPL, pero ofrece una visión más cercana a patrones de aplicaciones reales, con mayor peso de acceso a memoria, comunicaciones y comportamiento del sistema ante cargas menos ideales que una prueba LINPACK pura. El resultado no significa que LineShine sea automáticamente el sistema más avanzado para todas las cargas de Inteligencia Artificial. En HPL-MxP, benchmark orientado a cálculos de precisión mixta, El Capitan conserva el liderazgo con 16,7 Exaflop/s, seguido de Aurora y Frontier. LineShine queda cuarto, con 7,92 Exaflop/s. Esta diferencia es relevante porque muchas cargas modernas de entrenamiento e inferencia se benefician de aceleradores diseñados para precisión mixta y operaciones matriciales masivas. El TOP500 sigue siendo una referencia esencial, pero conviene leerlo con cuidado: mide capacidad de computación científica de alto rendimiento, no todo el rendimiento posible en Inteligencia Artificial, cloud o plataformas privadas de hiperescalares que, en muchos casos, no se presentan a este ranking. ## Cinco sistemas exaescala y un TOP10 más diverso La edición de junio de 2026 eleva a cinco el número de sistemas capaces de superar un exaflop sostenido en HPL. Esa frontera, que durante años fue un objetivo de laboratorio, ya empieza a consolidarse como una categoría real de infraestructura científica. PosiciónSuperordenadorPaísRendimiento HPL1LineShineChina2,198 Exaflop/s2El CapitanEstados Unidos1,809 Exaflop/s3FrontierEstados Unidos1,353 Exaflop/s4AuroraEstados Unidos1,012 Exaflop/s5JUPITER BoosterAlemania1,000 Exaflop/s6HPC7Italia571,5 Petaflop/s7EagleEstados Unidos561,2 Petaflop/s8HPC6Italia477,9 Petaflop/s9FugakuJapón442,01 Petaflop/s10AlpsSuiza434,9 Petaflop/s La tabla muestra algo más que una carrera por el primer puesto. Estados Unidos mantiene tres sistemas exaescala entre los cuatro primeros, Alemania conserva el primer sistema europeo por encima del exaflop con JUPITER Booster, Italia refuerza su posición con HPC7 y HPC6, Japón mantiene a Fugaku en el TOP10 y Suiza entra con Alps. También destaca la diversidad de arquitecturas. LineShine apuesta por silicio chino y diseño CPU-only. El Capitan y Frontier combinan procesadores AMD EPYC con aceleradores AMD Instinct. Aurora representa la vía Intel con Xeon CPU Max y Data Center GPU Max. JUPITER Booster y Alps se apoyan en NVIDIA Grace Hopper. Eagle, desplegado en Microsoft Azure, combina Intel Xeon con NVIDIA H100. Fugaku sigue siendo un caso singular con procesadores Fujitsu A64FX basados en Arm. La lectura empresarial es clara: no hay una única arquitectura ganadora para todas las cargas. La infraestructura se diseña en función del tipo de cálculo, la latencia, la red, el consumo, la refrigeración, el software disponible, la soberanía tecnológica y el coste operativo. Esa misma lógica, salvando las distancias de escala, se traslada al diseño de cloud privado, plataformas bare-metal y entornos de virtualización empresarial. Una organización que ejecuta bases de datos críticas, escritorios virtuales, plataformas de analítica, modelos de Inteligencia Artificial privados o aplicaciones con latencia sensible no debería elegir infraestructura solo por número de vCPU o capacidad bruta. La arquitectura previa importa: CPU, memoria, almacenamiento, red, aislamiento, licencias, backups, alta disponibilidad, observabilidad y operación diaria. ## Linux, eficiencia energética y soberanía de infraestructura El artículo de Stackscale de 2024 ponía el foco en un hecho que sigue siendo central: Linux domina la supercomputación. La nueva lista no cambia esa conclusión. LineShine utiliza Kylin OS; JUPITER Booster aparece con Red Hat Enterprise Linux; HPC7 y HPC6 usan RHEL; otros sistemas del TOP10 trabajan con HPE Cray OS, TOSS o entornos derivados y adaptados a grandes instalaciones HPC. La forma exacta varía, pero el patrón es el mismo: sistemas abiertos, modificables y preparados para ser ajustados al hardware. Linux encaja en supercomputación por razones muy parecidas a las que explican su peso en el cloud, el bare-metal y la infraestructura empresarial: permite controlar el sistema, eliminar componentes innecesarios, ajustar el kernel, integrar drivers específicos, automatizar despliegues, trabajar con redes de alto rendimiento y operar entornos muy especializados sin depender de una caja negra. No es solo una cuestión de coste de licencia; es control técnico. La eficiencia energética añade otra capa al debate. El TOP500 mide potencia, pero el Green500 ordena los sistemas por rendimiento por vatio. En junio de 2026, KAIROS, instalado en CALMIP / University of Toulouse-CNRS, conserva el primer puesto con 73,28 Gigaflops/Watt. Le siguen ROMEO-2025, también en Francia, y la extensión GPU de Levante, en Alemania. Los tres comparten una arquitectura BullSequana XH3000 con NVIDIA Grace Hopper e interconexión NVIDIA InfiniBand NDR200. La eficiencia no es un asunto secundario. A medida que los sistemas crecen, la limitación deja de estar solo en la compra del hardware. También aparece en la energía disponible, la refrigeración, el espacio en centro de datos, el diseño eléctrico, la reutilización de calor, la densidad por rack y la capacidad de mantener el sistema operando de forma estable. En centros de datos empresariales ocurre algo similar, aunque a otra escala: una mala arquitectura puede acabar generando más coste, más consumo y más complejidad operativa que el problema que pretendía resolver. España mantiene presencia relevante con MareNostrum 5 ACC, la partición acelerada del superordenador del Barcelona Supercomputing Center, situada en el puesto 16 del TOP500 de junio de 2026 con 175,30 Petaflop/s de rendimiento HPL. Aunque ha salido del TOP10 que ocupó en listados anteriores, sigue siendo una de las infraestructuras científicas más importantes de Europa y una pieza clave para investigación, simulación, biomedicina, clima, ingeniería e Inteligencia Artificial. La supercomputación pública y científica no es lo mismo que la infraestructura cloud privada que utiliza una empresa para sus aplicaciones críticas, pero ambas comparten varias lecciones. La primera es que el rendimiento real depende del sistema completo, no de un componente aislado. La segunda es que la soberanía tecnológica se construye con decisiones de arquitectura, operación y ubicación. La tercera es que la eficiencia empieza antes de comprar hardware: empieza en el diseño. En entornos empresariales, esto se traduce en evaluar cuándo conviene usar cloud público, cuándo es preferible una plataforma de cloud privado, cuándo una carga necesita bare-metal dedicado y cuándo una alternativa abierta como Proxmox VE puede ayudar a reducir dependencia de licencias, mejorar el control del TCO y evitar bloqueos de proveedor. No todas las cargas necesitan la misma infraestructura, pero las cargas críticas sí necesitan una arquitectura pensada antes de migrar. Stackscale trabaja precisamente en ese terreno intermedio entre la infraestructura empresarial tradicional y las necesidades modernas de rendimiento, control y soberanía. Cloud privado, bare-metal, redes privadas, almacenamiento, backups, alta disponibilidad y operación gestionada forman parte de una conversación que ya no es solo técnica. Para CIOs, CTOs y responsables financieros, la pregunta es cómo sostener cargas críticas con costes previsibles, control operativo y datos alojados en Europa. La nueva lista TOP500 2026 no debe leerse solo como una clasificación de máquinas gigantes. Es una señal de hacia dónde se mueve la infraestructura: más especialización, más peso de la red, más presión energética, más debate sobre soberanía, más Linux y más necesidad de elegir bien la arquitectura. La exaescala queda lejos de la mayoría de empresas, pero sus principios ya influyen en decisiones mucho más cercanas: dónde alojar los datos, cómo aislar cargas críticas, qué plataforma usar, cómo proteger los backups, cómo escalar sin perder control y cómo evitar que el coste de la infraestructura se vuelva imprevisible. ### Preguntas frecuentes **¿Cuál es el superordenador más potente del mundo en 2026?****Según el TOP500 de junio de 2026, el superordenador más potente del mundo es LineShine, instalado en el National Supercomputing Centre in Shenzhen, en China, con 2,198 Exaflop/s en el benchmark HPL. ¿Qué significa que un superordenador sea exaescala?****Un sistema exaescala es capaz de superar un exaflop de rendimiento, es decir, al menos un trillón europeo de operaciones de coma flotante por segundo. En junio de 2026, cinco sistemas superan esa barrera en HPL. ¿Por qué Linux domina la supercomputación?****Linux permite adaptar el sistema operativo al hardware, reducir componentes innecesarios, ajustar rendimiento, integrar redes de alto rendimiento y trabajar con arquitecturas muy específicas. Por eso sigue siendo la base habitual de los grandes sistemas HPC. ¿Qué relación tiene la supercomputación con el cloud privado empresarial?**Aunque la escala es distinta, comparten principios: diseño de arquitectura, rendimiento dedicado, eficiencia, control del dato, redes de baja latencia, almacenamiento fiable y operación segura. Para muchas empresas, estas ideas se trasladan a plataformas de cloud privado, bare-metal y virtualización abierta. Fuente: TOP500, June 2026 TOP500 List and Highlights --- ## Proxmox in production: how to design a solid private cloud URL: https://www.stackscale.com/blog/proxmox-in-production-how-to-design-a-solid-private-cloud/ Proxmox VE has become one of the most serious alternatives for companies that want to regain control over their virtualization infrastructure. Its open source foundation, integration with KVM and LXC, clustering capabilities, high availability, Ceph, ZFS, and Proxmox Backup Server have placed it firmly on the radar of CIOs, CTOs, and systems teams looking for a powerful platform without being tied to closed licensing models. But Proxmox should not be understood only as a way to reduce costs compared to VMware. That reading falls short. In production, Proxmox is a critical infrastructure platform and requires the same discipline as any enterprise environment: well-designed networking, proper storage, quorum, high availability, backup, monitoring, failure testing, and day-to-day operations. At Stackscale, we are seeing this more and more in private cloud projects. Many companies do not simply want to “move to Proxmox”. They want to build a stable, controlled platform that is ready to grow. To do that, installing Proxmox on several servers is not enough. The architecture underneath must be properly designed. ## Proxmox does not start with the hypervisor, it starts with the architecture One of the most common mistakes when approaching Proxmox is starting with the management interface or the creation of virtual machines. It is understandable: Proxmox VE offers a very straightforward user experience and makes it easy to deploy VMs and containers quickly. But in a real environment, stability does not depend only on the hypervisor. It depends on how the nodes have been designed, how networks are separated, what storage is used, how quorum is handled, what happens if a node fails, where backups are stored, and how much room there is to grow without redesigning the entire environment. Design layerQuestion to solve before productionComputeHow many nodes are needed and what headroom remains in case of failure?NetworkAre management, migration, storage, backup, and customer traffic separated?StorageWill you use local storage, Ceph, NFS/iSCSI, network storage, or synchronous storage?High availabilityWhich VMs should be automatically restarted, and where?QuorumCan the cluster make safe decisions during failures?BackupWhere are the backups, how are they verified, and how long does recovery take?OperationsAre monitoring, alerts, documentation, and maintenance procedures in place? This difference is what separates a functional lab from an enterprise platform. In a lab, it is enough for VMs to boot. In production, you need to ask what happens when a host fails at 3 a.m., when storage approaches its limit, when a migration overlaps with a traffic peak, or when a restore becomes the only recovery path. ## Dedicated nodes: the foundation of a private cloud with Proxmox In a Proxmox-based private cloud, compute nodes are a central component. They are not just servers where virtual machines “fit”. They are the foundation on which CPU, memory, connectivity, availability, and maintenance are distributed. Stackscale designs these environments on dedicated nodes, allowing each customer to have exclusive compute resources, without noisy neighbours or direct competition for CPU and RAM with third parties. This separation is important when the infrastructure supports ERP systems, databases, ecommerce platforms, virtual desktops, SaaS platforms, internal systems, or customer-facing applications. The value of Proxmox on dedicated nodes is not only performance. It is also predictability. The technical team knows what hardware is available, what real capacity exists, how much can be overcommitted, what headroom remains in case of failure, and when new nodes should be added. Node decisionOperational impactMinimum number of nodesDetermines HA, quorum, and fault toleranceCPU and memory per nodeConditions VM density and overcommitRedundancyEnables maintenance without bringing down the whole environmentHardware homogeneitySimplifies migrations, balancing, and operationsAvailable headroomPrevents a failure from leaving the cluster without enough capacitySpare node poolReduces recovery times after physical failure A three-node cluster may be enough for many initial environments, but not all three-node clusters are the same. If all three are running at 90 % capacity, high availability will be mostly theoretical: if one node fails, the other two will not have enough real capacity to absorb the workload. That is why sizing must take failure into account, not just normal daily operation. The question should not be “how many VMs fit”. The right question is: “how many VMs can continue running if I lose one node and need to maintain service”. ## The network determines much of the cluster’s behaviour Proxmox can move virtual machines between nodes, manage high availability, and work with different types of storage. But all these capabilities depend on the network. If the network is poorly designed, the cluster will eventually show it through latency, slow migrations, backups affecting production, or communication problems between nodes. In a professional environment, several types of traffic should be separated, at least logically: management, Corosync, migration, storage, backup, and customer traffic. In more demanding projects, that separation should also be physical or based on dedicated networks with guaranteed bandwidth. Type of trafficRisk if mixed without controlManagementUnnecessary exposure and harder operations during incidentsCorosync / clusterLoss of stability if there is latency or packet lossMigrationVM degradation if it competes with production trafficStorageHigh latency in virtual disks and databasesBackupImpact during critical hours if not limited or scheduledCustomerContention with internal cluster traffic Corosync deserves special mention. It is the basis for cluster communication and quorum. It should not casually coexist with heavy traffic or depend on unstable links. A saturated network may not bring down VMs immediately, but it can make cluster management less reliable exactly when fast decisions are needed. Live migration also depends on this layer. In Proxmox it works very well when the design supports it, but a large VM with a lot of memory and high write activity can take longer than expected if the migration network does not have enough capacity. The conclusion is simple: the network is not designed at the end. It is designed before creating the first production VM. ## Network storage: far more than capacity Storage is often the part that most determines the behaviour of a Proxmox environment. It is also one of the most underestimated. In production, looking only at available terabytes is not enough. You need to look at latency, IOPS, bandwidth, redundancy, snapshots, replication, recovery, growth, and maintenance. Proxmox can work with many options: local storage, ZFS, Ceph, NFS, iSCSI, Fibre Channel, external arrays, or network storage. Each option makes sense in specific scenarios, but none is universal. Storage optionMain advantagePrecautionLocal SSD/NVMeVery good local performanceLess flexibility for HA without replicationLocal ZFSSnapshots, integrity, and advanced managementRequires RAM, planning, and avoiding full poolsCephIntegrated distributed storageRequires properly sized nodes, disks, and networkNFS/iSCSISimple integration with shared storageDepends on array/network and availability designDedicated network storageSeparates compute and dataRequires low latency and real redundancySynchronous storageVery low RPO and advanced continuityHigher architectural and cost requirements At Stackscale, Proxmox can be supported by network storage and synchronous storage designed to decouple compute and data. This separation makes it possible to scale compute nodes and storage more independently, simplifies certain recovery scenarios, and reduces dependence on each host’s local disks. This does not mean Ceph or ZFS are not good options. They are, when they fit. Ceph can be very powerful in environments with enough nodes, a fast network, and specialized operations. ZFS is an excellent technology for integrity, snapshots, and local performance. But in enterprise environments where the goal is a manageable and predictable private cloud platform, network storage can provide a solid foundation for operations, growth, and continuity. The important point is not to make storage an improvised decision. Many virtualization incidents start as storage problems: pools that are too full, growing latency, forgotten snapshots, backups saturating links, arrays without enough headroom, or disks that do not behave as expected under load. ## HA in Proxmox: what it does and what it does not do Proxmox VE high availability allows virtual machines or containers to be automatically restarted on another node when the original node fails. It is a very valuable feature and one of the reasons Proxmox can be used in enterprise environments. But its limits must be clearly understood. HA does not mean that a VM will never be interrupted. If a node fails, the VM must start on another node. That implies recovery time. For many workloads, this is acceptable. For others, it is not. A critical database, a transactional application, or a system with connected users may also need application-level replication, load balancers, internal clusters, or its own fault-tolerance mechanisms. ConceptWhat it protectsWhat it does not replaceProxmox HANode failure and automatic VM restartApplication-level high availabilityLive migrationPlanned movement of VMs between nodesRecovery from sudden host failureBackupRecovery of data and systemsImmediate continuityApplication replicationService continuity at software levelHistorical backupDRRecovery from site failure or disasterNormal operation of the local cluster The confusion between HA, backup, and disaster recovery is common. HA helps restore service after a node failure. Backup allows data or systems to be recovered at an earlier point in time. DR enables response to a larger failure, such as the loss of a data centre, a serious platform issue, or a security incident. They are different layers and should coexist. ## Quorum: the small detail that decides the cluster In Proxmox, as in other cluster systems, quorum is what allows decisions to be made while avoiding dangerous situations such as split-brain. If the cluster does not have quorum, it may block certain operations to protect consistency. That is why two-node clusters must be handled with particular care. They can make sense in specific scenarios, but they usually require a qdevice or a very carefully tested design. In production environments, the most common and recommended approach is to start with at least three nodes to provide more reliable quorum. Cluster designPractical reading1 nodeNo real high availability2 nodes without qdeviceHigh risk of losing quorum2 nodes with qdeviceCan work in controlled scenarios3 nodesCommon baseline for reliable HA4+ nodesBetter growth and maintenance capacity Quorum should not be discovered during an incident. It must be tested beforehand. Simulating node failure, network loss, controlled reboots, and maintenance helps understand how the cluster behaves and avoids surprises in production. ## Snapshots, backups, and Proxmox Backup Server Snapshots are useful, but they are not backups. This sentence is repeated often because it remains one of the most common mistakes in virtualization. A snapshot is useful to preserve the state of a VM during a short window: an update, a configuration change, a controlled test, or a deployment. If kept for too long, it can grow, consume storage, and affect performance. Backup must be designed differently. In Proxmox environments, Proxmox Backup Server provides incremental backups, deduplication, verification, encryption, and natural integration with Proxmox VE. At Stackscale, Proxmox Backup Server can be combined with Archive storage via NFS or S3-compatible access, as well as faster network storage layers when reducing restore times is required. ElementCorrect useSnapshotTemporary change and short maintenance windowLocal backupFast recovery, but not enough as the only copyProxmox Backup ServerIncremental, deduplicated, and verifiable backupsArchive storageRetention and separate long-term copyCopy in another data centreProtection against major site failureRestore testingReal validation that the backup works A professional backup policy must answer specific questions: how often backups are taken, how long they are retained, where the copy is stored, who can delete it, how it is verified, how long a restore takes, and which systems are recovered first. A backup that has never been restored is not a guarantee. It is a hypothesis. ## Sizing and overcommit: efficiency without putting the cluster at risk Proxmox allows CPU and memory to be used efficiently, but overcommit is not unlimited. Assigning too many vCPUs or too much RAM without measuring real usage eventually creates contention. The problem does not always appear at the beginning. It appears when several VMs consume resources at the same time, when backups run, when a database grows, or when a node fails and the rest of the cluster must absorb its workload. ResourceRisk of poor sizingGood practicevCPUContention and CPU latencyMeasure real usage and avoid excessive allocationRAMSwapping or lack of headroom during failureReserve capacity for peaks and HADiskLatency and I/O waitMeasure IOPS, not only capacityNetworkBottlenecks in migration, backup, and storageSeparate traffic and size links properlyBackupImpact on productionWindows, limits, and monitoringHALack of capacity when a node failsDesign with N+1 headroom or equivalent In private cloud, sizing must be reviewed continuously. Workloads change. A VM that consumes little today may become critical tomorrow. An environment that started with ten VMs may grow to one hundred. The advantage of a well-designed infrastructure is that it allows nodes to be added, storage to be expanded, and resources to be adjusted without rebuilding the whole platform. ## Monitoring and operations: the difference between installing and managing A well-designed Proxmox platform needs operations. Monitoring of nodes, storage, network, backups, latency, capacity, SMART errors, CPU usage, memory, I/O wait, HA state, and scheduled tasks. It also needs useful alerts, not noise. If everything alerts, nothing alerts. Operations also include procedures: how a node is updated, how VMs are evacuated before maintenance, how HA is tested, how backups are reviewed, how changes are documented, how access is managed, and how teams respond to storage degradation. Proxmox has an important advantage: it is transparent. It allows many layers of the system to be inspected, works with familiar Linux tools, and can be automated through API and CLI. But that transparency requires knowledge. It does not remove the need for administration. It makes it more visible. ## Proxmox as the foundation of private cloud at Stackscale For many companies, the value of Proxmox is not only licence savings. It is the possibility of building an open, flexible, and controlled private cloud. At Stackscale, this architecture can be based on dedicated nodes, private networks, network storage, synchronous storage, backup, monitoring, support, and multi-data-centre options. This approach helps separate responsibilities. Stackscale provides the physical foundation, connectivity, data centre environment, hardware, network, storage, and infrastructure support. The customer can focus on systems, applications, security, data, and platform evolution. Business needProxmox on Stackscale approachInfrastructure controlDedicated nodes and exclusive-use environmentLower proprietary dependencyOpen source Proxmox VE platformContinuityHA, network storage, backup, and multi-DC optionsGrowthExpansion of nodes and storage on demandMigration from VMwareTarget environment design, pilot, and phased transitionRecoveryProxmox Backup Server, Archive, and restore testingOperationsMonitoring, support, and technical procedures The idea is not to present Proxmox as a magic solution. It is not. Proxmox works very well when it is designed with discipline. It can also create problems if deployed as a quick installation without proper architecture. The same is true of any virtualization platform in production. The difference lies in acknowledging it from the start: Proxmox is not cheap virtualization. It is critical infrastructure when it supports critical workloads. ## Technical summary for administrators AreaQuick recommendationClusterDesign with at least three nodes when reliable HA is requiredQuorumTest node loss and cluster behaviour before productionNetworkSeparate management, migration, storage, backup, and customer trafficStorageChoose according to workload: network, Ceph, ZFS, synchronous, or a combinationHAUse it for automatic restart, not as a replacement for application HABackupUse PBS, retention, verification, and tested restoresCapacityAlert before the limit, not when the pool is already fullSizingMeasure real consumption and reserve headroom for failureOperationsDocument changes, update in phases, and monitor everything ## Frequently asked questions **Is Proxmox a real alternative to VMware for private cloud?****Yes, as long as it is designed as a production platform. Proxmox VE can be a solid foundation for private cloud when combined with clustering, proper storage, segmented networking, high availability, backup, and professional operations. Is shared storage required to use Proxmox HA?****For many HA scenarios, VMs must be able to start on other nodes with access to their disks, either through shared storage, distributed storage, or properly designed replication. The exact architecture depends on the use case. Is Ceph mandatory in Proxmox?****No. Ceph is a powerful option, especially for distributed storage, but it is not mandatory. Proxmox can also work with local storage, ZFS, NFS, iSCSI, Fibre Channel, network storage, or external arrays. Do Proxmox snapshots work as backups?****No. Snapshots are useful for short maintenance windows, but they do not replace a backup strategy. For real backups, it is advisable to use Proxmox Backup Server or another backup solution, with retention, verification, and restore testing. What does Stackscale bring to a Proxmox project?**Stackscale provides private cloud infrastructure with dedicated nodes, connectivity, network storage, synchronous storage options, backup, monitoring, and specialized support to design and operate production Proxmox environments. --- ## Proxmox en producción: cómo diseñar un cloud privado sólido URL: https://www.stackscale.com/blog/proxmox-in-production-how-to-design-a-solid-private-cloud/ Proxmox VE se ha convertido en una de las alternativas más serias para empresas que quieren recuperar control sobre su infraestructura de virtualización. Su base open source, su integración con KVM y LXC, su capacidad de clustering, la alta disponibilidad, Ceph, ZFS y Proxmox Backup Server lo han situado en el radar de CIOs, CTOs y equipos de sistemas que buscan una plataforma potente sin depender de modelos de licenciamiento cerrados. Pero Proxmox no debe entenderse solo como una forma de reducir costes frente a VMware. Esa lectura se queda corta. En producción, Proxmox es una plataforma de infraestructura crítica y exige el mismo rigor que cualquier entorno empresarial: red bien diseñada, almacenamiento adecuado, quorum, alta disponibilidad, backup, monitorización, pruebas de fallo y operación diaria. En Stackscale lo vemos cada vez más en proyectos de cloud privado. Muchas empresas no quieren simplemente “migrar a Proxmox”. Quieren construir una plataforma estable, controlada y preparada para crecer. Para eso no basta con instalar Proxmox en varios servidores. Hay que diseñar la arquitectura que hay debajo. ## Proxmox no empieza en el hipervisor, empieza en la arquitectura Uno de los errores más habituales al plantear Proxmox es empezar por la interfaz de administración o por la creación de máquinas virtuales. Es comprensible: Proxmox VE tiene una experiencia de uso muy directa y permite levantar VMs y contenedores con rapidez. Pero en un entorno real, la estabilidad no depende solo del hipervisor. Depende de cómo se han diseñado los nodos, de cómo se separan las redes, de qué almacenamiento se utiliza, de cómo se resuelve el quorum, de qué ocurre si un nodo cae, de dónde están las copias de seguridad y de cuánto margen existe para crecer sin rediseñar todo el entorno. Capa de diseñoPregunta que debe resolverse antes de producciónComputación¿Cuántos nodos hacen falta y qué margen queda ante fallo?Red¿Están separados gestión, migración, almacenamiento, backup y tráfico de cliente?Almacenamiento¿Se usará almacenamiento local, Ceph, NFS/iSCSI, almacenamiento en red o síncrono?Alta disponibilidad¿Qué VMs deben reiniciarse automáticamente y dónde?Quorum¿El clúster puede tomar decisiones seguras ante fallos?Backup¿Dónde están las copias, cómo se verifican y cuánto tarda una restauración?Operación¿Hay monitorización, alertas, documentación y procedimientos de mantenimiento? Esta diferencia es la que separa un laboratorio funcional de una infraestructura empresarial. En un laboratorio basta con que las VMs arranquen. En producción hay que preguntarse qué ocurre cuando un host falla a las tres de la mañana, cuando el almacenamiento se acerca al límite, cuando una migración coincide con un pico de carga o cuando una restauración se convierte en la única vía de recuperación. ## Nodos dedicados: la base del cloud privado con Proxmox En un cloud privado basado en Proxmox, los nodos de computación son una pieza central. No son simples servidores donde “caben” máquinas virtuales. Son la base sobre la que se distribuyen CPU, memoria, conectividad, disponibilidad y mantenimiento. Stackscale plantea este tipo de entornos sobre nodos dedicados, lo que permite a cada cliente disponer de recursos de computación exclusivos, sin vecinos ruidosos ni competencia directa por CPU o RAM con terceros. Esta separación es importante cuando la infraestructura soporta ERP, bases de datos, ecommerce, escritorios virtuales, plataformas SaaS, sistemas internos o aplicaciones de clientes. La ventaja de Proxmox sobre nodos dedicados no está solo en el rendimiento. También está en la previsibilidad. El equipo técnico sabe qué hardware tiene, qué capacidad real existe, cuánto se puede sobreaprovisionar, qué margen queda ante fallo y cuándo conviene añadir nuevos nodos. Decisión sobre nodosImpacto operativoNúmero mínimo de nodosDetermina HA, quorum y tolerancia a fallosCPU y memoria por nodoCondiciona densidad de VMs y overcommitRedundanciaPermite mantenimiento sin parada completa del entornoHomogeneidad de hardwareSimplifica migraciones, balanceo y operaciónMargen libreEvita que un fallo deje al clúster sin capacidad suficientePool de nodos de reservaReduce tiempos de recuperación ante fallo físico Un clúster con tres nodos puede ser suficiente para muchos entornos iniciales, pero no todos los clústeres de tres nodos son iguales. Si los tres están llenos al 90 %, la alta disponibilidad será teórica: al caer uno, los otros dos no tendrán capacidad real para absorber la carga. Por eso el sizing debe contemplar el fallo, no solo el día normal de operación. La pregunta no debería ser “cuántas VMs caben”. La pregunta correcta es: “cuántas VMs pueden seguir funcionando si pierdo un nodo y necesito mantener servicio”. ## La red decide buena parte del comportamiento del clúster Proxmox puede mover máquinas virtuales entre nodos, gestionar alta disponibilidad y trabajar con distintos tipos de almacenamiento. Pero todas esas capacidades dependen de la red. Si la red está mal diseñada, el clúster lo acabará mostrando en forma de latencia, migraciones lentas, backups que afectan a producción o problemas de comunicación entre nodos. En un entorno profesional conviene separar, al menos de forma lógica, varios tipos de tráfico: gestión, Corosync, migración, almacenamiento, backup y tráfico de cliente. En proyectos más exigentes, esa separación también debe llevarse al plano físico o a redes dedicadas con ancho de banda garantizado. Tipo de tráficoRiesgo si se mezcla sin controlGestiónExposición innecesaria y dificultad para operar en incidenciasCorosync / clústerPérdida de estabilidad si hay latencia o paquetes perdidosMigraciónDegradación de VMs si compite con tráfico de producciónAlmacenamientoLatencia alta en discos virtuales y bases de datosBackupImpacto en horas críticas si no se limita o planificaClienteContención con tráfico interno del clúster Corosync merece una mención especial. Es la base de la comunicación del clúster y del quorum. No debería convivir alegremente con tráfico pesado ni depender de enlaces inestables. Una red saturada puede no tumbar las VMs de inmediato, pero puede hacer que la gestión del clúster sea menos fiable justo cuando se necesita tomar decisiones rápidas. La migración en caliente también depende de esta capa. En Proxmox funciona muy bien cuando el diseño acompaña, pero una VM grande con mucha memoria y alta actividad de escritura puede tardar más de lo esperado si la red de migración no tiene capacidad suficiente. La conclusión es sencilla: la red no se diseña al final. Se diseña antes de crear la primera VM de producción. ## Almacenamiento en red: mucho más que capacidad El almacenamiento suele ser la parte que más condiciona un entorno Proxmox. Y también una de las más subestimadas. En producción no basta con mirar terabytes disponibles. Hay que mirar latencia, IOPS, ancho de banda, redundancia, snapshots, replicación, recuperación, crecimiento y mantenimiento. Proxmox permite trabajar con múltiples opciones: almacenamiento local, ZFS, Ceph, NFS, iSCSI, Fibre Channel, cabinas externas o almacenamiento en red. Cada opción tiene sentido en determinados escenarios, pero ninguna es universal. Opción de almacenamientoVentaja principalPrecauciónLocal SSD/NVMeMuy buen rendimiento localMenor flexibilidad para HA si no hay replicaciónZFS localSnapshots, integridad y gestión avanzadaRequiere RAM, planificación y no llenar el poolCephAlmacenamiento distribuido integradoNecesita nodos, discos y red bien dimensionadosNFS/iSCSIIntegración sencilla con almacenamiento compartidoDepende de cabina/red y diseño de disponibilidadAlmacenamiento en red dedicadoSepara computación y datosRequiere baja latencia y redundancia realAlmacenamiento síncronoMuy bajo RPO y continuidad avanzadaMayor exigencia de arquitectura y coste En Stackscale, Proxmox puede apoyarse en almacenamiento en red y almacenamiento síncrono diseñado para desacoplar computación y datos. Esta separación permite escalar nodos de computación y almacenamiento de forma más independiente, facilita ciertos escenarios de recuperación y reduce la dependencia del disco local de cada host. Esto no significa que Ceph o ZFS no sean buenas opciones. Lo son, cuando encajan. Ceph puede ser muy potente en entornos con suficientes nodos, red rápida y operación especializada. ZFS es una tecnología excelente para integridad, snapshots y rendimiento local. Pero en entornos empresariales donde se busca una plataforma de cloud privado gestionable y predecible, el almacenamiento en red puede aportar una base sólida para operación, crecimiento y continuidad. El punto importante es no convertir el almacenamiento en una decisión improvisada. Muchas incidencias de virtualización empiezan como problemas de storage: pools demasiado llenos, latencia creciente, snapshots olvidados, backups que saturan enlaces, cabinas sin margen o discos que no responden como se esperaba bajo carga. ## HA en Proxmox: qué hace y qué no hace La alta disponibilidad de Proxmox VE permite reiniciar automáticamente máquinas virtuales o contenedores en otro nodo cuando el nodo original falla. Es una función muy valiosa y una de las razones por las que Proxmox puede usarse en entornos empresariales. Pero conviene entender bien sus límites. HA no significa que una VM no se vaya a interrumpir nunca. Si un nodo cae, la VM debe arrancar en otro nodo. Eso implica un tiempo de recuperación. Para muchas cargas es aceptable. Para otras, no. Una base de datos crítica, una aplicación transaccional o un sistema con usuarios conectados puede necesitar además replicación a nivel de aplicación, balanceadores, clústeres internos o mecanismos propios de tolerancia a fallos. ConceptoQué protegeQué no sustituyeProxmox HAFallo de nodo y reinicio automático de VMsAlta disponibilidad de la aplicaciónLive migrationMovimiento planificado de VMs entre nodosRecuperación ante caída brusca del hostBackupRecuperación de datos y sistemasContinuidad inmediataReplicación de aplicaciónContinuidad del servicio a nivel softwareBackup históricoDRRecuperación ante caída de ubicación o desastreOperación normal del clúster local La confusión entre HA, backup y disaster recovery es frecuente. HA ayuda a recuperar servicio ante la caída de un nodo. Backup permite recuperar datos o sistemas en un punto anterior. DR permite responder ante una caída mayor, como la pérdida de un CPD, un error grave de plataforma o un incidente de seguridad. Son capas distintas y deben convivir. ## Quorum: el pequeño detalle que decide el clúster En Proxmox, como en otros sistemas de clúster, el quorum es lo que permite tomar decisiones evitando situaciones peligrosas como split-brain. Si el clúster no tiene quorum, puede bloquear determinadas operaciones para proteger la consistencia. Por eso los clústeres de dos nodos deben tratarse con especial cuidado. Pueden tener sentido en escenarios concretos, pero normalmente requieren un qdevice o un diseño muy bien probado. En entornos de producción, el enfoque más habitual y recomendable es partir de al menos tres nodos para disponer de un quorum más fiable. Diseño de clústerLectura práctica1 nodoNo hay alta disponibilidad real2 nodos sin qdeviceRiesgo elevado de pérdida de quorum2 nodos con qdevicePuede funcionar en escenarios controlados3 nodosBase habitual para HA fiable4+ nodosMejor capacidad de crecimiento y mantenimiento El quorum no se debe descubrir durante una incidencia. Hay que probarlo antes. Simular caída de nodo, pérdida de red, reinicio controlado y mantenimiento ayuda a saber cómo se comporta el clúster y evita sorpresas en producción. ## Snapshots, backups y Proxmox Backup Server Los snapshots son útiles, pero no son backups. Esta frase se repite mucho porque sigue siendo uno de los errores más comunes en virtualización. Un snapshot sirve para conservar el estado de una VM durante una ventana corta: una actualización, un cambio de configuración, una prueba controlada o un despliegue. Si se mantiene demasiado tiempo, puede crecer, consumir almacenamiento y complicar el rendimiento. El backup debe diseñarse de otra manera. En entornos Proxmox, Proxmox Backup Server aporta copias incrementales, deduplicación, verificación, cifrado y una integración muy natural con Proxmox VE. En Stackscale, PBS puede combinarse con almacenamiento Archive vía NFS o acceso compatible S3, además de capas de almacenamiento en red más rápidas cuando se necesita reducir tiempos de restauración. ElementoUso correctoSnapshotCambio temporal y ventana cortaBackup localRecuperación rápida, pero no suficiente como única copiaProxmox Backup ServerCopias incrementales, deduplicadas y verificablesArchive storageRetención y copia separada para largo plazoCopia en otro CPDProtección frente a fallo mayor de ubicaciónPrueba de restauraciónValidación real de que el backup sirve Una política de backup profesional debe responder a preguntas concretas: cada cuánto se copia, cuánto se retiene, dónde está la copia, quién puede borrarla, cómo se verifica, cuánto tarda una restauración y qué sistemas se recuperan primero. Un backup que no se ha restaurado nunca no es una garantía. Es una hipótesis. ## Sizing y overcommit: eficiencia sin poner en riesgo el clúster Proxmox permite aprovechar bien CPU y memoria, pero el overcommit no es una barra libre. Asignar demasiadas vCPU o demasiada RAM sin medir uso real acaba generando contención. El problema no siempre aparece al principio. Aparece cuando varias VMs consumen recursos al mismo tiempo, cuando se ejecutan backups, cuando una base de datos crece o cuando un nodo falla y el resto debe absorber su carga. RecursoRiesgo de mal sizingBuena prácticavCPUContención y latencia de CPUMedir uso real y evitar asignaciones excesivasRAMSwapping o falta de margen ante falloReservar capacidad para picos y HADiscoLatencia e I/O waitMedir IOPS, no solo capacidadRedCuellos de botella en migración, backup y storageSeparar tráfico y dimensionar enlacesBackupImpacto en producciónVentanas, límites y monitorizaciónHAFalta de capacidad al caer un nodoDiseñar con margen N+1 o equivalente En cloud privado, el sizing debe revisarse de forma continua. Las cargas cambian. Una VM que hoy consume poco puede convertirse mañana en crítica. Un entorno que empezó con diez VMs puede crecer hasta cien. La ventaja de una infraestructura bien diseñada es que permite añadir nodos, ampliar almacenamiento y ajustar recursos sin tener que rehacer toda la plataforma. ## Monitorización y operación: la diferencia entre instalar y gestionar Una plataforma Proxmox bien diseñada necesita operación. Monitorización de nodos, almacenamiento, red, backups, latencia, capacidad, errores SMART, uso de CPU, memoria, I/O wait, estado de HA y tareas programadas. También necesita alertas útiles, no ruido. Si todo alerta, nada alerta. La operación también incluye procedimientos: cómo se actualiza un nodo, cómo se evacuan VMs antes de mantenimiento, cómo se prueba HA, cómo se revisan backups, cómo se documentan cambios, cómo se gestionan accesos y cómo se responde ante una degradación de almacenamiento. Proxmox tiene una ventaja importante: es transparente. Permite ver muchas capas del sistema, trabajar con herramientas Linux conocidas y automatizar mediante API y CLI. Pero esa transparencia exige conocimiento. No elimina la necesidad de administración. La hace más visible. ## Proxmox como base de cloud privado en Stackscale Para muchas empresas, el valor de Proxmox no está solo en el ahorro de licencias. Está en la posibilidad de construir un cloud privado abierto, flexible y controlado. En Stackscale, esa arquitectura puede apoyarse en nodos dedicados, redes privadas, almacenamiento en red, almacenamiento síncrono, backup, monitorización, soporte y opciones multi-CPD. Este enfoque permite separar responsabilidades. Stackscale aporta la base física, conectividad, CPD, hardware, red, almacenamiento y soporte de infraestructura. El cliente puede centrarse en sus sistemas, aplicaciones, seguridad, datos y evolución de la plataforma. Necesidad empresarialEnfoque con Proxmox sobre StackscaleControl de infraestructuraNodos dedicados y entorno de uso exclusivoReducción de dependencia propietariaPlataforma Proxmox VE open sourceContinuidadHA, almacenamiento en red, backup y opciones multi-CPDCrecimientoAmpliación de nodos y almacenamiento según demandaMigración desde VMwareDiseño de entorno destino, piloto y transición por fasesRecuperaciónProxmox Backup Server, Archive y pruebas de restauraciónOperaciónMonitorización, soporte y procedimientos técnicos La idea no es presentar Proxmox como una solución mágica. No lo es. Proxmox funciona muy bien cuando se diseña con rigor. También puede generar problemas si se despliega como una instalación rápida sin arquitectura. Lo mismo ocurre con cualquier plataforma de virtualización en producción. La diferencia está en asumirlo desde el principio: Proxmox no es virtualización barata. Es infraestructura crítica cuando soporta cargas críticas. ## Resumen técnico para administradores ÁreaRecomendación rápidaClústerDiseñar con al menos tres nodos cuando se busque HA fiableQuorumProbar pérdida de nodo y comportamiento del clúster antes de producciónRedSeparar gestión, migración, almacenamiento, backup y clienteStorageElegir según carga: red, Ceph, ZFS, síncrono o combinaciónHAUsarla para reinicio automático, no como sustituto de HA de aplicaciónBackupUsar PBS, retención, verificación y restauraciones probadasCapacidadAlertar antes del límite, no cuando el pool ya está llenoSizingMedir consumo real y reservar margen ante falloOperaciónDocumentar cambios, actualizar por fases y monitorizar todo ## Preguntas frecuentes **¿Proxmox es una alternativa real a VMware para cloud privado?****Sí, siempre que se diseñe como plataforma de producción. Proxmox VE puede ser una base sólida para cloud privado si se combina con clustering, almacenamiento adecuado, red bien segmentada, alta disponibilidad, backup y operación profesional. ¿Hace falta almacenamiento compartido para usar Proxmox HA?****Para muchos escenarios de HA es necesario que las VMs puedan arrancar en otros nodos con acceso a sus discos, ya sea mediante almacenamiento compartido, almacenamiento distribuido o replicación bien diseñada. La arquitectura exacta depende del caso de uso. ¿Ceph es obligatorio en Proxmox?****No. Ceph es una opción potente, especialmente para almacenamiento distribuido, pero no es obligatoria. Proxmox también puede trabajar con almacenamiento local, ZFS, NFS, iSCSI, Fibre Channel, almacenamiento en red o cabinas externas. ¿Los snapshots de Proxmox sirven como backup?****No. Los snapshots son útiles para ventanas cortas de mantenimiento, pero no sustituyen una estrategia de backup. Para copias reales conviene usar Proxmox Backup Server u otra solución de backup, con retención, verificación y pruebas de restauración. ¿Qué aporta Stackscale en un proyecto Proxmox?**Stackscale aporta infraestructura de cloud privado con nodos dedicados, conectividad, almacenamiento en red, opciones de almacenamiento síncrono, backup, monitorización y soporte especializado para diseñar y operar entornos Proxmox de producción. --- ## Linux enters a new phase: security, digital sovereignty and Artificial Intelligence URL: https://www.stackscale.com/blog/linux-enters-a-new-phase-security-digital-sovereignty-and-artificial-intelligence/ Linux has been associated with performance, stability and scalability for decades. It makes sense. A large part of the Internet, cloud infrastructure, supercomputing, telecommunications, embedded systems and enterprise IT runs on Linux or on technologies closely connected to its ecosystem. But that explanation is starting to fall short. Linux remains a solid technical foundation, but its role today goes far beyond running workloads efficiently. There is growing discussion around auditability, software supply chain security, digital sovereignty, memory safety, post-quantum cryptography, hardware sustainability and Artificial Intelligence applied to development and cybersecurity. The context has changed. Organisations no longer look only for fast and reliable systems. They need platforms they can understand, audit, protect and adapt. They also want to reduce dependencies that are difficult to reverse, retain control over their data and operate infrastructure prepared for threats that evolve very quickly. In this scenario, Linux is entering a stage shaped by trust. It is not just about choosing an operating system. It is about deciding which foundation will support servers, private cloud platforms, bare-metal environments, virtualisation, containers, automation, storage, networking and critical services. ## Kernel security: more CVEs do not necessarily mean less security One of the most visible changes is in the way Linux kernel vulnerabilities are managed. Since 2024, the Linux kernel project has acted as a CNA authority to assign CVE identifiers within its own scope. This has made many potentially security-related fixes more systematically documented. For IT teams, security managers and system administrators, this change requires a calm reading. The appearance of more CVEs associated with the kernel does not automatically mean that Linux is less secure. In many cases, it reflects a more formal, transparent and conservative process for identifying fixes that may have a security impact. The kernel’s own process makes clear that automatic CVE assignment happens when a fix has already been applied to a stable branch. In other words, this is not about flagging unresolved issues, but about documenting bugs that have already been corrected within the maintenance cycle. This distinction matters a great deal in private cloud, bare-metal, virtualisation and critical infrastructure environments. Vulnerability management should not be based solely on counting CVEs. What matters is assessing real exposure, kernel version, system configuration, loaded modules, accessible attack surface, compensating controls and workload criticality. The same CVE may have a high impact on one system and be irrelevant on another. It depends on the configuration, the actual use of the affected component and the operational context. More information should not create more alarm, but better prioritisation processes. TrendWhat is happeningWhy it mattersRisk if poorly managedKernel CVEsThe Linux kernel assigns CVEs more directly as a CNAImproves vulnerability and patch traceabilityTreating every CVE as an emergencyArtificial Intelligence reportsAutomated and duplicated reports are increasingThey can accelerate the discovery of real bugsOverloading maintainers and security teamsRust in the kernelComponents and drivers written in Rust are being introducedReduces certain classes of memory errorsRequires careful integration with C codeReproducible buildsDebian is strengthening package reproducibilityReinforces the software supply chainForces a review of build processesPost-quantum cryptographySome distributions are incorporating hybrid PQC algorithmsPrepares infrastructure for future threatsMay break compatibility if enabled without testingDigital sovereigntyEuropean administrations are reinforcing GNU/Linux adoptionReduces external dependencies and improves controlMigration can fail without user supportSustainabilityLinux can extend the useful life of hardwareReduces premature replacements and wasteShould not be done with unsupported software ## Artificial Intelligence: more analytical capacity, but also more noise Artificial Intelligence is already influencing Linux security. It can help review code, detect error patterns, reproduce bugs, analyse traces and accelerate tasks that previously required a great deal of manual work. Used properly, it can be a useful tool for finding issues earlier and improving software quality. But there is another, less comfortable side: the rise of low-quality, duplicated or poorly verified automated reports. In a project such as the Linux kernel, every security report requires analysis time from highly specialised maintainers. A report that does not correctly identify affected versions, exploitation conditions, traces, a reproducer or real impact is not very helpful. It can even slow work down. The kernel documentation already includes a specific section on the responsible use of Artificial Intelligence tools to find bugs. The underlying message is quite clear: AI can help, but human judgement remains essential. Reports must be concise, verifiable, technically useful and designed to make triage easier. This phenomenon anticipates a challenge that will also affect companies, cloud providers and cybersecurity teams. Automation increases detection capacity, but it also requires better filtering capacity. Having more alerts is not enough. Teams need to understand what is exploitable, what is already mitigated, what actually affects the infrastructure and what can wait for the normal maintenance cycle. In IT operations, maturity will increasingly be less about detecting a lot and more about prioritising well. ## Rust in Linux: memory safety without rewriting everything Another relevant movement is the evolution of Rust within the Linux ecosystem. Rust for Linux does not aim to turn the kernel into a project written entirely in Rust, nor to suddenly replace decades of C code. Its approach is more realistic: allowing new components, drivers and subsystems to benefit from a language with stronger guarantees against certain classes of memory errors. Memory safety matters because many serious low-level software bugs are related to use-after-free errors, overflows, invalid references or incorrect memory access. In a kernel, where an error can affect the entire system, reducing those categories of risk has clear value. Rust does not remove the need for review, testing or good design. Introducing it into the kernel requires compatibility with the existing ecosystem, careful review of interfaces with C code, performance validation, developer training and adapted maintenance processes. Its value lies in opening an additional path to write new code with lower risk, not in promising an immediate replacement of everything that came before. For enterprise infrastructure, this movement reflects a broader trend: security is being incorporated earlier in the software lifecycle. It is no longer only about patching afterwards. It is about reducing entire families of errors from the design stage. ## Debian and reproducible builds: verifying what gets installed Modern Linux security is not limited to the kernel. It also affects how the packages that reach systems are built and distributed. That is why reproducible builds are becoming increasingly important. A reproducible build allows two independent parties, using the same source code and the same build process, to obtain a bit-for-bit identical binary. This makes it easier to verify that the distributed package really corresponds to the published source code and has not been tampered with during the build phase. Debian has taken important steps to elevate reproducibility from a good practice to an operational requirement within its development process. For a distribution of its scale, the message is relevant: the software supply chain has become a strategic priority. Supply chain attacks have shown that trusting the source code is not enough. Organisations also need to trust how it is compiled, signed, distributed and updated. In cloud environments, where a base image can be replicated across hundreds or thousands of instances, this issue is critical. Reproducibility does not eliminate every risk, but it improves auditability. And in security, being able to verify is as important as being able to protect. ## Post-quantum cryptography: preparing without breaking compatibility Post-quantum cryptography is no longer a distant debate. The standardisation of algorithms such as ML-KEM and ML-DSA by NIST, and their progressive inclusion in distributions and system components, show that the industry is starting to prepare for a long-term scenario. Rocky Linux 10.2 is a recent example of this transition. The distribution includes improvements related to post-quantum cryptography in components such as OpenSSH, libssh, Directory Server, p11-kit and Podman. It also includes an important warning: enabling certain future cryptographic policies may break connections with systems that do not yet support these algorithms. That nuance is essential. Post-quantum cryptography should not be deployed as a global switch without prior analysis. Organisations need a cryptographic inventory, compatibility testing, supplier assessment, segmentation by criticality and a gradual transition strategy. This is where a concept becomes increasingly important: crypto-agility. It refers to the ability to change algorithms, certificates, protocols and cryptographic policies without redesigning the entire infrastructure. In the coming years, this capability will be as important as abandoning obsolete protocols or weak algorithms once was. For private cloud environments, bare-metal platforms and managed services, post-quantum preparation will need to combine caution and planning. Getting ahead makes sense. Breaking interoperability because of a lack of testing does not. ## Linux and digital sovereignty: more control over infrastructure Linux is also gaining weight in the European debate on digital sovereignty. Public administrations such as France’s are reinforcing the use of GNU/Linux and open tools as part of broader plans to reduce external technological dependencies. Digital sovereignty does not mean isolation or rejecting all proprietary software. It means increasing decision-making capacity over data, infrastructure, suppliers, formats, updates, auditing, deployment and operational continuity. In that area, free and open-source software offers clear advantages: transparency, inspectability, adaptability and reduced dependence on closed roadmaps. The French case is interesting because it is not limited to the operating system. The strategy includes workstations, collaborative tools, Artificial Intelligence, databases, virtualisation and network equipment. In other words, it treats digital infrastructure as a whole. This approach connects with the needs of many European companies. The question is no longer only which technology works best. It also matters which technology allows organisations to retain control, meet regulatory requirements, host data in suitable jurisdictions and avoid dependencies that are difficult to reverse. Linux does not solve every digital sovereignty problem by itself, but it does provide a technical foundation aligned with that objective. ## Sustainability: extending hardware lifespan is also an IT strategy Sustainability is another increasingly relevant angle. Many Linux distributions make it possible to extend the useful life of machines that remain functional but are left behind by other systems because of hardware requirements or commercial decisions. This can have an impact on workstations, laboratories, educational environments, development servers, auxiliary systems and non-critical infrastructure. Reusing hardware is not always possible or advisable, but when it is done with support, updates and a clear security policy, it can reduce costs and electronic waste. IT sustainability is not only about buying more efficient hardware. It is also about avoiding premature replacements, consolidating workloads, choosing suitable architectures, sizing resources properly and maintaining systems through reasonable lifecycles. Linux fits well into this vision because it offers flexibility. It can run on high-performance servers, virtualisation nodes, appliances, older machines, embedded devices and cloud platforms. That breadth allows infrastructure to adapt to the real need, not the other way around. ## What this new phase means for companies For companies, this new phase of Linux requires a change in mindset. It is no longer enough to install a stable distribution and apply periodic updates. Modern infrastructure requires a more complete view. First, vulnerability management needs to improve. This means monitoring CVEs, but also prioritising them according to real exposure, service criticality and specific configuration. Not every advisory has the same impact. Second, the supply chain should be strengthened. Base images, repositories, packages, automation scripts and dependencies need to be controlled. Reproducibility, package signing and traceability will become increasingly important. Third, Artificial Intelligence must be introduced with judgement. Automated tools can help, but their results must be validated. In security, automation without governance can generate more noise than value. Fourth, crypto-agility needs to enter planning. The post-quantum transition will be gradual, but organisations that do not know which algorithms they use, where their certificates are or which systems depend on old protocols will face more difficulty. Fifth, digital sovereignty needs to translate into concrete decisions: where data is hosted, which provider operates the infrastructure, what level of control exists over the platform, how backups are managed and what alternatives exist if the market changes. ## Linux as a foundation of trust for private cloud In the context of private cloud, Linux remains in a particularly strong position. It is present in hypervisors, container platforms, automation tools, storage solutions, backup systems, software-defined networks and observability services. Its value is not only that it is free or open. Its value lies in the combination of technical maturity, ecosystem, auditability, independence and flexibility. For companies looking to modernise their infrastructure without losing control, Linux remains one of the strongest foundations. This new stage does not replace its traditional strengths. It expands them. Performance, stability and scalability remain essential, but they are now joined by verifiable security, sovereignty, sustainability and preparation for emerging threats. Linux is still an operating system. In practice, it has also become a way to build infrastructure with more transparency, more control and more room for decision-making. ## Frequently asked questions What is changing in Linux security? The way vulnerabilities are documented, assigned and prioritised is changing. The Linux kernel now has a more direct process for assigning CVEs, which improves patch traceability but requires each advisory to be interpreted according to its real impact on each system. Why are there more CVEs associated with the Linux kernel? Because the assignment process is now more systematic. Not every CVE implies immediate exploitation or affects every configuration. In many cases, they reflect fixes already applied in stable branches. What does Rust bring to the Linux kernel? Rust allows new components to be written with stronger guarantees against certain memory errors. It does not replace existing C code, but it opens a path to reduce risk in specific drivers and subsystems. Why are reproducible builds important? Because they make it possible to verify that a binary package really corresponds to the published source code. This improves trust in the software supply chain and reduces the risk of tampering during package builds. --- ## Linux entra en una nueva fase: seguridad, soberanía digital e Inteligencia Artificial URL: https://www.stackscale.com/blog/linux-enters-a-new-phase-security-digital-sovereignty-and-artificial-intelligence/ Linux lleva décadas asociado a rendimiento, estabilidad y escalabilidad. Es normal. Buena parte de Internet, del cloud, de la supercomputación, de las telecomunicaciones, de los sistemas embebidos y de la infraestructura empresarial funciona sobre Linux o sobre tecnologías muy cercanas a su ecosistema. Pero esa explicación empieza a quedarse corta. Linux sigue siendo una base técnica sólida, pero su papel actual va más allá de ejecutar cargas de trabajo de forma eficiente. Cada vez se habla más de auditabilidad, cadena de suministro del software, soberanía digital, seguridad de memoria, criptografía poscuántica, sostenibilidad del hardware e Inteligencia Artificial aplicada al desarrollo y a la ciberseguridad. El contexto ha cambiado. Las organizaciones ya no solo buscan sistemas rápidos y fiables. Necesitan plataformas que puedan entender, auditar, proteger y adaptar. También quieren reducir dependencias difíciles de revertir, mantener control sobre sus datos y operar infraestructuras preparadas para amenazas que evolucionan muy deprisa. En ese escenario, Linux está entrando en una etapa marcada por la confianza. No se trata solo de elegir un sistema operativo. Se trata de decidir sobre qué base se construyen servidores, plataformas de cloud privado, entornos bare-metal, virtualización, contenedores, automatización, almacenamiento, redes y servicios críticos. ## Seguridad del kernel: más CVE no significa necesariamente más inseguridad Uno de los cambios más visibles está en la gestión de vulnerabilidades del kernel Linux. Desde 2024, el proyecto Linux kernel actúa como autoridad CNA para asignar identificadores CVE dentro de su propio ámbito. Esto ha hecho que muchas correcciones potencialmente relacionadas con seguridad se documenten de forma más sistemática. Para equipos de IT, responsables de seguridad y administradores de sistemas, este cambio exige una lectura serena. Que aparezcan más CVE asociados al kernel no significa automáticamente que Linux sea menos seguro. En muchos casos, refleja un proceso más formal, transparente y conservador para identificar correcciones que podrían tener impacto en la seguridad. El propio proceso del kernel aclara que la asignación automática de CVE se produce cuando ya existe una corrección aplicada a una rama estable. Es decir, no se trata de señalar problemas sin resolver, sino de documentar fallos ya corregidos dentro del ciclo de mantenimiento. Esta distinción importa mucho en entornos de cloud privado, bare-metal, virtualización o infraestructuras críticas. La gestión de vulnerabilidades no debería basarse únicamente en contar CVE. Lo relevante es evaluar exposición real, versión del kernel, configuración del sistema, módulos cargados, superficie accesible, controles compensatorios y criticidad de la carga de trabajo. Un mismo CVE puede tener impacto alto en un sistema y ser irrelevante en otro. Depende de la configuración, del uso real del componente afectado y del contexto operativo. Por eso, más información no debería generar más alarma, sino mejores procesos de priorización. TendenciaQué está pasandoPor qué importaRiesgo si se gestiona malCVE del kernelEl kernel Linux asigna CVE de forma más directa como CNAMejora la trazabilidad de vulnerabilidades y parchesConfundir cualquier CVE con una emergenciaInformes con Inteligencia ArtificialAumentan los reportes automatizados y duplicadosPuede acelerar el hallazgo de errores realesSaturar a mantenedores y equipos de seguridadRust en el kernelSe incorporan componentes y drivers escritos en RustReduce ciertas clases de errores de memoriaRequiere integración cuidadosa con código CBuilds reproduciblesDebian endurece la reproducibilidad de paquetesRefuerza la cadena de suministro del softwareObliga a revisar procesos de construcciónCriptografía poscuánticaAlgunas distribuciones incorporan algoritmos híbridos PQCPrepara infraestructuras frente a amenazas futurasPuede romper compatibilidad si se activa sin pruebasSoberanía digitalAdministraciones europeas refuerzan el uso de GNU/LinuxReduce dependencias externas y mejora el controlLa migración falla si no se acompaña a los usuariosSostenibilidadLinux permite alargar la vida útil del hardwareReduce sustituciones prematuras y residuosNo debe hacerse con software sin soporte ## Inteligencia Artificial: más capacidad de análisis, pero también más ruido La Inteligencia Artificial ya está influyendo en la seguridad de Linux. Puede ayudar a revisar código, detectar patrones de error, reproducir fallos, analizar trazas o acelerar tareas que antes requerían mucho trabajo manual. Bien utilizada, puede ser una herramienta útil para encontrar problemas antes y mejorar la calidad del software. Pero hay otra cara menos cómoda: el aumento de informes automatizados de baja calidad, duplicados o poco verificados. En un proyecto como el kernel Linux, cualquier reporte de seguridad exige tiempo de análisis por parte de mantenedores muy especializados. Un informe que no identifica versiones afectadas, condiciones de explotación, trazas, reproducer o impacto real no ayuda demasiado. Puede incluso ralentizar el trabajo. La documentación del kernel ya dedica un apartado específico al uso responsable de herramientas de Inteligencia Artificial para encontrar bugs. El mensaje de fondo es bastante claro: la IA puede ayudar, pero el criterio humano sigue siendo imprescindible. Los informes deben ser breves, verificables, técnicamente útiles y orientados a facilitar el triage. Este fenómeno anticipa un reto que también afectará a empresas, proveedores cloud y equipos de ciberseguridad. La automatización aumenta la capacidad de detección, pero también obliga a mejorar la capacidad de filtrado. No basta con tener más alertas. Hay que saber qué es explotable, qué está mitigado, qué afecta realmente a la infraestructura y qué puede esperar al ciclo normal de mantenimiento. En operaciones IT, la madurez estará cada vez menos en detectar mucho y cada vez más en priorizar bien. ## Rust en Linux: seguridad de memoria sin reescribirlo todo Otro movimiento relevante es la evolución de Rust dentro del ecosistema Linux. Rust for Linux no pretende convertir el kernel en un proyecto escrito íntegramente en Rust ni reemplazar de golpe décadas de código C. Su enfoque es más realista: permitir que nuevos componentes, drivers y subsistemas puedan beneficiarse de un lenguaje con garantías más fuertes frente a determinadas clases de errores de memoria. La seguridad de memoria importa porque muchos fallos graves en software de bajo nivel tienen relación con uso de memoria liberada, desbordamientos, referencias inválidas o accesos incorrectos. En un kernel, donde un error puede afectar a todo el sistema, reducir esas categorías de riesgo tiene un valor evidente. Rust no elimina la necesidad de revisión, pruebas ni buen diseño. Introducirlo en el kernel exige mantener compatibilidad con el ecosistema existente, revisar interfaces con código C, asegurar rendimiento, formar a desarrolladores y adaptar procesos de mantenimiento. Su valor está en abrir una vía adicional para escribir nuevo código con menos riesgo, no en prometer una sustitución inmediata de todo lo anterior. Para infraestructuras empresariales, este movimiento refleja una tendencia más amplia: la seguridad se está incorporando antes en el ciclo de vida del software. Ya no se trata solo de parchear después. Se trata de reducir familias enteras de errores desde el diseño. ## Debian y las builds reproducibles: verificar lo que se instala La seguridad moderna de Linux no se limita al kernel. También afecta a cómo se construyen y distribuyen los paquetes que llegan a los sistemas. Por eso las compilaciones reproducibles están ganando peso. Una build reproducible permite que dos partes independientes, usando el mismo código fuente y el mismo proceso de construcción, obtengan un binario idéntico bit a bit. Esto facilita comprobar que el paquete distribuido corresponde realmente al código publicado y que no ha sido manipulado durante la fase de construcción. Debian ha dado pasos importantes para elevar la reproducibilidad de buena práctica a requisito operativo dentro de su proceso de desarrollo. Para una distribución con su escala, el mensaje es relevante: la cadena de suministro del software se ha convertido en una prioridad estratégica. Los ataques a la cadena de suministro han demostrado que no basta con confiar en el código fuente. También hay que confiar en cómo se compila, cómo se firma, cómo se distribuye y cómo se actualiza. En entornos cloud, donde una imagen base puede replicarse en cientos o miles de instancias, esta cuestión es crítica. La reproducibilidad no elimina todos los riesgos, pero mejora la capacidad de auditoría. Y en seguridad, poder verificar es tan importante como poder proteger. ## Criptografía poscuántica: prepararse sin romper la compatibilidad La criptografía poscuántica ha dejado de ser un debate lejano. La estandarización de algoritmos como ML-KEM y ML-DSA por parte de NIST y su incorporación progresiva en distribuciones y componentes de sistema muestran que el sector empieza a prepararse para un escenario de largo plazo. Rocky Linux 10.2 es un ejemplo reciente de esta transición. La distribución incorpora mejoras relacionadas con criptografía poscuántica en componentes como OpenSSH, libssh, Directory Server, p11-kit y Podman. También introduce una advertencia importante: activar determinadas políticas criptográficas futuras puede romper conexiones con sistemas que aún no soportan estos algoritmos. Ese matiz es esencial. La criptografía poscuántica no debería desplegarse como un interruptor global sin análisis previo. Las organizaciones necesitan inventario criptográfico, pruebas de compatibilidad, evaluación de proveedores, segmentación por criticidad y una estrategia de transición gradual. Aquí aparece un concepto que conviene tener cada vez más presente: criptoagilidad. Es la capacidad de cambiar algoritmos, certificados, protocolos y políticas criptográficas sin rediseñar toda la infraestructura. En los próximos años, esta capacidad será tan importante como lo fue en su día abandonar protocolos obsoletos o algoritmos débiles. Para entornos de cloud privado, plataformas bare-metal y servicios gestionados, la preparación poscuántica deberá combinar prudencia y planificación. Adelantarse tiene sentido. Romper interoperabilidad por falta de pruebas, no. ## Linux y soberanía digital: más control sobre la infraestructura Linux también está ganando peso en el debate europeo sobre soberanía digital. Administraciones públicas como la francesa están reforzando el uso de GNU/Linux y herramientas abiertas dentro de planes más amplios para reducir dependencias tecnológicas externas. La soberanía digital no significa aislarse ni rechazar cualquier software propietario. Significa aumentar la capacidad de decisión sobre datos, infraestructura, proveedores, formatos, actualizaciones, auditoría, despliegue y continuidad operativa. En ese terreno, el software libre ofrece ventajas claras: transparencia, posibilidad de inspección, adaptación y menor dependencia de hojas de ruta cerradas. El caso francés es interesante porque no se limita al sistema operativo. La estrategia incluye puestos de trabajo, herramientas colaborativas, Inteligencia Artificial, bases de datos, virtualización y equipos de red. Es decir, aborda la infraestructura digital como un conjunto. Este enfoque conecta con las necesidades de muchas empresas europeas. La pregunta ya no es solo qué tecnología funciona mejor. También importa qué tecnología permite mantener control, cumplir requisitos regulatorios, alojar datos en jurisdicciones adecuadas y evitar dependencias difíciles de revertir. Linux no resuelve por sí solo todos los problemas de soberanía digital, pero sí proporciona una base técnica coherente con ese objetivo. ## Sostenibilidad: alargar la vida útil del hardware también es estrategia IT La sostenibilidad es otro ángulo cada vez más relevante. Muchas distribuciones Linux permiten extender la vida útil de equipos que siguen siendo funcionales, pero que otros sistemas dejan atrás por requisitos de hardware o decisiones comerciales. Esto puede tener impacto en puestos de trabajo, laboratorios, entornos educativos, servidores de desarrollo, sistemas auxiliares o infraestructuras no críticas. Reutilizar hardware no siempre es posible ni recomendable, pero cuando se hace con soporte, actualizaciones y una política clara de seguridad, puede reducir costes y residuos electrónicos. La sostenibilidad en IT no consiste solo en comprar hardware más eficiente. También consiste en evitar sustituciones prematuras, consolidar cargas de trabajo, elegir arquitecturas adecuadas, dimensionar bien los recursos y mantener sistemas durante ciclos de vida razonables. Linux encaja bien en esta visión porque ofrece flexibilidad. Puede ejecutarse en servidores de alto rendimiento, nodos de virtualización, appliances, equipos antiguos, dispositivos embebidos y plataformas cloud. Esa amplitud permite adaptar la infraestructura a la necesidad real, no al revés. ## Qué significa esta nueva fase para las empresas Para las empresas, la nueva fase de Linux implica un cambio de mentalidad. Ya no basta con instalar una distribución estable y aplicar actualizaciones periódicas. La infraestructura moderna exige una visión más completa. Primero, es necesario mejorar la gestión de vulnerabilidades. Esto implica monitorizar CVE, pero también priorizar según exposición real, criticidad del servicio y configuración concreta. No todos los avisos tienen el mismo impacto. Segundo, conviene reforzar la cadena de suministro. Las imágenes base, repositorios, paquetes, scripts de automatización y dependencias deben estar controlados. La reproducibilidad, la firma de paquetes y la trazabilidad serán cada vez más importantes. Tercero, hay que incorporar la Inteligencia Artificial con criterio. Las herramientas automáticas pueden ayudar, pero sus resultados deben validarse. En seguridad, automatizar sin gobernanza puede generar más ruido que valor. Cuarto, la criptoagilidad debe entrar en la planificación. La transición poscuántica será gradual, pero las organizaciones que no sepan qué algoritmos usan, dónde están sus certificados o qué sistemas dependen de protocolos antiguos tendrán más dificultades. Quinto, la soberanía digital debe traducirse en decisiones concretas: dónde se alojan los datos, qué proveedor opera la infraestructura, qué nivel de control existe sobre la plataforma, cómo se gestionan las copias de seguridad y qué alternativas hay ante cambios de mercado. ## Linux como base de confianza para el cloud privado En el contexto del cloud privado, Linux mantiene una posición especialmente fuerte. Está presente en hipervisores, plataformas de contenedores, herramientas de automatización, soluciones de almacenamiento, sistemas de backup, redes definidas por software y servicios de observabilidad. Su valor no está únicamente en ser gratuito o abierto. Su valor está en la combinación de madurez técnica, ecosistema, auditabilidad, independencia y flexibilidad. Para empresas que buscan modernizar su infraestructura sin perder control, Linux sigue siendo una de las bases más sólidas. Esta nueva etapa no sustituye sus fortalezas tradicionales. Las amplía. Rendimiento, estabilidad y escalabilidad siguen siendo esenciales, pero ahora se suman seguridad verificable, soberanía, sostenibilidad y preparación frente a amenazas emergentes. Linux sigue siendo un sistema operativo. En la práctica, también se ha convertido en una forma de construir infraestructura con más transparencia, más control y más margen de decisión. ## Preguntas frecuentes ¿Qué está cambiando en la seguridad de Linux? Está cambiando la forma en que se documentan, asignan y priorizan las vulnerabilidades. El kernel Linux cuenta con un proceso más directo para asignar CVE, lo que mejora la trazabilidad de los parches, pero obliga a interpretar cada aviso según su impacto real en cada sistema. ¿Por qué hay más CVE asociados al kernel Linux? Porque el proceso de asignación es ahora más sistemático. No todos los CVE implican una explotación inmediata ni afectan a todas las configuraciones. En muchos casos, reflejan correcciones ya aplicadas en ramas estables. ¿Qué aporta Rust al kernel Linux? Rust permite escribir nuevos componentes con mejores garantías frente a ciertos errores de memoria. No sustituye al código C existente, pero abre una vía para reducir riesgos en drivers y subsistemas concretos. ¿Por qué son importantes las builds reproducibles? Porque permiten verificar que un paquete binario corresponde realmente al código fuente publicado. Esto mejora la confianza en la cadena de suministro del software y reduce el riesgo de manipulación durante la construcción de paquetes. --- ## Subnet masks: a complete guide for infrastructure professionals URL: https://www.stackscale.com/blog/subnet-masks-a-complete-guide-for-infrastructure-professionals/ Few things are as fundamental in infrastructure management as subnet masks—and few are understood as superficially. Anyone who has ever configured a network interface has typed 255.255.255.0 almost on autopilot. But when it comes time to design the network architecture for a production environment, segment traffic across VLANs, size subnets for a private cloud deployment, or figure out why a firewall isn’t passing what it should, a real understanding of how subnet masks work is the difference between a well-designed infrastructure and a permanent source of incidents. This guide covers the concept from the fundamentals through the practical scenarios that come up daily in datacenter and cloud environments, including reference tables, calculation examples, and the most common mistakes. ## What is a subnet mask and why does it matter in infrastructure A subnet mask is a 32-bit value that, when applied to an IP address, separates two things: **the portion that identifies the network** and **the portion that identifies the host** (the specific device within that network). It is, in essence, the tool that tells an operating system, a switch, or a router whether a packet should stay on the local network or be forwarded through the default gateway. In binary, a subnet mask is always a sequence of **contiguous ones followed by contiguous zeros**. The ones mark the network bits; the zeros mark the host bits. No exceptions—although, as we’ll see later, there was a time when there were. Two ways to express the same thing: - **Dotted decimal notation**: 255.255.255.0 - **CIDR notation**: /24 Both represent exactly the same thing: the first 24 bits are network, the remaining 8 are host. ## How it works internally: the AND operation When a device needs to determine whether a destination IP is on its own network, it doesn’t compare addresses by eye. It performs a **logical AND operation** between its own IP address and the mask, then does the same with the destination IP. If the results match, the packet goes directly. If not, it’s sent to the gateway. **Practical example** with IP 192.168.1.45 and mask 255.255.255.0: ``` IP: 11000000.10101000.00000001.00101101 (192.168.1.45) Mask: 11111111.11111111.11111111.00000000 (255.255.255.0) ──────────────────────────────────── AND: 11000000.10101000.00000001.00000000 → 192.168.1.0 ``` The result—192.168.1.0—is the **network address**. If another device produces the same result when applying its mask, both are on the same subnet. This seemingly simple mechanism is what makes all IP communication work: from the most basic home network to the network architecture of a datacenter with hundreds of VLANs. ## Complete subnet mask table: /32 to /0 The following table is a reference worth keeping handy at all times. It includes the CIDR notation, the dotted decimal mask, the total number of IPs, **usable hosts** (subtracting the network address and broadcast), and the most common use case in real-world infrastructure environments. CIDRDecimal maskTotal IPsUsable hostsCommon use/32255.255.255.25511Host route, loopback, firewall rules/31255.255.255.25422*Point-to-point links (RFC 3021)/30255.255.255.25242Router-to-router interconnections/29255.255.255.24886DMZ segment, small public IP blocks/28255.255.255.2401614Small public IP pool, management/27255.255.255.2243230Management network, small office/26255.255.255.1926462Department VLAN, server segment/25255.255.255.128128126Medium server subnet/24255.255.255.0256254Standard LAN, typical VLAN/23255.255.254.0512510Large LAN, campus/22255.255.252.01,0241,022Campus, corporate WiFi/21255.255.248.02,0482,046Large campus/20255.255.240.04,0964,094ISP, cloud provider/19255.255.224.08,1928,190ISP block/18255.255.192.016,38416,382ISP block/17255.255.128.032,76832,766ISP block/16255.255.0.065,53665,534Large corporate network/12255.240.0.01,048,5761,048,574Class B private range (172.16.0.0/12)/8255.0.0.016,777,21616,777,214Class A private range (10.0.0.0/8)/00.0.0.04,294,967,296—Default route * The /31 mask, defined in RFC 3021, does not reserve a network address or broadcast address. It is widely supported on modern routers and saves one address compared to /30 on every point-to-point link—something that adds up when managing hundreds of interconnections in a datacenter. ### Decimal to binary conversion: the values that appear in each octet DecimalBinaryNetwork bits0000000000128100000001192110000002224111000003240111100004248111110005252111111006254111111107255111111118 These are the **only valid values** that can appear in a subnet mask octet. If someone configures a different value (for example, 255.255.255.200), the configuration is incorrect. ## The most commonly used masks in professional environments Not all masks are used with the same frequency. In datacenter and cloud infrastructure practice, these are the ones that come up again and again: ### /24 — The standard mask The most common in LANs and VLANs. It provides 254 hosts, making it suitable for most enterprise network segments: workstations, servers in a rack, management networks, or storage VLANs. **Example**: 10.10.5.0/24 covers from 10.10.5.1 to 10.10.5.254, with broadcast at 10.10.5.255. ### /25 — Splitting a /24 in two When a /24 is too large and you need to separate two environments (for example, production and staging), a /25 divides the block into two subnets of 126 hosts each. SubnetRangeHosts10.10.5.0/25.1 – .12612610.10.5.128/25.129 – .254126 ### /26 — Four segments per /24 Ideal for separating VLANs within a single block when smaller segments are needed: server network, management network, monitoring network, and user network, each with up to 62 hosts. SubnetNetwork addressFirst hostLast hostBroadcast110.10.5.0/2610.10.5.110.10.5.6210.10.5.63210.10.5.64/2610.10.5.6510.10.5.12610.10.5.127310.10.5.128/2610.10.5.12910.10.5.19010.10.5.191410.10.5.192/2610.10.5.19310.10.5.25410.10.5.255 ### /27 — 30-host segments Widely used for management networks (iDRAC/IPMI, switches, smart PDUs) where there are only a few dozen devices and a reduced broadcast domain is desirable. ### /28 — Small public IP blocks When a provider assigns a block of public IPs to a customer, /28 (14 hosts) is one of the most common units. Also used for DMZs with few exposed services. ### /30 and /31 — Point-to-point links In any datacenter network with multiple interconnected routers or firewalls, the links between them use /30 (2 hosts) or /31 (2 hosts with no waste). In an infrastructure with 50 interconnections, the difference between /30 and /31 amounts to 50 saved IP addresses—something that matters at scale. ### /32 — The individual host Not a “subnet” in the strict sense: it identifies a single IP address. Used in **host routes** (static routes to a specific host), specific firewall rules, router loopback interfaces, and IP assignment in point-to-multipoint networks. ## Network design with VLSM: a real-world example In a production infrastructure, subnets rarely all need to be the same size. The **VLSM** (Variable Length Subnet Mask) technique allows you to assign each segment exactly the mask it needs, optimizing address utilization. **Scenario**: A company has the allocated block 172.16.10.0/24 and needs: - Production servers: 100 hosts - User network: 50 hosts - Management/IPMI network: 20 hosts - DMZ: 10 hosts - Two WAN links: 2 hosts each The allocation—always starting with the largest subnet—would be: SegmentHosts neededCIDRMaskAvailable hostsAssigned networkProduction100/25255.255.255.128126172.16.10.0/25Users50/26255.255.255.19262172.16.10.128/26Management20/27255.255.255.22430172.16.10.192/27DMZ10/28255.255.255.24014172.16.10.224/28WAN 12/30255.255.255.2522172.16.10.240/30WAN 22/30255.255.255.2522172.16.10.244/30 Out of the 256 addresses in the original block, 238 are being used with minimal waste. Without VLSM, you would need to assign a /24 to each segment, requiring six /24 blocks instead of one. ## Wildcard mask: the other side of the subnet mask In **ACL** (access control list) configurations on routers and switches, and in protocols like **OSPF**, the subnet mask is not used directly. Instead, its inverse is used: the **wildcard mask**. The calculation is straightforward: 255.255.255.255 - subnet mask = wildcard. Subnet maskWildcard255.255.255.255 (/32)0.0.0.0255.255.255.252 (/30)0.0.0.3255.255.255.240 (/28)0.0.0.15255.255.255.0 (/24)0.0.0.255255.255.0.0 (/16)0.0.255.255 **Cisco ACL example**: Allow traffic from the server network 172.16.10.0/25: ``` access-list 100 permit ip 172.16.10.0 0.0.0.127 any ``` **OSPF example**: Advertise the management network 172.16.10.192/27: ``` router ospf 1 network 172.16.10.192 0.0.0.31 area 0 ``` ## Quick calculation formulas Two formulas worth having committed to memory: **Usable hosts per subnet:** ``` 2^(32 - CIDR_prefix) - 2 ``` **Number of subnets when dividing a block:** ``` 2^(new_prefix - original_prefix) ``` **Quick examples:** - How many hosts fit in a /27? → 2^(32-27) – 2 = **30** - How many /28s can I carve from a /24? → 2^(28-24) = **16 subnets** - I need at least 500 hosts: 2^n ≥ 502 → n = 9 → **/23** ## Route aggregation (supernetting) CIDR doesn’t just allow dividing networks into smaller subnets—it also allows **aggregating multiple networks into a larger announcement**. This is critical for keeping routing tables manageable, especially in BGP. **Example**: Instead of advertising four separate routes: ``` 192.168.0.0/24 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 ``` You can advertise a single summary route: 192.168.0.0/22, reducing the load on neighboring routers. This only works if the networks are contiguous and align on a power-of-2 boundary. ## Private addresses (RFC 1918) and CGNAT Three address blocks are reserved for internal use and are not routed on the public Internet: BlockCIDRTotal hostsCommon use10.0.0.0 – 10.255.255.25510.0.0.0/816,777,214Large corporate networks, private cloud, datacenters172.16.0.0 – 172.31.255.255172.16.0.0/121,048,574Mid-size networks, infrastructure segments192.168.0.0 – 192.168.255.255192.168.0.0/1665,534Home networks, small offices Additionally, the block **100.64.0.0/10** is reserved for **CGNAT** (Carrier-Grade NAT, RFC 6598), a technique used by ISPs to share public IPs across multiple customers. It’s important not to use this range in your own internal networks to avoid conflicts. ## A brief history: from flat networks to CIDR IP addressing hasn’t always worked this way: **1970s**: IP networks were flat. They always assumed 8 bits for the network and 24 for the host. Only 256 networks were possible across the entire Internet. **1981 (RFC 791)**: Jon Postel introduces Classes A, B, and C. The mask was implicitly derived from the class. The problem: a mid-size organization needed a Class B (65,534 hosts) because Class C (254 hosts) was too small, wasting thousands of addresses. **1985 (RFC 950)**: **Subnet masks** are formalized, allowing networks to be divided into smaller subnets. **1993 (RFC 1519)**: **CIDR** (*Classless Inter-Domain Routing*) is born, eliminating the class concept and adopting VLSM. This is the system in use today and the one that allowed IPv4 to survive far longer than anyone expected. An interesting historical note: in the early years, **masks didn’t require contiguous bits**. A mask like 255.255.192.128 was perfectly valid. The practice was abandoned in the early 1990s because it made efficient *longest prefix match* routing computationally impractical. ## Subnet masks in IPv6 In IPv6, dotted decimal mask notation doesn’t exist. Only **prefix notation**, equivalent to CIDR, is used: ``` 2001:0db8:85a3::1/64 ``` The most common prefix is /64 for local networks (2^64 = 18.4 quintillion addresses per subnet—more than enough for any scenario). ISPs receive /32 or /48 blocks from regional registries (RIPE, ARIN, LACNIC, etc.). In practice, subnet planning in IPv6 is simpler than in IPv4: the abundance of addresses eliminates the need for the fine-grained subnetting that makes mastering VLSM essential in IPv4. ## Checking your subnet mask: quick commands **Linux** (the mask appears in CIDR notation): ``` ip addr show # Example output: inet 10.10.5.45/24 brd 10.10.5.255 scope global eth0 ``` **Windows**: ``` ipconfig # Look for: Subnet Mask . . . . . . . . . . . : 255.255.255.0 ``` **macOS**: ``` ifconfig en0 # Look for: netmask 0xffffff00 (hex for 255.255.255.0) ``` **On a Cisco switch or router**: ``` show ip interface brief show running-config interface Vlan10 ``` ## Common configuration mistakes These are the most frequent problems found in network audits—worth knowing so you can avoid them: **Inconsistent masks on the same VLAN.** If one server has /24 and another has /25 on the same physical network, part of the range will be unreachable for one of them. This is a classic source of “it works sometimes” issues that are notoriously difficult to diagnose. **Overlapping subnets.** When manually assigning blocks with VLSM without a clear plan, it’s easy for two subnets to overlap. The result: packets arriving at the wrong destination or ambiguous routes. **Defaulting to /24 when it’s not needed.** A WAN link between two routers doesn’t need 254 addresses. A /30 or /31 is the right choice; using /24 wastes 252 IPs on every link. **Forgetting to subtract 2 when calculating hosts.** The network address (all host bits set to 0) and the broadcast address (all set to 1) are not assignable. A /24 has 254 hosts, not 256. A /30 has 2, not 4. **Forgetting to update the gateway and DNS.** When changing a mask, the default gateway and firewall rules must reflect the new scheme. Changing a mask without reviewing the gateway is a guaranteed outage. ## Subnet masks in the context of private cloud In **private cloud** and **bare metal** environments, subnet design is one of the first architectural decisions. The choice of masks directly affects scalability, traffic isolation, and operational complexity. A typical datacenter infrastructure design uses separate VLANs with masks tailored to each function: VLANFunctionTypical maskWhyVLAN 10Production/24 or /23Enough room for servers and growthVLAN 20Management/IPMI/27 or /28Few devices, critical isolationVLAN 30Storage (iSCSI/NFS)/24Dedicated traffic, jumbo MTU, no gatewayVLAN 40Backup/24Separated from production trafficVLAN 50DMZ/28 or /27Only exposed services, strict firewallVLAN 100Router interconnections/31 per linkMaximum IP utilization This type of design, combined with inter-VLAN firewall rules and thorough IP addressing documentation, is what separates a professional infrastructure from an improvised deployment. At **Stackscale**, network management is designed so that each customer has properly sized and isolated segments, with network-level redundancy and connectivity to multiple carriers. If you’re planning a deployment that requires custom network design, our team can help you size the subnets, VLANs, and segmentation rules that best fit your use case. --- ## Máscaras de red: guía completa para profesionales de infraestructura URL: https://www.stackscale.com/blog/subnet-masks-a-complete-guide-for-infrastructure-professionals/ Pocas cosas son tan fundamentales en la administración de infraestructura como las máscaras de red —y pocas se entienden tan superficialmente. Cualquiera que haya configurado una interfaz de red ha escrito 255.255.255.0 casi por inercia. Pero cuando llega el momento de diseñar la arquitectura de red de un entorno de producción, de segmentar el tráfico entre VLANs, de dimensionar subredes para un despliegue en cloud privado o de entender por qué un firewall no deja pasar lo que debería, la comprensión real de cómo funcionan las máscaras de red marca la diferencia entre una infraestructura bien diseñada y una fuente permanente de incidencias. Esta guía recorre el concepto desde los fundamentos hasta los escenarios prácticos que se encuentran a diario en entornos de datacenter y cloud, incluyendo tablas de referencia, ejemplos de cálculo y los errores más habituales. ## Qué es una máscara de red y por qué importa en infraestructura Una máscara de red es un valor de 32 bits que, aplicado a una dirección IP, separa dos cosas: **la parte que identifica la red** y **la parte que identifica el host** (el dispositivo concreto dentro de esa red). Es, en esencia, la herramienta que le dice a un sistema operativo, a un switch o a un router si un paquete debe quedarse en la red local o si tiene que salir por la puerta de enlace. En binario, una máscara de red es siempre una secuencia de **unos consecutivos seguidos de ceros consecutivos**. Los unos marcan los bits de red; los ceros, los bits de host. No hay excepciones —aunque, como veremos más adelante, hubo un tiempo en que las había—. Dos formas de expresar lo mismo: - **Notación decimal**: 255.255.255.0 - **Notación CIDR**: /24 Ambas representan exactamente lo mismo: los primeros 24 bits son red, los 8 restantes son host. ## Cómo funciona internamente: la operación AND Cuando un dispositivo necesita saber si una IP de destino está en su misma red, no compara direcciones “a ojo”. Realiza una **operación AND lógica** entre su propia dirección IP y la máscara, y hace lo mismo con la IP de destino. Si los resultados coinciden, el paquete va directo. Si no, sale por el gateway. **Ejemplo práctico** con la IP 192.168.1.45 y máscara 255.255.255.0: ``` IP: 11000000.10101000.00000001.00101101 (192.168.1.45) Máscara: 11111111.11111111.11111111.00000000 (255.255.255.0) ──────────────────────────────────── AND: 11000000.10101000.00000001.00000000 → 192.168.1.0 ``` El resultado —192.168.1.0— es la **dirección de red**. Si otro dispositivo produce el mismo resultado al aplicar su máscara, ambos están en la misma subred. Este mecanismo, aparentemente simple, es lo que hace que toda la comunicación IP funcione: desde la red doméstica más básica hasta la arquitectura de red de un datacenter con cientos de VLANs. ## Tabla completa de máscaras de red: de /32 a /0 La siguiente tabla es una referencia que conviene tener siempre a mano. Incluye la notación CIDR, la máscara en decimal, el número total de IPs, los **hosts utilizables** (descontando dirección de red y broadcast) y el uso más habitual en entornos reales de infraestructura. CIDRMáscara decimalTotal IPsHosts utilizablesUso habitual/32255.255.255.25511Host route, loopback, reglas de firewall/31255.255.255.25422*Enlaces punto a punto (RFC 3021)/30255.255.255.25242Interconexión entre routers/29255.255.255.24886Segmento DMZ, IPs públicas pequeñas/28255.255.255.2401614Pequeño pool de IPs públicas, gestión/27255.255.255.2243230Red de gestión, oficina pequeña/26255.255.255.1926462VLAN de departamento, segmento de servidores/25255.255.255.128128126Subred de servidores mediana/24255.255.255.0256254LAN estándar, VLAN típica/23255.255.254.0512510LAN grande, campus/22255.255.252.01.0241.022Campus, WiFi corporativo/21255.255.248.02.0482.046Campus grande/20255.255.240.04.0964.094ISP, cloud provider/19255.255.224.08.1928.190Bloque ISP/18255.255.192.016.38416.382Bloque ISP/17255.255.128.032.76832.766Bloque ISP/16255.255.0.065.53665.534Red corporativa grande/12255.240.0.01.048.5761.048.574Rango privado Clase B (172.16.0.0/12)/8255.0.0.016.777.21616.777.214Rango privado Clase A (10.0.0.0/8)/00.0.0.04.294.967.296—Ruta por defecto (default route) * La máscara /31, definida en la RFC 3021, no reserva dirección de red ni broadcast. Su uso está ampliamente soportado en routers modernos y ahorra una dirección respecto a /30 en cada enlace punto a punto —algo relevante cuando se gestionan cientos de interconexiones en un datacenter—. ### Conversión decimal a binario: los valores que aparecen en cada octeto DecimalBinarioBits de red0000000000128100000001192110000002224111000003240111100004248111110005252111111006254111111107255111111118 Estos son los **únicos valores válidos** que pueden aparecer en un octeto de una máscara de subred. Si alguien configura un valor diferente (por ejemplo, 255.255.255.200), la configuración es incorrecta. ## Las máscaras más utilizadas en entornos profesionales No todas las máscaras se usan con la misma frecuencia. En la práctica de datacenter e infraestructura cloud, estas son las que aparecen una y otra vez: ### /24 — La máscara estándar La más habitual en redes LAN y VLANs. Proporciona 254 hosts, lo que la hace adecuada para la mayoría de segmentos de una red empresarial: estaciones de trabajo, servidores de un rack, redes de gestión o VLANs de almacenamiento. **Ejemplo**: 10.10.5.0/24 cubre desde 10.10.5.1 hasta 10.10.5.254, con broadcast en 10.10.5.255. ### /25 — Dividir una /24 en dos Cuando una /24 es demasiado grande y se necesita separar dos entornos (por ejemplo, producción y staging), una /25 divide el bloque en dos subredes de 126 hosts cada una. SubredRangoHosts10.10.5.0/25.1 – .12612610.10.5.128/25.129 – .254126 ### /26 — Cuatro segmentos por /24 Ideal para separar VLANs dentro de un mismo bloque cuando se necesitan segmentos más pequeños: red de servidores, red de gestión, red de monitorización y red de usuarios, cada una con hasta 62 hosts. SubredDirección de redPrimer hostÚltimo hostBroadcast110.10.5.0/2610.10.5.110.10.5.6210.10.5.63210.10.5.64/2610.10.5.6510.10.5.12610.10.5.127310.10.5.128/2610.10.5.12910.10.5.19010.10.5.191410.10.5.192/2610.10.5.19310.10.5.25410.10.5.255 ### /27 — Segmentos de 30 hosts Muy usado para redes de gestión (iDRAC/IPMI, switches, PDUs inteligentes) donde hay pocas decenas de dispositivos y se quiere un dominio de broadcast reducido. ### /28 — Bloques pequeños de IPs públicas Cuando un proveedor asigna un bloque de IPs públicas para un cliente, /28 (14 hosts) es una de las unidades más frecuentes. También se usa para DMZs con pocos servicios expuestos. ### /30 y /31 — Enlaces punto a punto En cualquier red de datacenter con múltiples routers o firewalls interconectados, los enlaces entre ellos usan /30 (2 hosts) o /31 (2 hosts sin desperdicio). En una infraestructura con 50 interconexiones, la diferencia entre /30 y /31 supone 50 direcciones IP ahorradas —algo que, a escala, importa—. ### /32 — El host individual No es una “subred” en sentido estricto: identifica una única dirección IP. Se utiliza en **host routes** (rutas estáticas a un host concreto), reglas de firewall específicas, interfaces loopback de routers y asignación de IPs en redes punto a multipunto. ## Diseño de red con VLSM: un ejemplo real En una infraestructura de producción, rara vez todas las subredes necesitan el mismo tamaño. La técnica **VLSM** (Variable Length Subnet Mask) permite asignar a cada segmento exactamente la máscara que necesita, optimizando el uso de direcciones. **Escenario**: Una empresa tiene asignado el bloque 172.16.10.0/24 y necesita: - Servidores de producción: 100 hosts - Red de usuarios: 50 hosts - Red de gestión/IPMI: 20 hosts - DMZ: 10 hosts - Dos enlaces WAN: 2 hosts cada uno La asignación —empezando siempre por la subred más grande— sería: SegmentoHosts necesariosCIDRMáscaraHosts disponiblesRed asignadaProducción100/25255.255.255.128126172.16.10.0/25Usuarios50/26255.255.255.19262172.16.10.128/26Gestión20/27255.255.255.22430172.16.10.192/27DMZ10/28255.255.255.24014172.16.10.224/28WAN 12/30255.255.255.2522172.16.10.240/30WAN 22/30255.255.255.2522172.16.10.244/30 De las 256 direcciones del bloque original, se están utilizando 238 con un desperdicio mínimo. Sin VLSM, habría que asignar una /24 a cada segmento, necesitando seis bloques /24 en lugar de uno. ## Wildcard mask: la otra cara de la máscara En configuraciones de **ACLs** (listas de control de acceso) en routers y switches, y en protocolos como **OSPF**, no se usa la máscara de subred directamente sino su inverso: la **wildcard mask** o máscara comodín. El cálculo es simple: 255.255.255.255 - máscara de subred = wildcard. Máscara de subredWildcard255.255.255.255 (/32)0.0.0.0255.255.255.252 (/30)0.0.0.3255.255.255.240 (/28)0.0.0.15255.255.255.0 (/24)0.0.0.255255.255.0.0 (/16)0.0.255.255 **Ejemplo en ACL de Cisco**: Permitir tráfico desde la red de servidores 172.16.10.0/25: ``` access-list 100 permit ip 172.16.10.0 0.0.0.127 any ``` **Ejemplo en OSPF**: Anunciar la red de gestión 172.16.10.192/27: ``` router ospf 1 network 172.16.10.192 0.0.0.31 area 0 ``` ## Fórmulas de cálculo rápido Dos fórmulas que conviene tener interiorizadas: **Hosts utilizables por subred:** ``` 2^(32 - prefijo_CIDR) - 2 ``` **Número de subredes al dividir un bloque:** ``` 2^(nuevo_prefijo - prefijo_original) ``` **Ejemplos rápidos:** - ¿Cuántos hosts caben en una /27? → 2^(32-27) – 2 = **30** - ¿En cuántas /28 puedo dividir una /24? → 2^(28-24) = **16 subredes** - Necesito al menos 500 hosts: 2^n ≥ 502 → n = 9 → **/23** ## Agregación de rutas (supernetting) CIDR no solo permite dividir redes en subredes más pequeñas, sino también **agregar varias redes en un anuncio más grande**. Esto es fundamental para mantener las tablas de enrutamiento manejables, especialmente en BGP. **Ejemplo**: En lugar de anunciar cuatro rutas separadas: ``` 192.168.0.0/24 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 ``` Se puede anunciar una sola ruta resumida: 192.168.0.0/22, reduciendo la carga en los routers vecinos. Esto solo funciona si las redes son contiguas y se alinean en un límite de potencia de 2. ## Direcciones privadas (RFC 1918) y CGNAT Tres bloques de direcciones están reservados para uso interno y no se enrutan en Internet: BloqueCIDRHosts totalesUso habitual10.0.0.0 – 10.255.255.25510.0.0.0/816.777.214Redes corporativas grandes, cloud privado, datacenters172.16.0.0 – 172.31.255.255172.16.0.0/121.048.574Redes medianas, segmentos de infraestructura192.168.0.0 – 192.168.255.255192.168.0.0/1665.534Redes domésticas, oficinas pequeñas Además, el bloque **100.64.0.0/10** está reservado para **CGNAT** (Carrier-Grade NAT, RFC 6598), una técnica que usan los ISP para compartir IPs públicas entre múltiples clientes. Es importante no utilizar este rango en redes internas propias para evitar conflictos. ## Breve historia: de las redes planas a CIDR El direccionamiento IP no siempre funcionó así: **Años 70**: Las redes IP eran planas. Se asumían 8 bits para red y 24 para host. Solo existían 256 redes posibles en toda Internet. **1981 (RFC 791)**: Jon Postel introduce las clases A, B y C. La máscara se deduce implícitamente de la clase. El problema: una empresa mediana necesitaba una Clase B (65.534 hosts) porque la Clase C (254 hosts) se quedaba corta, desperdiciando miles de direcciones. **1985 (RFC 950)**: Se formalizan las **máscaras de subred**, permitiendo dividir redes en subredes más pequeñas. **1993 (RFC 1519)**: Nace **CIDR** (*Classless Inter-Domain Routing*), eliminando el concepto de clases y adoptando VLSM. Es el sistema que se usa actualmente y el que permitió que IPv4 sobreviviera mucho más de lo previsto. Un dato curioso: en los primeros años, **las máscaras no requerían bits contiguos**. Una máscara como 255.255.192.128 era perfectamente válida. La práctica se abandonó a principios de los 90 porque hacía inviable el enrutamiento *longest prefix match* de forma eficiente. ## Máscaras de red en IPv6 En IPv6, la notación decimal de máscara no existe. Se utiliza exclusivamente la **notación de prefijo**, equivalente a CIDR: ``` 2001:0db8:85a3::1/64 ``` Lo más habitual es /64 para redes locales (2^64 = 18,4 trillones de direcciones por subred, más que suficiente para cualquier escenario). Los ISP reciben bloques /32 o /48 de los registros regionales (RIPE, ARIN, LACNIC…). En la práctica, la planificación de máscaras en IPv6 es más sencilla que en IPv4: la abundancia de direcciones elimina la necesidad del subnetting fino que hace imprescindible el dominio de VLSM en IPv4. ## Consultar la máscara de red: comandos rápidos **Linux** (la máscara aparece en notación CIDR): ``` ip addr show # Ejemplo de salida: inet 10.10.5.45/24 brd 10.10.5.255 scope global eth0 ``` **Windows**: ``` ipconfig # Buscar: Máscara de subred . . . : 255.255.255.0 ``` **macOS**: ``` ifconfig en0 # Buscar: netmask 0xffffff00 (hexadecimal de 255.255.255.0) ``` **En un switch o router Cisco**: ``` show ip interface brief show running-config interface Vlan10 ``` ## Errores frecuentes en la configuración de máscaras Estos son los problemas más habituales que se encuentran en auditorías de red y que conviene conocer para evitarlos: **Máscaras inconsistentes en la misma VLAN.** Si un servidor tiene /24 y otro /25 en la misma red física, parte del rango será inalcanzable para uno de ellos. Es una fuente clásica de “funciona a veces” difícil de diagnosticar. **Subredes solapadas.** Al asignar manualmente bloques con VLSM sin un plan claro, es fácil que dos subredes se pisen. La consecuencia: paquetes que llegan al destino equivocado o rutas ambiguas. **Usar /24 por defecto cuando no es necesario.** Un enlace WAN entre dos routers no necesita 254 direcciones. Un /30 o /31 es lo correcto; usar /24 desperdicia 252 IPs en cada enlace. **No restar 2 al calcular hosts.** La dirección de red (todos los bits de host a 0) y la de broadcast (todos a 1) no son asignables. En una /24 hay 254 hosts, no 256. En una /30 hay 2, no 4. **Olvidar actualizar el gateway y el DNS.** Al cambiar una máscara, la puerta de enlace y las reglas de firewall deben reflejar el nuevo esquema. Un cambio de máscara sin revisar el gateway es una caída garantizada. ## Máscaras de red en el contexto de cloud privado En entornos de **cloud privado** y **bare metal**, el diseño de subredes es una de las primeras decisiones arquitectónicas. La elección de máscaras afecta directamente a la escalabilidad, al aislamiento de tráfico y a la complejidad operativa. Un diseño habitual en infraestructura de datacenter utiliza VLANs separadas con máscaras ajustadas a cada función: VLANFunciónMáscara típicaPor quéVLAN 10Producción/24 o /23Espacio suficiente para servidores y crecimientoVLAN 20Gestión/IPMI/27 o /28Pocos dispositivos, aislamiento críticoVLAN 30Almacenamiento (iSCSI/NFS)/24Tráfico dedicado, MTU jumbo, sin gatewayVLAN 40Backup/24Separado del tráfico de producciónVLAN 50DMZ/28 o /27Solo servicios expuestos, firewall estrictoVLAN 100Interconexión de routers/31 por enlaceMáximo aprovechamiento de IPs Este tipo de diseño, combinado con reglas de firewall entre VLANs y una buena documentación de la tabla de direccionamiento, es lo que separa una infraestructura profesional de un despliegue improvisado. En la infraestructura de **Stackscale**, la gestión de red se diseña para que cada cliente disponga de segmentos correctamente dimensionados y aislados, con redundancia a nivel de red y conectividad a múltiples operadores. Si estás planificando un despliegue que requiere un diseño de red a medida, nuestro equipo puede ayudarte a dimensionar las subredes, VLANs y reglas de segmentación que mejor se adapten a tu caso. --- ## Migrating from VMware to Proxmox VE: what CIOs and CTOs really ask URL: https://www.stackscale.com/blog/migrating-from-vmware-to-proxmox-ve-what-cios-and-ctos-really-ask/ For years, many virtualization decisions were made almost by inertia. However, the current landscape has pushed many companies to revisit something that once seemed settled: **whether it still makes sense to stay on the same platform or whether the time has come to explore alternatives that offer more technical control, less vendor dependence, and a more predictable cost structure.** In that context, Proxmox VE has gone from being seen as a valid option for small environments or labs to becoming part of much more serious discussions within systems, operations, and infrastructure teams. **The key point, however, is not just the potential savings.** When a CIO or CTO considers a migration away from VMware, the relevant questions are not only financial. **The real questions are about risk, continuity, high availability, backups, performance, compatibility, and operational readiness.** And that is the most important point: migrating from VMware to Proxmox VE is not simply about changing hypervisors. It is about reviewing the virtualization platform as a whole. Below, we look at the questions technical leadership teams typically ask before taking on a migration like this, and why the answer cannot be reduced to a simple feature-by-feature comparison. ## The first question is not “how much will we save?” but “what risk are we taking on?” When evaluating a migration, savings usually get attention first. That is normal. But in enterprise projects, that is rarely the deciding factor. The conversation quickly shifts to other concerns: how much downtime there will be, how operations will be protected, what will happen to high availability, how backups will be handled, and how much real room there will be to roll back if something goes wrong. **In other words, the real debate is not whether Proxmox VE costs less, but whether it can support operations with the required guarantees.** That shift in perspective also explains why a well-planned migration should not be treated as a purely technical project. In reality, it affects business continuity, change management, operational procedures, and recovery architecture. Once it is understood that way, the decision stops being a reaction to market conditions and becomes a platform project. ## How much downtime am I going to have? This is almost always the first question that comes up in any serious meeting. The correct answer is rarely “zero.” It depends on the workload type, the migration method, the available maintenance window, and the organization’s tolerance for risk. In export-import scenarios, each virtual machine will usually require downtime. For critical services, on the other hand, the sensible approach is to organize the work in waves, with prior testing, functional validation, and a rollback plan that exists in practice, not just on paper. **The lesson here is fairly simple: migrating everything at once is usually not a good idea.** The right approach is to classify workloads by criticality and dependencies. An auxiliary VM, a development environment, or an internal application does not require the same treatment as a transactional database, an ERP system, or a platform serving end customers. That initial segmentation often makes the difference between an orderly migration and a painful one. ## Can high availability be maintained in Proxmox VE? Yes, but it is important to explain what that really means. **Proxmox VE includes clustering and high availability capabilities**, and its HA model allows virtual machines or containers to restart automatically on other healthy nodes when a failure occurs. That said, this does not mean high availability appears by magic. It also depends on cluster design, quorum, networking, and storage. In other words, HA is not something you simply switch on. It is something you build. This fits very well with the way Stackscale approaches these projects: not as a checklist of isolated items, but as a combination of infrastructure, operations, and recovery objectives. In practice, the platform has to align with technical, operational, and business requirements, and Proxmox VE can fit into multi-node clusters with high availability, integrated backups, and different storage options. ## What risks are involved in a V2V conversion? In any **VMware-to-Proxmox project, V2V (virtual-to-virtual) conversion comes up sooner or later**. And here it is important to avoid two very common mistakes: assuming everything will be trivial or assuming everything will be problematic. Most issues tend to be concentrated around the same areas: - drivers and tools installed in the guest operating system - BIOS versus UEFI differences - network interface configuration - disk performance after conversion - specific drivers in Windows environments - services that depend on settings inherited from the previous environment These are not exotic risks. They are normal risks. That is why the most solid migrations almost never start with a large-scale wave. They start with a pilot. A pilot with representative machines, different operating systems, different workload profiles, and applications that make it possible to validate not only that the VM boots, but that the application continues to work as expected. That pilot helps refine templates, document exceptions, identify incompatibilities, and build a realistic decision matrix. In practice, it turns the migration into a repeatable process. ## What about backups and Disaster Recovery? This is where many organizations realize they are not just reviewing a hypervisor, but their entire recovery strategy. **Proxmox VE can integrate natively with Proxmox Backup Server (PBS)**, which provides incremental backups, deduplication, integrity verification, and synchronization options between locations. All of this makes it possible to design more efficient policies in terms of both storage consumption and network impact. But beyond the specific tool, the underlying issue remains the same: copying is not the same as recovering. If a restore has not been tested, the backup should not be considered validated. That is why a well-designed **migration requires defining RPO (Recovery Point Objective) and RTO (Recovery Time Objective) targets from the outset, along with retention policies, restore procedures, and post-recovery functional validation**. Recovering a virtual machine is not enough; you need to verify that the service actually comes back online and works as expected. This approach is fully aligned with Stackscale’s broader view of Disaster Recovery: prioritize resources, define RTO and RPO, test the plan regularly, and understand that there is no universal design. Recovery architecture must be adapted to each company’s level of criticality. ## Is Proxmox VE suitable for enterprise environments? **The short answer is yes.** The useful answer is yes, as long as it is treated as an enterprise platform and not as a “cheap hypervisor” to which everything else will be added later. **That means designing the cluster correctly,** defining the storage strategy, setting up roles and permissions with RBAC (role-based access control), strengthening hardening, ensuring monitoring, organizing networks properly, and documenting operational and recovery procedures. It also means relying on an infrastructure layer that supports that design. In Stackscale’s case, we link Proxmox environments to cloud infrastructure capabilities such as dedicated compute nodes, network storage, synchronous storage, integration with a network independent from the virtualization environment, and multi-data-center architectures for continuity and backup. That becomes especially relevant when the organization is not just trying to “move away from VMware,” but to use the migration as an opportunity to leave behind a more organized, more stable, and more predictable platform for the years ahead. ## Basic checklist for a VMware → Proxmox VE migration PhaseCheckpointWhat to reviewProject governanceScope and ownershipDefine sponsor, technical team, success criteria, and communication planInventoryWorkload discoveryInventory VMs, dependencies, networking, storage, operating systems, and criticalityClassificationSegmentationSeparate services by criticality: low, medium, high, and mission-criticalTarget designProxmox VE clusterSize nodes, quorum, HA, management network, and storage networkTarget designStorageChoose between local, network, or synchronous storage based on RPO/RTOSecurityAccess and hardeningReview RBAC, segmentation, logs, and monitoringPilotInitial selectionChoose representative VMs to test compatibility, boot, networking, and performancePilotFunctional validationConfirm that applications work correctly after conversionV2VCompatibilityReview BIOS/UEFI, drivers, Windows controllers, and disk/network behaviorWavesPlanningGroup machines by dependencies and criticality; avoid simultaneous mass migrationRollbackReal rollback planDocument and test rollback by service typeBackupPolicy and restoreDefine retention, repositories, and periodic restores with functional validationDRSecondary locationEvaluate recovery in another zone or data center if applicablePost-migrationStable operationsReview usage, incidents, capacity, and procedures before project closeout ## Success is not “it boots,” but “it runs well weeks later” Many companies measure the success of a migration on the day the virtual machines boot on the new platform. But that moment only closes one phase of the project. By itself, it does not prove the migration was successful. The real test comes later: when operations remain stable, backups restore correctly, monitoring provides useful visibility, teams have clear procedures, and the business no longer feels that every change could trigger an incident. That is when it becomes clear whether the organization carried out a reactive migration just to get away from a commercial problem, or whether it used the transition to genuinely strengthen its platform. In many cases, the most important savings do not come only from licensing. They come from reducing complexity, avoiding operational mistakes, and building a more predictable infrastructure, both in terms of costs and continuity. ## Frequently asked questions ### Can Proxmox VE replace VMware in an enterprise environment? **Yes, as long as the migration is approached as a complete platform project**, including cluster design, storage, backup, security, and operations. ### Does high availability in Proxmox VE work the same way as in VMware? It should not be treated as an automatic one-to-one equivalent. Proxmox VE supports HA, but its effectiveness depends on cluster design, quorum, networking, and storage. ### What usually causes the most problems in a V2V migration? Typically, drivers, BIOS/UEFI settings, networking, storage, and certain Windows-specific drivers or dependencies. ### Is a pilot required before migrating? In enterprise environments, it is highly recommended. It helps validate compatibility, performance, procedures, and rollback before touching critical workloads. ### What role do backups play in this type of migration? They are essential. A migration forces you to review not only how backups are created, but how they are restored, how long recovery takes, and whether they truly meet the defined RPO and RTO objectives. --- ## Migrar de VMware a Proxmox VE: lo que CIO y CTO preguntan de verdad URL: https://www.stackscale.com/blog/migrating-from-vmware-to-proxmox-ve-what-cios-and-ctos-really-ask/ Durante años, muchas decisiones de virtualización se tomaban casi por inercia. Sin embargo, el contexto actual ha hecho que muchas empresas vuelvan a revisar algo que parecía cerrado: **si tiene sentido seguir en la misma plataforma o si ha llegado el momento de estudiar alternativas con más control técnico, menos dependencia comercial y una estructura de costes más previsible.** En ese escenario, **Proxmox VE** ha pasado de ser visto como una opción válida para entornos pequeños o laboratorios a entrar en conversaciones mucho más serias dentro de departamentos de sistemas, operaciones e infraestructura. **La clave, eso sí, no está solo en el ahorro potencial.** Cuando un CIO o un CTO plantea una migración desde VMware, las preguntas relevantes no son únicamente financieras. **Las preguntas de verdad** tienen que ver con riesgo, **continuidad, alta disponibilidad, backups, rendimiento, compatibilidad y capacidad de operación**. Y ahí está el punto más importante: migrar de VMware a Proxmox VE no es simplemente cambiar de hipervisor. Es revisar la plataforma de virtualización como un todo. A continuación, repasamos qué suelen preguntar realmente los equipos de dirección técnica antes de abordar una migración de este tipo y por qué la respuesta no puede quedarse en una simple comparación de funcionalidades. ## La primera pregunta no es “cuánto ahorro”, sino “qué riesgo asumo” Cuando se analiza una migración, el ahorro suele llamar la atención primero. Es normal. Pero en proyectos enterprise, esa no suele ser la cuestión decisiva. La conversación cambia muy rápido hacia otros temas: cuánto downtime habrá, cómo se va a proteger la operación, qué pasará con la alta disponibilidad, cómo se harán los backups y qué margen real existirá para volver atrás si algo falla. **En otras palabras: el verdadero debate no es si Proxmox VE cuesta menos, sino si puede sostener la operación con garantías.** Ese cambio de enfoque también explica por qué una migración bien planteada no debería tratarse como un proyecto puramente técnico. En realidad, afecta a continuidad de negocio, gobierno del cambio, procedimientos operativos y arquitectura de recuperación. Cuando se entiende así, la decisión deja de ser una reacción al mercado y pasa a convertirse en un proyecto de plataforma. ## ¿Cuánto downtime voy a tener? Esta es casi siempre la primera pregunta que aparece en cualquier reunión seria. La respuesta correcta rara vez es “cero”. Depende del tipo de carga, del método de migración, de la ventana disponible y de la tolerancia al riesgo. En escenarios de exportación e importación, lo habitual es que cada máquina virtual necesite una parada. En servicios críticos, en cambio, lo razonable es organizar el trabajo por oleadas, con pruebas previas, validaciones funcionales y un plan de reversión que no exista solo sobre el papel. **La lección aquí es bastante simple: no conviene migrarlo todo a la vez.** Lo sensato es clasificar las cargas por criticidad y dependencias. No exige el mismo tratamiento una VM auxiliar, un entorno de desarrollo o una aplicación interna que una base de datos transaccional, un ERP o una plataforma que da servicio a clientes. Esa segmentación inicial suele marcar la diferencia entre una migración ordenada y una migración traumática. ## ¿Se puede mantener alta disponibilidad en Proxmox VE? Sí, pero conviene explicar bien qué significa eso. **Proxmox VE incorpora capacidades de clúster y alta disponibilidad**, y su propio modelo de HA permite reiniciar automáticamente máquinas virtuales o contenedores en otros nodos sanos cuando se produce un fallo. Ahora bien, eso no significa que la alta disponibilidad aparezca por arte de magia. También depende del diseño del clúster, del quórum, de la red y del almacenamiento. La propia documentación de Proxmox recuerda que, para un quórum fiable, lo recomendable es contar con al menos tres nodos, o diseñar correctamente escenarios equivalentes con qdevice cuando proceda. **Dicho de otra forma: la HA no se activa, se construye.** Esto encaja muy bien con la forma en la que Stackscale aborda este tipo de proyectos: no como una lista de checks aislados, sino como una combinación de infraestructura, operación y objetivos de recuperación. En contenidos recientes del blog se insiste precisamente en que la plataforma debe ajustarse a los requisitos técnicos, operativos y de negocio, y en que Proxmox VE puede encajar en clústeres multi-nodo con alta disponibilidad, backups integrados y distintas opciones de almacenamiento. ## ¿Qué riesgos hay en una conversión V2V? En cualquier **proyecto VMware → Proxmox aparece tarde o temprano la conversión V2V (virtual-to-virtual)**. Y aquí conviene evitar dos errores muy frecuentes: pensar que todo será trivial o asumir que todo será problemático. La mayoría de incidencias suelen concentrarse en los mismos puntos: - drivers y herramientas instaladas en el sistema invitado; - diferencias entre BIOS y UEFI; - configuración de interfaces de red; - rendimiento de disco tras la conversión; - controladores específicos en entornos Windows; - servicios que dependen de configuraciones heredadas del entorno anterior. No son riesgos exóticos. Son riesgos normales. Por eso, **las migraciones más sólidas casi nunca empiezan por la oleada masiva. Empiezan por un piloto**. Un piloto con máquinas representativas, sistemas operativos distintos, perfiles de carga diferentes y aplicaciones que permitan validar no solo que la VM arranca, sino que la aplicación sigue funcionando como debe. Ese piloto sirve para ajustar plantillas, documentar excepciones, detectar incompatibilidades y construir una matriz de decisión realista. En la práctica, convierte la migración en un proceso repetible. ## ¿Qué pasa con los backups y el Disaster Recovery? Aquí muchas organizaciones descubren que no están revisando solo un hipervisor, sino toda su estrategia de recuperación. **Proxmox VE puede integrarse de forma nativa con Proxmox Backup Server (PBS)**, que ofrece backups incrementales, deduplicación, verificación de integridad y opciones de sincronización entre ubicaciones. Todo ello permite diseñar políticas más eficientes tanto en consumo de almacenamiento como en impacto sobre la red. Pero más allá de la herramienta concreta, el problema de fondo sigue siendo el mismo: copiar no es recuperar. Si una restauración no se ha probado, el backup no debería darse por validado. Por eso, **una migración bien diseñada obliga a definir desde el principio objetivos de RPO (Recovery Point Objective) y RTO (Recovery Time Objective), políticas de retención, procedimientos de restore y validación funcional** posterior. No basta con recuperar una máquina virtual; hay que comprobar que el servicio realmente vuelve a operar. Este enfoque coincide con otros contenidos del blog de Stackscale sobre Disaster Recovery, donde se insiste en priorizar recursos, definir RTO y RPO, probar el plan periódicamente y entender que no existe una solución universal: el diseño debe adaptarse a la criticidad de cada empresa. ## ¿Proxmox VE sirve para enterprise? **La respuesta corta es sí.** La respuesta útil es sí, siempre que se trate como una plataforma empresarial y no como un “hipervisor barato” al que después ya se le irán añadiendo piezas. Eso **significa diseñar bien el clúster**, definir la estrategia de almacenamiento, establecer roles y permisos con RBAC (control de acceso basado en roles), reforzar el hardening, garantizar la monitorización, organizar bien las redes y documentar procedimientos de operación y recuperación. También significa apoyarse en una infraestructura que acompañe ese diseño. En el caso de Stackscale, vinculamos los entornos Proxmox a capacidades de infraestructura cloud de nodos de computación dedicados, almacenamiento en red, almacenamiento síncrono, integración con una red independiente del entorno de virtualización y arquitecturas multi-CPD para continuidad y backup. Eso es especialmente relevante cuando la organización no busca solo “salir de VMware”, sino aprovechar la migración para dejar una plataforma más ordenada, más estable y más previsible para los próximos años. ## Checklist básica para una migración VMware → Proxmox VE FasePunto de controlQué revisarGobierno del proyectoAlcance y responsablesDefinir sponsor, equipo técnico, criterios de éxito y plan de comunicaciónInventarioDescubrimiento de cargasInventariar VMs, dependencias, red, almacenamiento, sistemas operativos y criticidadClasificaciónSegmentaciónSeparar servicios por criticidad: baja, media, alta y misión críticaDiseño destinoClúster Proxmox VEDimensionar nodos, quórum, HA, red de gestión y red de almacenamientoDiseño destinoAlmacenamientoElegir entre almacenamiento local, en red o síncrono según RPO/RTOSeguridadAccesos y hardeningRevisar RBAC, segmentación, logs y monitorizaciónPilotoSelección inicialElegir VMs representativas para probar compatibilidad, arranque, red y rendimientoPilotoValidación funcionalConfirmar que las aplicaciones funcionan correctamente tras la conversiónV2VCompatibilidadRevisar BIOS/UEFI, drivers, controladores Windows y comportamiento de disco y redOleadasPlanificaciónAgrupar máquinas por dependencias y criticidad; evitar migración masiva simultáneaRollbackPlan realDocumentar y probar el retorno por tipo de servicioBackupPolítica y restoreDefinir retención, repositorios y restores periódicos con validación funcionalDRUbicación secundariaValorar recuperación en otra zona o centro de datos si aplicaPost-migraciónOperación estableRevisar consumo, incidencias, capacidad y procedimientos antes del cierre ## El éxito no es “arranca”, sino “opera bien semanas después” Muchas empresas miden el éxito de una migración el día en que las máquinas virtuales arrancan en la nueva plataforma. Pero ese momento solo cierra una fase del proyecto. No demuestra por sí solo que la migración haya salido bien. La prueba real llega después: cuando la operación sigue siendo estable, los backups restauran correctamente, la monitorización ofrece visibilidad útil, los equipos tienen procedimientos claros y el negocio deja de vivir con la sensación de que cualquier cambio puede provocar una incidencia. Ahí es donde se ve si la organización ha ejecutado una migración reactiva para salir de un problema comercial o si ha aprovechado el cambio para reforzar de verdad su plataforma. En muchos casos, el ahorro más importante no viene solo de la licencia. Viene de reducir complejidad, evitar errores operativos y construir una infraestructura más predecible, tanto en costes como en continuidad. ## Preguntas frecuentes ### ¿Proxmox VE puede sustituir a VMware en un entorno enterprise? **Sí, siempre que la migración se plantee como un proyecto de plataforma completo**, con diseño de clúster, almacenamiento, backup, seguridad y operación. ### ¿La alta disponibilidad en Proxmox VE funciona igual que en VMware? No debe plantearse como una equivalencia automática. Proxmox VE dispone de HA, pero su efectividad depende del diseño del clúster, del quórum, de la red y del almacenamiento. ### ¿Qué suele dar más problemas en una migración V2V? Normalmente, drivers, BIOS/UEFI, red, disco y ciertos controladores o dependencias en sistemas Windows. ### ¿Es obligatorio hacer un piloto antes de migrar? En entornos empresariales, es muy recomendable. Permite validar compatibilidad, rendimiento, procedimientos y rollback antes de tocar cargas críticas. ### ¿Qué papel juegan los backups en una migración de este tipo? Son esenciales. La migración obliga a revisar no solo cómo se hacen las copias, sino cómo se restauran, cuánto tardan y si cumplen realmente el RPO y el RTO definidos. --- ## The Linux kernel prepares for a “day after” Linus Torvalds URL: https://www.stackscale.com/blog/linux-kernel-prepares-for-day-after-linus-torvalds/ For more than three decades, the Linux kernel has grown with a comfortable paradox: a massive project maintained by hundreds of people worldwide, yet with a final, centralised step that has effectively passed through the hands of a near-single figure. Linus Torvalds didn’t just write the first lines of code; since 1991, he has also been the final integrator of the mainline tree—the canonical repository that decides what lands and what doesn’t. That centrality—both efficient and fragile—now has a formal answer. The kernel community has documented a continuity procedure: a “plan to activate a plan” in case there is no orderly transition one day, whether due to retirement, incapacity, or any scenario that leaves the stewardship of the canonical repository in limbo. It’s not a dramatic turn and it doesn’t crown an heir. It’s what a mature, industrial-grade project does: accept that even strong informal institutions need a protocol once time passes and the software stops being a hobby and becomes critical infrastructure. ## Linux: from “personal project” to digital backbone It’s easy to forget that Linux began as a small kernel in the era of newsgroups and mailing lists. What followed was organic growth: first in universities and technical environments, then as a foundation for servers, networking and supercomputing, and later as an indirect pillar of the mobile world (through Android) and the cloud. The impact is obvious to anyone running production systems: Linux isn’t “just another operating system”. It’s a de facto standard in data centres, a structural ingredient in the software supply chain, and a layer on which essential services are built. When something like that depends—at the very last step—on a single central figure, a familiar risk concept comes into play: the **bus factor**. ## The bus factor of mainline Kernel development is distributed: subsystem maintainers, intermediate trees, public review, pull requests, and an engineering culture that has turned Linux into a remarkably effective social machine. Still, the final step—merging into mainline—has historically been the “good bottleneck”: a consistency filter that keeps the project coherent in both technical direction and style. The uncomfortable question is not whether the community has the talent to keep going. The question is what happens if, when the time comes, there is no transition “with a script”—or if the person responsible for mainline cannot (or does not want to) facilitate it. That is the gap the new document is designed to close. ## What the continuity procedure establishes The text has been added to kernel documentation as “Linux kernel project continuity”, describing an emergency mechanism that is intended to be activated only if there is no smooth transition. The logic is straightforward: - An **Organizer** is designated to kick off the process. The document defines this role as the most recent Linux Maintainers Summit organizer, with the chair of the Linux Foundation Technical Advisory Board (TAB) as an alternative. - That Organizer has **72 hours** to initiate discussion with the invitees of the most recent Maintainers Summit. - If more than **15 months** have passed since the last Maintainers Summit, the **TAB** determines the set of invitees. - The group may include additional maintainers if needed. - Within **two weeks**, a representative of the group communicates next steps to the wider community via **ks*****@*********ux.dev**. In other words: the clock is defined, the convener is defined, the “electoral college” is bounded to the people already carrying day-to-day technical responsibility, and public communication is required on a short timeline. The goal isn’t to pre-appoint a successor—it’s to avoid a vacuum and reduce uncertainty in a project on which millions of deployments depend. The approach also reveals a key idea: kernel continuity is not decided behind closed doors or through a mass vote, but within the core group that already bears the project’s operational weight. ## Why this matters to companies, cloud, and operations For an infrastructure provider—and especially for the European cloud ecosystem, where Linux is ubiquitous—the headline is not “Linus might retire tomorrow”. The headline is that the kernel treats as first-class something IT considers almost sacred: planning for critical failure modes. Business continuity is a relentless lesson: technical redundancy is not enough; you also need organisational redundancy. The Linux kernel is a textbook case of software becoming global public infrastructure. Once a project reaches that status, its governance must also be “operable” under adverse conditions. In systems terms: - If Linux underpins your workloads, you benefit from clear, documented procedures for unexpected scenarios. - If you run platforms at scale, you want the core of your stack to have continuity mechanisms—just like you demand within your own organisation. - If your business depends on stability and planning (kernel cycles, drivers, security, support), you don’t want the final integration point to be stuck in limbo due to the absence of a protocol. There’s also a broader reading: in a world where the software supply chain is under increasing scrutiny, trust doesn’t come only from code quality. It also comes from how a project governs itself when the hard days arrive. ## A quiet lesson: Linux scales in governance too Linux has long proven it can scale in lines of code, number of maintainers, and technical complexity. The continuity document adds another layer: the ability to scale organisationally. The community isn’t saying “this will happen”. It’s saying “if it happens, we won’t improvise”. That subtle difference is enormous—and it’s one of the signals that separates a brilliant project from a truly industrial one. In an industry where critical systems live on procedures (change management, review, audits, recovery, incident response), formalising a continuity plan is not bureaucracy. It’s maturity. ## Sysadmin quick take - **What changes:** a continuity procedure is documented to keep mainline moving if the canonical repository cannot be managed normally. - **Trigger:** lack of an orderly transition or an inability to facilitate one. - **Timelines:** 72 hours to start the process; 2 weeks to communicate next steps publicly. - **Governance:** driven by the Maintainers Summit invitee set and the Linux Foundation TAB, with Linux Foundation support. References: GitHub Linus y System Administration --- ## El kernel de Linux se prepara para el “día después” de Linus Torvalds URL: https://www.stackscale.com/blog/linux-kernel-prepares-for-day-after-linus-torvalds/ Durante más de tres décadas, el kernel de Linux ha crecido con una paradoja cómoda: un proyecto gigantesco, mantenido por cientos de personas repartidas por el mundo, pero con un último paso centralizado que, en la práctica, ha pasado por las manos de una figura casi única. Linus Torvalds no solo escribió las primeras líneas de código; también ha sido, desde 1991, el punto de integración del repositorio principal (mainline) que marca qué entra y qué no entra en el árbol oficial. Esa centralidad —tan eficiente como frágil— acaba de recibir una respuesta formal: el proyecto ha documentado un procedimiento de continuidad para el caso de que el repositorio “canónico” no pueda seguir avanzando con normalidad. No es una coronación de heredero, ni un plan de sucesión al uso. Es, literalmente, un “plan para activar un plan”: un mecanismo que solo se dispara si un día no hay transición ordenada o no es posible facilitarla. ## Linux: de “proyecto personal” a infraestructura crítica Cuesta recordarlo hoy, pero Linux empezó como un kernel pequeño, nacido en la era de los grupos de noticias y las listas de correo. Lo que vino después fue crecimiento orgánico: primero en universidades y entornos técnicos; luego como base de servidores, redes y supercomputación; y, más tarde, como cimiento indirecto del mundo móvil (Android) y del cloud. La consecuencia es muy tangible para cualquiera que opere sistemas: Linux no es “un sistema operativo más”. Es un estándar de facto en centros de datos, un ingrediente estructural en la cadena de suministro de software y una capa sobre la que se construyen servicios esenciales. Y cuando una pieza así depende, en su último paso, de un punto central, aparece el concepto que en gestión de riesgos se repite como un mantra: el **bus factor**. ## El bus factor del repositorio principal El desarrollo del kernel está distribuido: mantenedores por subsistemas, árboles intermedios, revisiones públicas, cultura de consenso técnico… Linux se ha convertido en una máquina social de ingeniería. Pero el “último merge” importa: es el filtro final de coherencia técnica y de rumbo. El nuevo documento lo explica sin dramatismos: el trabajo está muy repartido (habla de “más de 100 mantenedores”), pero la integración final en mainline es un paso centralizado que normalmente realiza Torvalds. Añade además un detalle importante: ya se ha demostrado que hay otras personas capaces de hacer ese trabajo cuando hace falta (menciona el caso de la 4.19 en 2018). La pregunta incómoda, por tanto, no es si falta talento. La pregunta es qué ocurre si, llegado el momento, no existe una transición “con guion” o si no es posible facilitarla sin fricción. ## Qué establece el procedimiento de continuidad El texto figura ya en la documentación oficial del kernel como “Linux kernel project continuity” (Documentation/process/conclave.rst).**Su lógica es deliberadamente simple, con plazos cortos y un canal público de comunicación: - Se designa un $ORGANIZER**: será la última persona que organizó el *Linux Maintainers Summit*; si no, actúa como respaldo el **chair del Linux Foundation Technical Advisory Board (TAB)**. - En un plazo de **72 horas**, el $ORGANIZER abre la discusión con los invitados del *Maintainers Summit* más reciente y se programa una reunión con ese grupo y el TAB, maximizando la participación. - Si no ha habido *Maintainers Summit* en **15 meses**, el **TAB** determina el conjunto de invitados. - Los invitados pueden sumar a otros mantenedores si lo consideran necesario. - En un plazo de **dos semanas**, un representante comunica a la comunidad los siguientes pasos usando la lista **ks*****@*********ux.dev**. - La **Linux Foundation**, guiada por el TAB, apoyará los pasos necesarios para implementar el plan. En otras palabras: se fija un reloj, se define quién convoca, se delimita un grupo de decisión vinculado al mantenimiento real del kernel, y se obliga a una comunicación pública en un plazo breve. No se nombra sucesor “en frío”; se evita el vacío. ## Por qué importa a empresas, cloud y operaciones Para un proveedor de infraestructura —y especialmente para el ecosistema cloud europeo, donde Linux es omnipresente— la noticia no es “si Linus se jubila mañana”. La noticia es otra: el kernel se toma en serio algo que en IT es casi religión, **planificar el fallo de lo crítico**. En continuidad de negocio se repite hasta la saciedad que no basta con redundancia técnica; hace falta redundancia organizativa. Si tu plataforma vive sobre Linux, te interesa que su gobernanza también sea “operable” cuando el escenario se tuerce. Traducido al lenguaje de sistemas: - Si Linux es base de tus cargas, te interesa que su desarrollo tenga procedimientos claros ante imprevistos. - Si gestionas plataformas a escala, te interesa que el “punto de integración final” no quede en un limbo por falta de protocolo. - Si dependes de planificación (ciclos de kernel, drivers, seguridad, soporte), te interesa que exista un mecanismo de continuidad con plazos y canal de comunicación definidos. Y hay una lectura adicional: en un mundo donde la cadena de suministro de software está bajo lupa, la confianza no viene solo del código; también viene de cómo responde el proyecto cuando llegan los días difíciles. ## Una lección silenciosa: Linux también escala en gobernanza Linux lleva años demostrando que puede escalar en líneas de código, en número de mantenedores y en complejidad técnica. Este documento añade otra capa: la capacidad de escalar en organización. La comunidad no está diciendo “esto va a pasar”. Está diciendo “si pasa, no improvisamos”. Esa diferencia —sutil, pero enorme— separa un proyecto brillante de un proyecto verdaderamente industrial. Y en un sector donde los sistemas críticos viven de procedimientos (cambios, revisiones, auditorías, respuesta a incidentes, recuperación), que el kernel de Linux formalice su plan de continuidad no es un detalle burocrático: es una señal de madurez. ## Resumen técnico para administradores de sistemas - **Qué cambia:** se documenta un “plan de continuidad” para mantener el avance de mainline si el repositorio canónico no puede gestionarse con normalidad. - **Disparador:** ausencia de transición ordenada o imposibilidad de facilitarla. - **Plazos:** 72 horas para abrir el proceso; 2 semanas para comunicar siguientes pasos. - **Gobernanza:** la coordinación recae en el entorno del Maintainers Summit + TAB, con apoyo de Linux Foundation. Referencias: GitHub Linus y Administración de Sistemas --- ## Let’s Encrypt abre la puerta al HTTPS por IP: certificados para IPv4 e IPv6 con caducidad de 160 horas URL: https://www.stackscale.com/blog/lets-encrypt-opens-the-door-to-https-by-ip/ Durante años, el cifrado web se ha apoyado en una regla tácita: si un servicio quiere HTTPS, necesita un nombre de dominio. Tiene lógica (las personas navegan por nombres, no por números), pero también es una herencia técnica del ecosistema TLS, donde la validación se diseñó pensando en DNS. Esa regla empieza a romperse. Desde el **15 de enero de 2026**, Let’s Encrypt ofrece **disponibilidad general** de certificados TLS **para direcciones IP** (IPv4 e IPv6), con una particularidad clave: **caducan a las 160 horas**, es decir, algo más de seis días. ## Certificados TLS para IP: qué son y por qué cambian el juego Un certificado TLS “clásico” valida que el servidor al que se conecta el cliente es legítimo para un **nombre** (FQDN), usando el campo SAN (Subject Alternative Name). La novedad es que ahora el identificador que se valida puede ser directamente **una dirección IP**. En la práctica, esto elimina un problema habitual en administración de sistemas: acceder por IP a un servicio HTTPS (paneles temporales, consolas de administración, endpoints de prueba, servicios de infraestructura) sin caer en certificados autofirmados, avisos del navegador o excepciones de seguridad que se eternizan. ## 160 horas de validez: la condición que lo hace viable (y más seguro) Let’s Encrypt ha vinculado los certificados de IP a un modelo de **vida ultracorta**: 160 horas. La lógica es directa: **las IP son más “transitorias” que los dominios** (reasignaciones, cambios de proveedor, despliegues efímeros), y un certificado “largo” asociado a una IP que ya no controlas sería un riesgo innecesario. Además, este enfoque encaja con una tendencia más amplia: reducir la “ventana de exposición” si una clave privada se filtra o se compromete. En su anuncio, Let’s Encrypt insiste en que la revocación histórica es imperfecta, y que **la caducidad rápida reduce la dependencia de esos mecanismos**. ## ACME Profiles: la pieza que obliga a automatizar (de verdad) La emisión de estos certificados se apoya en **perfiles (ACME Profiles)**. Para obtener un certificado de vida corta hay que seleccionar explícitamente el perfil **shortlived** en el cliente ACME. Esto tiene dos implicaciones prácticas: - No todos los clientes ACME lo soportan todavía. - La operativa manual deja de ser una opción realista: con certificados de ~6 días, el proceso debe ser 100 % automático. Let’s Encrypt, además, deja claro que los certificados de vida corta son **opt-in** y que no planean convertirlos en el valor por defecto “por ahora”; pero sí confirman su hoja de ruta para reducir validez estándar **de 90 a 45 días** durante los próximos años. ## Validación: por qué DNS-01 no aplica y qué métodos quedan En certificados por IP hay una limitación lógica: **no puedes demostrar control de una IP mediante DNS**, porque DNS no es el identificador primario del certificado. Por eso, Let’s Encrypt restringe la validación a: - **http-01** - **tls-alpn-01** Y deja fuera **dns-01**. Además, no existe un mecanismo equivalente para comprobar **CAA** en IPs (CAA se define por dominio). ## Casos de uso donde sí encaja (y donde no) La clave es entender que esto no sustituye a los certificados por dominio: amplía el abanico para escenarios donde DNS es un estorbo o directamente no existe. ### Encaja especialmente bien en: - **Homelabs y laboratorios** con servicios expuestos puntualmente. - **Entornos de pruebas** y front-ends temporales. - **Consolas de administración** o endpoints internos con exposición controlada. - **Servicios de infraestructura** que hablan HTTPS como transporte (por ejemplo, ciertos despliegues de DoH u otros endpoints técnicos donde el cliente valida por IP). - **Despliegues efímeros en cloud** donde se provisionan IPs públicas por tiempo limitado. ### Suele ser mala idea en: - Servicios estables con balanceo, multirregión o cambios de hosting frecuentes (ahí DNS sigue siendo la capa correcta). - Sistemas donde no puedas garantizar renovación + despliegue automático + monitorización. ## Tabla comparativa: certificado “clásico” vs vida corta vs IP Tipo de certificadoIdentificadorValidezCómo se solicitaCuándo encajaClásicoDominio (DNS)90 díasEmisión estándar ACMEWeb pública, servicios establesVida corta (dominio)Dominio (DNS)160 horasPerfil shortlivedOperaciones con rotación agresiva y automatización maduraVida corta (IP)IP (IPv4/IPv6)160 horasIP + perfil shortlivedAcceso por IP, infra efímera, homelab, pruebas ## Checklist operativo: lo mínimo para no convertirlo en una fuente de incidencias Con certificados de 160 horas, la pregunta no es “¿cómo lo emito?”, sino “¿cómo lo opero sin sorpresas?”. En entornos profesionales, el checklist mínimo debería incluir: - **Renovación programada con margen**, no “al límite”. - **Despliegue automático** del certificado renovado (y recarga controlada del servicio). - **Validación externa** (healthcheck) del endpoint HTTPS, no solo logs locales. - **Alertas proactivas** si falla la renovación o si el certificado baja de X horas de vida. - **Rollback sencillo** al certificado anterior si el despliegue rompe TLS. - **Inventario y caducidad centralizada** si hay múltiples endpoints (evitar “islas” de certificados). En infraestructuras donde se gestionan muchos servicios —y especialmente en escenarios multi-entorno—, esta disciplina se parece más a la rotación de secretos que a la gestión tradicional de certificados. ## Un cambio pequeño en apariencia, grande en implicaciones Que Let’s Encrypt (por volumen, impacto y coste) normalice los certificados por IP manda un mensaje claro: **HTTPS deja de ser “algo de dominios” y se convierte aún más en un transporte seguro por defecto**, incluso cuando la capa DNS no participa. Para administradores de sistemas, el beneficio es inmediato: menos excepciones inseguras y más opciones para exponer servicios de forma limpia. Para el ecosistema, el cambio es cultural: el futuro del TLS se parece menos a “instalo un certificado y me olvido” y más a “mi infraestructura rota certificados como un proceso rutinario y monitorizado”. ## Preguntas frecuentes ### ¿Para qué sirve un certificado TLS para una IP si ya puedo usar un dominio dinámico? Para entornos donde no quieres depender de DNS (o no puedes): laboratorios, pruebas, endpoints efímeros o accesos directos por IP. La ventaja es evitar excepciones de seguridad y certificados autofirmados cuando el cliente llega por IP. ### ¿Por qué Let’s Encrypt limita estos certificados a 160 horas? Porque la asignación de IPs puede cambiar con rapidez y un certificado “largo” podría seguir siendo válido cuando el solicitante ya no controla esa IP. El ciclo corto reduce ese riesgo y acorta la ventana de exposición ante claves comprometidas. ### ¿Qué necesito para emitir certificados de vida corta o por IP con Let’s Encrypt? Un cliente ACME que soporte **selección de perfiles** y la capacidad de solicitar el perfil **shortlived**. ### ¿Qué método de validación se puede usar con certificados por IP? Let’s Encrypt restringe la validación a **http-01** y **tls-alpn-01**; **dns-01 no aplica** para IPs. Fuente: Let’s Encrypt abre la puerta al HTTPS por IP --- ## Let’s Encrypt Opens the Door to HTTPS by IP: IPv4 and IPv6 Certificates With a 160-Hour Lifetime URL: https://www.stackscale.com/blog/lets-encrypt-opens-the-door-to-https-by-ip/ For years, web encryption has relied on a basic assumption: if a service wants HTTPS, it needs a domain name. That’s practical—people browse names, not numbers—but also historical: certificate validation and lifecycle management were designed around DNS. That rule has started to change. As of **January 15, 2026**, Let’s Encrypt has announced **general availability** of **TLS certificates for IP addresses**, a development that makes it possible to secure HTTPS connections directly over **IPv4 or IPv6** without relying on a domain. This is particularly relevant for homelabs, temporary infrastructure, test environments, “base” network services, and scenarios where a domain does not fit (or does not exist). ## What an “IP Certificate” Means—and Why It Matters Now A traditional TLS certificate includes domain names in the SAN (Subject Alternative Name) field so that a browser or client can verify that the server it is connecting to is who it claims to be. With this new option, the certificate identifier can be an **IP address**: the client validates the encrypted channel against that IP, not against an FQDN. In practice, this solves a very common problem: accessing an HTTPS service by IP—say, an admin console, a temporary panel, a test front-end, or an internal service exposed briefly—without browser warnings, self-signed certificates, or permanent security exceptions. Let’s Encrypt acknowledges that this will not be “for everyone.” Their own view is that most services will continue to work better with domain-based certificates, due to flexibility (hosting changes, load balancing, multi-site deployments) and usage habits. But for the cases where HTTPS by IP is genuinely needed, general availability removes a barrier that has slowed administrators and developers for years. ## The Trade-Off: Ultra-Short 160-Hour Certificates The key condition for IP certificates is their **mandatory short lifetime**: **160 hours**, a little over six days. Let’s Encrypt chose this approach for a straightforward reason: IP addresses can change hands quickly, especially with residential connections or ephemeral deployments. Keeping a “long-lived” certificate tied to an IP that the requester no longer controls would create avoidable risk. This aligns with the broader industry trend toward shortening exposure windows in the event of key theft or mis-issuance, and leaning on automation so rotation becomes routine. Let’s Encrypt explicitly positions the 160-hour certificates as part of its strategy to move the ecosystem toward shorter lifecycles. ## How Issuance Works: ACME Profiles and Validation Challenges To obtain IP certificates, Let’s Encrypt requires an ACME client that supports **ACME Profiles**, and the requester must explicitly select the **shortlived** profile (the short-lived one). The design prioritizes automation and leaves less room for “manual” setups that tend to be forgotten over time. There are also sensible technical constraints: you cannot use **DNS-01** to prove control of an IP address (there is no DNS record that proves ownership of the address as the primary identifier), so validation is restricted to **http-01** and **tls-alpn-01**. In practical terms, the server must demonstrate real control over the endpoint reachable at that IP to pass the challenge. ## Real-World Use Cases: From Homelabs to Critical Infrastructure Services Let’s Encrypt lists several scenarios where these certificates make sense, and the common pattern is clear: environments where a domain is a luxury, an extra cost, or simply unnecessary for the technical goal. Typical examples include: - Secure access to services without a domain, accepting that this is less convenient and more fragile than DNS-based setups. - Default hosting provider pages—when someone pastes an IP into a browser and the service wants to respond over HTTPS without errors. - Infrastructure services such as DNS over HTTPS (DoH) or other endpoints where a public certificate helps client validation. - Remote access to home devices (NAS, IoT, lab equipment) when there is no associated domain. - Ephemeral connections inside cloud infrastructure, including administration or temporary services—provided there is a public IP available. The underlying point is that the internet is not only “web pages”: more and more services use HTTPS as a secure transport, even if the end user never sees a friendly name in the browser bar. ## Quick Table: What Changes With Short-Lived Certificates Certificate typeIdentifierValidityProfile / approachBest fit“Classic” certificateDomain (DNS)90 daysStandard automated renewalPublic web, stable services, hybrid infrastructurePlanned short-lived (domain)Domain (DNS)45 daysOpt-in and gradual transitionTeams that want more frequent rotationUltra-shortDomain or IP160 hoursshortlived profile (ACME Profiles)Homelabs, ephemeral environments, direct IP access, testing ## A Note for Sysadmins: Without Automation, This Isn’t Viable The downside of 160-hour certificates is obvious: renewing every few days is not realistic without a solid automation and monitoring chain. At a minimum, that means: - scheduled renewals with sufficient margin, - automated deployment of the new certificate, - alerts if renewal fails, - and recurring tests (for example, verifying externally if the endpoint is public). Let’s Encrypt does not hide that this is the direction it wants the market to move toward. Their roadmap points to progressively reducing the default validity period—from 90 to 45 days—starting with opt-in adoption and supported by ecosystem improvements to make renewal more predictable. ## A Small Change on the Surface, With Big Implications A free, high-volume CA like Let’s Encrypt issuing certificates for IP addresses has impact beyond the novelty. In practice, it normalizes a pattern: encrypt by default even when there is no DNS, using a trust model based on rapid rotation. For advanced users, the result is immediate: more options to build and expose services without insecure shortcuts. For the broader ecosystem, the message is deeper: the future of TLS looks less like “install a cert and forget it,” and more like “my infrastructure renews certificates the same way it rotates secrets.” ## Frequently Asked Questions ### What’s the point of a TLS certificate for an IP if I can use dynamic DNS? It’s useful in environments where you don’t want—or can’t—depend on DNS: labs, testing, ephemeral endpoints, infrastructure services, or direct IP access. With a valid public certificate, clients can verify HTTPS without security exceptions. ### Why does Let’s Encrypt cap these certificates at 160 hours? Because IP “ownership” can change quickly (dynamic IPs, reassignment, temporary infrastructure). A short window reduces the risk of a certificate remaining valid after the requester no longer controls that IP. ### What do I need to issue an IP certificate with Let’s Encrypt? An ACME client compatible with **ACME Profiles** and an explicit request for the **shortlived** profile. Also, validation cannot be done with DNS-01; you must use methods such as **http-01** or **tls-alpn-01**, depending on the deployment. ### How should homelabs or dev environments operate such short-lived certificates? With full automation: renewals with margin, automated deployment, alerts, and continuous verification. If the process depends on manual steps, expirations and service interruptions become likely. Source: Let’s Encrypt Opens the Door to HTTPS by IP --- ## Proxmox in 2025: the definitive leap from “alternative” to standard — and how Stackscale speeds up the migration URL: https://www.stackscale.com/blog/proxmox-in-2025/ For years, **Proxmox Virtual Environment (Proxmox VE)** lived in a kind of “in-between land”: too powerful to be dismissed as a lab tool, yet still lacking the commercial gravity of the biggest names in virtualization. In 2025, that balance has broken. **This open-source platform has solidified as a real — and in many cases preferred — option for companies looking to reduce dependence on complex licensing**, unify virtualization and containers, and keep control of their infrastructure. ## Table of contents - From a niche project to global adoption - What changed: why Proxmox fits better in 2025 - Migrating from VMware: less drama, more engineering - Proxmox + Stackscale: a proposal focused on what happens after the migration - On-premises to Proxmox: modernize without giving up control - The 2025 effect: Proxmox isn’t explained anymore — it’s compared - Frequently asked questions The conversation no longer revolves only around price. In the day-to-day work of infrastructure teams, the question is more practical: “Can we migrate with minimal friction, operate with real guarantees, and get serious support?” That’s where Proxmox has been closing the loop: technical maturity, a large community, a growing partner ecosystem, and a consistent roadmap. And with Stackscale, you also get access to specialized, close-to-the-customer support. ## From a niche project to global adoption In terms of deployment, Proxmox has been growing for a while — but the number that best captures its maturity is scale. Proxmox Server Solutions places the platform at more than **1,500,000 installed hosts** and presence in **140+ countries**. That data point alone dismantles the “minority solution” narrative and reflects sustained adoption in production environments. In parallel, industry media and players have highlighted a symbolic milestone: **2025 marks 20 years of project development** — a rare track record for infrastructure tools that not only survive, but improve their value proposition year after year. That anniversary also arrives at a particularly favorable market moment: many organizations have revisited their strategy after shifts in the VMware ecosystem and a rising sensitivity to technology sovereignty. ## What changed: why Proxmox fits better in 2025 The short version is familiar: Proxmox combines KVM virtualization, LXC containers, cluster management, high availability, integrated storage (ZFS/Ceph), connectivity with network storage solutions, and an API ready for automation. But the real impact shows up when you overlay it with today’s operational pressure: - **Standardization and simplification:** a single console for VMs, containers, networking, storage, and roles. - **Automation:** natural integration with IaC tools and pipelines — critical when infrastructure teams can’t “click” their way through everything. - **Hybrid architectures:** Proxmox doesn’t force you into “all on-prem” or “all cloud”; it supports an in-between path. - **A culture of control:** the open-source model encourages auditing, understanding, and deciding — instead of accepting black boxes. This shift is also reflected in market surveys: in 2025, PeerSpot places Proxmox VE at **16.1% mindshare** in the server virtualization segment — a meaningful indicator of visibility and consideration among professionals comparing solutions. ## Migrating from VMware: less drama, more engineering The critical point isn’t “does Proxmox work?” — it’s “how do you get there?” VMware-to-Proxmox migrations often fail when they’re treated as a simple VM move. In reality, the dependencies that matter more than the VM itself are: networks, storage, backups, maintenance windows, compliance, observability, team procedures, and above all, the rollback plan. In this context, Stackscale keeps pushing a realistic approach: turn migration into a controlled project, with clear phases, testing, and validation — instead of a weekend sprint. In its Proxmox VE migration guide, the company frames the move as an “efficient and secure” alternative for organizations that need to move forward without getting trapped by third-party decisions. The key is to break the journey into three layers: ### 1) Platform layer Define the destination: a Proxmox cluster with network design; shared storage or synchronous storage or Ceph; HA; segmentation; and roles. Here you decide whether the goal is a private cloud, a hybrid model, or a “transitional Proxmox” setup to exit VMware first and consolidate later. ### 2) Data and continuity layer Before moving workloads, you protect what can’t be lost: backup policies, retention, encryption, restore testing, and — where relevant — a multi-datacenter strategy. ### 3) Workload layer Batch-based migration: start with less critical systems, then core services, and finally the most delicate dependencies (databases, hardware-tied licenses, apps with specific drivers, or virtual appliances). ## Proxmox + Stackscale: a proposal focused on what happens *after* the migration A migration promise is worthless if day-two operations become painful. That’s why Stackscale’s approach is built around two ideas: production-ready infrastructure and continuity mechanisms. A clear example is backups. In its content on Proxmox Backup Server (PBS), Stackscale presents PBS as a structural component in Proxmox environments running mission-critical workloads: incremental backups, deduplication, encryption, and fast restores — with the ability to integrate with “Archive”-type storage and multi-location designs (for example, between Madrid and Amsterdam) to reinforce strategies like 3-2-1. That point — backups as part of the design, not an add-on — often makes the difference between a migration that merely “works” and a platform that’s sustainable. Week one, everything boots. The first real incident? Only the teams that tested recovery beforehand make it through cleanly. ## On-premises to Proxmox: modernize without giving up control Beyond VMware, 2025 is accelerating another shift: companies running heterogeneous on-prem environments (mixed hypervisors, NAS without governance, manual processes) want a unified management layer without losing control over data and latency. Proxmox fits especially well here because it enables you to: - Consolidate virtualization and containers under a single control plane. - Design HA with clustering and move workloads with more flexibility. - Build mission-critical infrastructure more consistently. - Professionalize backups and replication. - Prepare for a hybrid jump (without rewriting everything) when the business demands it. The takeaway is simple: rather than treating “move to the cloud” as a dogma, many organizations are choosing to get their house in order with a properly built private cloud — and then connect only what they need. ## The 2025 effect: Proxmox isn’t explained anymore — it’s compared The clearest sign of maturity is that Proxmox is no longer defended with ideological arguments (“open source is better”), but with operational comparisons: total cost, deployment speed, ease of automation, support, resilience, and reversibility. In a market where licensing changes have strained budgets and IT roadmaps, that comparison has become routine. And that’s where Proxmox is gaining ground: it enters the conversation with two strong cards — solid technology and a control-first narrative — right when many organizations are tired of depending on other people’s decisions. ## Frequently asked questions **What typical risks show up when migrating from VMware to Proxmox VE, and how can they be reduced?****The most common ones are isolated incompatibilities, poorly documented network/storage dependencies, and lack of restore testing. You reduce them with a phased pilot, a real workload inventory, and a rollback plan. Can Proxmox VE be used as the foundation of an enterprise private cloud?****Yes — especially when it’s designed with clustering, high availability, network segmentation, role-based access control, and verified backup/retention policies. What does Proxmox Backup Server add compared to “traditional backups” in Proxmox?****PBS is built for Proxmox: incremental backups, deduplication, encryption, and fast restores with tight ecosystem integration — simplifying operations and improving recovery times. Which strategy is better: migrate to Proxmox first and redesign later, or redesign before migrating?**It depends on the timeline. In many cases, a controlled migration (an orderly exit) followed by step-by-step optimization works better, so the project doesn’t turn into an endless “big migration.” Source: Cloud News Tech --- ## Proxmox en 2025: el salto definitivo del “alternativo” al estándar, y cómo Stackscale acelera la migración desde VMware y on-premise URL: https://www.stackscale.com/blog/proxmox-in-2025/ Durante años, **Proxmox Virtual Environment (Proxmox VE)** vivió en una especie de “tierra intermedia”: demasiado potente para encasillarlo como herramienta de laboratorio, pero aún sin el peso comercial de los grandes nombres de la virtualización. En 2025, ese equilibrio se ha roto. **La plataforma open source se ha consolidado como una alternativa real** —y en muchos casos prioritaria— para empresas que buscan reducir dependencia de licencias complejas, unificar virtualización y contenedores, y mantener el control sobre su infraestructura. ## Tabla de contenidos - De proyecto de nicho a adopción global - Qué ha cambiado: por qué Proxmox encaja mejor en 2025 - La migración desde VMware: menos épica, más ingeniería - Proxmox + Stackscale: una propuesta centrada en el “después” de migrar - On-premise a Proxmox: modernizar sin renunciar al control - El efecto 2025: Proxmox ya no se explica, se compara - Preguntas frecuentes La conversación ya no gira solo alrededor del precio. En el día a día de los equipos de sistemas, la pregunta es más práctica: “¿Podemos migrar sin fricciones, operar con garantías y tener soporte serio?”. Y ahí es donde Proxmox ha ido cerrando el círculo: madurez tecnológica, comunidad grande, ecosistema de partners y una hoja de ruta consistente. Además con el apoyo de Stackscale tendrás acceso a un soporte especilizado y cercano. ## De proyecto de nicho a adopción global En términos de implantación, Proxmox lleva tiempo creciendo, pero la cifra que mejor retrata su madurez es la escala: la propia Proxmox Server Solutions sitúa la plataforma en **más de 1.500.000 de hosts instalados** y presencia en más de **140 países**. Ese dato, por sí solo, desmonta la idea de “solución minoritaria” y refleja una adopción sostenida en entornos productivos. En paralelo, medios y actores del sector vienen destacando un hito simbólico: **2025 marca los 20 años de desarrollo** del proyecto, un recorrido poco habitual en herramientas de infraestructura que no solo sobreviven, sino que mejoran su propuesta año tras año. Ese aniversario coincide con un momento de mercado especialmente propicio: muchas organizaciones han revisado su estrategia tras los cambios en el ecosistema VMware y el aumento de la sensibilidad hacia la soberanía tecnológica. ## Qué ha cambiado: por qué Proxmox encaja mejor en 2025 La explicación corta es conocida: Proxmox combina **virtualización KVM**, **contenedores LXC**, **gestión de clúster**, **alta disponibilidad**, almacenamiento integrado (ZFS/Ceph), conexión con soluciones de almacenamiento en red y una **API** lista para automatizar. Pero el impacto real aparece cuando se cruza con la presión operativa actual: - **Estandarización y simplificación**: una sola consola para VMs, contenedores, red, almacenamiento y roles. - **Automatización**: integración natural con herramientas de IaC y pipelines, algo clave cuando el equipo de sistemas no puede “hacer clic” para todo. - **Arquitecturas híbridas**: Proxmox no te obliga a elegir entre “todo on-premise” o “todo cloud”; permite construir un camino intermedio. - **Cultura de control**: el modelo open source favorece auditar, entender y decidir, en vez de aceptar cajas negras. Este cambio de mentalidad se ve también en encuestas del mercado: en 2025, PeerSpot sitúa a Proxmox VE con una **mindshare del 16,1%** en el segmento de virtualización de servidores, un indicador relevante de visibilidad y consideración entre profesionales que comparan soluciones. ## La migración desde VMware: menos épica, más ingeniería El punto crítico no es “si Proxmox sirve”, sino “cómo se llega”. La migración desde VMware suele fallar cuando se plantea como un simple traslado de máquinas. En la práctica, hay dependencias que pesan más que la VM: redes, storage, backups, ventanas de parada, cumplimiento, observabilidad, procedimientos del equipo y, sobre todo, el plan de vuelta atrás. En este contexto, **Stackscale viene insistiendo en un enfoque realista: convertir la migración en un proyecto controlado, con fases claras, pruebas y validación, en lugar de una carrera de fin de semana. **En su guía de migración a Proxmox VE, la compañía presenta el cambio como una alternativa “eficiente y segura” para organizaciones que necesitan avanzar sin quedarse bloqueadas por decisiones de terceros. La clave es separar el viaje en tres capas: - **Capa de plataforma****Definir el destino: clúster Proxmox con diseño de red, almacenamiento en red o síncrono o Ceph, HA, segmentación y roles. Aquí se decide si el objetivo es un cloud privado**, un **modelo híbrido** o un Proxmox “de transición” para salir de VMware y consolidar después. - **Capa de datos y continuidad****Antes de mover cargas, se asegura lo que no se puede perder: políticas de backup, retención, cifrado, pruebas de restauración y, si aplica, estrategia multi-CPD. - Capa de workloads****Migración por lotes: primero sistemas menos críticos, luego servicios core, y por último las dependencias más delicadas (bases de datos, licencias ligadas a hardware, aplicaciones con drivers específicos o appliances virtuales). ## Proxmox + Stackscale: una propuesta centrada en el “después” de migrar La promesa de una migración no vale nada si la operación posterior se complica. Por eso, el enfoque de Stackscale se apoya en dos ideas: infraestructura lista para producción** y **mecanismos de continuidad**. proxmox estadisticas form Newsletter ### No sabes por donde empezar…**escríbenos y te contamos más sobre como migrar a Proxmox. NombreEmpresaCorreo electrónicoNúmero de teléfonoProvinciacomunicaciones Acepto el envío de comunicaciones comerciales personalizadas sobre los productos y servicios de Stackscale (incluida la newsletter), por cualquier medio, incluidos los electrónicos.aviso He leído y acepto la Política de Privacidad y autorizo el tratamiento de mis datos.Enviar para saber más de migración a Proxmox Un ejemplo claro es el backup. En su contenido sobre Proxmox Backup Server (PBS)**, Stackscale lo presenta como un componente estructural en entornos Proxmox con cargas de misión crítica: copias incrementales, deduplicación, cifrado y restauraciones rápidas, con capacidad de integrarse con almacenamiento tipo “Archive” y planteamientos multiubicación (por ejemplo, entre Madrid y Ámsterdam) para reforzar estrategias como 3-2-1. Ese punto —el backup como diseño, no como accesorio— suele marcar la diferencia entre una migración “que funciona” y una plataforma sostenible: la primera semana todo arranca; el primer incidente real, solo sobrevive quien lo probó antes. ## On-premise a Proxmox: modernizar sin renunciar al control Más allá de VMware, 2025 también está acelerando otro movimiento: empresas que operaban on-premise con entornos heterogéneos (hipervisores mezclados, NAS sin gobernanza, procesos manuales) están buscando una capa de gestión unificada sin perder control sobre datos y latencia. Aquí Proxmox encaja especialmente bien porque permite: - Consolidar virtualización y contenedores bajo un mismo plano. - Diseñar HA con clúster y mover cargas con mayor flexibilidad. - Infraestructuras de misión crítica. - Profesionalizar backups y replicación. - Preparar un salto a híbrido (sin reescribirlo todo) cuando el negocio lo exija. La lectura es sencilla: en vez de “pasarse al cloud” como dogma, muchas organizaciones están eligiendo **reordenar su casa** con un cloud privado bien montado, y conectar después lo necesario. ## El efecto 2025: Proxmox ya no se explica, se compara La señal más clara de madurez es que Proxmox ya no se defiende con argumentos ideológicos (“open source es mejor”), sino con comparativas operativas: coste total, velocidad de despliegue, facilidad de automatización, soporte, resiliencia y reversibilidad. En un mercado donde los cambios de licenciamiento han tensionado presupuestos y planes de TI, esa comparación se ha vuelto cotidiana. Y ahí Proxmox está ganando terreno: porque llega a la conversación con dos cartas fuertes —tecnología sólida y narrativa de control— justo cuando muchas organizaciones están cansadas de depender de decisiones ajenas. ## Preguntas frecuentes **¿Qué riesgos típicos aparecen al migrar de VMware a Proxmox VE y cómo se reducen?****Los más habituales son incompatibilidades puntuales, dependencias de red/almacenamiento mal documentadas y falta de pruebas de restauración. Se reducen con un piloto por fases, inventario real de cargas y un plan de rollback. ¿Se puede usar Proxmox VE como base de un cloud privado para entornos empresariales?****Sí, especialmente cuando se diseña con clúster, alta disponibilidad, segmentación de red, control de acceso por roles y políticas de backup/retención verificadas. ¿Qué aporta Proxmox Backup Server frente a “backups tradicionales” en Proxmox?****PBS está pensado para Proxmox: copias incrementales, deduplicación, cifrado y restauraciones rápidas con integración directa en el ecosistema, lo que simplifica operación y tiempos de recuperación. ¿Qué estrategia es mejor: migrar primero a Proxmox y luego rediseñar, o rediseñar antes de migrar?**Depende del plazo. En muchos casos funciona mejor una migración controlada (salida ordenada) seguida de optimización por etapas, para no convertir el proyecto en una “gran migración” interminable. Fuentes: Revista Cloud (visión y datos de adopción de Proxmox en 2025, contexto de crecimiento) --- ## Proxmox Backup Server: enterprise-grade backups for Proxmox environments on Stackscale URL: https://www.stackscale.com/blog/proxmox-backup-server-enterprise/ In any modern infrastructure, backups are no longer a “nice to have”, but a structural component on the same level as storage or networking. When you work with Proxmox VE clusters, HA solutions, and mission-critical workloads, having a backup solution designed specifically for this ecosystem is what makes the difference between a fast recovery and a long, expensive outage. That’s where **Proxmox Backup Server (PBS)** comes in: an enterprise backup solution, 100% open source, designed to protect virtual machines, containers, and physical hosts with incremental, deduplicated, encrypted backups, tightly integrated with Proxmox VE. ## Table of contents - What is Proxmox Backup Server? - Architecture and how it works - Proxmox Backup Server on Stackscale infrastructure - Example architectures with PBS and Archive on Stackscale - Best practices when designing the solution - Quick summary for administrators On **Stackscale** infrastructure, Proxmox Backup Server can be combined with **Archive storage** (via NFS or S3-compatible access), available in two separate data center locations in **Madrid** and **Amsterdam**, to build robust, multi–data center backup strategies aligned with the 3-2-1 model. It can also be complemented with remote storage on other providers to add extra backup copies and data resilience. ## What is Proxmox Backup Server? Proxmox Backup Server is a Linux distribution focused specifically on backup, based on Debian with native ZFS support, written primarily in Rust and licensed under **GNU AGPLv3**. Its goal is to offer an open alternative to proprietary backup solutions, without limiting the number of machines or the amount of protected data. Key features include: - Incremental, deduplicated backups for VMs, containers, and physical hosts. - High-performance **Zstandard compression**. - **Client-side authenticated encryption (AES-256-GCM)**, so data travels and is stored encrypted even on targets that are not fully trusted. - Integrity verification using checksums and schedulable verification jobs. - Native integration with **Proxmox VE**, including support for QEMU dirty bitmaps for fast incremental backups. - Support for **tape (LTO)** and **S3-compatible storage** as data backends. **Proxmox Backup Server 4.1**, released in November 2025, is based on Debian 13.2 “Trixie”, uses the Linux 6.17.2-1 kernel as the new default, and ZFS 2.3.4. It introduces important improvements in traffic control, verification, and S3-based storage usage. ## Architecture and how it works ### Client–server model and namespaces PBS follows a **client–server model**: one or more backup servers store the data, while clients (including Proxmox VE) send backups incrementally over TLS 1.3. Backups are organized into **datastores** and **namespaces**, which makes it possible to separate environments (for example, production, preproduction, or different clusters) while maintaining effective deduplication. Thanks to deduplication and incremental backups, only the blocks that have changed since the last backup are transferred and stored, drastically reducing network and storage consumption. ### Integration with Proxmox VE In Proxmox VE, you only need to **add a PBS datastore as a new backup storage** to start using it for VMs and containers. From the Proxmox interface itself you define backup jobs (full, incremental, scheduling, retention) targeting the PBS datastore. PBS also allows you to restore: - Full VMs (with **live restore** support in many cases). - Full containers. - Individual files from VM or container backups, directly from the GUI or an interactive shell. ### Security, integrity, and ransomware protection Security is one of the core pillars of Proxmox Backup Server: - **Client-side encryption** with AES-256-GCM, so the backup server cannot read the data without the corresponding keys. - **SHA-256 checksums** to verify the integrity of all stored blocks. - **Schedulable verification jobs** to detect bit rot or corruption. - A granular **role-based access control (RBAC)** model with roles, API tokens, integration with LDAP, Active Directory, and OpenID Connect, plus 2FA support. Starting with version 4.1, PBS also adds **user-based traffic control** and **bandwidth limiting for S3 endpoints**, which helps prevent network congestion when running heavy backup or restore operations to object storage. All of this makes Proxmox Backup Server a very solid component in a broader strategy for defending against ransomware and large-scale infrastructure failures. ## Proxmox Backup Server on Stackscale infrastructure On Stackscale, Proxmox Backup Server can be integrated with different types of storage, but the recommended design is always that the **primary backup copy lives on Archive storage**, isolated and redundant, and then faster layers are added if you need to accelerate recovery. The general pattern looks like this: - **Reference copy (golden copy):** always on **Stackscale Archive storage**, accessible via NFS or S3-compatible API, and available across **three separate physical locations** (2 data centers in Madrid and 1 in Amsterdam). - **Optional performance layers:** additional copies on **faster network storage from Stackscale (All-Flash)** to speed up frequent restores. - **Local disk storage on the backup server:** possible, but with clear limitations: access to the backups depends on that specific physical server, and this layer does not provide redundancy. ### Archive storage as the primary backend for Proxmox Backup Server Stackscale’s **Archive storage** should be the **reference backend** for Proxmox Backup Server, ensuring that no matter what happens to hosts or clusters, there is always a consistent, recoverable copy in a separate environment: - **Archive mounted via NFS** PBS sees Archive as just another datastore exported via NFS. - Ideal for large backup volumes over the network, while keeping PBS’s own deduplication and compression. - Recommended as the **primary destination** for medium- and long-term retention. - **Archive via S3-compatible access** Archive can be exposed as an S3 bucket and configured in PBS as a remote target. - This allows you to leverage Proxmox Backup Server’s object storage capabilities (including bandwidth limiting and multi–data center scenarios). - Especially suitable for **long-term backups** and **disaster recovery plans**. In both cases, Archive is available in **two regions**: - **2 data centers in Madrid.** - **1 data center in Amsterdam.** This makes it easy to design **multi–data center strategies**: for example, keeping primary backups in Archive Madrid and periodically syncing them to Archive Amsterdam using PBS remote sync jobs. ### Fast network storage as an accelerated recovery layer On top of Archive, customers can add a **faster network storage layer** from Stackscale (All-Flash) to: - Store the most recent backups (for example, from the last few days). - Speed up frequent restores or recovery tests. - Reduce RTO for services that are extremely sensitive to downtime. In this model, **Archive remains the single source of truth**, and the network storage acts as a **hot cache** for the most common restores. ### Local disk: a situational option, but use with care Local storage on the Proxmox Backup Server host itself can still be used in some scenarios (for example, as an initial backup buffer), but it comes with several drawbacks: - Access to the backups depends on the health of that **specific physical server**. - There is no intrinsic redundancy at this layer unless data is replicated to Archive or network storage. - In the event of a serious host or local storage failure, the most valuable backup layer could be lost. That’s why, in professional architectures on Stackscale, the recommended approach is: - **Stackscale Archive** as the **mandatory destination** for critical backups (NFS or S3). - **Fast network storage** to accelerate restores. - **Local disk** only as a temporary or complementary layer, never as the only backup repository. ## Example architectures with PBS and Archive on Stackscale #### 1. Proxmox private cloud with Archive as primary repository and a fast recovery layer - Proxmox VE cluster in **Madrid**. - Proxmox Backup Server deployed as a **VM or bare-metal server** on Stackscale. - **Primary PBS datastore** hosted on Stackscale Archive storage (in Madrid), accessible via NFS or S3-compatible access. - Optionally, an additional datastore on **fast network storage (SSD/NVMe over network)** to speed up frequent restores. In this design, **backup jobs always write to Archive**, which acts as the **golden copy**.**Optionally, you can define additional jobs or internal PBS syncs towards the fast datastore to maintain a “hot” layer** for faster restores of specific machines. To comply with a **3-2-1 and multi–data center strategy**, a common pattern is: - Keep the primary datastore in **Archive Madrid**. - Periodically sync that datastore to **Archive Amsterdam** using PBS remote sync jobs. This way, even if a full data center fails, the organization still has recoverable copies in another region (Madrid and Amsterdam). #### 2. Multi-cluster platforms with namespaces and Archive as the single source of truth - Several dedicated Proxmox clusters (production, preproduction, QA, customer environments, etc.) across different Stackscale data centers. - One or more central Proxmox Backup Server instances, with **datastores backed by Archive** and **namespaces** separated by environment or internal customer. - Optionally, additional datastores on faster network storage for environments that require very low RTO (for example, production). In this model: - All environments write their backups to **Archive**, organized into namespaces (for example: prod/, preprod/, qa/, customer-X/). - Namespaces provide logical isolation and allow different retention policies and permissions while still benefiting from global datastore deduplication. - For certain namespaces (like production), you can add a **“fast” datastore** that acts as an accelerated recovery layer, but always backed by Archive as the long-term, multi–data center repository. In this way, the organization combines: - Governance and segregation (namespaces + RBAC). - Robust, isolated copies on Archive. - And, where needed, very fast restores from higher-performance network storage. #### 3. Backups of physical hosts and specific services with Archive as the primary target Proxmox Backup Server is not limited to VMs and containers: the **backup client** can be installed on physical Linux servers to back up files or volumes. On Stackscale, this makes it possible to: - Protect **specific appliances** (for example, physical database servers, legacy application nodes, or specialized servers). - Send those backups **directly to Stackscale Archive storage**, using NFS or S3-compatible access as the main PBS backend. By placing these backups on Archive: - You decouple the backup from the physical hardware itself (which is often a single point of failure). - You gain **multi–data center redundancy** by replicating PBS datastores between the two Archive locations in Madrid and Archive Amsterdam. - Long-term retention becomes more cost-efficient on a per-GB basis, while keeping the option to restore in another region if needed. If you need to speed up certain restores (for example, for regular DR drills or frequent incidents on a critical physical server), you can add an additional datastore on fast network storage—but always under the assumption that the **“definitive” copy lives on Archive**. ## Best practices when designing the solution When combining Proxmox Backup Server with Archive on Stackscale, it’s recommended to: - Define a **clear retention policy** (daily, weekly, monthly) using PBS pruning options and the prune simulator to visualize its long-term effect. - Separate **operational backups** (fast restores) from **archival backups** (long-term retention) into different datastores or namespaces. - Take advantage of **per-user traffic control and S3 bandwidth limiting** so backup windows don’t saturate the network or impact production services. - Integrate PBS with the corporate identity system (LDAP/AD/OIDC) and enable **2FA** for administrative logins. ## Quick summary for administrators - **What it is****Proxmox Backup Server is an enterprise, open source backup solution based on Debian and written in Rust, with native ZFS support, deduplication, Zstandard compression, and client-side authenticated encryption. - What it’s for****Protecting VMs, containers, and physical hosts with fast, efficient incremental backups, natively integrated with Proxmox VE and with support for tape and S3-compatible storage. - Key new features in 4.1****Based on Debian 13.2 “Trixie”, Linux kernel 6.17, ZFS 2.3.4, per-user traffic control, configurable parallelism for verification jobs, and bandwidth limiting for S3 endpoints. - How it fits into Stackscale****It can be deployed as a VM or bare-metal node inside a Proxmox private cloud, using Stackscale’s Archive storage as an NFS or S3-compatible backend, available in Madrid and Amsterdam, to build multi–data center backup architectures with fast local restores and long-term off-site copies. If you’re already considering Proxmox as a virtualization alternative, or you want to strengthen your backup strategy on Proxmox infrastructures running on Stackscale, Proxmox Backup Server + Archive** is a very solid combination to gain resilience without giving up the open source model or sovereignty over your data. Request information form EN Subscribe NameEmailPhoneI am interested in:Cloud solutionsBare Metal solutionsManaged ServicesBackup and Disaster Recovery solutionsColocation servicesCDN solutionsTell us more about your needs I give my consent to receiving customized commercial communications about Stackscale products and services (including the newsletter), by any channel, including electronic ones. I have read and accept the privacy policy. Submit The Stackscale Group processes the information you provide in order to respond to your request regarding the services we deliver and the products we provide. The data provided will be stored while we stay in contact and deleted when the request is closed, unless you consent to receiving sales communications, in which case your data will be stored until the previously given consent is revoked. As part of the Group to which Stackscale belongs, we inform you that your data will be communicated to the companies of Grupo Aire for corporate reasons. You can consult the companies integrating Grupo Aire at: https://grupoaire.es. You can exercise your rights of access, rectification, erasure, disagreement, limitation of the processing and, when legally appropriate, portability, by sending a request to Stackscale to the address dp*@********le.com, indicating the right you exercise and providing a double-sided photocopy of your identification. Additionally, you will be able to present a complaint to the Dutch Data Protection Authority, especially when you are not content with the exercise of your rights, via https://autoriteitpersoonsgegevens.nl/en. --- ## Proxmox Backup Server: copias de seguridad de nivel enterprise para entornos Proxmox en Stackscale URL: https://www.stackscale.com/blog/proxmox-backup-server-enterprise/ En cualquier infraestructura moderna, las copias de seguridad ya no son un “extra”, sino un componente estructural al mismo nivel que el almacenamiento o la red. Cuando se trabaja con clusters Proxmox VE, soluciones en HA y cargas de misión crítica, contar con una solución de backup pensada para este ecosistema marca la diferencia entre una recuperación rápida o una parada larga y costosa. Ahí es donde entra **Proxmox Backup Server (PBS)**: una solución de copia de seguridad enterprise, 100 % open source, diseñada para proteger máquinas virtuales, contenedores y hosts físicos con respaldos incrementales, deduplicados y cifrados, y con una integración muy estrecha con Proxmox VE. ## Tabla de contenidos - ¿Qué es Proxmox Backup Server? - Arquitectura y funcionamiento - Proxmox Backup Server sobre la infraestructura de Stackscale - Ejemplos de arquitectura con PBS y Archive en Stackscale - Buenas prácticas al diseñar la solución - Resumen rápido para administradores Sobre la infraestructura de **Stackscale**, Proxmox Backup Server se puede combinar con el **almacenamiento Archive** (vía NFS o acceso compatible S3) disponible en **dos ubicaciones de centros de datos separadas, en Madrid y en Ámsterdam**, para construir estrategias de backup robustas, multi-CPD y alineadas con el modelo 3-2-1. Además de poder complementarlo con almacenamiento remotos en otros proveedores para aportar copias de seguridad y resiliencia de datos. ## **¿Qué es Proxmox Backup Server?** **Proxmox Backup Server** es una distribución Linux orientada específicamente a backup, basada en Debian y con soporte nativo de ZFS, escrita principalmente en Rust y licenciada bajo **GNU AGPLv3**. Su objetivo es ofrecer una alternativa abierta a las soluciones de copia de seguridad propietarias, sin limitar el número de máquinas ni el volumen protegido. Entre sus características clave se encuentran: - **Copias incrementales y deduplicadas** para VMs, contenedores y hosts físicos. - **Compresión Zstandard** de alto rendimiento. - **Cifrado autenticado en el cliente (AES-256-GCM)**, de forma que los datos viajan y se almacenan cifrados incluso en destinos no totalmente confiables. - **Verificación de integridad** mediante checksums y trabajos de verificación programables. - **Integración nativa con Proxmox VE**, incluyendo soporte de QEMU dirty bitmaps para backups incrementales rápidos. - **Soporte de cinta (LTO) y almacenamiento compatible S3** como backends de datos. * La versión **Proxmox Backup Server 4.1**, lanzada en noviembre de 2025, se basa en **Debian 13.2 “Trixie”**, utiliza el kernel Linux 6.17.2-1 como nuevo valor por defecto y ZFS 2.3.4, e introduce mejoras importantes en control de tráfico, verificación y uso de almacenamiento S3. ## **Arquitectura y funcionamiento** ### **Modelo cliente-servidor y namespaces** PBS sigue un modelo **cliente-servidor**: uno o varios servidores de backup almacenan los datos, mientras clientes (incluyendo Proxmox VE) envían los respaldos incrementalmente sobre TLS 1.3. Los backups se organizan en **datastores** y **namespaces**, lo que permite separar entornos (por ejemplo, producción, preproducción o distintos clusters) manteniendo una deduplicación eficaz. Gracias a la deduplicación y a las copias incrementales, solo se transfieren y almacenan los bloques modificados desde el último backup, reduciendo drásticamente el consumo de red y de capacidad. ### **Integración con Proxmox VE** En Proxmox VE, basta con **añadir un datastore de PBS como nuevo almacenamiento de backup** para empezar a usarlo con VMs y contenedores. Desde la propia interfaz de Proxmox se definen jobs de copia de seguridad (full, incremental, programación, retención) apuntando al datastore de PBS. Además, PBS permite recuperar: - VMs completas (con soporte de live restore* en muchos casos). - Contenedores completos. - **Ficheros individuales** desde backups de VM o contenedor, directamente desde la GUI o una shell interactiva. ### **Seguridad, integridad y protección frente a ransomware** La seguridad es uno de los pilares de Proxmox Backup Server: - **Cifrado en cliente** con AES-256-GCM, de modo que el servidor de backup no puede leer los datos sin las claves correspondientes. - **Checksums SHA-256** para comprobar la integridad de todos los bloques almacenados. - **Jobs de verificación programables** para detectar *bit rot* o corrupciones. - Modelo de **control de acceso granular (RBAC)** con roles, tokens de API, integración con LDAP, Active Directory y OpenID Connect, y soporte de 2FA. Desde la versión 4.1, PBS añade además **control de tráfico por usuario autenticado** y **limitación de ancho de banda en endpoints S3**, lo que ayuda a evitar congestión de red cuando se realizan backups o restores intensivos hacia almacenamiento de objetos. Todo esto convierte a Proxmox Backup Server en una pieza muy sólida dentro de una estrategia de defensa frente a ransomware y fallos masivos de infraestructura. ## **Proxmox Backup Server sobre la infraestructura de Stackscale** En Stackscale, Proxmox Backup Server se puede integrar sobre diferentes tipos de almacenamiento, pero el diseño recomendado pasa siempre por que **la copia de seguridad principal resida en una solución de Archive**, aislada y redundante, y que después se añadan capas más rápidas si se necesita acelerar la recuperación. El esquema general sería: - **Copia de referencia (golden copy):** siempre en **almacenamiento Archive de Stackscale**, accesible por NFS o mediante API compatible S3, y disponible en **tres ubicaciones físicas separadas (2 centros de datos en Madrid y 1 en  Ámsterdam)**. - **Capas opcionales de rendimiento:** copias adicionales en **almacenamiento en red más rápido de Stackscale **(All-Flash) para acelerar las restauraciones más frecuentes. - **Almacenamiento local en disco del servidor:** posible, pero con limitaciones claras: depende del propio servidor físico para acceder a las copias y no aporta redundancia en esa capa. ### **Almacenamiento Archive como backend principal de Proxmox Backup Server** El **almacenamiento Archive de Stackscale** debe ser el **backend de referencia** para Proxmox Backup Server, garantizando que, pase lo que pase en los hosts o clusters, siempre exista una copia consistente y recuperable en un entorno separado: - **Archive montado por NFS** PBS ve Archive como un datastore más, exportado vía NFS. - Ideal para grandes volúmenes de backup con acceso en red, manteniendo la deduplicación y compresión propias de PBS. - Recomendado como **destino principal** para la retención media y larga. - **Archive vía acceso compatible S3** Archive puede exponerse como bucket S3 y configurarse en PBS como destino remoto. - Permite aprovechar las capacidades de Proxmox Backup Server sobre almacenamiento de objetos (incluyendo limitación de ancho de banda y escenarios multi-CPD). - Especialmente adecuado para **copias de larga duración y planes de recuperación ante desastres**. En ambos casos, Archive está disponible en **dos regiones**: - 2 centros de datos en **Madrid**. - 1 centro de datos en **Ámsterdam**. Esto facilita diseñar **estrategias multi-CPD**: por ejemplo, mantener los backups principales en Archive Madrid y sincronizar de forma periódica hacia Archive Ámsterdam mediante jobs de sincronización remota de PBS. ### **Almacenamiento en red rápido como capa de recuperación acelerada** Por encima de Archive, los clientes pueden añadir una capa de **almacenamiento en red más rápido de Stackscale** (All-Flash) para: - Guardar las últimas copias (por ejemplo, de los últimos días). - Acelerar **restauraciones frecuentes** o pruebas de recuperación. - Reducir el RTO en servicios muy sensibles al tiempo de parada. En este modelo, Archive sigue siendo la **fuente de verdad**, y el almacenamiento en red actúa como **caché caliente** para los restores más habituales. ### **Disco local: opción puntual, pero con precaución** El almacenamiento local en el propio servidor de Proxmox Backup Server puede seguir utilizándose en algunos escenarios (por ejemplo, para un primer buffer de backup), pero con varios inconvenientes: - La accesibilidad a las copias depende del estado del **servidor físico concreto**. - No hay **redundancia** intrínseca en esa capa si no se replica hacia Archive o almacenamiento en red. - En un fallo grave del host o del almacenamiento local, se podría perder la capa de backup más valiosa. Por eso, en arquitecturas profesionales sobre Stackscale, el enfoque recomendado es: - **Archive de Stackscale como destino obligatorio de las copias de seguridad críticas** (NFS o S3). - **Almacenamiento en red rápido** para acelerar restauraciones. - Disco local solo como complemento puntual, nunca como único repositorio de backup. ## **Ejemplos de arquitectura con PBS y Archive en Stackscale** **1. Cloud privado Proxmox con Archive como repositorio principal y capa rápida de recuperación** - Clúster Proxmox VE en **Madrid**. - Proxmox Backup Server desplegado como **VM o servidor bare-metal** en Stackscale. - **Datastore principal de PBS alojado en el almacenamiento Archive de Stackscale** (en Madrid), accesible vía **NFS o S3 compatible**. - Opcionalmente, un **datastore adicional** sobre almacenamiento en red rápido (SSD/NVMe en red) para acelerar las restauraciones más frecuentes. En este diseño, los **jobs de backup escriben siempre en Archive**, que actúa como copia de referencia (golden copy).**De forma opcional, se pueden definir jobs adicionales o sincronizaciones internas de PBS hacia el datastore rápido para disponer de una “capa caliente” desde la que restaurar más deprisa ciertas máquinas. Para cumplir una estrategia 3-2-1 y multi-CPD, es habitual: - Mantener el datastore principal en Archive Madrid**. - Sincronizar periódicamente ese datastore hacia **Archive en Ámsterdam** mediante jobs de sincronización remota de PBS. Así, aunque falle un CPD completo, la organización sigue contando con copias recuperables en otra región en Madrid y Ámsterdam. **2. Plataformas multi-clúster con separación por namespaces y Archive como punto de verdad** - Varios clusters Proxmox dedicados (producción, preproducción, QA, entornos de cliente, etc.) en distintos centros de datos de Stackscale. - Uno o varios Proxmox Backup Server centrales, con **datastores respaldados en Archive** y **namespaces** separados por entorno o por cliente interno. - Opcionalmente, datastores adicionales sobre **almacenamiento en red rápido** para los entornos donde se requiera un RTO muy bajo (por ejemplo, producción). En este modelo: - Todos los entornos escriben sus copias en **Archive**, organizado en namespaces (por ejemplo: prod/, preprod/, qa/, cliente-X/). - Los **namespaces** aportan independencia lógica y permiten aplicar **políticas de retención y permisos distintas**, manteniendo a la vez la deduplicación global del datastore. - Para ciertos namespaces (como producción), se puede añadir un datastore “rápido” que actúe como **capa de recuperación acelerada**, pero siempre respaldado por Archive como repositorio de larga duración y multi-CPD. De este modo, la organización combina: - Gobierno y segregación (namespaces + RBAC). - Copias robustas y aisladas en Archive. - Y, donde es necesario, restauraciones muy rápidas desde almacenamiento en red más performante. **3. Backups de hosts físicos y servicios específicos con Archive como destino principal** Proxmox Backup Server no se limita a VMs y contenedores: el **cliente de backup** se puede instalar en servidores Linux físicos para hacer copias de ficheros o volúmenes. Sobre Stackscale, esto permite: - Proteger **appliances específicos** (por ejemplo, servidores de bases de datos físicos, nodos de aplicaciones legadas o servidores especializados). - Enviar esas copias **directamente al almacenamiento Archive de Stackscale**, usando NFS o S3 compatible como backend principal de PBS. Al ubicar estos backups en Archive: - Se desacopla la copia del propio hardware físico (que suele ser punto único de fallo). - Se gana **redundancia multi-CPD** al poder replicar los datastores de PBS entre las 2 ubicaciones de Archive Madrid y Archive Ámsterdam. - La **retención a largo plazo** resulta más eficiente en coste por GB, manteniendo la posibilidad de restaurar en otra región si fuera necesario. Si se necesita acelerar restauraciones concretas (por ejemplo, para pruebas de recuperación o incidentes frecuentes en un servidor físico clave), se puede añadir un datastore adicional sobre almacenamiento en red rápido, pero siempre con la premisa de que la copia “definitiva” está en Archive. - ubicar datos en otra región hacen más eficiente la retención a largo plazo. ## **Buenas prácticas al diseñar la solución** Al combinar Proxmox Backup Server con Archive en Stackscale, es recomendable: - Definir una **política de retención** clara (diarias, semanales, mensuales) usando las opciones de *pruning* de PBS y el simulador de poda para visualizar el efecto en el tiempo. - Separar los **backups operativos** (restores rápidos) de los **backups de archivo** (retención prolongada) en datastores o namespaces distintos. - Aprovechar el **control de tráfico por usuario y limitación de ancho de banda S3** para que las ventanas de backup no saturen la red ni impacten servicios de producción. - Integrar PBS con el sistema de identidades corporativo (LDAP/AD/OIDC) y activar 2FA para accesos administrativos. ## **Resumen rápido para administradores** - **Qué es****Proxmox Backup Server es una solución de backup enterprise open source, basada en Debian y escrita en Rust, con soporte nativo de ZFS, deduplicación, compresión Zstandard y cifrado autenticado en el cliente. - Para qué sirve****Proteger VMs, contenedores y hosts físicos con copias incrementales, rápidas y eficientes, integradas de forma nativa con Proxmox VE y con opciones de tape y almacenamiento compatible S3. - Novedades clave en 4.1****Basado en Debian 13.2 “Trixie”, kernel 6.17, ZFS 2.3.4, control de tráfico por usuario, paralelismo configurable en verificaciones y limitación de ancho de banda para endpoints S3. - Cómo encaja en Stackscale****Puede desplegarse como VM o bare-metal dentro del cloud privado Proxmox, utilizando el almacenamiento Archive de Stackscale como backend NFS o S3 compatible**, disponible en **Madrid y Ámsterdam**, para construir arquitecturas de backup multi-CPD, con copias locales rápidas y copias de largo plazo off-site. Si ya estás valorando Proxmox como alternativa de virtualización o si quieres reforzar tu estrategia de copias de seguridad sobre infraestructuras Proxmox en Stackscale, **Proxmox Backup Server + Archive** es una combinación muy sólida para ganar resiliencia sin renunciar al modelo open source ni a la soberanía sobre tus datos. Request information form ES Newsletter NombreEmailTeléfonoEstoy interesado/a en:Soluciones cloudSoluciones Bare MetalServicios gestionadosSoluciones de Disaster Recovery y backupServicios de housingSoluciones de CDNCuéntanos más sobre tus necesidades Acepto el envío de comunicaciones comerciales personalizadas sobre los productos y servicios de Stackscale (incluida la newsletter), por cualquier medio, incluidos los electrónicos. He leído y acepto la política de privacidad. Enviar El Grupo Stackscale trata la información que nos facilita con el fin de dar respuesta a la solicitud realizada en relación con los servicios que prestamos y los productos que suministramos. Los datos proporcionados se conservarán mientras se mantenga el contacto siendo eliminados una vez finalizada la solicitud, a no ser que consienta el envío de comunicaciones comerciales, donde sus datos se conservarán hasta la revocación del consentimiento previamente otorgado. En el marco del Grupo al que pertenece Stackscale, se le informa de que sus datos serán comunicados a las empresas de Grupo Aire por motivos corporativos. Puede consultar las empresas que forman parte del Grupo Aire en: https://grupoaire.es. Usted puede ejercitar sus derechos de acceso, rectificación, supresión, oposición, limitación del tratamiento y, cuando legalmente proceda, portabilidad, mediante el envío a Stackscale de una solicitud a la dirección dp*@********le.com, indicando el derecho que ejercita y aportando una fotocopia por las dos caras de su DNI o documento legal de identificación de su identidad. Igualmente, podrá presentar una reclamación ante la Agencia Española de Protección de Datos, especialmente cuando no haya obtenido la satisfacción en el ejercicio de sus derechos, a través de la sede electrónica en www.aepd.es. --- ## Proxmox Datacenter Manager 1.0: the new “command center” for Proxmox environments at Stackscale URL: https://www.stackscale.com/blog/proxmox-datacenter-manager-new/ The Proxmox ecosystem has just taken an important step forward with the release of **Proxmox Datacenter Manager 1.0**, the first stable version of its centralized management platform. The tool is designed to solve a very specific problem: how to operate, monitor, and scale dozens of Proxmox VE nodes and clusters and Proxmox Backup Server instances spread across multiple data centers and locations, without losing visibility or increasing operational complexity. For companies already using Proxmox-based infrastructure —such as Stackscale customers with dedicated platforms and clusters in high-availability data centers— this release opens the door to a management model much closer to what tools like VMware vCenter have historically offered, while preserving the open-source philosophy and flexibility of the Proxmox ecosystem. ### **What is Proxmox Datacenter Manager?** **Proxmox Datacenter Manager (PDM)** is a “single pane of glass” platform designed to monitor and manage multiple, independent Proxmox environments from a single control point. From that central console you can see nodes, clusters, virtual machines, containers, storage, and backup datastores, even if they are spread across different data centers or remote locations. Instead of logging manually into each Proxmox VE cluster or each Proxmox Backup Server instance, PDM aggregates metrics, states, and alerts, and lets you perform basic operations on resources from a unified view. It does not aim to completely replace the classic Proxmox VE interface, but it does become the top governance and multi-cluster orchestration layer. Technically, Proxmox Datacenter Manager 1.0 is built on Debian 13.2 “Trixie,” a Linux 6.17 kernel, and ZFS 2.3, and it is developed in Rust end to end (backend, CLI, and the new Yew-based web UI framework). The result is a modern platform focused on performance, security, and long-term maintainability. ### **Key technical capabilities of PDM 1.0** While the most visible change is the global view across all clusters, version 1.0 ships with a set of features that are highly relevant for enterprise environments and infrastructure providers like Stackscale and their customers’ platforms: #### **1. Centralized view and metrics aggregation** PDM lets you register multiple “remotes” (Proxmox VE nodes and clusters and backup servers) and display their global health status on a single dashboard: CPU usage, RAM, storage I/O, capacity, alerts, and critical KPIs. It also caches data locally, so you keep the latest snapshot of the environment even if a remote becomes temporarily unavailable. For a customer with several Proxmox clusters spread across different racks or Stackscale data centers, this makes it easy to answer at a glance questions like: “Where do I have free capacity?”, “Which cluster is under the most pressure?”, or “How are the metrics of a critical service evolving across all sites?”. #### **2. Multi-cluster management and live migration across clusters** One of PDM’s strongest points is its multi-cluster management and the ability to perform live migrations of virtual machines between independent clusters, without service disruption. This allows you to: - Rebalance load across clusters when one approaches its limit.** - Carry out planned maintenance without downtime windows. - Implement high-availability scenarios across data centers with much greater flexibility. On Proxmox platforms hosted at Stackscale, this fits perfectly with designs where a customer has multiple dedicated clusters (for example, production and pre-production in different racks or even different data centers) and wants to move workloads between them without manual export/import processes. #### 3. Basic VM and container lifecycle from a single panel** From Proxmox Datacenter Manager you can start, stop, reboot, and perform basic operations on VMs, containers, and storage resources on different remotes, without jumping between interfaces. The tool also centralizes task and log history, which simplifies auditing and compliance in regulated environments. For systems teams, this means less time spent on scattered “clickops” and more capacity to standardize operational procedures, scripts, and automations around a single API. #### **4. Advanced search and custom views** The integrated search uses a syntax inspired by languages like Elasticsearch or GitHub’s query language, allowing you to filter resources by type (VM, container, remote, etc.), state (running, stopped, etc.), or tags. In environments with thousands of virtual guests, quickly locating a problematic VM or a specific datastore is no longer a challenge. On top of that, PDM lets you create custom “views” —dashboards focused by remote, resource type, tags, internal customer, and more— and bind them to specific roles. A development team, for example, can have its own view of resources without seeing or touching the rest of the infrastructure. #### **5. Integration with Proxmox Backup Server and SDN (EVPN)** Version 1.0 includes full integration with Proxmox Backup Server: you can view datastores, namespaces, and backup snapshots in dedicated panels, along with usage and performance metrics. This makes it easier to monitor the state of backups globally, which is especially important in multi-site disaster recovery strategies. On the networking side, PDM introduces initial Software-Defined Networking (SDN) capabilities with EVPN, allowing you to configure zones and VNets across multiple remotes from a single interface. For architectures with L2/L3 overlays distributed across data centers, this is key to maintaining configuration consistency. #### **6. Security, authentication, and access governance** Proxmox Datacenter Manager supports authentication via LDAP, Active Directory, and OpenID Connect, as well as tokens and 2FA. It combines identity support with a very granular role-based access control (RBAC) system: you can grant access to specific views without giving direct access to the underlying nodes or virtual machines. In multi-tenant environments or organizations with highly segmented teams (development, security, operations, business), this helps balance operational visibility with the principle of least privilege. #### **7. Centralized update management and remote shell access** The platform adds a centralized update panel showing repository status and pending packages across all connected Proxmox VE and Proxmox Backup Server instances. From there, you can trigger updates using PDM’s new remote shell capabilities, without opening separate sessions to each node. For providers like Stackscale or for their customers who manage their own Proxmox platform, this global view of patch status significantly reduces the risk of running desynchronized clusters or leaving vulnerabilities unpatched somewhere in the environment. ### **What does Proxmox Datacenter Manager bring to Stackscale customers?** Stackscale customers already running platforms based on Proxmox VE and Proxmox Backup Server —whether in self-managed mode or as a managed service— gain several clear benefits when they add Proxmox Datacenter Manager to their architecture: #### **Unified multi–data center, multi-cluster view** Instead of treating each Proxmox cluster as a “silo,” PDM gives an end-to-end view of the distributed infrastructure: dedicated clusters in different racks, redundant data centers, nodes specifically for AI workloads or databases, and even Proxmox environments running on-premises at the customer’s facilities and connected to Stackscale through dedicated links or VPN. This global view helps with: - Capacity planning and scale-out decisions.** - Early detection of CPU, RAM, or I/O bottlenecks. - Prioritizing hardware investments where they have the most impact. #### Workload mobility across clusters and data centers** Live migration across clusters, combined with Stackscale’s network and inter–data center connectivity options, unlocks interesting scenarios: - Moving production workloads to a more powerful cluster without downtime.** - Draining clusters to perform hardware migrations or generational refreshes. - Preparing moves between data centers as part of a resilience strategy or an orderly exit from a given facility. All of this with a unified operational experience, instead of treating each move as a separate manual project. #### Better governance, auditing, and multi-tenant operation** In organizations where different departments share the same Stackscale-based Proxmox platform, Proxmox Datacenter Manager helps to: - Define specific views for each business unit, project, or internal customer.** - Limit the scope of operations by role (for example, allowing a development team to start/stop VMs in its own scope, but not touch shared network or storage). - Centralize logs and tasks, improving traceability of who did what, where, and when. This fits especially well in mission-critical environments where regulatory compliance, separation of duties, and auditing are non-negotiable. #### More efficient day-to-day operations** For teams managing dozens or hundreds of Proxmox nodes at Stackscale, the combination of: - Advanced search,** - A unified task panel, - Centralized updates, - Shell access from a single console, reduces friction in day-to-day work. Routine tasks take less time, and there are fewer errors caused by juggling multiple interfaces. ### Typical use cases in Stackscale environments** Some examples of how Proxmox Datacenter Manager can fit into real-world architectures on top of Stackscale: #### **Multi-site private cloud with DR** A company deploys dedicated Proxmox clusters in two Stackscale data centers and maintains a third site as a disaster recovery location. With PDM, all three environments are managed from the same panel, with the ability to migrate workloads between clusters and monitor the state of remote backups and datastores. #### **Consolidation after a VMware migration** After changes to VMware’s licensing and strategy, many organizations are looking for open alternatives with more predictable costs. Proxmox, combined with a specialized provider like Stackscale, has become one of the go-to options. Proxmox Datacenter Manager acts as the missing piece to comfortably operate multiple Proxmox clusters that replace previous VMware environments. #### **Hybrid on-premises + Stackscale environments** A customer maintains small Proxmox clusters in branches or plants, and a backbone of more powerful clusters hosted at Stackscale for core workloads. PDM lets them manage both ends —edge and core— from the same platform, with aggregated metrics and coordinated operations. ### **Deployment and support considerations** Proxmox Datacenter Manager 1.0 is available as an ISO image that can be installed on bare metal or on top of an existing Debian installation, and it is distributed as free software under the GNU AGPLv3 license. For production environments, Proxmox offers subscriptions with access to enterprise repositories and certified technical support. For Stackscale customers, the most common options are: - Deploying PDM as a dedicated VM (or bare-metal node) within their own Proxmox platform at Stackscale.** - Integrating it with corporate directory services (LDAP/AD/OIDC) and existing security policies. - Defining, together with the Stackscale team, a strategy for views, roles, and permissions aligned with how systems, development, and business teams are organized. As a first stable release, it makes sense to start with a well-scoped pilot —for example, connecting a few non-critical clusters— and then evolve toward full management of the entire Proxmox footprint as the organization gains confidence in the tool. At Stackscale we can already help you with the deployment and maintenance of your own Proxmox Datacenter Manager instance, so feel free to reach out. ### Quick summary for administrators** - **What it is:** an open-source, centralized management platform for Proxmox VE and Proxmox Backup Server, built on Debian 13.2, Linux kernel 6.17, ZFS 2.3, and developed in Rust.** - Problem it solves:** lack of global visibility and unified operations in environments with multiple clusters and distributed nodes.** - Key technical features:** aggregated metrics, RBAC-driven custom views, advanced search, live migration between clusters, centralized update panel, SDN with EVPN, and integration with Proxmox Backup Server.** - Value for Stackscale customers:** makes it easier to operate multi-cluster, multi–data center Proxmox platforms, improve workload mobility, strengthen governance and auditing, and reduce the time spent on routine operational tasks. For organizations that already trust Proxmox running on Stackscale infrastructure —or that are planning a migration from other virtualization platforms— Proxmox Datacenter Manager 1.0 becomes a strategic building block to professionalize environment management without giving up open-source principles or infrastructure sovereignty. --- ## Proxmox Datacenter Manager 1.0: el nuevo “centro de mando” para entornos Proxmox en Stackscale URL: https://www.stackscale.com/blog/proxmox-datacenter-manager-new/ El ecosistema Proxmox acaba de dar un paso importante con el lanzamiento de **Proxmox Datacenter Manager 1.0**, la primera versión estable de su plataforma de gestión centralizada. La herramienta nace para resolver un problema muy concreto: cómo operar, monitorizar y escalar decenas de nodos y clústeres Proxmox VE y Proxmox Backup Server repartidos entre varios centros de datos y ubicaciones, sin perder visibilidad ni aumentar la complejidad operativa. Para empresas que ya utilizan infraestructura basada en Proxmox —como los clientes de Stackscale con plataformas y clústeres dedicados en centros de datos de alta disponibilidad— este lanzamiento abre la puerta a un modelo de gestión mucho más cercano a lo que históricamente ofrecían herramientas como vCenter de VMware, pero manteniendo la filosofía open source y la flexibilidad del ecosistema Proxmox. ## **¿Qué es Proxmox Datacenter Manager?** **Proxmox Datacenter Manager (PDM)** es una plataforma de “single pane of glass” diseñada para supervisar y gestionar múltiples entornos Proxmox independientes desde un único punto de control. Desde esa consola central se pueden ver nodos, clústeres, máquinas virtuales, contenedores, almacenamientos y datastores de backup, aunque estén repartidos entre distintos centros de datos o incluso ubicaciones remotas. En lugar de entrar manualmente a cada clúster Proxmox VE o a cada instancia de Proxmox Backup Server, PDM agrega métricas, estados y alarmas y permite ejecutar operaciones básicas sobre los recursos desde una vista unificada. No pretende sustituir por completo a la interfaz clásica de Proxmox VE, pero sí se convierte en la capa superior de gobierno y orquestación multi-clúster. A nivel técnico, Proxmox Datacenter Manager 1.0 se apoya en Debian 13,2 “Trixie”, un kernel Linux 6.17 y ZFS 2.3, y está desarrollado en Rust de extremo a extremo (backend, CLI y nuevo framework de interfaz web basado en Yew). El resultado es una plataforma moderna, con foco en rendimiento, seguridad y mantenibilidad a largo plazo. ## **Principales capacidades técnicas de PDM 1.0** Aunque el cambio más visible es la vista global de todos los clústeres, la versión 1.0 llega con un conjunto de funcionalidades muy relevantes para entornos empresariales y proveedores de infraestructura como Stackscale y la plataformas de sus clientes: ### **1. Vista centralizada y agregación de métricas** PDM permite registrar múltiples “remotes” (nodos, clústeres Proxmox VE y servidores de backup) y mostrar en un único dashboard el estado de salud global: uso de CPU, RAM, I/O de almacenamiento, capacidad, alertas y KPIs críticos. Además, cachea datos localmente, de modo que se conserva la última foto del entorno incluso si algún remoto queda temporalmente inaccesible. Para un cliente con varios clústeres Proxmox repartidos entre diferentes racks o centros de datos de Stackscale, esto se traduce en poder responder de un vistazo a preguntas como: “¿dónde tengo capacidad libre?”, “¿qué clúster está más tensionado?” o “¿cómo evolucionan las métricas de un servicio crítico en todos los sites?”. ### **2. Gestión multi-clúster y migración en vivo entre clústeres** Uno de los puntos fuertes de PDM es la gestión de entornos multi-clúster y la posibilidad de realizar migraciones en vivo de máquinas virtuales entre clústeres independientes, sin interrupción del servicio. Esto permite: - Reequilibrar carga entre clústeres cuando uno se acerca a su límite.** - Ejecutar tareas de mantenimiento planificado sin ventanas de caída. - Implementar escenarios de alta disponibilidad entre centros de datos con mayor flexibilidad. En plataformas Proxmox alojadas en Stackscale, esa capacidad encaja muy bien con diseños donde un cliente dispone de varios clústeres dedicados (por ejemplo, producción y preproducción en distintos racks o incluso en distintos CPD) y quiere mover cargas de trabajo entre ellos sin pasar por procesos manuales de exportación e importación. ### 3. Ciclo de vida básico de VMs y contenedores desde un único panel** Desde Proxmox Datacenter Manager se pueden arrancar, detener, reiniciar y realizar operaciones básicas sobre VMs, contenedores y recursos de almacenamiento de distintos remotos, sin tener que saltar de interfaz en interfaz. La herramienta centraliza también el histórico de tareas y logs, lo que facilita auditoría y cumplimiento en entornos regulados. Para los equipos de sistemas, esto se traduce en menos tiempo haciendo “clickops” disperso y más capacidad para estandarizar procedimientos operativos, scripts y automatizaciones sobre una API única. ### **4. Búsqueda avanzada y vistas personalizadas** La búsqueda integrada utiliza una sintaxis inspirada en lenguajes como Elasticsearch o GitHub, lo que permite filtrar recursos por tipo (VM, contenedor, remoto…), estado (en ejecución, detenido, etc.) o etiquetas. En entornos con miles de invitados virtuales, localizar rápidamente una VM problemática o un datastore concreto deja de ser un reto. Sobre esta base, PDM permite crear “vistas” personalizadas —dashboards focalizados por remoto, tipo de recurso, etiquetas, cliente interno, etc.— y asociarlas a roles concretos. Así, un equipo de desarrollo puede tener su propia vista de recursos, sin ver ni tocar el resto de la infraestructura. ### **5. Integración con Proxmox Backup Server y SDN (EVPN)** La versión 1.0 incluye integración completa con Proxmox Backup Server: se pueden ver datastores, namespaces y snapshots de backup en paneles dedicados, junto con métricas de uso y rendimiento. Esto facilita la supervisión del estado de las copias de seguridad a nivel global, algo especialmente relevante en estrategias de recuperación ante desastres multi-site.  En el plano de red, PDM incorpora capacidades iniciales de Software-Defined Networking (SDN) con EVPN, permitiendo configurar zonas y VNets entre múltiples remotos desde una sola interfaz. Para arquitecturas con overlays L2/L3 distribuidos entre centros de datos, este punto es clave para mantener la coherencia de la configuración. ### **6. Seguridad, autenticación y gobierno de acceso** Proxmox Datacenter Manager soporta autenticación mediante LDAP, Active Directory y OpenID Connect, así como tokens y 2FA. Combina este soporte de identidades con un sistema de control de acceso basado en roles (RBAC) muy granular: es posible conceder acceso a vistas concretas sin otorgar acceso directo a los nodos o máquinas subyacentes. En escenarios multi-tenant o con equipos muy segmentados (desarrollo, seguridad, operaciones, negocio), esto permite equilibrar visibilidad operativa y principio de mínimo privilegio. ### **7. Gestión centralizada de actualizaciones y acceso remoto al shell** La plataforma añade un panel de actualizaciones centralizado que muestra el estado de los repositorios y paquetes pendientes en todos los Proxmox VE y Proxmox Backup Server conectados. Desde ahí es posible lanzar actualizaciones apoyándose en el nuevo acceso remoto a shell que expone PDM, sin tener que abrir sesiones independientes a cada nodo. Para proveedores como Stackscale o para sus clientes que gestionan su propia plataforma Proxmox, esa visión global del estado de parches reduce significativamente el riesgo de quedarse con clústeres desalineados o con vulnerabilidades sin corregir en algún punto del entorno. ## **¿Qué aporta Proxmox Datacenter Manager a los clientes de Stackscale?** Los clientes de Stackscale que ya operan plataformas basadas en Proxmox VE y Proxmox Backup Server —ya sea en modo self-managed o como servicio gestionado— se encuentran con varios beneficios claros al incorporar Proxmox Datacenter Manager a su arquitectura: ### **Vista unificada multi-CPD y multi-clúster** En lugar de tratar cada clúster Proxmox como un “silo”, PDM permite ver la infraestructura distribuida de extremo a extremo: clústeres dedicados en distintos racks, CPD redundantes, nodos específicos para cargas de trabajo de IA o bases de datos, e incluso entornos Proxmox alojados on-premise en las instalaciones del cliente y conectados a Stackscale mediante enlaces dedicados o VPN. Esta visión global facilita: - Planificación de capacidad y decisiones de ampliación.** - Detección temprana de cuellos de botella en CPU, RAM o I/O. - Priorización de inversiones en hardware donde más impacto tienen. ### Movilidad de cargas entre clústeres y centros de datos** La funcionalidad de migración en vivo entre clústeres, combinada con la red de Stackscale y las opciones de conectividad entre CPD, abre escenarios interesantes: - Reubicar cargas de producción a un clúster más potente sin parada.** - Vaciar clústeres para realizar migraciones de hardware o cambios de generación. - Preparar movimientos entre centros de datos como parte de una estrategia de resiliencia o salida ordenada de un CPD. Todo ello con una experiencia de operación unificada, en lugar de tener que gestionar cada movimiento como un proyecto manual aislado. ### Mejor gobierno, auditoría y multi-tenant** En organizaciones donde distintos departamentos comparten la misma plataforma Proxmox de Stackscale, Proxmox Datacenter Manager ayuda a: - Definir vistas específicas para cada unidad de negocio, proyecto o cliente interno.** - Limitar el alcance de las operaciones según roles (por ejemplo, permitir a un equipo de desarrollo arrancar/parar VMs de su ámbito, pero no tocar la red ni el almacenamiento compartido). - Centralizar logs y tareas, mejorando la trazabilidad de quién hizo qué, dónde y cuándo. Esto encaja especialmente bien con entornos de misión crítica donde el cumplimiento normativo, la segregación de funciones y la auditoría son requisitos básicos. ### Operación día a día más eficiente** Para equipos que gestionan decenas o cientos de nodos Proxmox en Stackscale, la suma de: - Búsqueda avanzada,** - Panel de tareas unificado, - Actualizaciones centralizadas, - Acceso a shell desde una única consola, reduce fricción en el día a día. Las tareas rutinarias consumen menos tiempo y se reducen errores derivados de trabajar en interfaces dispersas. ## Escenarios de uso típicos en entornos Stackscale** Algunos ejemplos de cómo puede encajar Proxmox Datacenter Manager en arquitecturas reales sobre Stackscale: - **Cloud privado multi-site con DR******Una empresa despliega clústeres Proxmox dedicados en dos centros de datos de Stackscale y mantiene un tercero como site de recuperación ante desastres. Con PDM, los tres entornos se gestionan desde un mismo panel, con capacidad para migrar cargas entre clústeres y monitorizar el estado de los backups y datastores remotos.** - Consolidación tras una migración desde VMware**Tras cambios en licencias y estrategia de VMware, muchas organizaciones están valorando alternativas abiertas y más predecibles en costes. Proxmox, combinado con un proveedor especializado como Stackscale, se ha convertido en una de las opciones recurrentes. Proxmox Datacenter Manager actúa como la pieza que faltaba para operar de forma cómoda múltiples clústeres Proxmox que sustituyen a entornos VMware previos.** - Entornos híbridos on-premise + Stackscale******Un cliente mantiene pequeños clústeres Proxmox en delegaciones o fábricas, y un backbone de clústeres más potentes alojados en Stackscale para cargas centrales. PDM permite gestionar ambos extremos —edge y core— desde la misma plataforma, con métricas agregadas y operaciones coordinadas.** ## Consideraciones de despliegue y soporte** Proxmox Datacenter Manager 1.0 está disponible mediante imagen ISO instalable en bare-metal o sobre una instalación Debian existente, y se distribuye como software libre bajo licencia GNU AGPLv3. Para entornos de producción, Proxmox ofrece suscripciones con acceso a repositorios enterprise y soporte técnico certificado. En el caso de clientes de Stackscale, las opciones más habituales pasan por: - Desplegar PDM como una máquina dedicada (o nodo bare-metal) dentro de su propia plataforma Proxmox en Stackscale.** - Integrarlo con los servicios de directorio corporativos (LDAP/AD/OIDC) y políticas de seguridad existentes. - Definir, con ayuda del equipo de Stackscale, una estrategia de vistas, roles y permisos alineada con cómo se organizan los equipos de sistemas, desarrollo y negocio. Como primera versión estable, es razonable comenzar con un pilotaje bien acotado —por ejemplo, conectando algunos clústeres no críticos— y evolucionar hacia la gestión completa del parque Proxmox a medida que la organización gane confianza en la herramienta. Desde Stackscale ya podemos ayudarte con el despliegue y mantenimiento de tu propio Proxmox Datacenter Manager, no dudes en consultarnos. ## Resumen rápido para administradores** - **Qué es**: plataforma open source de gestión centralizada para Proxmox VE y Proxmox Backup Server, basada en Debian 13,2, kernel 6.17, ZFS 2.3 y desarrollada en Rust.** - Problema que resuelve**: falta de visión global y operaciones unificadas en entornos con múltiples clústeres y nodos distribuidos.** - Claves técnicas**: métricas agregadas, vistas personalizadas con RBAC, búsqueda avanzada, migración en vivo entre clústeres, panel central de actualizaciones, SDN con EVPN, integración con Proxmox Backup Server.** - Valor para clientes de Stackscale**: facilita operar plataformas Proxmox multi-clúster y multi-CPD, mejorar la movilidad de cargas, reforzar gobierno y auditoría, y reducir el tiempo dedicado a tareas rutinarias de operación. Para organizaciones que ya confían en Proxmox sobre la infraestructura de Stackscale —o que están planificando una migración desde otras plataformas de virtualización— Proxmox Datacenter Manager 1.0 se convierte en una pieza estratégica para profesionalizar la gestión del entorno sin renunciar a la filosofía open source ni a la soberanía sobre la infraestructura. --- ## How to prepare your infrastructure for traffic peaks without your site going down URL: https://www.stackscale.com/blog/how-to-prepare-your-infrastructure-for-traffic-peaks-without-your-site-going-down/ On a normal day, everything looks fine: the website is fast, APIs are calm, and monitoring dashboards stay in comfortable ranges. Then a big newsletter goes out, a paid campaign performs better than expected, or Black Week (Black Friday and Cyber Monday) kicks off. Suddenly traffic spikes and you quickly see whether your infrastructure is well designed — or whether every peak turns into a late-night incident. For many projects (eCommerce, SaaS, online banking, media, gaming, etc.), traffic peaks are not an anomaly; they are part of the business model. And when we talk about **mission-critical environments**, with **geo-redundant high availability** and **network storage with synchronous replication**, the margin for error is very small. At Stackscale, where we work every day with **private cloud based on Proxmox or VMware**, **bare-metal servers** and **network storage solutions** for exactly these scenarios, the conclusion is quite clear:**it’s not just about “adding more machines”, it’s about designing the architecture so that these peaks are part of the plan**. ## 1. First things first: really understand your traffic patterns Without data, everything else is just intuition. The first step is having a clear picture of how your platform behaves. Questions you should be able to answer without breaking a sweat: - What does your “normal” traffic look like per hour and per day of the week? - What have your real peaks been over the last 6–12 months, and what triggered them? - Which parts of the platform suffer first under stress? Checkout, login, APIs, internal searches, private area, etc. - At what point do errors, high response times or conversion drops start to appear? To get there, the minimum reasonable approach is to combine: - **Application metrics**: response times per endpoint, error ratios, job queues. - **Infrastructure metrics**: CPU, RAM, disk I/O, network latency, storage usage. - **Business data**: abandoned carts, forms that never complete, support tickets during campaigns. With that base you can start talking about capacity in a meaningful way:**“we want to handle 3× last November’s peak” is very different from“we need something more powerful because the site feels slow”. ## 2. Optimize before you scale: common bottlenecks The most common reaction when a site goes down during a traffic spike is to blame the hosting. And sometimes that’s fair… but very often it’s not the whole story. In practice, we usually see a combination of: ### Heavy frontend - Huge uncompressed images or no use of modern formats. - Too many third-party scripts: tags, pixels, chats, A/B testing tools, etc. - Themes or frontends overloaded with JavaScript that block rendering. The more “expensive” each visit is in terms of resources, the faster your infrastructure saturates — no matter how good your bare-metal servers or private cloud are underneath. ### Backend under pressure - Database queries without proper indexes, or logic that is simply too complex. - Overuse of plugins, modules or extensions that add logic to every request. - Lack of caching (page, fragment or object cache) that forces recalculation on each request. - Tasks that should go to a queue (bulk email sending, report generation, external integrations) running in real time. ### Infrastructure at the limit Even with good code, there are physical limits: - CPU and RAM permanently high during peak hours. - Storage systems or arrays saturated in terms of IOPS. - Virtual machines oversized for secondary services and undersized for the critical path. Practical rule of thumb:****before increasing resources at Stackscale (or anywhere else), it’s highly recommended to: - Clean up frontend and media. - Review database and cache usage. - Remove unnecessary complexity from the backend. Every improvement in this layer means the same hardware can handle more traffic**, and every euro invested in infrastructure delivers better returns. ## 3. From a single server to a peak-ready architecture Many projects start on a single server (physical or virtual) acting as a “Swiss army knife”: web, database, cache, cron jobs, queues… all in one place. It works — until it doesn’t. Once the business depends on that platform or traffic grows, priorities shift to: - Reducing single points of failure. - Separating responsibilities. - Being able to add capacity without breaking everything. ### Typical architectures we see in critical environments A very common pattern in **private cloud or bare-metal** deployments: - **Several application nodes** behind one or more load balancers. - A **separate database**, with the option of read replicas when volume requires it. - A **cache/intermediate storage layer** (for example Redis, Varnish cache, other cache proxies, etc.). - **Centralised, redundant network storage**, simplifying high availability setups. At Stackscale, many customers choose this type of architecture from the start or grow into it in stages, especially when: - They cannot afford prolonged downtime windows. - Traffic growth is structural, not just occasional. - There are demanding requirements in terms of compliance, audits or internal SLAs. ## 4. Geo-redundant high availability and synchronous replication: taking “plan B” seriously When we talk about **mission-critical** workloads, it’s not enough that one node can replace another inside the same data center. You also have to consider: - Full data center failures. - Network issues at carrier level. - Serious incidents at region/city level. This is where concepts such as: - **Geo-redundancy** come in: having resources ready in a secondary data center that can take over if the primary fails. - **Synchronous storage replication between data centers**: writes are only confirmed once they have been stored on both sides, minimizing the risk of data loss in case of a failure. This kind of architecture makes sense when: - The acceptable **RPO** is practically 0 (you cannot lose transactions). - The expected **RTO** is very low (recovery in minutes). - The impact of a prolonged outage clearly outweighs the additional cost of geo-redundancy. In this context, a provider like Stackscale brings: - Redundantly interconnected data centers. - Network storage solutions designed for synchronous replication. - Technical teams used to sizing and operating this kind of environment. ## 5. Capacity planning: enough headroom without paying for over-engineering all year long The practical question is: **how much headroom do I really need?** You don’t want an infrastructure that is permanently oversized, nor do you want to run “in the red” all the time: - **Start from real peaks**, not gut feelings. Put the actual graphs of your strongest days on the table. - **Define a reasonable target**: For example, handle **3× your current peak** with acceptable response times. - **Translate that into infrastructure**: How many application nodes? - What size and type of bare-metal servers or private cloud resources? - What minimum performance do you need from network storage? - **Design growth steps with your provider**: Increase CPU/RAM for VMs without stopping the service. - Add nodes to the application cluster. - Increase capacity and performance of network storage and the inter-DC network. Here the advantage of a **hosted private cloud** versus on-premise is obvious: you can grow step by step, with more predictable costs and without over-provisioning your own hardware “just in case”. ## 6. Dress rehearsal: test the limit before your next campaign You don’t want to discover your limits on the day of your biggest campaign of the year. The sensible approach is to run a **dress rehearsal** in advance. Minimum test elements: - **Load tests on critical paths** (homepage, search, listing pages, product pages, login, checkout, APIs). - **Fine-grained monitoring during tests**: Response times. - CPU/RAM usage. - I/O latency and saturation. - Application errors. - **Failure simulations**: Remove one application node from the load balancer and see how the system reacts. - Test how the platform behaves with partial storage or network failures (where the environment allows, always in coordination with the infrastructure team). The outcome should be a concrete list of: - Configuration parameters to adjust. - Resources to increase (or rebalance). - Internal procedures for campaign day (what to watch, how often, who decides what). ## 7. “Good” peaks vs “bad” peaks: campaigns vs DDoS Not every traffic spike is good news. On top of successful campaigns, you also have: - DDoS attacks at network or layer-7 (HTTP) level. - Bots crawling or attacking forms. - Automated traffic trying to exploit vulnerabilities. To avoid mixing everything together, you need: - **Visibility**: the ability to detect anomalous behaviour by IP pattern, user-agent, country, path, etc. - **Mitigation measures**: WAF with specific rules. - Rate limiting on sensitive endpoints. - Upstream DDoS protection and/or use of a CDN where it makes sense. - **Response procedures**: What to do if traffic suddenly explodes and it’s not linked to a planned campaign. - How to coordinate with your infrastructure provider to filter at network level before the attack reaches your nodes. A solid architecture helps, but the security layer and procedures are just as important to ensure **good peaks add value and bad peaks don’t take anything down**. ## Conclusion Traffic peaks are not going away; in fact, they are becoming more frequent and more abrupt. The difference lies in whether your infrastructure: - Suffers them as an unpredictable problem, or - Absorbs them as something already accounted for in the design. With **private cloud, bare-metal servers, network storage and synchronous replication between data centers**, and an architecture built for **geo-redundant high availability**, you can move from “surviving as best you can” to **planning growth intelligently**. If you’re reviewing your mission-critical platform or preparing your next major campaign, this is a **good time to sit down with the Stackscale team**, look at real data and define together what you need so that the next traffic peak is good news — not the start of an incident. ## FAQ on traffic peaks and infrastructure architecture **1. What’s the difference between vertical and horizontal scaling to handle traffic peaks?****Vertical scaling means giving more resources to a single machine (more CPU, RAM, etc.). It’s simple and works well up to a point, but it has a physical limit and it remains a single point of failure.Horizontal scaling means distributing the load across multiple application nodes behind one or more load balancers. It requires more architectural work, but offers better resilience and more room to grow, especially in mission-critical, high-availability environments. 2. What role does a private cloud provider like Stackscale play compared to an on-premise solution?****On-premise, you handle everything: hardware purchase, installation, maintenance, spare parts, growth planning, etc.With hosted private cloud and bare-metal servers** at Stackscale, you delegate the physical and data center layers (power, networking, hardware, replacements, etc.) and focus on the system and application layers. On top of that, you get **geo-redundancy options between data centers** and **network storage prepared for synchronous replication**, which is much harder to implement efficiently in a single on-premise data center. **3. How do I know if I really need geo-redundancy and synchronous replication, or if a single data center is enough?****It depends on your RPO/RTO and the real cost of downtime. If your business can afford to lose a few minutes of data and be offline for a while while the primary data center recovers, a solid high-availability setup within one DC might be enough.If, on the other hand, every minute of downtime has a serious impact (economic, regulatory or reputational) and you cannot afford to lose transactions, the usual approach is to plan for two data centers** and some form of replication (synchronous or asynchronous, depending on the case). The final recommendation comes from balancing **risk vs cost**. **4. How often should I run load tests on my platform?****A sensible minimum is to run them: - Before major predictable campaigns (Singles’ Day, Black Friday, Cyber Monday, Black Week, big product launches, etc.). - After significant architectural changes (new application version, database change, new provider, etc.). In very dynamic projects, some companies integrate them into their CI/CD cycle on a regular basis (for example monthly or quarterly). The key idea is to avoid letting changes in application and infrastructure pile up for years** without checking again how the system behaves under stress. --- ## Cómo preparar tu infraestructura para picos de tráfico sin que el sitio se caiga URL: https://www.stackscale.com/blog/how-to-prepare-your-infrastructure-for-traffic-peaks-without-your-site-going-down/ En un día normal todo va razonablemente bien: la web responde ágil, las APIs no se quejan y las gráficas de monitorización se mueven en rangos cómodos. Hasta que llega una newsletter importante, una campaña de pago empieza a funcionar mejor de lo previsto o arranca la Black Week (BlackFriday y Cibermonday). De repente, el tráfico se dispara y se ve rápido si tu infraestructura está bien pensada o si cualquier pico se convierte en una guardia de madrugada. Para muchos proyectos (eCommerce, SaaS, banca online, medios, gaming, etc.), los picos de tráfico no son una anomalía, sino parte del negocio. Y cuando hablamos de **entornos de misión crítica**, con **alta disponibilidad geográfica** y **almacenamiento en red con replicación síncrona**, el margen de error es muy pequeño. Desde Stackscale, donde trabajamos a diario con **cloud privado con Proxmox o VMware, servidores bare-metal y soluciones de almacenamiento en red** para este tipo de escenarios, la conclusión es bastante clara:**no se trata solo de “poner más máquinas”, sino de diseñar la arquitectura** para que esos picos formen parte del plan. ## 1. Antes de nada: entender de verdad tus patrones de tráfico Sin datos, todo lo demás es intuición. El primer paso es tener una foto clara de cómo se comporta tu plataforma. Preguntas que deberías poder contestar sin sudar: - ¿Cuál es tu tráfico “normal” por hora y por día de la semana? - ¿Cuáles han sido tus picos reales de los últimos 6–12 meses y qué los disparó? - ¿Qué partes de la plataforma sufren primero cuando hay estrés? Checkout, login, APIs, búsquedas internas, área privada, etc. - ¿En qué punto empiezan a aparecer errores, tiempos de respuesta altos o caídas de conversión? Para esto, lo mínimo razonable es combinar: - **Métricas de aplicación**: tiempos de respuesta por endpoint, proporción de errores, colas de trabajo. - **Métricas de infraestructura**: CPU, RAM, I/O de disco, latencias de red, consumo de almacenamiento. - **Datos de negocio**: carritos abandonados, formularios que no se completan, tickets de soporte durante campañas. Con esa base puedes empezar a hablar de capacidad con sentido: “queremos soportar 3x el pico de noviembre pasado” es muy distinto a “necesitamos algo más potente porque la web va justa”. ## 2. Optimizar antes de escalar: los cuellos de botella habituales Lo más habitual cuando una web se cae en un pico de tráfico es culpar al hosting. Y a veces es cierto… pero muchas veces no. En la práctica, solemos ver una combinación de: ### Frontend pesado - Imágenes gigantes sin comprimir o sin formatos modernos. - Demasiados scripts de terceros: tags, píxeles, chats, A/B testing, etc. - Temas o frontends muy cargados de JavaScript que bloquean el renderizado. Cuanto más “cara” es cada visita en términos de recursos, antes se satura la infraestructura, por muy buenos que sean tus servidores bare-metal o tu cloud privado. ### Backend sin respiración - Consultas a base de datos sin índices, o con lógica demasiado compleja. - Abuso de plugins, módulos o extensiones que añaden lógica en cada petición. - Falta de **caché** (de página, de fragmentos o de objetos) que obligue a recalcular todo en cada request. - Tareas que deberían ir a una cola (envío masivo de emails, generación de informes, integraciones externas) ejecutándose en tiempo real. ### Infraestructura al límite Incluso con buen código, hay límites físicos: - CPU y RAM permanentemente altos en las horas de más uso. - Cabinas o sistemas de almacenamiento saturados de IOPS. - Máquinas virtuales sobredimensionadas en servicios secundarios y subdimensionadas en la parte crítica. **Regla práctica**:**antes de subir recursos en Stackscale (o donde sea), es muy recomendable: - Limpiar frontend y medios. - Revisar base de datos y caché. - Quitar complejidad innecesaria en el backend. Cada mejora en esta capa hace que el mismo hardware aguante más tráfico** y que cada euro invertido en infraestructura rinda mejor. ## 3. De servidor único a arquitectura preparada para picos Muchos proyectos empiezan en un único servidor (físico o virtual) que hace de “navaja suiza”: web, base de datos, caché, cron, colas… todo junto. Funciona, hasta que deja de hacerlo. En cuanto el negocio depende de esa plataforma o crece el tráfico, la prioridad pasa a ser: - Reducir puntos únicos de fallo. - Separar responsabilidades. - Poder añadir capacidad sin tirar nada abajo. ### Arquitecturas típicas que vemos en entornos críticos Un patrón bastante frecuente en despliegues sobre **cloud privado o bare-metal**: - **Varios nodos de aplicación** detrás de uno o más balanceadores de carga. - **Base de datos separada**, con opción de réplicas de lectura cuando el volumen lo exige. - **Capa de caché/almacenamiento intermedio** (por ejemplo, Redis, Varnish cache, proxies de caché, etc.). - **Almacenamiento en red centralizado**, redundado, para simplificar la alta disponibilidad. En Stackscale, muchos clientes optan por este tipo de arquitectura desde el principio o la van alcanzando por fases, especialmente cuando: - No se pueden permitir ventanas de caída prolongadas. - El crecimiento del tráfico ya es estructural, no puntual. - Hay requisitos de cumplimiento, auditoría o SLA internos exigentes. ## 4. Alta disponibilidad geográfica y replicación síncrona: pensando en serio en el “plan B” Cuando hablamos de **misión crítica**, no basta con que un nodo sustituya a otro dentro del mismo centro de datos. También hay que pensar en: - Fallos de CPD completo. - Problemas de red a nivel de operador. - Incidencias graves a nivel de región/ciudad. Aquí entran conceptos como: - **Georedundancia**: tener recursos listos en un centro de datos secundario que pueda asumir cargas si el principal falla. - **Replicación síncrona de almacenamiento** entre CPDs: las escrituras se confirman solo cuando se han almacenado en ambos lados, minimizando el riesgo de pérdida de datos en caso de caída. Este tipo de arquitectura tiene sentido cuando: - El RPO aceptable es prácticamente 0 (no puedes perder transacciones). - El RTO esperado es muy bajo (recovery en minutos). - El impacto de una caída prolongada supera con creces el coste adicional de la georedundancia. En este contexto, un proveedor como Stackscale aporta: - Centros de datos interconectados de forma redundante. - Soluciones de almacenamiento en red diseñadas para replicación síncrona. - Equipos técnicos acostumbrados a dimensionar y operar este tipo de entornos. ## 5. Plan de capacidad: margen suficiente sin pagar “sobre-ingeniería” todo el año La pregunta práctica es: **¿cuánto margen necesito realmente?** Ni infra sobredimensionada permanentemente, ni ir siempre “en rojo”: - **Parte de picos reales**, no de sensaciones. Trae a la mesa las gráficas reales de tus días más fuertes. - **Define un objetivo razonable**: Por ejemplo, soportar **3x tu pico actual** con tiempos de respuesta aceptables. - **Traduce eso a infraestructura**: ¿Cuántos nodos de aplicación? - ¿Qué tamaño y tipo de servidores bare-metal o recursos de cloud privado? - ¿Qué rendimiento mínimo necesitas en el almacenamiento en red? - **Diseña escalones de crecimiento** con tu proveedor: Subir CPU/RAM de las VMs sin parar el servicio. - Añadir nodos al clúster de aplicación. - Aumentar capacidad y rendimiento del almacenamiento en red y de la red entre CPDs. La ventaja del **cloud privado alojado** frente al on-premise aquí es clara: puedes crecer por pasos, con costes más predecibles y sin tener que sobredimensionar hardware propio “por si acaso”. ## 6. Ensayo general: probar el límite antes de la próxima campaña No quieres descubrir tus límites el día de tu mayor campaña del año. Lo razonable es hacer un ensayo general con antelación. Elementos mínimos del test: - **Pruebas de carga** a rutas críticas (inicio, buscador, listados, fichas, login, checkout, APIs). - **Monitorización fina** durante las pruebas: Tiempos de respuesta. - Uso de CPU/RAM. - Latencia y saturación de I/O. - Errores de aplicación. - **Simulación de fallos**: Quitar un nodo de aplicación del balanceo y ver cómo responde el sistema. - Probar cómo se comporta la plataforma ante un fallo parcial de almacenamiento o red (cuando el entorno lo permite, siempre en coordinación con el equipo de infraestructura). El resultado debería ser una lista concreta de: - Parámetros de configuración a ajustar. - Recursos que ampliar (o reequilibrar). - Procedimientos internos para el día de la campaña (qué mirar, cada cuánto, quién decide qué). ## 7. Picos “buenos” vs picos “malos”: campañas frente a DDoS No todo pico de tráfico es una buena noticia. A las campañas exitosas se suman: - Ataques DDoS a nivel de red o de capa 7 (HTTP). - Bots que rastrean o atacan formularios. - Tráfico automatizado que intenta explotar vulnerabilidades. Para no mezclarlo todo, necesitas: - **Visibilidad**: poder distinguir comportamientos anómalos por patrones de IP, user-agent, país, ruta, etc. - **Medidas de mitigación**: WAF con reglas específicas. - Rate limiting en endpoints sensibles. - Protección DDoS aguas arriba y/o uso de CDN allí donde tenga sentido. - **Procedimientos de respuesta**: Qué hacer si el tráfico se dispara de repente y no corresponde a una campaña planificada. - Cómo coordinarse con el proveedor de infraestructura para filtrar en red antes de que el ataque llegue a los nodos. Una buena arquitectura ayuda, pero la capa de seguridad y los procedimientos son igual de importantes para que **los picos buenos sumen y los malos no tiren nada abajo**. ## Conclusión Los picos de tráfico no van a desaparecer; al contrario, cada vez son más frecuentes y bruscos. La diferencia está en si tu infraestructura: - Los sufre como un problema imprevisible, o - Los absorbe como algo previsto en el diseño. Con **cloud privado, servidores bare-metal, almacenamiento en red y replicación síncrona entre centros de datos**, y una arquitectura pensada para alta disponibilidad geográfica, puedes pasar de “aguantar como se pueda” a **planificar el crecimiento con cabeza**. Si estás revisando tu plataforma de misión crítica o preparando tu próxima gran campaña, es **buen momento para sentarse con el equipo de Stackscale**, revisar datos reales y definir juntos qué necesitas para que el próximo pico de tráfico sea una buena noticia, y no el inicio de una incidencia. ## FAQ sobre picos de tráfico y arquitectura de infraestructura **1. ¿Qué diferencia hay entre escalar vertical y horizontalmente para gestionar picos de tráfico?****Escalar verticalmente** significa dar más recursos a una misma máquina (más CPU, RAM, etc.). Es sencillo y funciona bien hasta cierto punto, pero tiene límite físico y sigue siendo un único punto de fallo.**Escalar horizontalmente** implica repartir la carga entre varios nodos de aplicación detrás de uno o varios balanceadores. Es más trabajo de arquitectura, pero ofrece mejor resiliencia y más margen para crecer, especialmente en entornos de misión crítica y alta disponibilidad. **2. ¿Qué papel juega un proveedor de cloud privado como Stackscale frente a una solución on-premise?****En on-premise tú te encargas de todo: compra de hardware, instalación, mantenimiento, repuestos, crecimiento, etc.Con un cloud privado alojado y servidores bare-metal** en Stackscale, delegas la parte física y de centro de datos (energía, red, hardware, reemplazos, etc.) y te centras en la capa de sistema y aplicación. Además, dispones de opciones de **georedundancia** entre CPDs y **almacenamiento en red** preparado para replicación síncrona, algo más complejo de conseguir de forma eficiente en un único CPD on-premise. **3. ¿Cómo sé si necesito georedundancia y replicación síncrona o con un solo centro de datos me basta?****Depende de tu RPO/RTO y del coste real de una caída. Si tu negocio puede asumir perder algunos minutos de datos y estar fuera de servicio un rato mientras se recupera el CPD principal, quizá una buena alta disponibilidad interna sea suficiente.Si, en cambio, cada minuto de caída implica un impacto serio (económico, regulatorio o de reputación) y no puedes permitirte perder transacciones, lo habitual es plantear dos centros de datos** y algún tipo de replicación (síncrona o asíncrona, según el caso). La recomendación final sale del cruce entre **riesgo y coste**. **4. ¿Cada cuánto tiempo debería repetir pruebas de carga en mi plataforma?****Lo razonable es hacerlas al menos: - Antes de grandes campañas previsibles (Single Day, Black Friday, Cibermonday, Black Week, lanzamientos importantes, etc.). - Después de cambios relevantes en la arquitectura (nueva versión de la aplicación, cambio de base de datos, nuevo proveedor, etc.). En proyectos muy dinámicos, hay empresas que las integran en su ciclo de CI/CD de forma periódica (por ejemplo, mensual o trimestral). La idea es que los cambios en la aplicación y en la infraestructura no se acumulen durante años** sin volver a comprobar cómo responde el sistema bajo estrés. --- ## From High Availability to a Real Plan B: Lessons from the Latest AWS Outage and a Practical Guide URL: https://www.stackscale.com/blog/from-high-availability-to-a-real-plan-b/ AWS’s October 20 outage reminded us of a simple truth: **resilience can’t be improvised**. **High availability (HA)** within a single region helps, but it doesn’t replace a **plan B** that keeps services running when the **common element** too many components depend on fails (region, control plane, DNS, queues, identity, etc.). This guide lays out a **practical path** from “HA” to **business continuity**, with patterns we see working in production—and that we at Stackscale implement with **two active-active data centers**. When required, these architectures **combine smoothly with other providers**. It all starts with the basics: **define RTO/RPO** and **rehearse** failover. ** David Carrero (Stackscale co-founder):** “HA is necessary, but if **everything** hinges on a **single common point**, **HA fails**. The difference between a scare and a crisis comes down to a **rehearsed plan B**.” ## 1) Align business and tech: RTO/RPO and a dependency map - **RTO (Recovery Time Objective):** how long a service can be **down**. - **RPO (Recovery Point Objective):** how much **data loss** (in time) you can accept when restoring. With those targets **signed off by the business**, draw the **dependency map**: what breaks what? Where do **identity**, **DNS**, **queues**, **catalogs**, or **global tables** really **anchor**? The output is your list of **services that can’t go down**—and **what they depend on**. ## 2) Continuity patterns that actually work ### Active–active across two data centers (RTO=0 / RPO=0) For **payments**, **identity**, or **core transactions**: - **Synchronous storage replication** between both DCs → **RTO=0 / RPO=0**. - **Distributed / quorum databases**, with conflict handling (CRDTs / sagas). - **DNS/GTM** with **real service health checks** (not just pings). - **Degrade modes** pre-defined (read-only, feature flags). At Stackscale we offer **active–active** across **two European data centers** with **synchronous replication** as a mission-critical foundation. You can **complement** that core with third parties (hyperscalers or other DCs) if you need a **third continuity path** or sovereignty/localization guarantees. ### Multi-site warm standby (hot passive) For most important workloads: - **Asynchronous data replication** to a second site. - **Pre-provisioned infrastructure** (templates / IaC) to promote site B in **minutes**. - **Automatic failover** via **DNS/GTM** and **rehearsed runbooks**. ### Minimum footprint at an alternate provider (formerly “pilot-light”) When you want to **lower concentration risk** at a reasonable cost: - Keep the **bare minimum running** outside your primary provider (e.g., **DNS**, **observability**, **immutable backups**, **break-glass identity**, **status page**). - Promote to **active-passive** or **active-active** only what’s **truly critical**, based on RTO/RPO. ** Carrero:** “It’s not about abandoning hyperscalers—it’s about **balancing**. The **European ecosystem**—Spain included—is **mature** and a strong **complement** for resilience and sovereignty.” ## 3) Three layers that move the needle (and how to handle them) **Data** - **Transactional:** **quorum-based distribution** + **conflict control**. - **Objects:** **versioning + inter-site replication**, **immutability** (WORM lock) and, where needed, **air-gap**. - **Catalogs/queues:** avoid “global” services **anchored in a single external region** if your RTO/RPO can’t tolerate it. **Network / DNS / CDN** - **Two DNS providers** and **GTM** with **business-level probes** (a real “health transaction,” not a ping). - **Multi-CDN** and **alternate origins** (A/A or A/P) with **origin shielding**. - **Redundant private connectivity** (overlay SD-WAN) between cloud and DC. **Identity & access** - **IdP** with **key (JWKS) caching** and **contextual re-auth**. - **Break-glass accounts** **outside the failure domain**, protected by **strong MFA** (hardware keys). - **App governance** to stop **consent phishing** and **OAuth abuse**. ## 4) Observability, backups, and drills: without these, there’s no plan B - **Observability outside the same failure domain:** at least one **mirror** of metrics/logs and a **status page** that **don’t** depend on the primary provider. - **Immutable backups** and **timed restore drills** (with **recent success**). - **Quarterly gamedays:** region/IdP/DNS/queue/DB failures. Measure **real RTO**, **dwell time**, and **MTTR**. ## 5) Two reference architectures (and how they fit with Stackscale) ### All-in with Stackscale continuity - **DC A + DC B** (Stackscale) in **active–active** with **synchronous replication** (RTO=0/RPO=0). - **Immutable backups** in a **third domain** (another DC or isolated object storage). - **Multi-provider DNS/DNSSEC** + **GTM** with business health checks. - **Observability** mirrored out (dedicated provider or a second Stackscale site). - **Runbooks** and **regular gamedays** with local, 24/7 support. ### Hybrid continuity (Stackscale + another location/provider) - **DC A + DC B** (Stackscale) **active–active** for the **core**. - **Minimum footprint** at another provider for **DNS**, **status**, **logs/SIEM**, and **immutable object storage** (or vice versa). - **Non-critical workloads** at the other location, with **DR back to Stackscale** if sovereignty or cost requires it. - **Private connectivity** and **portable policies** (identity, logging, backup). **What Stackscale brings** (without the sales pitch): - **Two European data centers** with **low latency**, **redundant power & networks**, and **nearby 24/7 support**. - **Synchronous replication** for mission-critical apps (**RTO=0/RPO=0**). - **High-performance storage** (block/object) with **versioning** and **WORM lock (Object Lock)** for **immutable backups**. - **Bare-metal and private cloud** to consolidate workloads, plus **dedicated connectivity** with carriers and public clouds via partners. - Easy integration with **external providers** (DNS, CDN, observability, hyperscalers) for **hybrid or selective multicloud** strategies. ## 6) A realistic 30-60-90 day roadmap **Days 1–30** - Get **RTO/RPO** approved per service. - Build the **dependency & global-anchor map**. - **Immutable backups** and your **first timed restore**. **Days 31–60** - **Multi-provider DNS/GTM**, **multi-CDN**, and **observability outside** the same failure domain. - **Minimum footprint** (emergency identity, status, SIEM). - First **gameday** (DNS + DB/queues). **Days 61–90** - **Active–active** or **warm standby** between Stackscale’s two DCs. - Integrations with **third parties** (if needed). - **Full-region failure gameday** and metrics review. ## 7) Executive metrics that actually say something - **% of services** with **signed RTO/RPO** and **met in drills**. - **Restore OK** (last 30 days) and **average restore time**. - **Failover time** (gamedays) and **dwell time** by scenario. - **Observability coverage “outside”** the failure domain (yes/no by domain). - **“Global” dependencies with alternatives** (yes/no). ## Final word: resilience with a clear head (and without handcuffs) The lesson isn’t to “flee the cloud,” but to **design for failure** and **de-concentrate** single points of breakage. **HA** is necessary, but not sufficient: you need a **complete alternate route** to the same outcome. With **two active–active DCs** (**RTO=0/RPO=0**) as the base and **continuity layers**—DNS, immutable copies, observability, and break-glass identity—**outside the same failure domain**, your platform will stay up when a provider or region stumbles. At Stackscale, we support that transition every day. And when continuity goals or regulations call for it, we **combine** our **two-data-center** infrastructure with **other providers**. That way, plan B isn’t a PDF in a drawer—it’s a **path you’ve already walked**. --- ## De la alta disponibilidad al plan B real: aprendizajes del último apagón de AWS y una guía práctica URL: https://www.stackscale.com/blog/from-high-availability-to-a-real-plan-b/ El incidente de AWS del 20 de octubre volvió a recordarnos lo de siempre: **la resiliencia no se improvisa**. La **alta disponibilidad (HA)** dentro de una región ayuda, pero **no sustituye** un plan B capaz de mantener el servicio cuando falla **el elemento común** del que dependen demasiadas piezas (región, plano de control, DNS, colas, identidad, etc.). En esta guía compartimos un enfoque **práctico** para pasar de “HA” a **continuidad de negocio**, con patrones que vemos funcionar en producción y que en Stackscale implementamos con **dos centros de datos en activo-activo**. Y, cuando el negocio lo requiere, **se combinan** sin fricciones con otros proveedores. Todo empieza por lo básico: **definir RTO/RPO** y **ensayar** la conmutación. ** David Carrero (cofundador de Stackscale)**: “La **HA** es necesaria, pero si **todo** depende de un **punto común**, **HA falla**. La diferencia entre un susto y una crisis la decide un **plan B ensayado**”. ## 1) Alinear negocio y tecnología: RTO/RPO y mapa de dependencias - **RTO** (Recovery Time Objective): cuánto **tiempo** puede estar parado un servicio. - **RPO** (Recovery Point Objective): cuántos **datos** puedes **perder** (en tiempo) al recuperar. Con esos objetivos **firmados por negocio**, dibuja el **mapa de dependencias**: ¿qué rompe a qué?, ¿dónde “ancoran” **identidad**, **DNS**, **colas**, **catálogos** o **tablas globales**? La salida de ese análisis es tu lista de **servicios que no pueden caer** y **de qué dependen**. ## 2) Patrones de continuidad que sí funcionan ### Activo-activo en dos centros de datos (RTO=0 / RPO=0) Para **pagos**, **identidad** o **transacciones** core: - **Replicación síncrona** de almacenamiento entre los dos CPDs → **RTO=0 / RPO=0**. - **BBDD distribuidas** o con **quórum**, con contención de conflictos (CRDTs / *sagas*). - **DNS/GTM** con *health checks* de **servicio real** (no pings). - **Modos degradados** definidos (lectura-solo, *feature flags*). En Stackscale ofrecemos **activo-activo** en **dos centros de datos** de Europa con **replicación síncrona** como base de misión crítica. Ese núcleo puede **complementarse** con terceros (hiperescalares u otros CPD) si necesitas una **tercera vía de continuidad** o requisitos de soberanía/localización. ### Espera caliente multisitio (activo-pasivo “caliente”) Para la mayoría de cargas importantes: - **Replicación asíncrona** de datos a un segundo site. - **Infra preaprovisionada** (plantillas / IaC) para elevar el site B en **minutos**. - **Failover automático** vía **DNS/GTM** y *runbooks* **ensayados**. ### Encendido mínimo en proveedor alterno (antes “pilot-light”) Cuando quieres **reducir concentración de riesgo** con coste controlado: - Mantén **lo mínimo encendido** fuera del proveedor principal (p. ej., **DNS**, **observabilidad**, **backups inmutables**, **identidad de emergencia**, *status page*). - Eleva a **activo-pasivo** o **activo-activo** solo lo **crítico**, según RTO/RPO. ** Carrero**: “No se trata de abandonar a los hiperescalares, sino de **equilibrar**. El **ecosistema europeo** —incluida España— es **maduro** y **complementa** muy bien para resiliencia y soberanía”. ## 3) Tres capas que mueven la aguja (y cómo tratarlas) **Datos** - **Transaccional**: distribución por **quórums** + control de **conflictos**. - **Objetos**: **versionado + replicación entre sites**, **inmutabilidad** (bloqueo WORM) y, si aplica, **air-gap**. - **Catálogos/colas**: evita servicios “globales” **anclados en una única región externa** si tu RTO/RPO no lo tolera. **Red / DNS / CDN** - **Dos proveedores de DNS** y **GTM** con pruebas **de negocio** (una transacción de salud, no un simple ping). - **Multi-CDN** y **orígenes alternos** (A/A o A/P) con *origin shielding*. - **Conectividad privada redundante** (overlay SD-WAN) entre nube y CPD. **Identidad y acceso** - **IdP** con **caché de claves** (JWKS) y **re-autenticación contextual**. - **Cuentas “break-glass”** fuera del **dominio de fallo** con **MFA fuerte** (llaves hardware). - **App governance** para frenar **consent phishing** y abusos de **OAuth**. ## 4) Observabilidad, copias y ensayo: sin esto no hay plan B - **Observabilidad fuera del mismo fallo**: al menos un *mirror* de métricas/logs y una **status page** que **no** dependan del proveedor principal. - **Backups inmutables** y **restauración cronometrada** (con éxito reciente). - **Gamedays** trimestrales: caída de **región/IdP/DNS/colas/BBDD**. Mide **RTO real**, **dwell time** y **MTTR**. ## 5) Dos arquitecturas de referencia (y cómo encajan con Stackscale) ### Continuidad “todo Stackscale” - **CPD A + CPD B** (Stackscale) en **activo-activo** con **replicación síncrona** (RTO=0/RPO=0). - **Backups inmutables** en un **tercer dominio** (otro CPD u *object storage* aislado). - **DNS/DNSSEC** multi-proveedor + **GTM** con *health checks* de negocio. - **Observabilidad** replicada fuera (proveedor dedicado o segundo Stackscale). - **Runbooks** y **gamedays** regulares con soporte de proximidad. ### Continuidad híbrida (Stackscale + otra ubicación/proveedor) - **CPD A + CPD B** (Stackscale) **activo-activo** para lo **core**. - **Encendido mínimo** en otro proveedor para **DNS**, **status**, **logs/SIEM** y **objeto inmutable** (o a la inversa). - **Workloads no críticos** en la otra ubicación, con **DR de vuelta** a Stackscale si exige **soberanía** o **coste**. - **Conectividad privada** y **políticas portables** (identidad, logging, backup). **Qué aporta Stackscale**: - **Dos centros de datos** en Europa con **latencia baja**, **redes y energía redundantes**, y **soporte 24/7** cercano. - **Replicación síncrona** para aplicaciones de misión crítica (**RTO=0/RPO=0**). - **Almacenamiento** de alto rendimiento (bloque/objeto) con **versionado** y **bloqueo WORM** (*Object Lock*) para **copias inmutables**. - **Bare-metal y cloud privado** para consolidar cargas, y **conectividad dedicada** con operadores y nubes públicas a través de socios. - Integración sencilla con **proveedores externos** (DNS, CDN, observabilidad, hiperescalas) para **estrategias híbridas o multicloud selectivas**. ## 6) Hoja de ruta 30-60-90 días (realista y accionable) **Día 1–30** - Aprobación **RTO/RPO** por servicio. - **Mapa de dependencias** y **anclas globales**. - **Backups inmutables** y primer **restore cronometrado**. **Día 31–60** - **DNS/GTM** multi-proveedor, **multi-CDN** y **observabilidad fuera** del mismo dominio de fallo. - **Encendido mínimo** (identidad de emergencia, status, SIEM). - Primer **gameday** (DNS + BBDD/colas). **Día 61–90** - Despliegue **activo-activo** o **espera caliente** entre los dos CPDs de Stackscale. - Integraciones con **terceros** (si aplican). - **Gameday** de caída de región completa y **revisión de métricas**. ## 7) Métricas ejecutivas que sí dicen algo - **% de servicios** con **RTO/RPO firmados** y **cumplidos** en ensayo. - **Restore OK** (últimos 30 días) y **tiempo medio** de restauración. - **Tiempo de conmutación** (gamedays) y **dwell time** por escenario. - **Cobertura de observabilidad “fuera”** del fallo (sí/no por dominio). - **Dependencias “globales” con alternativa** (sí/no). ## Cierre: resiliencia con cabeza (y sin atarse las manos) La lección no es “huir del cloud”, sino **diseñar para fallar** y **desconcentrar** puntos únicos de ruptura. La **HA** es necesaria, pero no basta: hace falta **otra ruta completa** hacia el mismo resultado. Con **dos CPDs en activo-activo** (**RTO=0/RPO=0**) como base y **capas de continuidad** —DNS, copias inmutables, observabilidad e identidad de emergencia— **fuera del mismo dominio de fallo**, tu plataforma seguirá en pie cuando un proveedor o una región tropiece. En Stackscale acompañamos esa transición todos los días. Y, cuando lo piden los objetivos de continuidad o la regulación, **combinamos** nuestra infraestructura en **dos centros de datos** con **otros proveedores**. Así el plan B deja de ser un PDF en un cajón y pasa a ser **un camino ya transitado**. Request information form ES Updates NombreEmailTeléfonoEstoy interesado/a en:Soluciones cloudSoluciones Bare MetalServicios gestionadosSoluciones de Disaster Recovery y backupServicios de housingSoluciones de CDNCuéntanos más sobre tus necesidades Acepto el envío de comunicaciones comerciales personalizadas sobre los productos y servicios de Stackscale (incluida la newsletter), por cualquier medio, incluidos los electrónicos. He leído y acepto la política de privacidad. Enviar El Grupo Stackscale trata la información que nos facilita con el fin de dar respuesta a la solicitud realizada en relación con los servicios que prestamos y los productos que suministramos. Los datos proporcionados se conservarán mientras se mantenga el contacto siendo eliminados una vez finalizada la solicitud, a no ser que consienta el envío de comunicaciones comerciales, donde sus datos se conservarán hasta la revocación del consentimiento previamente otorgado. En el marco del Grupo al que pertenece Stackscale, se le informa de que sus datos serán comunicados a las empresas de Grupo Aire por motivos corporativos. Puede consultar las empresas que forman parte del Grupo Aire en: https://grupoaire.es. Usted puede ejercitar sus derechos de acceso, rectificación, supresión, oposición, limitación del tratamiento y, cuando legalmente proceda, portabilidad, mediante el envío a Stackscale de una solicitud a la dirección dp*@********le.com, indicando el derecho que ejercita y aportando una fotocopia por las dos caras de su DNI o documento legal de identificación de su identidad. Igualmente, podrá presentar una reclamación ante la Agencia Española de Protección de Datos, especialmente cuando no haya obtenido la satisfacción en el ejercicio de sus derechos, a través de la sede electrónica en www.aepd.es. --- ## VMware vs Proxmox VE: how to choose (for real) for your virtualization platform URL: https://www.stackscale.com/blog/vmware-vs-proxmox-how-to-choose/ At Stackscale we work with **VMware vSphere** and **Proxmox VE** every day. Our approach isn’t to “force” a tool, but to **fit the platform to the project’s requirements** (technical, operational, and business). Below is a practical analysis—aligned with Stackscale’s editorial style—of **when each technology makes sense** and how that translates into operations, cost, and risk. ## Why one-to-one comparisons are often unfair - **VMware vSphere** is an **end-to-end product** with decades of evolution and a broad ecosystem (vCenter, vSAN, etc.), aimed at **enterprise** environments that require **certifications, compatibility matrices, and formal support**. - **Proxmox VE** is an **open distribution** that integrates very mature technologies—**KVM/QEMU** (hypervisor), **LXC** (containers), **ZFS** and **Ceph** (storage)—behind a **solid web console** and **API/CLI** (Application Programming Interface / Command-Line Interface). The value isn’t about “who checks more boxes,” but **what you actually use** today and across the project’s lifecycle (3–5 years). ## Where VMware fits… and where Proxmox shines ### When VMware makes sense (and brings everything you need) - **Certifications and compliance**: regulated sectors and demanding audits. - **VDI** (Virtual Desktop Infrastructure) and graphics workloads: wide **vGPU** and **MIG** (Multi-Instance GPU) support with ISV certifications. - **Continuous availability**: **FT** (*Fault Tolerance*, host-level Tolerance to Failures) with **zero downtime** and **zero loss of in-memory data** if a host fails. - **Large-scale operations**: **DRS** (*Distributed Resource Scheduler*) for resource balancing and **vDS** (*vSphere Distributed Switch*) when you want the hypervisor’s own distributed switching (although Stackscale does not depend on it; see the network section). ### When Proxmox VE shines (and optimizes TCO) - **Large-scale Linux workloads**: hundreds or thousands of VMs with **HA** (*High Availability*) and **live migration**, automation (Ansible/Terraform), and accessible **API/CLI**. - **SDS** (*Software-Defined Storage*) without vendor lock-in: **Ceph** integrated or NFS/iSCSI/ZFS depending on the case. - **Native backups**: **Proxmox Backup Server** with scheduling, retention, verification, and **immutability**. - **Clear failure domains**: sensible, segmented clusters (not mega-clusters). - **Cost efficiency** (**TCO**, *Total Cost of Ownership*): open model with **optional support subscription**. ## Operational comparison (what matters on Monday morning) AreaVMware vSphereProxmox VE**Hypervisor**ESXiKVM/QEMU + LXC**Management**vCenter (GUI + API), AriaWeb console + API/CLI**Network**vDS (if used); **Stackscale network with real VLANs**, hypervisor-agnosticLinux bridge/OVS; **Stackscale network with real VLANs**, hypervisor-agnostic**Local / software-defined storage**vSAN + ecosystem**Ceph** integrated; ZFS/NFS/iSCSI**Network / synchronous storage (Stackscale)****Available to both**: NetApp arrays with synchrony and performance tiers**Available to both**: NetApp arrays with synchrony and performance tiers**HA / Balancing**Mature HA/DRSHA + live migration**FT** (Fault Tolerance)**Yes** (zero downtime / zero in-RAM data loss)No direct equivalent**vGPU / MIG**Broad support and certificationsPossible, less standardized**Backups**Very large third-party ecosystem**Native backup** (PBS) + third parties**Support**Global enterprise (SLA)Optional enterprise subscription**Cost / TCO**HigherVery competitive ** FT (Fault Tolerance)**: keeps two synchronized instances of the VM on different hosts; if one fails, the secondary takes over **instantly** with **no memory loss**. It’s one of vSphere’s enterprise differentiators. ## Stackscale networking: real VLANs and a hypervisor-agnostic architecture At Stackscale we **don’t depend on the hypervisor’s software-defined networking**. Our **network is independent of VMware or Proxmox** and **delivers real VLANs** directly over our private and bare-metal infrastructure.**This enables: - Extending the same VLAN** across **VMware clusters**, **Proxmox clusters**, **bare-metal servers**, and even **housing** connected to Stackscale. - Simplifying design, avoiding SDN lock-in at the hypervisor layer, and enabling hybrid **VMware ↔ Proxmox ↔ bare-metal** scenarios with **low latency** and **high performance**. - Keeping **segmentation and control** in the **Stackscale network** itself, instead of tying the topology to hypervisor-specific networking features. When a project **requires** especially fine-grained policies or specific security use cases, we **implement them on the Stackscale network**, keeping the data plane **hypervisor-agnostic**. ## **Storage at Stackscale**: compute–storage separation, **synchronous RTO=0 & RPO=0**, and performance tiers Beyond each stack’s local or SDS options (vSAN/Ceph), Stackscale offers **network storage** and **synchronous storage** based on **NetApp arrays**, designed to **decouple compute from storage**. This boosts **resilience**, enables **independent scaling**, and minimizes recovery times. **Continuity objectives** - **RTO=0** (*Recovery Time Objective*): service continuity with no noticeable downtime in the event of an incident. - **RPO=0** (*Recovery Point Objective*): **zero data loss** thanks to **synchronous** replication. **All-flash performance tiers** - **Flash Premium**: ultra-low latency and very high IOPS for critical databases, real-time analytics, or high-throughput queues. - **Flash Plus**: balance between latency and throughput for app servers, middleware, and mixed workloads. - **Flash Standard**: consistent performance and optimized cost for general VMs and steady workloads. - **Archive** (backup & retention): capacity-optimized for copies, replicas, and long-term retention. **Protection & continuity** - Frequent, block-efficient **snapshot policies**. - **Cross-datacenter replication** included, providing consistent copies ready for **failover/failback**. - Integration with native or third-party backup tools and **granular recovery** (file/VM). **Combinations** - You can **combine** Stackscale network storage with **vSAN** (VMware) or **Ceph** (Proxmox) depending on design: e.g., **SDS for scratch/hot data** and **NetApp** for **persistent data with multi-DC replication**. - The outcome: **resilience by design**, with **decoupled planes** (compute ↔ network ↔ storage) and **RPO/RTO** aligned with the service’s criticality. ## Total cost and operational risk - **VMware**: **higher TCO**, **low operational risk** when its catalog and certifications are **explicit project requirements**. - **Proxmox VE**: **very competitive TCO**, **controlled risk** when you define failure domains, runbooks, and observability from day one (and work with an experienced partner). The right decision shows up as **stability**, **predictable costs**, and **operator velocity**. ## Design patterns by use case ### 1) Linux/DevOps workloads (microservices, middleware, queues, non-relational DBs) - **Proxmox VE + Ceph** for compute, plus **Stackscale network storage (Flash Plus/Standard)** for persistent data and replicas. - Recommendation: **many small/medium clusters** vs. a mega-cluster; well-defined failure domains. ### 2) Datacenters with segmentation and complex topologies - **Stackscale network with real VLANs** and centralized control, regardless of hypervisor. - Recommendation: leverage **agnostic networking** to move or coexist workloads across VMware and Proxmox without redesigning the network plane. ### 3) VDI and graphics profiles - **VMware + vGPU/MIG** and **Flash Premium** when storage latency affects UX. - Recommendation: validate profiles and seasonal peaks. ### 4) Modernization with SDS - **Proxmox VE + Ceph** for scratch/hot data, **NetApp (Flash Plus/Standard)** for persistent data + **multi-DC replication**. - Recommendation: separate networks (front/back), NVMe/SSD for journals, monitor **placement groups**. ## Implementation best practices ### With Proxmox VE - **Ceph**: dedicated networks, CRUSH rules, health alerts. - **Backup**: dedicated PBS repositories, restore tests, immutable retention. - **Automation**: templates, cloud-init, tagging, quotas, hooks, API/CLI. - **Security**: VLAN isolation, cluster firewall, users/roles, host hardening. ### With VMware - **Licensing fit**: align to **actual feature usage**. - **Disaster recovery (DR)**: runbooks, replicas, and periodic drills. - **Capacity**: plan DRS and CPU/RAM/IO headroom; enable FT where it adds real value. ## Migration with rollback (both directions) - **VMware → Proxmox**: inventory and criticality (RPO/RTO), compatibility (virtio, guest tools, cloud-init), storage design (Ceph / NFS / iSCSI or **NetApp**), controlled pilot, and cutover automation (API/scripts, re-IP if needed). - **Proxmox → VMware**: classify by dependency on **FT**, **vGPU**, or ISV certs; network mapping (VLANs/segments, port groups); IOPS/latency validation; HA/live migration tests. ## How we approach it at Stackscale - **We start from the use case**, not the tool. - We design clusters with **clear failure domains**, **observability**, and **runbooks** from day one. - We **operate and support** environments on **VMware vSphere** and **Proxmox VE** across **private and bare-metal infrastructure**. - **Hypervisor-independent networking**: we deliver **real VLANs** and can **extend segments** across VMware, Proxmox, and bare-metal/housing connected to Stackscale. - **Stackscale storage**: **NetApp** arrays with **Flash Premium/Plus/Standard** and **Archive**, snapshots and **multi-DC replication** included; and a **synchronous option with RTO=0 and RPO=0** for workloads that cannot tolerate downtime or data loss. - **We guide migrations**: **to VMware or Proxmox**, and also **VMware → Proxmox** and **Proxmox → VMware**, with pilots, defined rollback, and planned maintenance windows. **Ask us!** - **We iterate**: recurring measurements, recovery tests, and adjustments as the project evolves. ## Conclusions - Choose **VMware vSphere** when **advanced features (FT, vGPU), certifications, and enterprise support** are **explicit requirements**. - Choose **Proxmox VE** when you prioritize **control, cost efficiency, and flexibility**, especially for **large Linux estates** (and SDS with Ceph). - At Stackscale, **both technologies coexist** and integrate on a **hypervisor-agnostic network and storage**, so the **architecture** serves the project—not the other way around. ## FAQ **Does Proxmox VE support Windows?****Yes. Proxmox runs Windows and Linux; its sweet spot is Linux efficiency** and the fit with **Ceph/ZFS** and automation. **Is VMware always more expensive?****It depends on the license profile** and **actual use** of features like **FT** (Fault Tolerance), **vGPU/MIG**, or ISV certifications. When these are **requirements**, their value justifies the cost. **Can I run both?****Yes. It’s common to segment by criticality or workload type**: e.g., **VDI and certified workloads on VMware**, and **microservices/DevOps on Proxmox VE** with Ceph. Our **real-VLAN network** and **network/synchronous storage** make that coexistence straightforward. **What does Stackscale provide in each case?****We design and operate VMware vSphere and Proxmox VE platforms** on **private and bare-metal infrastructure**, with **SDS** (Ceph), a **hypervisor-independent network**, and **NetApp arrays** (Flash Premium/Plus/Standard, Archive) with snapshots and **multi-DC replication** included—and **synchronous** options (**RTO=0, RPO=0**) for critical workloads. We tailor the platform to **each project’s needs**. --- ## VMware vs Proxmox VE: cómo elegir (de verdad) para tu plataforma de virtualización URL: https://www.stackscale.com/blog/vmware-vs-proxmox-how-to-choose/ En Stackscale trabajamos a diario con **VMware vSphere** y **Proxmox VE**. Nuestro enfoque no es “forzar” una herramienta, sino **ajustar la plataforma a los requisitos del proyecto** (técnicos, operativos y de negocio). A continuación, un análisis práctico —en la línea editorial del blog de Stackscale— de **cuándo encaja cada tecnología** y cómo se traduce en operación, coste y riesgo. ## Por qué la comparación “uno a uno” suele ser injusta - **VMware vSphere** es un **producto integral** con décadas de evolución y un ecosistema amplio (vCenter, vSAN, etc.), orientado a entornos **enterprise** que necesitan **certificaciones, matrices de compatibilidad y soporte**. - **Proxmox VE** es una **distribución abierta** que integra tecnologías muy maduras —**KVM/QEMU** (hipervisor), **LXC** (contenedores), **ZFS** y **Ceph** (almacenamiento)— bajo una **consola web** y **API/CLI** (*Application Programming Interface* / *Command-Line Interface*) completas. El valor no está en “quién tiene más *checkboxes*”, sino en **qué usas de verdad** hoy y durante el ciclo de vida (3–5 años) del proyecto. ## Dónde encaja VMware… y dónde aporta Proxmox ### Cuándo VMware tiene sentido (y lo aporta todo) - **Certificaciones y cumplimiento**: sectores regulados y auditorías exigentes. - **VDI** (*Virtual Desktop Infrastructure*) y cargas gráficas: soporte amplio de **vGPU** y **MIG** (*Multi-Instance GPU*) con certificaciones ISV. - **Disponibilidad continua**: **FT** (*Fault Tolerance*, Tolerancia a Fallos) a nivel de hipervisor para **cero tiempo de inactividad** y **cero pérdida de datos en memoria** ante la caída de un host. - **Operación a gran escala**: **DRS** (*Distributed Resource Scheduler*) para balanceo de recursos y **vDS** (*vSphere Distributed Switch*) cuando se desea switching distribuido propio del hipervisor (aunque en Stackscale no dependemos de ello; ver sección de red). ### Cuándo Proxmox VE brilla (y optimiza el TCO) - **Cargas Linux a gran escala**: cientos o miles de VM con **HA** (*High Availability*, Alta Disponibilidad) y **migración en caliente**, automatización (Ansible/Terraform) y **API/CLI** accesibles. - **SDS** (*Software-Defined Storage*) sin *vendor lock-in*: **Ceph** integrado o NFS/iSCSI/ZFS según el caso. - **Copias de seguridad** nativas: **Proxmox Backup Server** con programación, retenciones, verificación e **inmutabilidad**. - **Dominios de fallo claros**: clústeres razonables y segmentados (no megaclústeres). - **Eficiencia de costes** (**TCO**, *Total Cost of Ownership*): modelo abierto con **suscripción de soporte** opcional. ## Comparativa operativa (lo que importa el lunes por la mañana) AspectoVMware vSphereProxmox VE**Hipervisor**ESXiKVM/QEMU + LXC**Gestión**vCenter (GUI + API), AriaConsola web + API/CLI**Red**vDS (si se usa); **red Stackscale con VLAN reales** agnóstica al hipervisorLinux bridge/OVS; **red Stackscale con VLAN reales** agnóstica al hipervisor**Almacenamiento local/definido por software**vSAN + ecosistema**Ceph** integrado; ZFS/NFS/iSCSI**Almacenamiento en red / síncrono (Stackscale)****Disponible para ambos**: cabinas NetApp con sincronía y tiers de rendimiento**Disponible para ambos**: cabinas NetApp con sincronía y tiers de rendimiento**HA/Balanceo**HA/DRS madurosHA + *live migration***FT** (Tolerancia a Fallos)**Sí** (cero downtime / cero pérdida de RAM)Sin equivalente directo**vGPU/MIG**Amplio soporte y certificacionesPosible, menos estandarizado**Backups**Ecosistema de terceros muy amplio**Backup nativo** (PBS) + terceros**Soporte**Enterprise global (SLA)Suscripción empresarial opcional**Coste/TCO**SuperiorMuy competitivo ** FT (Fault Tolerance)**: mantiene dos instancias sincronizadas de la VM en hosts distintos; si uno cae, la secundaria toma el control **al instante** y **sin pérdida de memoria**. Es uno de los diferenciales *enterprise* de vSphere. ## Red en Stackscale: VLAN reales y arquitectura agnóstica al hipervisor En Stackscale **no dependemos de la red definida por software del hipervisor**. Nuestra **red es independiente de VMware o Proxmox** y **entrega VLAN reales** directamente sobre nuestra infraestructura privada y *bare-metal*.**Esto permite: - Extender la misma VLAN** entre **clusters VMware**, **clusters Proxmox**, **servidores *bare-metal*** e incluso **equipos en housing** conectados a Stackscale. - Simplificar el diseño, evitar *lock-in* en la capa SDN del hipervisor y facilitar escenarios híbridos **VMware ↔ Proxmox ↔ *bare-metal*** con **baja latencia** y **alto rendimiento**. - Mantener **segmentación y control** de red desde la propia **red de Stackscale**, sin atar la topología a funcionalidades específicas del software de virtualización. Cuando un proyecto **requiere** políticas especialmente finas o casos de seguridad concretos, las **implementamos sobre la red de Stackscale**, manteniendo el plano de datos **agnóstico al hipervisor**. ## **Almacenamiento en Stackscale**: separación cómputo–almacenamiento, **sincronía con RTO=0 y RPO=0** y tiers de rendimiento Además de las opciones locales o SDS (vSAN/Ceph) de cada stack, en Stackscale ofrecemos **almacenamiento en red** y **almacenamiento síncrono** basados en **cabinas NetApp**, diseñados para **separar la computación del almacenamiento**. Este desacoplamiento mejora la **resiliencia**, facilita el **escalado independiente** y reduce al mínimo el tiempo de recuperación. **Objetivos de continuidad** - **RTO=0** (*Recovery Time Objective*): continuidad del servicio sin tiempo de inactividad apreciable en caso de incidencia. - **RPO=0** (*Recovery Point Objective*): **cero pérdida de datos** gracias a la replicación **síncrona**. **Tiers de rendimiento (todo-flash)** - **Flash Premium**: latencias ultra-bajas e IOPS muy altos para bases de datos críticas, analítica en tiempo real o colas de alto rendimiento. - **Flash Plus**: equilibrio entre latencia y *throughput* para *app servers*, middleware y cargas mixtas. - **Flash Standard**: rendimiento consistente y coste ajustado para VM generales y *workloads* estables. - **Archive** (orientado a backup y retención): capacidad optimizada para copias, réplicas y conservación a largo plazo. **Protección y continuidad adicional** - **Políticas de *snapshot*** frecuentes y eficientes por bloque. - **Réplica entre centros de datos** incluida, para disponer de copias consistentes listas para *failover/failback*. - Integración con herramientas de backup (nativas o de terceros) y **recuperación granular** (archivo/VM). **Combinaciones posibles** - Puedes **combinar** el almacenamiento en red de Stackscale con **vSAN** (VMware) o **Ceph** (Proxmox) según el diseño del proyecto: por ejemplo, **SDS para *scratch*/datos calientes** y **cabina NetApp** para **datos persistentes con réplica multi-DC**. - Resultado: **resiliencia por diseño**, con **planos desacoplados** (cómputo ↔ red ↔ almacenamiento) y **RPO/RTO** acordes a la criticidad del servicio. ## Coste total y riesgo operativo - **VMware**: **TCO más alto**, con **riesgo operativo bajo** cuando su catálogo y certificaciones son **requisitos** del proyecto. - **Proxmox VE**: **TCO muy competitivo**, con **riesgo controlado** si diseñas dominios de fallo, *runbooks* y observabilidad desde el inicio (y cuentas con un partner experto). La decisión correcta se nota en **estabilidad**, **previsibilidad de costes** y **velocidad de operación**. ## Patrones de diseño por caso de uso ### 1) Cargas Linux/DevOps (microservicios, middleware, *queues*, bases no relacionales) - **Proxmox VE + Ceph** para *compute* y **almacenamiento en red Stackscale (Flash Plus/Standard)** para datos persistentes y réplicas. - Recomendación: **clústeres pequeños/medios** frente a megaclústeres; dominios de fallo claros. ### 2) Data center con segmentación de red y topologías complejas - **Red de Stackscale con VLAN reales** y control centralizado, independientemente del hipervisor. - Recomendación: aprovechar la **agnosticidad** para mover o coexistir cargas entre VMware y Proxmox sin rediseñar el plano de red. ### 3) VDI y perfiles gráficos - **VMware + vGPU/MIG** y **Flash Premium** cuando la latencia de almacenamiento impacta la experiencia. - Recomendación: validar *profiles* y picos estacionales. ### 4) Modernización con SDS - **Proxmox VE + Ceph** para *scratch*/datos calientes y **NetApp (Flash Plus/Standard)** para datos persistentes + **réplica multi-DC**. - Recomendación: separar redes (front/back), NVMe/SSD para *journals*, monitorizar *placement groups*. ## Buenas prácticas de implementación ### Con Proxmox VE - **Ceph**: redes dedicadas, reglas CRUSH, alertas de salud. - **Backup**: repositorios dedicados (PBS), restauraciones de prueba, retenciones con inmutabilidad. - **Automatización**: plantillas, *cloud-init*, etiquetado, cuotas, *hooks*, API/CLI. - **Seguridad**: aislamiento por VLAN, *firewall* de clúster, usuarios/roles y *hardening* del host. ### Con VMware - **Licencias a medida**: ajustar al **uso real** de funcionalidades. - **Recuperación ante desastres (DR)**: *runbooks*, réplicas y simulacros periódicos. - **Capacidad**: planificar DRS y *headroom* de CPU/RAM/IO; activar FT donde aporta valor. ## Migración con *rollback* (ambas direcciones) - **De VMware a Proxmox**: inventario y criticidad (RPO/RTO), compatibilidad (*virtio*, *guest tools*, *cloud-init*), diseño de almacenamiento (Ceph / NFS / iSCSI o **NetApp**), piloto controlado y automatización del corte (API/scripts, *re-IP* si aplica). - **De Proxmox a VMware**: clasificación por dependencia de **FT**, **vGPU** o certificaciones ISV, mapeo de red (VLAN/segmentos, *port groups*), validación de IOps/latencias y pruebas de HA/*live migration*. ## Cómo lo enfocamos en Stackscale - **Partimos del caso de uso**, no de la herramienta. - Diseñamos clústeres con **dominios de fallo claros**, **observabilidad** y **runbooks** desde el día uno. - **Operamos y soportamos** entornos sobre **VMware vSphere** y **Proxmox VE** en **infraestructura privada y *bare-metal***. - **Red independiente del hipervisor**: entregamos **VLAN reales** y podemos **extender segmentos** entre VMware, Proxmox y *bare-metal/housing* conectados a Stackscale. - **Almacenamiento Stackscale**: cabinas **NetApp** con **Flash Premium/Plus/Standard** y **Archive**, *snapshots* y **réplica multi-DC** incluidas; y en modo **síncrono con RTO=0 y RPO=0** para cargas que no toleran ni tiempo de caída ni pérdida de datos. - **Acompañamos migraciones**: **hacia VMware o Proxmox**, y también **de VMware a Proxmox y de Proxmox a VMware**, con pilotos, *rollback* y ventanas de mantenimiento planificadas. **¡Pregúntanos!** - **Iteramos**: medición periódica, pruebas de recuperación y ajustes a medida que el proyecto evoluciona. ## Conclusiones - Elige **VMware vSphere** cuando **funciones avanzadas (FT, vGPU), certificaciones y soporte enterprise** son **requisitos explícitos**. - Elige **Proxmox VE** cuando priorizas **control, eficiencia de costes y flexibilidad**, especialmente en **grandes parques Linux** (y SDS con Ceph). - En Stackscale, **ambas tecnologías conviven** y se integran sobre una **red y un almacenamiento agnósticos al hipervisor**, para que la **arquitectura** responda al proyecto y no al revés. ## Preguntas frecuentes **¿Proxmox VE soporta Windows?****Sí. Proxmox ejecuta Windows y Linux; su punto fuerte es la eficiencia en cargas Linux** y el encaje con **Ceph/ZFS** y automatización. **¿VMware siempre implica coste superior?****Depende del perfil de licencias** y del **uso real** de funciones como **FT** (Fault Tolerance), **vGPU/MIG** o certificaciones. Cuando son **requisitos**, su valor compensa el coste. **¿Puedo combinar ambos?****Sí. Es habitual segmentar por criticidad o tipo de carga**: por ejemplo, **VDI y cargas certificadas en VMware** y **microservicios/DevOps en Proxmox VE** con Ceph. Nuestra **red con VLAN reales** y **almacenamiento en red/síncrono** facilitan esa coexistencia. **¿Qué ofrece Stackscale en cada caso?****Diseñamos y operamos plataformas sobre VMware y Proxmox VE** en **infraestructura privada y *bare-metal***, con **SDS** (Ceph), **red independiente del hipervisor** y **cabinas NetApp** (Flash Premium/Plus/Standard, Archive) con *snapshots* y **réplica multi-DC** incluidas; y con opción **síncrona (RTO=0, RPO=0)** para cargas críticas. Ajustamos la plataforma a las **necesidades de cada proyecto o cliente**. --- ## Proxmox VE 9: The Evolution of Open Source Private Cloud URL: https://www.stackscale.com/blog/proxmox-ve-9-the-evolution-of-open-source-private-cloud/ ***Proxmox Virtual Environment 9.0** is now available, marking a major step forward in key features such as snapshots, high availability, and software-defined networking. At Stackscale, as a provider of private cloud infrastructure with Proxmox VE support, we review its innovations and compare them with the previous version to help you make informed decisions for your deployments.* ## A Version Designed for Enterprise Environments Officially released on July 8, 2025, **Proxmox VE 9.0** positions itself as a mature, powerful alternative to commercial platforms like VMware vSphere, Hyper-V, or Nutanix. This open-source virtualization system has built a growing, active community thanks to its reliability, customization capabilities, and complete independence from proprietary licenses. Key highlights include: - Storage vendor-agnostic snapshots. - New affinity rules in high-availability (HA) environments. - Support for “Fabrics” in software-defined networking (SDN). - Completely redesigned mobile web interface using Rust and the Yew framework. - Updated software stack with the latest stable versions of Debian, kernel, hypervisors, and distributed file systems. Beyond these technical improvements, Proxmox VE 9 strengthens its role as a foundation for hybrid multicloud, edge computing, and DevOps platforms. ## Comparison: Proxmox VE 8 vs Proxmox VE 9 FeatureProxmox VE 8.xProxmox VE 9.0Base OSDebian 12 “Bookworm”Debian 13 “Trixie”KernelLinux 6.2 / 6.5Linux 6.14.8-2QEMU7.x / 8.x10.0.2LXC5.x6.0.4ZFS2.1.x2.3.3 (supports adding disks to RAIDZ)CephReefSquid 19.2.3SnapshotsBackend-dependentVendor-agnostic (volume chains)High Availability (HA)No affinity rulesNode/VM affinity rulesSDN NetworkingBridges and Open vSwitchIntroduction of “Fabrics”Mobile Web UILegacyRedesigned with Rust/YewUpgrade PathVia APT, with precautionsOfficially supportedVersion SupportUntil August 2026LTS (full cycle from 2025) ## Key Features in Depth ### Vendor-Agnostic Snapshots The new *volume chains* snapshot system is a paradigm shift in Proxmox VE. Unlike previous versions, snapshots no longer depend on the storage backend, enabling consistent block-level backups whether using local storage, NFS, Ceph, iSCSI, or external SAN arrays. This enhances disaster recovery strategies, automates testing environments, and speeds up cloning. ### HA Affinity Rules Proxmox VE 9 allows defining positive or negative affinity rules between VMs and nodes. This is essential for mission-critical environments, preventing two critical services from running on the same host or ensuring workloads run on preferred hosts. This integrates natively with failover systems for better availability. ### Smarter Networking with “Fabrics” The SDN system advances with the introduction of **Fabrics**: structures for building complex routed networks between nodes and containers. Benefits include: - Multi-tenant segmentation. - Hybrid cloud integration. - Secure isolation between development and production. It remains compatible with Linux bridges and Open vSwitch, increasing flexibility. ### New Mobile Interface in Rust The mobile web interface has been rebuilt in Rust using the **Yew** framework, improving usability, load times, and security. It delivers smoother management from smartphones or tablets without sacrificing the classic panel experience. ## Ready for the Future Although Debian 13 “Trixie” is officially released in August 2025, its key components were frozen since May after rigorous beta testing. This allowed Proxmox to confidently launch early without compromising stability. The migration path from Proxmox VE 8.4 is supported and documented, including for environments running Ceph Reef. In such cases, a progressive upgrade to Ceph Squid is recommended before moving to VE 9.0. ## Stackscale’s Perspective Currently, at Stackscale we closely monitor the evolution of Proxmox VE 9 and its improvements. However, **we recommend our customers keep Proxmox VE 8.4 in production** for now, as it is still early to adopt the new version in critical environments. While Proxmox VE 9 introduces promising features, we advise giving it more time to mature, validate its stability with real workloads, and wait for best practices and community documentation to consolidate. We provide bare-metal and private cloud infrastructure optimized for Proxmox VE environments. Our expertise allows us to support both production enterprises and integrators or developers adopting the Proxmox ecosystem. With version 9’s arrival, our technical teams are ready to assist with transition planning, compatibility checks, and performance optimization. “Proxmox 9 is a qualitative leap for enterprise virtualization without proprietary licenses. Universal snapshots, SDN improvements, and better HA allow us to deliver more resilient, predictable, and flexible environments than ever,” says David Carrero, co-founder of Stackscale and head of sales and marketing. ## Conclusion Proxmox VE 9.0 marks a before-and-after moment in the open-source virtualization landscape. Not just for its updated stack, but for its mature, production-ready features: advanced storage management, smart networking, modular HA, and a mobile-friendly interface. With long-term support, modern hardware compatibility, and a growing community, Proxmox VE 9 strengthens its place as a robust, secure platform without proprietary dependencies. At Stackscale, we’re ready to guide you through this transition—whether planning a migration, deploying new services, or scaling your infrastructure—to get the most out of this new Proxmox VE release. --- ## Proxmox VE 9: la evolución del cloud privado open source URL: https://www.stackscale.com/blog/proxmox-ve-9-the-evolution-of-open-source-private-cloud/ ***Proxmox Virtual Environment 9.0** ya está disponible, y marca un salto significativo en funcionalidades clave como snapshots, alta disponibilidad y redes definidas por software. En Stackscale, como proveedor de infraestructura cloud privada con soporte para Proxmox VE, analizamos sus novedades y las comparamos con la versión anterior para ayudarte a tomar decisiones informadas en tus despliegues.* ## Una versión pensada para entornos empresariales Lanzada oficialmente el 8 de julio de 2025, **Proxmox VE 9.0** se posiciona como una alternativa madura y potente frente a plataformas comerciales como VMware vSphere, Hyper-V o Nutanix. Este sistema de virtualización open source ha ganado una comunidad activa y creciente gracias a su fiabilidad, capacidad de personalización y total independencia de licencias propietarias. Entre sus grandes novedades destacan: - Snapshots agnósticos al proveedor de almacenamiento. - Nuevas reglas de afinidad en entornos de alta disponibilidad (HA). - Soporte para “Fabrics” en redes definidas por software (SDN). - Interfaz web móvil completamente rediseñada usando Rust y el framework Yew. - Stack de software actualizado con las versiones más recientes y robustas de Debian, kernel, hipervisores y sistemas de archivos distribuidos. Además de estas mejoras técnicas, Proxmox VE 9 fortalece su posición como pilar en entornos multicloud híbridos, edge computing y plataformas DevOps. ## Comparativa: Proxmox VE 8 vs Proxmox VE 9 CaracterísticaProxmox VE 8.xProxmox VE 9.0Base del sistemaDebian 12 “Bookworm”Debian 13 “Trixie”KernelLinux 6.2 / 6.5Linux 6.14.8-2QEMU7.x / 8.x10.0.2LXC5.x6.0.4ZFS2.1.x2.3.3 (soporta añadir discos en RAIDZ)CephReefSquid 19.2.3SnapshotsDependientes del backendSnapshots agnósticos (volume chains)Alta disponibilidad (HA)Sin reglas de afinidadReglas de afinidad para nodos/VMsRedes SDNBridges y Open vSwitchIntroducción de “Fabrics”Web UI (móvil)LegacyRediseñada con Rust/YewRuta de actualizaciónVía APT, con precaucionesSoportada oficialmenteSoporte de la versiónHasta agosto de 2026LTS (ciclo completo desde 2025) ## Novedades destacadas en profundidad ### Snapshots independientes del proveedor El nuevo sistema de snapshots basado en *volume chains* representa un cambio de paradigma en Proxmox VE. A diferencia de versiones anteriores, ahora los snapshots no dependen del backend de almacenamiento, lo que permite realizar backups a nivel de bloque de forma uniforme, tanto si se usa almacenamiento local, NFS, Ceph, iSCSI o una cabina externa. Esto permite mejorar las estrategias de recuperación ante desastres, automatizar entornos de testing o clonar sistemas en tiempo récord. ### Reglas de afinidad en HA Proxmox VE 9 permite definir reglas de afinidad positiva o negativa entre VMs y nodos. Esto es fundamental para entornos de misión crítica, donde se debe evitar que dos servicios esenciales compartan el mismo host o garantizar que ciertas cargas se ejecuten siempre en hosts con características específicas. Esta lógica de planificación inteligente se integra de forma nativa con el sistema de failover, mejorando notablemente la disponibilidad general. ### Networking más inteligente con “Fabrics” El sistema de SDN (Software Defined Networking) da un paso adelante con la introducción del concepto de **Fabrics**: estructuras que permiten crear redes enrutadas complejas entre nodos y contenedores. Esta capacidad facilita escenarios como: - Segmentación multi-tenant. - Redes híbridas con integración cloud. - Aislamiento seguro entre entornos de desarrollo y producción. Todo ello manteniendo compatibilidad con Linux bridges y Open vSwitch, lo que amplía la flexibilidad en entornos empresariales y de laboratorio. ### Nueva interfaz móvil en Rust El rediseño de la interfaz web móvil, ahora basada en el lenguaje Rust mediante el framework **Yew**, representa una mejora en usabilidad, tiempos de carga y seguridad. Esta decisión tecnológica apunta a una gestión más fluida desde smartphones o tablets, sin comprometer la experiencia del panel clásico. ## Una actualización preparada para el futuro Aunque Debian 13 “Trixie” tiene su lanzamiento oficial previsto para agosto de 2025, los componentes clave en los que se basa Proxmox VE 9 llevan congelados desde mayo, tras rigurosas pruebas en fase beta. Esto ha permitido a Proxmox adelantarse con confianza, ofreciendo una plataforma lista para producción sin comprometer estabilidad. La ruta de migración desde Proxmox VE 8.4 es compatible, bien documentada y acompañada por guías específicas, incluso para entornos que ya utilizan Ceph Reef. En estos casos, se recomienda un salto progresivo hacia Ceph Squid antes de actualizar Proxmox, minimizando riesgos y garantizando la integridad de los datos. ## Perspectiva desde Stackscale Actualmente, en Stackscale seguimos de cerca la evolución de Proxmox VE 9 y sus mejoras. Sin embargo, **recomendamos a nuestros clientes mantener en producción la versión 8.4**, ya que aún es pronto para adoptar la nueva versión en entornos críticos. Aunque Proxmox VE 9 introduce características prometedoras, consideramos prudente permitirle más recorrido, validar su estabilidad con nuevas cargas reales y esperar a que se consoliden mejores prácticas y documentación comunitaria. En Stackscale ofrecemos infraestructura bare-metal y cloud privado optimizada para entornos basados en Proxmox VE. Nuestra experiencia nos permite acompañar tanto a empresas en producción como a integradores y desarrolladores en su adopción del ecosistema Proxmox. Con la llegada de la versión 9, nuestros equipos técnicos están preparados para facilitar la transición, validar compatibilidad con cargas existentes y optimizar el rendimiento de nuevas implantaciones. “Proxmox 9 representa un salto cualitativo para la virtualización empresarial sin licencias propietarias. La posibilidad de snapshots universales, las mejoras en redes definidas por software y en alta disponibilidad, nos permiten ofrecer entornos más resilientes, predecibles y flexibles que nunca”, comenta David Carrero, uno de los fundadores de Stackscale y responsable del área de ventas y marketing. ## Conclusión Proxmox VE 9.0 marca un antes y un después en el panorama de la virtualización open source. No solo por su stack actualizado, sino por la madurez de sus funcionalidades orientadas a producción: gestión avanzada de almacenamiento, redes inteligentes, alta disponibilidad modular y una interfaz que se adapta al ritmo actual de administración remota. Con soporte a largo plazo, compatibilidad con hardware moderno, y una comunidad en constante crecimiento, Proxmox VE 9 consolida su lugar como una plataforma robusta, segura y sin dependencias propietarias. En Stackscale estamos listos para acompañarte en esta transición tecnológica. Ya sea planificando una migración, desplegando nuevos servicios, o escalando tu infraestructura, contamos con el equipo y las soluciones para sacar el máximo partido a esta nueva versión de Proxmox VE. --- ## La revolución silenciosa de Proxmox VE Helper-Scripts: cómo una comunidad está transformando la administración de sistemas URL: https://www.stackscale.com/blog/revolution-proxmox-ve-helper-scripts/ *En Stackscale, como especialistas en infraestructura cloud privada con Proxmox VE, hemos sido testigos de un fenómeno que ha cambiado las reglas del juego en nuestros centros de datos en España y los Países Bajos. Se trata de los Proxmox VE Helper-Scripts: una colección de herramientas creadas por y para administradores que está redefiniendo el modo de desplegar y gestionar servicios IT. Esta es su historia.* ## Un cambio de paradigma en tiempo real En una madrugada de octubre, Marc, administrador de sistemas en una startup tecnológica de Barcelona, tenía una misión urgente: levantar un entorno de desarrollo completo antes del amanecer. GitLab, PostgreSQL, Grafana y Nextcloud debían estar funcionando antes de que llegara el equipo. Hace solo unos años, esta situación habría requerido horas de configuración manual, docenas de comandos y una buena dosis de paciencia. Pero Marc contaba con una ventaja: **Proxmox VE Helper-Scripts**, una batería de automatizaciones que le permitirían tenerlo todo listo en minutos. Así comenzó lo que muchos ya describen como una revolución silenciosa. ## Un binomio potente: Stackscale y Proxmox VE Helper-Scripts En Stackscale ofrecemos infraestructura basada en Proxmox VE desde centros de datos de alto rendimiento. Sabemos por experiencia que la velocidad, consistencia y confiabilidad son esenciales en despliegues empresariales. Y es precisamente ahí donde los Helper-Scripts brillan con luz propia. ** “Lo que antes nos llevaba una tarde ahora lo resolvemos en 10 minutos”, cuenta una ingeniera DevOps en una consultora tecnológica cliente de Stackscale. Estos scripts no son magia, pero rozan lo milagroso. Automatizan tareas complejas con una simplicidad y robustez que sólo puede surgir de una comunidad que conoce profundamente el día a día del administrador de sistemas. ## De una idea personal a un estándar comunitario Detrás de los Helper-Scripts está @tteck (Tom), un desarrollador alemán que comenzó automatizando sus propios despliegues en Proxmox. Sus scripts destacaban por su enfoque claro, opciones interactivas y una obsesión por el detalle. El boca a boca hizo el resto. Su repositorio alcanzó decenas de miles de estrellas en GitHub. Pero en 2023, su repentina muerte dejó en vilo a una comunidad que dependía de su trabajo. La respuesta fue ejemplar: se creó community-scripts**, un proyecto que no sólo preservó su legado, sino que ha continuado evolucionándolo con contribuciones de todo el mundo. ** “Tom nos enseñó que la verdadera innovación nace del conocimiento compartido”, explica una mantenedora del proyecto. ## Una filosofía de automatización centrada en el usuario Hoy, con más de 17.000 estrellas en GitHub, Helper-Scripts es más que una colección de código: es una filosofía. Cada script busca ahorrar tiempo, reducir errores y ofrecer opciones realistas para administradores con distintos niveles de experiencia. El diseño de los scripts prioriza la experiencia de usuario: - Interfaces con whiptail** para opciones interactivas - Configuraciones seguras por defecto - Feedback visual durante cada paso del despliegue - Documentación clara, actualizada y accesible Ejecutar un script es tan sencillo como este comando: ``` bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/homeassistant.sh)" ``` ## Un catálogo que no deja fuera a nadie La colección actual supera los **350 scripts**, cubriendo categorías como: ### IA y aprendizaje automático Modelos de lenguaje con **Ollama** o generación de imágenes con **ComfyUI** se despliegan en minutos. Ideal para investigadores o desarrolladores que necesitan entornos funcionales sin complicaciones. ### Herramientas empresariales Desde **OnlyOffice** hasta **InvoiceNinja**, pasando por **Akaunting**, los scripts permiten a pymes y freelancers disponer de herramientas robustas sin recurrir a servicios SaaS externos. ### Media y entretenimiento Instalar **Jellyfin**, **Plex** o el ecosistema *ARR (Radarr, Sonarr, etc.)* nunca fue tan sencillo. Ideal para homelabs o servidores multimedia personales. ### DevOps y desarrollo Scripts para **Gitea**, **Jenkins**, **Code-Server** y otros acortan el tiempo de despliegue de entornos CI/CD. Equipos completos pueden tener su stack funcionando en una tarde. ## Casos reales: eficiencia en acción **TechnoSolutions**, startup en Valencia, desplegó toda su infraestructura sin un equipo DevOps gracias a estos scripts, en combinación con infraestructura de Stackscale. Resultado: más foco en el desarrollo de producto y menos tiempo invertido en mantenimiento. **Un hospital en Andalucía** digitalizó su archivo documental en tiempo récord usando **Paperless-ngx** y almacenamiento en Stackscale. **Una consultora de Barcelona** gestiona más de 40 servicios internos con Helper-Scripts, reduciendo tiempos de despliegue y aumentando la autonomía de sus equipos. ## Bajo el capó: lo que no se ve, pero marca la diferencia Los scripts están diseñados para adaptarse al entorno: - Detectan recursos disponibles y ajustan configuraciones automáticamente - Gestionan dependencias y versiones con precisión quirúrgica - Implementan políticas de seguridad sólidas desde el inicio - Documentan los cambios aplicados y permiten rollback si es necesario ## Seguridad: automatización sin renunciar al control Uno de los pilares del proyecto es la seguridad. Todo el código es abierto y auditable. Las configuraciones por defecto siguen buenas prácticas: usuarios no root, permisos mínimos, firewall activo y actualizaciones automáticas. Además, los scripts se prueban en múltiples entornos antes de su inclusión oficial. Y, como apoyo extra, la comunidad en Discord ofrece soporte en tiempo real. ## Impacto económico: menos tiempo, más valor Los Helper-Scripts tienen un impacto directo en los costes operativos: - **Reducción del tiempo de despliegue**: de horas a minutos. - **Menos errores humanos**: menos tickets de soporte y más estabilidad. - **Estandarización**: menos problemas de “en mi máquina funcionaba”. - **Escalabilidad**: un administrador puede gestionar más servicios sin aumentar plantilla. ## ¿Qué viene después? El roadmap del proyecto incluye: - Soporte para otras plataformas (KVM, LXD, Docker) - Scripts orquestadores para stacks completos (con HA y balanceo) - Integración híbrida con cloud público - IA para recomendaciones de configuración según métricas reales ## Stackscale y el valor de la comunidad técnica Desde Stackscale seguimos de cerca y apoyamos esta iniciativa. Como proveedores de infraestructura especializada en Proxmox VE, comprobamos cada día cómo estas herramientas permiten a nuestros clientes desplegar soluciones reales con una fracción del esfuerzo habitual. ** “Proxmox VE Helper-Scripts ha democratizado el acceso a infraestructuras profesionales”, afirma desde Stackscale. “Clientes con pocos recursos pueden competir al mismo nivel que grandes empresas.” ## Conclusión: una comunidad, un legado, una revolución La historia de los Helper-Scripts es la historia de cómo una comunidad puede mejorar radicalmente la forma en que trabajamos. De cómo una idea nacida en un entorno personal se convirtió en herramienta esencial para miles de profesionales. En Stackscale seguiremos apoyando este tipo de iniciativas. Porque creemos que el futuro de la infraestructura no solo está en el hardware, sino en las personas que comparten su conocimiento para resolver problemas reales. ### ¿Quieres empezar? En Stackscale ofrecemos entornos Proxmox VE optimizados para trabajar con Helper-Scripts desde el primer minuto. Nuestra infraestructura en España y los Países Bajos es el complemento ideal para acelerar despliegues y garantizar estabilidad operativa. Enlaces útiles:** - Sitio oficial: https://community-scripts.github.io/ProxmoxVE/ - GitHub: https://github.com/community-scripts/ProxmoxVE --- ## The Silent Revolution of Proxmox VE Helper-Scripts: How a Community is Transforming Systems Administration URL: https://www.stackscale.com/blog/revolution-proxmox-ve-helper-scripts/ *At Stackscale, as specialists in private cloud infrastructure based on Proxmox VE, we’ve witnessed firsthand how Proxmox VE Helper-Scripts are changing the way organizations deploy and manage their systems. From our data centers in Spain and the Netherlands, we’ve seen this grassroots tool evolve into a vital asset for thousands of sysadmins. This is the story of a quiet but transformative revolution.* ## A Real-Time Paradigm Shift It was a late October night when Marc, a systems administrator at a tech startup in Barcelona, faced a familiar challenge: set up a full development environment — GitLab, PostgreSQL, Grafana, and Nextcloud — before the team arrived the next morning. A few years ago, this would have meant hours of manual configuration and troubleshooting. But Marc had a secret weapon: **Proxmox VE Helper-Scripts**, a powerful set of automation tools that would do the heavy lifting in minutes. This isn’t fiction — it’s happening daily in data centers and home labs around the world. ## A Powerful Duo: Stackscale and Proxmox VE Helper-Scripts At Stackscale, we offer high-performance infrastructure based on Proxmox VE, with a focus on private cloud deployments. Over time, we’ve seen how these Helper-Scripts have become a natural extension of the platform, especially in enterprise environments where speed, consistency, and repeatability are critical. ** “What used to take us an entire afternoon can now be done in 10 minutes,” says a DevOps engineer at a consulting firm that runs on Stackscale’s infrastructure. These scripts are not just time-savers — they represent a new philosophy in systems automation, born from the community and tailored to real-world challenges. ## From Personal Project to Global Standard The origin of the project traces back to @tteck (Tom), a German developer who began writing scripts to automate repetitive tasks in his personal Proxmox environment. His creations were fast, elegant, and surprisingly user-friendly. As word spread, so did his impact. GitHub stars skyrocketed. Forums called his work the “correct” way to deploy on Proxmox. But in 2023, Tom passed away unexpectedly — and the community was left with a vital question: what now? The answer came quickly. Community-scripts**, a collaborative initiative, emerged to preserve and evolve his legacy. Today, dozens of contributors from around the world continue to expand the project. ** “Tom taught us that true innovation comes from understanding real problems,” says one of the project’s lead maintainers. “We’re just carrying that vision forward.” ## More Than Just Scripts — It’s a Workflow Philosophy With over 17,000 GitHub stars**, Helper-Scripts is more than a repo — it’s a movement. Each script is designed with care, offering interactive dialogs, secure defaults, and intelligent configurations. Even beginner users can deploy sophisticated stacks with a single command like: ``` bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/homeassistant.sh)" ``` ## A Vast Catalog for Every Use Case The project now includes more than **350 scripts**, neatly categorized and regularly updated. ### AI & Machine Learning Spin up **Ollama** for local LLMs or **ComfyUI** for image generation in just a few clicks. Researchers can now test ideas in minutes — not days. ### Business Tools From **OnlyOffice** to **InvoiceNinja** and **Akaunting**, small businesses can deploy robust software without SaaS licensing headaches. ### Media & Entertainment Install **Jellyfin**, **Plex**, or the *ARR* ecosystem (Sonarr, Radarr, Lidarr) in no time. A favorite among home labbers and media enthusiasts. ### Development & DevOps Scripts for **Gitea**, **Jenkins**, and **Code-Server** make it easy to build full CI/CD pipelines quickly — even for entire development teams. ## Real-World Stories: Speed Meets Scale **TechnoSolutions**, a data analytics startup in Valencia, used Stackscale and Helper-Scripts to build its full stack — PostgreSQL, Redis, GitLab, Prometheus, Nextcloud — in two days, without a dedicated DevOps team. **A hospital in southern Spain** used **Paperless-ngx** to digitize years of medical records in just three weeks, cutting their expected timeline in half. **A consulting firm in Barcelona** runs 40+ internal tools — from **Mattermost** to **Uptime Kuma** — all deployed using Helper-Scripts. Efficiency and autonomy at scale. ## What Happens Behind the Scenes Each script goes through multiple intelligent phases: - **Environment detection** (Proxmox version, resource checks) - **Interactive configuration** (RAM/CPU, USB/Zigbee access, storage mounts) - **Secure setup** (systemd services, firewalls, backups) - **Post-install guidance** (access URLs, logs, management commands) All of this, typically in under 10 minutes. ## Security First: Open and Auditable Automation doesn’t mean giving up control. The project emphasizes: - **Open-source code** for full auditability - **Secure defaults**: non-root users, limited permissions, hardened services - **Continuous testing** on multiple Proxmox versions - **Rollback support** and clear change documentation ## Measurable Impact: Real ROI From our vantage point at Stackscale, we’ve seen the numbers: - **Setup time cut by 80–90%** — saving €150–400 per deployment - **Fewer human errors**, fewer support tickets - **Environment consistency**: faster testing, more reliable releases - **Operational scalability**: more services managed with fewer staff ## Engineering Excellence Under the Hood Helper-Scripts integrates advanced techniques: - **Smart resource detection** to auto-tune deployments - **Dependency management** across diverse environments - **Reusable templates** for complex configurations - **Cross-integration** with monitoring tools like Grafana ## What’s Next? A Roadmap of Possibilities The project’s roadmap includes: - **Cross-platform support** (Docker, KVM, LXD) - **AI-powered recommendations** for optimal settings - **Meta-scripts** for deploying entire high-availability stacks - **Hybrid cloud integration** for edge + core infrastructure setups ## Stackscale’s Take: Empowering through Specialization As a Proxmox-focused infrastructure provider, Stackscale is proud to support this community-driven movement. We see daily how Helper-Scripts empower customers — from startups to institutions — to deploy faster and with greater confidence. ** “Helper-Scripts have leveled the playing field,” says Head of Technical Operations at Stackscale. “They allow small teams to compete with larger players using enterprise-grade infrastructure.” ## Lessons Beyond Code This project is proof that: - Community is key**: shared knowledge multiplies impact - **Simplicity wins**: true complexity lies in making things simple - **Documentation matters**: clarity invites contribution - **Open source is sustainable**: when a passionate community leads the way ## Conclusion: A Quiet Revolution, A Shared Legacy Somewhere in the world, a sysadmin is running their first Helper-Script right now. Maybe it’s a student setting up their first homelab. Or a CTO deploying production infrastructure on a tight schedule. In both cases, they’re part of a growing movement — a quiet revolution built on code, collaboration, and trust. At Stackscale, we’re proud to power that movement. With private cloud infrastructure optimized for Proxmox VE, we provide the solid foundation from which innovation grows. Helper-Scripts reminds us that great technology often comes from people — not corporations. That collaboration beats complexity. And that every script executed is a tribute to the vision of @tteck and the strength of the community that carries it forward. ### Ready to Experience the Power of Helper-Scripts? Stackscale offers private cloud environments optimized for Proxmox VE and fully compatible with Helper-Scripts. Our data centers in Spain and the Netherlands provide the ideal foundation for your deployments. **Resources:** - Project site: https://community-scripts.github.io/ProxmoxVE/ - GitHub repo: https://github.com/community-scripts/ProxmoxVE --- ## PrivateGPT: Why Private Generative AI Is Essential for Modern Enterprises URL: https://www.stackscale.com/blog/privategpt-ai-enterprises/ The adoption of generative artificial intelligence (GenAI) is advancing at an unprecedented pace in companies. According to recent data, **75% of knowledge workers already use generative AI tools in their daily work**, and nearly half would continue to use them even if their employer forbade it. This reality raises a major challenge: **how can organizations benefit from AI without jeopardizing privacy or regulatory compliance?** ### The Challenge of Privacy and Technological Dependence Many AI solutions on the market operate in the public cloud. When a company connects its corporate data to these services, it assumes significant risks: - **Sensitive information can leave the organization’s control.** - **Technical and economic dependence on external providers increases,** and unpredictable variable costs may arise. - **It is not always possible to meet legal or industry requirements,** especially in highly regulated sectors. A recent security report highlights that a relevant share of AI queries involve confidential data, often without the company even realizing it. This underscores the need for solutions that keep data **within the corporate infrastructure**. ### PrivateGPT: Private Generative AI on Dedicated Infrastructure To address these challenges, alternatives like **PrivateGPT** are emerging: an open source solution that allows organizations to deploy language models (LLMs) and Retrieval-Augmented Generation (RAG) systems **directly on dedicated servers**, under the organization’s exclusive control. #### Changing the Paradigm: From Cloud Dependence to Technological Independence - **Before:** Private data is sent outside the organization. - Technological dependence on external providers. - Variable costs based on usage. - **Now:** Data always remains within the company’s infrastructure. - Total technological independence and flexibility. - Predictable, stable costs. ### Key PrivateGPT Features for Enterprise Environments - **100% On-premise Deployment:** All processing takes place within the organization, with no connections to external services. - **Flexible Integration:** Connects with document management systems, knowledge bases (such as SharePoint, Confluence, Drive, NextCloud, DropBox, etc.), and local file servers. - **Secure and Controlled Collaboration:** Enables the creation of collaborative workspaces where each project has its own space, preventing unwanted data exposure between teams. - **Access Control and Traceability:** Allows assignment of roles and permissions, logging usage, and analyzing the solution’s impact in the organization. - **Multi-format and OCR Support:** Ability to index and work with over 20 types of documents (PDF, Word, Excel, PowerPoint, images, etc.). ### Security and Privacy Built-in by Design Unlike cloud solutions, in a PrivateGPT architecture: - Data is **never shared with third parties** at any time. - No information leaves the corporate perimeter. - Only authorized members can access project-specific data. - Risks of “cross-pollution” between projects or business areas are avoided. - It is possible to maintain a complete access and activity log. ### Technical Requirements and Sizing To deploy PrivateGPT, it is essential to have a private cloud infrastructure or bare-metal servers with enterprise GPUs capable of handling advanced language models. At Stackscale, we offer dedicated nodes optimized for AI, with NVIDIA L40S, L4, or Tesla T4 GPUs, high-speed networks, and NVMe storage, with the following minimum recommendations: - **CPU:** Minimum 8 cores, preferably 12 or more. - **RAM:** Minimum 32 GB, ideally 128 GB or more for enterprise deployments. - **Storage:** From 1 TB NVMe/SSD and Network Storage. - **GPU:** At least 24 GB dedicated memory. - **Private connectivity and secure access.** These configurations allow serving entire teams and departments, supporting dozens or hundreds of users depending on concurrent usage. ### When Does Private Generative AI Make Sense? - **When regulatory compliance is a priority** (GDPR, ENS, ISO, etc.). - **If especially sensitive data is handled** (legal, healthcare, industry, public sector). - **For companies seeking technological independence** and avoiding variable usage-based costs. - **If you need to customize models, workflows, or integrations** without depending on third parties. ### Example Use Cases - Private virtual assistants for employees or customers. - Advanced semantic search and automatic document generation. - Automation of reports, summaries, and analysis on internal data. - Integration of AI into business workflows without exposing information to the public cloud. ### The Future of AI in Business Is Private The trend is clear: more and more organizations are seeking solutions that allow them to harness the potential of artificial intelligence **without giving up privacy or control**. PrivateGPT on dedicated infrastructure is one of the most robust alternatives to meet this challenge. At Stackscale, we continue to evaluate and deploy this type of technology for clients who prioritize security, independence, and efficiency. **Interested in exploring how private generative AI can be integrated into your organization?** If you’d like to know more about proof of concept, sizing, or real-world use cases, you can get in touch with our technical team. Contact us form EN Newsletter NameEmailPhoneWho would you like to contact?SalesSupportBillingMarketingMessage I give my consent to receiving customized commercial communications about Stackscale products and services (including the newsletter), by any channel, including electronic ones. I have read and accept the privacy policy. Submit The Stackscale Group processes the information you provide in order to respond to your request regarding the services we deliver and the products we provide. The data provided will be stored while we stay in contact and deleted when the request is closed, unless you consent to receiving sales communications, in which case your data will be stored until the previously given consent is revoked. As part of the Group to which Stackscale belongs, we inform you that your data will be communicated to the companies of Grupo Aire for corporate reasons. You can consult the companies integrating Grupo Aire at: https://grupoaire.es. You can exercise your rights of access, rectification, erasure, disagreement, limitation of the processing and, when legally appropriate, portability, by sending a request to Stackscale to the address dp*@********le.com, indicating the right you exercise and providing a double-sided photocopy of your identification. Additionally, you will be able to present a complaint to the Dutch Data Protection Authority, especially when you are not content with the exercise of your rights, via https://autoriteitpersoonsgegevens.nl/en. --- ## PrivateGPT: Por qué la IA generativa privada es esencial en la empresa moderna URL: https://www.stackscale.com/blog/privategpt-ai-enterprises/ La adopción de la inteligencia artificial generativa (GenAI) avanza a un ritmo sin precedentes en las empresas. Según datos recientes, **el 75% de los trabajadores del conocimiento ya utiliza herramientas de IA generativa en su día a día** y casi la mitad seguiría utilizándolas incluso si la empresa lo prohibiera. Esta realidad plantea un gran reto: **¿cómo pueden las organizaciones beneficiarse de la IA sin poner en riesgo la privacidad ni el cumplimiento normativo?** ### El reto de la privacidad y la dependencia tecnológica Muchas soluciones de IA disponibles en el mercado operan en la nube pública. Cuando una empresa conecta sus datos corporativos con estos servicios, asume riesgos importantes: - **La información sensible puede salir fuera del control de la organización.** - **La dependencia técnica y económica** de proveedores externos crece, y aparecen costes variables difíciles de prever. - **No siempre es posible cumplir con los requisitos legales o sectoriales**, especialmente en sectores regulados. Un reciente informe de seguridad subraya que una parte relevante de las consultas realizadas a sistemas de IA incluye datos confidenciales, muchas veces sin que la propia empresa sea consciente. Esto refuerza la necesidad de soluciones que permitan mantener los datos **dentro de la infraestructura corporativa**. ### PrivateGPT: IA generativa privada sobre infraestructura dedicada Para responder a estos retos, surgen alternativas como **PrivateGPT**: una solución open source que permite desplegar modelos de lenguaje (LLM) y sistemas de recuperación aumentada por generación (RAG) **directamente sobre servidores dedicados**, bajo control exclusivo de la organización. #### Cambiando el paradigma: de la dependencia cloud a la independencia tecnológica - **Antes:** Los datos privados se envían fuera. - Dependencia tecnológica de proveedores externos. - Costes variables en función del uso. - **Ahora:** Los datos permanecen siempre en la infraestructura de la empresa. - Total independencia tecnológica y flexibilidad. - Coste predecible y estable. ### Funcionalidades clave de PrivateGPT en entorno empresarial - **Despliegue 100% on-premise**: Todo el procesamiento se realiza dentro de la organización, sin conexiones a servicios externos. - **Integración flexible**: Se conecta con sistemas documentales, gestores de conocimiento (como SharePoint, Confluence, Drive, NextCloud, DropBox, …) y servidores de archivos locales. - **Colaboración segura y controlada**: Permite crear entornos de trabajo colaborativo donde cada proyecto tiene su propio espacio, evitando la exposición de datos entre equipos. - **Control de accesos y trazabilidad**: Posibilidad de asignar roles y permisos, registrar el uso y analizar el impacto de la solución en la organización. - **Soporte multi-formato y OCR**: Capacidad de indexar y trabajar con más de 20 tipos de documentos (PDF, Word, Excel, PowerPoint, imágenes, etc.). ### Seguridad y privacidad integradas en el diseño A diferencia de soluciones cloud, en una arquitectura PrivateGPT: - Los datos **no se comparten con terceros** en ningún momento. - No hay transferencia de información fuera del perímetro empresarial. - Solo los miembros autorizados pueden acceder a los datos del proyecto concreto. - Se evitan riesgos de “cross-pollution” entre proyectos o áreas de la organización. - Es posible mantener un registro completo de acceso y actividad. ### Requisitos técnicos y dimensionamiento Para desplegar PrivateGPT, es **fundamental contar con la infraestructura de cloud privado o servidores bare-metal con GPUs empresariales** capaces de manejar modelos avanzados de lenguaje. En **Stackscale ofrecemos nodos dedicados optimizados para IA**, con GPUs NVIDIA L40S, L4 o Tesla T4, redes de alta velocidad y almacenamiento NVMe, con las siguientes recomendaciones mínimas: - **CPU:** mínimo 8 núcleos, preferiblemente 12 o más. - **RAM:** mínimo 32 GB, idealmente 128 GB o más para despliegues empresariales. - **Almacenamiento:** desde 1 TB NVMe/SSD y almacenamiento en red. - **GPU:** al menos 24 GB de memoria dedicada. - **Conectividad desde 2x10Gbps, privada y acceso seguro.** Estas configuraciones permiten dar servicio a equipos y departamentos completos, soportando decenas o cientos de usuarios en función del uso concurrente. ### ¿Cuándo tiene sentido optar por una IA generativa privada? - **Cuando el cumplimiento normativo es prioritario** (RGPD, ENS, ISO…). - **Si se manejan datos especialmente sensibles** (legal, salud, industria, administración pública). - **Para empresas que buscan independencia tecnológica** y evitar costes variables por uso. - **Si se necesita personalizar modelos, flujos o integraciones** sin depender de terceros. ### Ejemplo de casos de uso - Asistentes virtuales privados para empleados o clientes. - Búsqueda semántica avanzada y generación automática de documentación. - Automatización de informes, resúmenes y análisis sobre datos internos. - Integración de la IA en flujos de negocio sin exponer información a la nube pública. ### El futuro de la IA en la empresa es privado La tendencia es clara: cada vez más organizaciones buscan soluciones que permitan aprovechar el potencial de la inteligencia artificial **sin renunciar a la privacidad ni al control**. PrivateGPT sobre infraestructura dedicada es una de las alternativas más sólidas para afrontar este desafío. En Stackscale seguimos evaluando y desplegando este tipo de tecnologías para clientes que priorizan la seguridad, la independencia y la eficiencia. **¿Te interesa explorar cómo la IA generativa privada puede integrarse en tu organización?** Si quieres saber más sobre pruebas de concepto, dimensionamiento o casos de uso reales, puedes ponerte en contacto con nuestro equipo técnico. Contact us form ES Subscribe NombreEmailTeléfono¿Con quién deseas contactar?ComercialSoporteFacturaciónMarketingMensaje Acepto el envío de comunicaciones comerciales personalizadas sobre los productos y servicios de Stackscale (incluida la newsletter), por cualquier medio, incluidos los electrónicos. He leído y acepto la política de privacidad. Enviar El Grupo Stackscale trata la información que nos facilita con el fin de dar respuesta a la solicitud realizada en relación con los servicios que prestamos y los productos que suministramos. Los datos proporcionados se conservarán mientras se mantenga el contacto siendo eliminados una vez finalizada la solicitud, a no ser que consienta el envío de comunicaciones comerciales, donde sus datos se conservarán hasta la revocación del consentimiento previamente otorgado. En el marco del Grupo al que pertenece Stackscale, se le informa de que sus datos serán comunicados a las empresas de Grupo Aire por motivos corporativos. Puede consultar las empresas que forman parte del Grupo Aire en: https://grupoaire.es. Usted puede ejercitar sus derechos de acceso, rectificación, supresión, oposición, limitación del tratamiento y, cuando legalmente proceda, portabilidad, mediante el envío a Stackscale de una solicitud a la dirección dp*@********le.com, indicando el derecho que ejercita y aportando una fotocopia por las dos caras de su DNI o documento legal de identificación de su identidad. Igualmente, podrá presentar una reclamación ante la Agencia Española de Protección de Datos, especialmente cuando no haya obtenido la satisfacción en el ejercicio de sus derechos, a través de la sede electrónica en www.aepd.es. --- ## How to Migrate from VMware to Proxmox VE with Stackscale: An Efficient and Secure Alternative URL: https://www.stackscale.com/blog/how-to-migrate-from-vmware-to-proxmox-ve/ The recent acquisition of VMware by Broadcom has led to significant changes in the virtualization market. The shift to a subscription-based licensing model, the restructuring of the partner ecosystem, and cost variations have prompted many organizations to rethink their IT strategy. In this new landscape, **Proxmox VE** emerges as a robust, flexible, and growing open source solution. At Stackscale, we continue to offer VMware-based infrastructure for customers who need it. However, we also provide a comprehensive migration service from VMware or other hypervisors for those **looking to explore new alternatives**—**without compromising the stability or security of their infrastructure**. ## A Migration Tailored to Each Organization No two IT environments are the same. That’s why our team customizes every migration project to meet the specific characteristics and objectives of each client. This personalized approach allows us to offer a secure, **planned transition with no service interruptions—regardless of the number of virtual machines or the size of the infrastructure**. We work in close collaboration with technical teams to: - Assess the current environment and define a realistic migration plan. - Automate critical tasks to improve efficiency and reduce human error. - Validate each workload’s functionality before final cutover. - Provide guidance before, during, and after the migration. As part of this process, **we also help improve the target infrastructure**—adding capabilities such as enhanced availability and resilience, disaster recovery and business continuity planning, and even deploying dual geo-replicated zones with synchronous storage to achieve **RTO=0 and RPO=0**. ## Our Step-by-Step Migration Approach At Stackscale, we apply a clear, structured methodology—refined through real-world experience—to ensure migration success. The key stages include: ### 1. Pre-Migration Assessment We analyze the current VMware environment, identify technical and functional dependencies, collect usage and performance metrics, and detect potential risks. This information is used to design a migration plan aligned with business goals. ### 2. Target Environment Setup We deploy and configure the Proxmox VE environment, including networks, storage, security policies, and backups. A pilot migration is performed using selected virtual machines to validate the process and fine-tune the configuration. ### 3. Migration Execution We convert virtual machines using automated tools, verify data integrity, and perform phased transitions—ensuring production systems remain untouched until the right moment. ### 4. Testing and Validation We test application behavior, performance, connectivity, and workflow integrity in the new environment. Rollback procedures are also defined and tested, just in case a reversal becomes necessary. ### 5. Optimization and Tuning Once in production, we optimize the configuration of resources (CPU, RAM, storage, network, and even GPU). We also activate features such as high availability, monitoring, and task automation. ### 6. Support and Knowledge Transfer Post-migration, we provide active technical support, documentation, and—if needed—training for internal teams. Our goal is to ensure that each client can operate their new infrastructure confidently and independently. ## Benefits of Migrating to Proxmox VE with Stackscale Migration is not only an opportunity to change platforms—it’s a chance to enhance efficiency, control, and infrastructure flexibility. Key advantages include: - **Zero-impact transition**: fully planned and tested before production cutover. - **Advanced automation**: reduces manual errors and conversion times. - **Data protection**: with backups, restore points, and granular recovery options. - **Cost reduction**: through predictable licensing and more efficient resource use. - **Infrastructure and HA improvements**: including geo-replication across two data centers, synchronous storage with RTO=0 and RPO=0, and updated disaster recovery strategies. - **Expert support**: from initial assessment to full production operation. - **Regulatory compliance**: with technical documentation for GDPR, ISO 27001, ENS, and other frameworks. ## Why Choose Proxmox VE **Proxmox VE is an open source virtualization platform** that combines the robustness of the KVM hypervisor with the agility of LXC containers. It simplifies the management of complex virtual environments without sacrificing control or scalability. Its key features include: - Centralized web-based management console. - Multi-node clustering with high availability. - Integrated backup and programmable snapshot systems. - Software-defined storage support (ZFS, Ceph), and compatibility with our own network storage and synchronous storage solutions. - Seamless integration with the **Stackscale Network**, which operates independently of the virtualization platform—allowing networks to be shared across both VMware and Proxmox environments. - Active community and transparent subscription model. ## Stackscale: Your Strategic Partner for IT Evolution Whether driven by cost optimization, modernization goals, or the desire for greater autonomy, **migrating from VMware to Proxmox VE** can be a powerful step forward for your IT infrastructure. At Stackscale, we support businesses of all sizes through this journey—combining technology, automation, and deep expertise to ensure a smooth and beneficial transition. If you’re considering this move, we invite you to get in touch. We can perform a no-obligation assessment of your current environment and help you choose the best path forward. **Contact Stackscale** and start planning the next phase of your cloud infrastructure. Request information form EN Subscribe NameEmailPhoneI am interested in:Cloud solutionsBare Metal solutionsManaged ServicesBackup and Disaster Recovery solutionsColocation servicesCDN solutionsTell us more about your needs I give my consent to receiving customized commercial communications about Stackscale products and services (including the newsletter), by any channel, including electronic ones. I have read and accept the privacy policy. Submit The Stackscale Group processes the information you provide in order to respond to your request regarding the services we deliver and the products we provide. The data provided will be stored while we stay in contact and deleted when the request is closed, unless you consent to receiving sales communications, in which case your data will be stored until the previously given consent is revoked. As part of the Group to which Stackscale belongs, we inform you that your data will be communicated to the companies of Grupo Aire for corporate reasons. You can consult the companies integrating Grupo Aire at: https://grupoaire.es. You can exercise your rights of access, rectification, erasure, disagreement, limitation of the processing and, when legally appropriate, portability, by sending a request to Stackscale to the address dp*@********le.com, indicating the right you exercise and providing a double-sided photocopy of your identification. Additionally, you will be able to present a complaint to the Dutch Data Protection Authority, especially when you are not content with the exercise of your rights, via https://autoriteitpersoonsgegevens.nl/en. --- ## Cómo migrar de VMware a Proxmox VE con Stackscale: una alternativa eficiente y segura URL: https://www.stackscale.com/blog/how-to-migrate-from-vmware-to-proxmox-ve/ La reciente adquisición de VMware por parte de Broadcom ha provocado importantes cambios en el mercado de la virtualización. La transición hacia un modelo de licenciamiento por suscripción, la reorganización del canal de partners y las variación de los costes han llevado a muchas organizaciones a replantearse su estrategia tecnológica. En este nuevo escenario, **Proxmox VE** se presenta como una solución open source sólida, flexible y en crecimiento. En Stackscale seguimos ofreciendo infraestructura basada en VMware para los clientes que la necesitan, pero también proporcionamos un servicio completo de migración desde VMware u otros hipervisores para quienes desean **explorar nuevas alternativas** sin comprometer la estabilidad ni la seguridad de su infraestructura. ## Una migración pensada para cada organización No existen dos entornos iguales. Por eso, nuestro equipo adapta cada proyecto de migración a las características y objetivos específicos de cada cliente. Este enfoque personalizado nos permite ofrecer **una transición segura, planificada y sin interrupciones del servicio**, independientemente del número de máquinas virtuales o del tamaño de la infraestructura. Trabajamos integrándonos con los equipos técnicos para: - Evaluar el entorno actual y definir un plan de migración realista. - Automatizar las tareas más críticas para ganar eficiencia y fiabilidad. - Validar el funcionamiento de cada carga de trabajo antes del cambio definitivo. - Acompañar al cliente antes, durante y después de la migración. Durante este proceso también **ayudamos a mejorar la infraestructura objeto de la migración **para añadir elementos que puedan ser necesarios como aumentar la disponibilidad y resilencia, crear un buen escenario de continuidad de negocio y recuperación ante desastres, incluso aprovechando para dividir la infraestructura en dos **zonas georeplicadas para conseguir RTO=0 y RPO=0 con la ayuda de nuestro almacenamiento síncrono**. ## Nuestro enfoque paso a paso En Stackscale aplicamos una metodología clara, estructurada y validada en múltiples proyectos para asegurar el éxito de la migración. Estas son las fases principales: ### 1. Evaluación previa Analizamos el entorno VMware existente, identificamos las dependencias técnicas y funcionales, recopilamos métricas de uso y rendimiento y detectamos riesgos potenciales. Con esta información diseñamos un plan de migración adaptado a los objetivos del cliente. ### 2. Preparación del entorno de destino Desplegamos y configuramos el entorno Proxmox VE, incluyendo redes, almacenamiento, políticas de seguridad y backups. Realizamos una migración piloto con máquinas seleccionadas para validar el proceso y ajustar la configuración según los resultados. ### 3. Ejecución de la migración Convertimos las máquinas virtuales mediante herramientas automatizadas, verificamos la integridad de los datos y realizamos la transición por fases, manteniendo intactos los sistemas de producción hasta el momento adecuado. ### 4. Pruebas y validación Probamos el comportamiento de las aplicaciones, el rendimiento, la conectividad y los flujos de trabajo en el nuevo entorno. También se definen y prueban procedimientos de retroceso por si fuera necesario deshacer algún cambio. ### 5. Optimización y ajustes Una vez en producción, optimizamos la configuración de recursos (CPU, RAM, almacenamiento, red, incluso GPU) y activamos funciones como la alta disponibilidad, la monitorización y la automatización de tareas. ### 6. Soporte y transferencia de conocimiento Durante el periodo posterior a la migración, ofrecemos soporte técnico activo, documentación y, si es necesario, formación para los equipos internos. El objetivo es garantizar que el cliente pueda operar con autonomía y confianza. ## Ventajas de migrar a Proxmox VE con Stackscale El proceso de migración no solo permite cambiar de plataforma, sino también mejorar la eficiencia, el control y la flexibilidad de la infraestructura. Estos son algunos de los beneficios más destacados: - **Transición sin impacto**: planificada y probada antes de tocar producción. - **Automatización avanzada**: reducción de errores manuales y tiempos de conversión. - **Protección de datos**: con copias de seguridad, puntos de restauración y opciones de recuperación granular. - **Reducción de costes**: gracias a un modelo de licencias más predecible y a un uso más eficiente de los recursos. - **Mejora de infraestructura y HA**: previo al inicio de la migración podemos mejorar el entorno con georeplicación en 2 centros de datos, soluciones de almacenamiento síncrono con RTO=0 y RPO=0, nuevos planes de continuidad y *disaster recovery*, etc. - **Soporte experto**: desde el primer análisis hasta la operación en producción. - **Cumplimiento normativo**: incluyendo documentación técnica para GDPR, ISO 27001, ENS y otros marcos reguladores. ## Por qué elegir Proxmox VE **Proxmox VE es una solución de virtualización open source** que combina la robustez del hipervisor KVM con la agilidad de los contenedores LXC. Está diseñada para simplificar la administración de entornos virtuales complejos sin renunciar al control ni a la escalabilidad. Entre sus principales características destacan: - Consola web de gestión centralizada. - Clústeres multi-nodo con alta disponibilidad. - Backups integrados y snapshots programables. - Soporte para almacenamiento definido por software (ZFS, Ceph). También con nuestros almacenamiento en red y almacenamiento síncrono. - Integración con la Red de Stackscale que no depende los entornos de virtualización pudiendo incluso compartir redes entre entorno con VMware y Proxmox. - Comunidad activa y modelo de suscripción transparente. ## Stackscale, tu socio estratégico en la evolución tecnológica Ya sea por necesidad presupuestaria, estrategia de modernización o búsqueda de mayor autonomía, **migrar desde VMware a Proxmox VE puede ser una oportunidad para mejorar tu infraestructura IT**. En Stackscale acompañamos a empresas de todos los tamaños en este tipo de procesos, combinando tecnología, automatización y conocimiento especializado para que la transición no solo sea posible, sino también beneficiosa. Si estás valorando esta opción, te invitamos a hablar con nosotros. Podemos realizar un análisis sin compromiso de tu entorno actual y ayudarte a tomar la mejor decisión para tu negocio. Contacta con Stackscale y empieza a planificar el siguiente paso de tu infraestructura cloud. Request information form ES Subscribe NombreEmailTeléfonoEstoy interesado/a en:Soluciones cloudSoluciones Bare MetalServicios gestionadosSoluciones de Disaster Recovery y backupServicios de housingSoluciones de CDNCuéntanos más sobre tus necesidades Acepto el envío de comunicaciones comerciales personalizadas sobre los productos y servicios de Stackscale (incluida la newsletter), por cualquier medio, incluidos los electrónicos. He leído y acepto la política de privacidad. Enviar El Grupo Stackscale trata la información que nos facilita con el fin de dar respuesta a la solicitud realizada en relación con los servicios que prestamos y los productos que suministramos. Los datos proporcionados se conservarán mientras se mantenga el contacto siendo eliminados una vez finalizada la solicitud, a no ser que consienta el envío de comunicaciones comerciales, donde sus datos se conservarán hasta la revocación del consentimiento previamente otorgado. En el marco del Grupo al que pertenece Stackscale, se le informa de que sus datos serán comunicados a las empresas de Grupo Aire por motivos corporativos. Puede consultar las empresas que forman parte del Grupo Aire en: https://grupoaire.es. Usted puede ejercitar sus derechos de acceso, rectificación, supresión, oposición, limitación del tratamiento y, cuando legalmente proceda, portabilidad, mediante el envío a Stackscale de una solicitud a la dirección dp*@********le.com, indicando el derecho que ejercita y aportando una fotocopia por las dos caras de su DNI o documento legal de identificación de su identidad. Igualmente, podrá presentar una reclamación ante la Agencia Española de Protección de Datos, especialmente cuando no haya obtenido la satisfacción en el ejercicio de sus derechos, a través de la sede electrónica en www.aepd.es. --- ## Backup vs. Replication: What do you really need, and why combining both may be the best strategy URL: https://www.stackscale.com/blog/backup-vs-replication/ In today’s business landscape, protecting data effectively is no longer optional—it’s essential. Yet many organizations still wonder whether traditional backups are enough or if they should also invest in replication solutions. What’s the difference between backup and replication? And when is it wise to use both? At Stackscale, we help you understand the benefits, limitations, and how combining them leads to a resilient and robust data protection strategy. ## Backup: Point-in-Time Data Copies A **backup** is a snapshot of production data at a specific point in time. These backups are typically stored in a compressed file format on lower-cost, slower storage media. ### Advantages of Backups - **Cost-effective**: Backup files can be archived on low-performance storage. Stackscale’s Archive Storage is ideal for this use case. - **Long-term retention**: Backups can be preserved for weeks, months, or even years to meet audit or compliance requirements. - **Protection against ransomware and logical corruption**: By keeping historical versions and leveraging snapshots, it’s possible to restore data to a previous clean state. ### Disadvantages of Backups - **Resource-intensive**: Backup operations can consume significant bandwidth and processing power. With Stackscale’s Archive Storage, there are no additional bandwidth charges as long as the data remains within our private network. - **Wider recovery point intervals**: With daily backups, up to 24 hours of recent data could be lost after an incident. - **Slower recovery**: Restoring from a backup often involves decompressing and copying files back to production, which can take hours. ## Replication: Near-Real-Time Data Copies **Replication** involves copying data continuously or periodically, typically in a format that can be immediately read and used by the system. However, there are **different types of replication**, and not all of them are real-time. ### Replication Solutions at Stackscale #### 1. **Hourly Replication in Network Storage** Stackscale’s **network storage** solutions replicate data to a secondary data center **every hour**. This approach offers a solid level of protection without the complexity or cost of synchronous replication. - **Low RTO**: Fast recovery of environments within minutes, depending on the storage system and data volume. - **Reasonable RPO**: Maximum data loss of up to one hour. - **Efficient storage and bandwidth usage**. - **Geographic redundancy**: Replication between data centers over 10 km apart ensures physical separation and added resilience. #### 2. **Synchronous Geo-Replicated Storage** Our **synchronous geo-replicated storage** ensures data is stored **simultaneously in two different data centers**, using write-confirmation and synchronous replication. - **RTO = 0 / RPO = 0**: No data loss and immediate recovery in the event of failure. - **Ideal for mission-critical systems**: Databases, financial services, medical infrastructure, telecom platforms, etc. - **High availability even during full data center outages**. - **Engineered for the most demanding compliance and operational needs**. ### General Advantages of Replication - **Near-instant availability**: Environments can be recovered in seconds or minutes. - **More recent data than backup**: Reduces potential data loss during failure. - **Complements backups**: Works alongside snapshots and archival policies for full protection. ### General Drawbacks - **Error propagation**: Logical corruption (e.g., ransomware or human error) can be replicated to the recovery site. This is why backups and snapshots remain critical. - **Higher cost**: Especially for synchronous replication, due to higher-performance storage and dual-site operations. ## Why You Likely Need Both Most organizations adopt a **combined strategy**: - **Scheduled backups** provide historical restoration points and protection against corruption or deletion. - **Replication** (hourly or synchronous) ensures quick recovery and minimal disruption. Using both enables **redundancy, fast failover, historical retention**, and the flexibility to recover from a variety of incidents—from user errors to full infrastructure failures. ## How Stackscale Can Help At Stackscale, we provide advanced European infrastructure to protect your data efficiently, flexibly, and securely: - **Network storage with hourly replication**, supporting S3, NFS/iSCSI and automated snapshot policies. - **Synchronous geo-replicated storage**, with real-time write confirmation between two data centers over 10 km apart in Madrid. - **Managed backups**, including automatic snapshots, long-term retention, and granular restore options. - **Housing for private infrastructure, disaster recovery services, business continuity plans, and 24/7 specialized support**. All our infrastructure is hosted in high-availability data centers in **Madrid and Amsterdam**, adhering to strict European standards for data protection and operational continuity. Our tailored solutions adapt to each customer’s needs, industry compliance, and recovery objectives. **Looking to improve your backup and replication strategy?**Get in touch with our team—we’ll help you design a solution that guarantees the availability, integrity, and recoverability of your critical data. --- ## Backup vs. Replicación: ¿Cuál necesitas realmente y por qué combinarlas puede ser la mejor estrategia? URL: https://www.stackscale.com/blog/backup-vs-replication/ En el entorno empresarial actual, proteger los datos de forma eficaz ya no es opcional: es imprescindible. Sin embargo, muchas organizaciones aún se preguntan si es suficiente con realizar copias de seguridad tradicionales o si deberían invertir también en soluciones de replicación. ¿Cuál es la diferencia entre backup y replicación? ¿Y en qué casos es recomendable contar con ambos? En Stackscale te ayudamos a entender sus ventajas, limitaciones y cómo combinarlos para lograr una estrategia de protección robusta y resiliente. ## Backup: copias de seguridad punto en el tiempo Una copia de seguridad o **backup** es una instantánea de los datos de producción en un momento determinado. Estas copias se almacenan en un formato de archivo específico, normalmente comprimido y ubicado en un sistema de almacenamiento de menor coste y rendimiento. ### Ventajas del backup - **Reducción de costes**: los archivos pueden almacenarse en soluciones de almacenamiento más lentas y económicas. La solución de almacenamiento Archive de Stackscale es ideal para este escenario. - **Historial prolongado**: puedes conservar backups durante semanas, meses o años, según las necesidades de cumplimiento o auditoría. - **Protección frente a ransomware o corrupción lógica**: al conservar versiones anteriores y utilizar snapshots, es posible recuperar un estado anterior de los datos. ### Desventajas del backup - **Uso intensivo de recursos**: las operaciones de copia de seguridad pueden consumir un ancho de banda considerable y ralentizar servidores. Si bien utilizando el almacenamiento Archive de Stackscale no existen costes adicionales de ancho de banda, como ocurre si los datos tienen que salir de nuestra red. - **Puntos de restauración más espaciados**: si se realiza un backup diario, puedes perder hasta 24 horas de datos recientes ante un fallo. - **Restauración más lenta**: recuperar desde un backup implica extraer, descomprimir y copiar los datos al entorno de producción, lo que puede llevar horas. ## Replicación: copias casi en tiempo real Por su parte, la replicación crea una copia continua o periódica del entorno de producción, normalmente en un formato que es inmediatamente legible y utilizable por el sistema. Sin embargo, existen **diferentes tipos de replicación**, y no todas funcionan en tiempo real. ### Tipos de replicación en Stackscale #### 1. **Replicación horaria en almacenamiento en red** En Stackscale, nuestras soluciones de **almacenamiento en red** permiten replicar los datos a otro centro de datos cada hora. Este enfoque permite disponer de una copia reciente ante una eventualidad grave, sin la complejidad de la replicación continua. - **RTO bajo**: restauración rápida de entornos, en minutos, dependiendo del tipo de almacenamiento en el que está realizada la réplica y del volumen de datos. - **RPO razonable**: hasta 1 hora de datos como máximo podrían perderse. - **Uso eficiente del almacenamiento y ancho de banda**. - **Replicación entre centros de datos** con más de 10 km de separación, garantizando separación física efectiva. #### 2. **Almacenamiento síncrono georeplicado** Nuestra solución de **almacenamiento georeplicado síncrono** permite tener los datos almacenados **al mismo tiempo en dos centros de datos distintos**, con replicación síncrona y confirmación de escritura. - **RTO = 0 / RPO = 0**: ningún dato se pierde y la restauración es inmediata. - **Ideal para aplicaciones críticas**, bases de datos, sistemas financieros, entornos médicos o de telecomunicaciones. - **Alta disponibilidad garantizada** incluso ante la caída de un centro de datos completo. - **Diseñado para entornos de misión crítica**, cumpliendo con exigencias normativas y operativas más elevadas. ### Ventajas generales de la replicación - **Disponibilidad inmediata**: el entorno puede restaurarse en segundos o minutos. - **Datos más recientes que el backup**: útil para minimizar pérdida de información ante un fallo. - **Complementa a los backups**: se puede utilizar junto a políticas de snapshots y archivado para una protección completa. ### Desventajas generales - **Posibilidad de replicar errores**: si se produce una corrupción lógica (por ejemplo, ransomware), esta puede replicarse al entorno de contingencia. Aunque con los snapshots y backups adicionales podemos proteger este tipo de situaciones. - **Mayor coste**: en el caso de replicación síncrona, el coste del almacenamiento y la red es mayor, ya que los datos se escriben simultáneamente en dos ubicaciones. ## ¿Por qué necesitas ambos? La mayoría de organizaciones combinan ambas estrategias: - **Backups periódicos** garantizan protección ante corrupción, errores humanos, ransomware o necesidad de recuperar versiones históricas. - **Replicación** (horaria o síncrona) reduce el impacto del tiempo de inactividad y permite una recuperación rápida de los servicios. Combinar ambas permite tener **redundancia de datos, múltiples puntos de restauración, alta disponibilidad** y recuperación flexible frente a múltiples tipos de fallo. Es una forma eficaz de lograr continuidad operativa, sin comprometer la integridad ni la disponibilidad de la información. ## Cómo puede ayudarte Stackscale En Stackscale contamos con una infraestructura europea avanzada para proteger tus datos de forma eficiente, flexible y segura: - **Soluciones de almacenamiento en red replicado por hora**, con soporte para S3, NFS/iSCSI y políticas de snapshot automatizadas. - **Almacenamiento síncrono georeplicado**, con confirmación de escritura entre dos centros de datos separados más de 10 km en Madrid. - **Backups gestionados**, con snapshots automáticos, retención de largo plazo y posibilidad de restauración granular. - **Housing de infraestructura propia, servicios de Disaster Recovery, planes de continuidad de negocio y soporte técnico especializado 24/7**. Nuestros entornos están alojados en centros de datos de alta disponibilidad en Madrid y Ámsterdam, cumpliendo los más altos estándares europeos en protección de datos y continuidad de negocio. Además, nuestras soluciones permiten adaptar políticas de backup y replicación a medida, según las necesidades de cada cliente, sector o aplicación. **¿Quieres mejorar tu estrategia de backup y replicación?**Contáctanos y te ayudaremos a diseñar una solución que garantice la disponibilidad, integridad y recuperación de tus datos. --- ## Grandfather-Father-Son (GFS) backup strategy: A reliable and scalable solution for business environments URL: https://www.stackscale.com/blog/grandfather-father-son-gfs-backup/ In today’s information-driven world, data is one of the most valuable assets for any organization. Whether due to human error, technical failures, or cyberattacks, data loss can have severe consequences. That’s why having a robust and secure backup strategy is essential. Among the various methodologies available, the Grandfather-Father-Son (GFS) strategy stands out for its reliability, flexibility, and time-proven effectiveness. In this Stackscale blog article, we explore the GFS backup strategy in depth—its benefits, limitations, real-world applications, and how it can be successfully implemented in modern environments, including bare-metal servers and private cloud infrastructure. ## What is the GFS Backup Strategy? The Grandfather-Father-Son (GFS) strategy is a hierarchical backup rotation system designed to balance long-term data retention with efficient storage usage. This method operates across three backup tiers: - **Son**: Daily backups, often incremental or differential, designed to quickly restore the most recent data. - **Father**: Weekly full backups, providing intermediate and consolidated recovery points. - **Grandfather**: Monthly full backups stored for long-term retention, typically offline or in the cloud. Originally developed for tape storage, GFS remains highly adaptable to today’s technologies, whether in local, cloud, or hybrid environments. ## How Does GFS Work? A Visual Example Day / WeekMondayTuesdayWednesdayThursdayFridaySaturdaySundayWeek 1SonSonSonSonSonSonFatherWeek 2SonSonSonSonSonSonFatherWeek 3SonSonSonSonSonSonFatherWeek 4SonSonSonSonSonSonGrandfather This structure is fully customizable depending on your organization’s specific needs, as we’ll see further below. ## Benefits of the GFS Strategy - **Multiple recovery points****Having backups across different time intervals reduces the risk of permanent data loss. - Efficient storage use****By rotating and overwriting older backups, GFS minimizes redundancy without sacrificing retention depth. - Regulatory compliance****Industries such as finance, healthcare, and legal must retain data for several years. GFS helps meet these obligations (e.g., GDPR, MiFID II). - Scalability and versatility****GFS adapts well to evolving business needs and data growth over time. - Compatible across environments****GFS can be deployed in bare-metal servers, virtualized platforms, and private cloud infrastructures like those offered by Stackscale. ## Limitations and How to Overcome Them While GFS is highly effective, it has some limitations: - Scalability challenges**: Manually managing backup sets can become complex. Automation with tools like SimpleBackups, **NAKIVO Backup & Replication**, or **Veeam Backup & Replication** can significantly streamline the process. - **Heavy use of resources**: Weekly and monthly full backups can consume considerable bandwidth and storage. Techniques like deduplication, compression, or synthetic full backups can optimize performance. - **Limited temporal granularity**: To recover files at very specific times, GFS should be complemented with frequent snapshots or continuous backup for critical systems. ## GFS in Private Cloud and Bare-Metal Environments At Stackscale, clients can easily implement the GFS strategy using high-speed NVMe or SSD storage in our private cloud or dedicated server infrastructure. Backups can be configured locally and replicated across geographically redundant data centers for enhanced resilience. Key advantages of Stackscale: - High availability (99.90% SLA) - NVMe storage with hardware RAID and NVRAM - European-certified infrastructure for regulatory compliance - Integration with leading backup software - 24/7 specialized technical support ## Integration with Professional Backup Tools Stackscale supports seamless GFS implementation with leading backup solutions, including: - **NAKIVO Backup & Replication**: Ideal for VMware, Hyper-V, Nutanix AHV, and Proxmox environments. Offers built-in GFS automation, deduplication, compression, and off-site replication. - **Veeam Backup & Replication**: Widely used for both physical and virtual environments. Enables GFS-style retention policies, instant recovery, immutability, and granular restore. - **Bacula Enterprise**: Suitable for hybrid infrastructures. Offers advanced GFS retention and management for both tape and cloud-based storage. - **Restic / BorgBackup**: Open-source alternatives that allow custom GFS scripting with cron jobs, perfect for Linux and bare-metal systems. - **SimpleBackups**: User-friendly solution for automating GFS backups with services like Dropbox, Wasabi, or Amazon S3—even with serverless deployment. Stackscale provides full support for deploying these tools in cloud or bare-metal environments, including automation, backup testing, and encrypted secondary storage. ## Best Practices for Implementing GFS - **Define a clear retention policy** based on industry requirements, data volume, and business needs. - **Automate the workflow** using compatible tools like NAKIVO, Veeam, or Bacula. - **Choose the right storage**: local storage for daily backups, cloud or offsite storage for long-term backups. - **Schedule regular tests** to ensure backup and restore functionality. - **Use encryption and access control** to comply with cybersecurity standards. ## Conclusion The Grandfather-Father-Son backup strategy remains one of the most effective and reliable data protection methods. Its simplicity, combined with adaptability, makes it ideal for organizations seeking scalable, secure, and regulation-compliant backup strategies. At Stackscale, we provide the infrastructure needed to deploy GFS strategies reliably—whether on dedicated servers or private cloud. We also assist clients in integrating professional backup tools like NAKIVO, Veeam, or Bacula, ensuring end-to-end data protection. **Ready to safeguard your business with a professional GFS backup strategy?**Contact Stackscale today to design the ideal backup solution for your infrastructure. --- ## Estrategia de copia de seguridad Grandfather-Father-Son (GFS): una solución fiable y escalable para entornos empresariales URL: https://www.stackscale.com/blog/grandfather-father-son-gfs-backup/ En la era de la información, los datos se han convertido en uno de los activos más valiosos para cualquier organización. Su pérdida, ya sea por errores humanos, fallos técnicos o ciberataques, puede tener consecuencias críticas. Por ello, contar con una estrategia de copias de seguridad eficiente y segura es imprescindible. Entre las distintas metodologías disponibles, la **estrategia Grandfather-Father-Son (GFS) destaca por su robustez, flexibilidad y eficacia probada a lo largo del tiempo**. En este artículo del blog de Stackscale, exploramos en profundidad en qué consiste esta estrategia, sus beneficios, limitaciones, casos de uso en el mundo real y cómo puede implementarse en entornos modernos, incluidos servidores bare-metal y cloud privado. ## ¿Qué es la estrategia de copia de seguridad GFS? La estrategia Grandfather-Father-Son (GFS) es un sistema jerárquico de retención de copias de seguridad que permite equilibrar la protección de datos a largo plazo con un uso eficiente del almacenamiento. Esta metodología se basa en tres niveles de backup: - **Son (Hijo)**: copias de seguridad diarias, habitualmente incrementales o diferenciales, pensadas para recuperar rápidamente los datos más recientes. - **Father (Padre)**: copias de seguridad semanales, generalmente completas, que permiten un punto de restauración intermedio y más consolidado. - **Grandfather (Abuelo)**: copias mensuales completas, diseñadas para la conservación de largo plazo y almacenadas en ubicaciones seguras, ya sea offline o en cloud. Este sistema, originado en la era de las cintas magnéticas, ha demostrado ser lo suficientemente flexible como para adaptarse a las nuevas tecnologías de almacenamiento, ya sea en local, en la nube o en soluciones híbridas. ## ¿Cómo funciona GFS? Un ejemplo visual Día / SemanaLunesMartesMiércolesJuevesViernesSábadoDomingoSemana 1SonSonSonSonSonSonFatherSemana 2SonSonSonSonSonSonFatherSemana 3SonSonSonSonSonSonFatherSemana 4SonSonSonSonSonSonGrandfather Este patrón puede personalizarse en función de las necesidades específicas del negocio, como veremos más adelante. ## Ventajas de la estrategia GFS - **Diversificación de puntos de recuperación****Al mantener múltiples versiones de backup en distintos momentos del tiempo, se reduce significativamente el riesgo de pérdida de datos. - Optimización del espacio de almacenamiento****Al aplicar políticas de rotación y sobrescritura controlada, GFS evita redundancias innecesarias sin comprometer la retención a largo plazo. - Cumplimiento normativo****Sectores como el financiero, sanitario o jurídico requieren retención de datos durante varios años. GFS facilita la adecuación a normativas como el GDPR o MiFID II. - Versatilidad y escalabilidad****GFS puede adaptarse fácilmente al crecimiento del negocio y a las necesidades cambiantes de retención. - Compatibilidad con diferentes entornos****Puede implementarse tanto en soluciones locales (bare-metal), como en entornos virtualizados, híbridos o cloud privado, como los ofrecidos por Stackscale. ## Limitaciones y cómo mitigarlas Aunque eficaz, GFS no está exenta de desafíos: - Limitaciones de escalabilidad**: La gestión manual de múltiples backups puede volverse compleja sin automatización. La integración con software como SimpleBackups o soluciones profesionales como NAKIVO Backup & Replication o Veeam Backup & Replication puede solventar esta barrera. - **Uso intensivo de recursos en backups completos**: Las copias semanales y mensuales suelen ser completas, lo que implica mayor consumo de red y almacenamiento. Una posible solución es emplear deduplicación y compresión, o combinar con copias incrementales sintéticas. - **Falta de granularidad temporal**: Si se requiere restaurar información con precisión horaria, puede ser útil complementar GFS con snapshots más frecuentes o backup continuo en puntos críticos. ## GFS en entornos cloud privado y servidores bare-metal En Stackscale, los clientes pueden implementar fácilmente una estrategia GFS utilizando la infraestructura cloud privada o servidores dedicados con discos NVMe y SSD de alta velocidad. Las copias pueden configurarse localmente y replicarse en centros de datos geográficamente redundantes, garantizando disponibilidad y resiliencia. Ventajas específicas en Stackscale: - Alta disponibilidad (SLA del 99,90 %) - Almacenamiento NVMe con RAID y NVRAM para rendimiento y fiabilidad - Infraestructura europea certificada, ideal para cumplir regulaciones locales - Compatibilidad con herramientas de backup profesionales - Soporte técnico 24/7 especializado ## Integración con herramientas de copia de seguridad profesionales Stackscale facilita la integración de GFS con soluciones de backup líderes en el mercado, entre las que destacan: - **NAKIVO Backup & Replication**: Ideal para entornos VMware, Hyper-V, Nutanix AHV y Proxmox. Permite configurar estrategias GFS automatizadas, con deduplicación y compresión integradas, y replicación off-site. - **Veeam Backup & Replication**: Muy utilizado en entornos virtualizados y físicos, permite configurar políticas de retención tipo GFS, junto con recuperación instantánea, backup inmutable y recuperación granular. - **Bacula Enterprise**: Recomendado para entornos híbridos, permite una configuración detallada de retención basada en GFS y gestión avanzada de cintas o almacenamiento cloud. - **Restic / BorgBackup**: Alternativas open-source que permiten personalizar la retención GFS mediante scripts y cron jobs, ideales para entornos Linux y servidores bare-metal. - **SimpleBackups**: Solución sencilla para configurar backups en servicios como Dropbox, Wasabi o Amazon S3, compatible con esquemas GFS y backup serverless. Stackscale proporciona soporte para la integración de estas soluciones en sus entornos cloud o bare-metal, incluyendo configuraciones automatizadas, testeo de restauraciones y almacenamiento secundario cifrado. ## Recomendaciones para implementar GFS con éxito - **Definir una política clara de retención** según el sector, el volumen de datos y los requisitos legales. - **Automatizar el proceso** con herramientas compatibles (NAKIVO, Veeam, Bacula, etc.). - **Elegir el almacenamiento adecuado**: discos locales para copias diarias, almacenamiento remoto o cloud para copias mensuales. - **Establecer calendarios de revisión** y testing periódico de restauración. - **Integrar cifrado y control de acceso** para cumplir con estándares de ciberseguridad. ## Conclusión La estrategia Grandfather-Father-Son sigue siendo una de las más sólidas y eficaces para la protección de datos empresariales. Su simplicidad, combinada con una gran capacidad de adaptación, la convierte en una excelente elección para organizaciones que buscan una solución escalable, segura y conforme a normativas. En Stackscale, ofrecemos la infraestructura necesaria para llevar a cabo una estrategia GFS de forma fiable, ya sea mediante servidores dedicados o cloud privado. Además, ayudamos a nuestros clientes a integrar soluciones profesionales de backup como NAKIVO, Veeam o Bacula, garantizando una protección completa del dato. **¿Preparado para proteger tus datos con una estrategia GFS profesional?**Contacta con nosotros para asesorarte en la mejor solución de backup para tu empresa. --- ## The 3-2-1 backup strategy: A practical guide to protecting business-critical data URL: https://www.stackscale.com/blog/the-3-2-1-backup-strategy-a-practical-guide-to-protecting-business-critical-data/ In today’s digital landscape, a reliable backup strategy is not just a best practice—it’s essential. Data loss can be catastrophic: according to studies, 60% of companies that suffer major data loss shut down within six months. **The 3-2-1 backup strategy**, widely adopted for its simplicity and effectiveness, provides a robust solution for safeguarding your data against threats such as ransomware, human error, and system failures. ## What Is the 3-2-1 Backup Strategy? The 3-2-1 rule was originally proposed by photographer Peter Krogh as part of his digital workflow. It’s now considered a gold standard in IT environments. The 3-2-1 rule means: - **3** copies of your data: One primary copy and at least two backups. - **2** different types of storage media: Such as a local NAS and cloud storage, or an internal hard drive and an external drive. - **1** off-site copy: A backup stored in a different physical location or data center. This approach ensures redundancy, minimizes risk, and improves recoverability in case of incidents. ## How to Implement the 3-2-1 Strategy ### 1. Select the Right Backup Media Using at least two different storage media is key. Some of the most commonly used include: - **Internal or external hard drives** – Good for local storage but may have limited durability. - **NAS (Network Attached Storage)** – Centralized storage accessible by multiple systems. - **Cloud storage** – Scalable and accessible remotely, though data privacy and cost should be considered. - **Data centers or colocation** – Ideal for secure, off-site backups with physical separation from the main site. ### 2. Configure Local and Off-Site Backups Make sure backups are spread across different locations: - Store one copy locally, such as on an internal server or on-premises NAS. - Store at least one backup off-site—for example, in a private cloud or a dedicated server in a geographically remote Stackscale data center. - This protects against localized threats like natural disasters, hardware failure, or cyberattacks. ### 3. Choose and Install Backup Software The backup software you select should support: - **Automation** – To streamline backup creation and reduce errors. - **Scheduling** – To ensure regular backups (daily, weekly, etc.). - **Versioning** – Keeping multiple versions of files for easy recovery. - **Encryption** – To protect sensitive information. - **Compression** – To optimize storage space. ### 4. Automate and Schedule Backups Backups should be scheduled regularly based on your data’s criticality and compliance requirements (e.g., GDPR or sector-specific mandates). For example: - Daily backups for sensitive customer or financial data. - Weekly or monthly backups for less volatile information. Modern backup solutions support full automation, helping ensure consistency without requiring daily manual intervention. ### 5. Validate Backup Integrity and Test Recovery Don’t wait until disaster strikes to find out your backups don’t work. Implement the following: - Run periodic test restores to confirm files are intact and accessible. - Simulate real-world recovery scenarios to test speed and efficiency. - Use checksum tools (e.g., MD5, SHA256) to verify data consistency. ## Advantages of the 3-2-1 Strategy - **Data loss protection** – With redundant backups in different formats and locations. - **Reduced downtime** – Faster recovery after data loss or cyber incidents. - **Ransomware resilience** – Off-site or disconnected backups prevent attackers from encrypting all copies. - **Regulatory compliance** – Helps meet data protection mandates like GDPR, ISO 27001, HIPAA, or PCI-DSS. - **Scalability** – Adapts to growing data volumes and evolving business needs. ## Going Further: The 3-2-1-1-0 Rule Some organizations adopt an enhanced version of this strategy for added security: - **3** copies of data. - **2** types of storage media. - **1** off-site copy. - **1** offline or immutable copy (e.g., air-gapped). - **0** backup errors, verified through regular testing. This advanced strategy protects against sophisticated threats, ensuring one backup remains untouched by malware or system breaches. ## Cost Considerations and ROI Implementation costs vary depending on the tools and infrastructure chosen. Stackscale offers private cloud and bare-metal server environments that support flexible backup strategies, optimized for cost-efficiency and compliance. Unlike public cloud providers, Stackscale avoids hidden fees such as egress charges, helping businesses maintain predictable costs over time. ## Conclusion **The 3-2-1 backup strategy is a simple yet powerful approach to business continuity**. It offers a solid foundation for any organization looking to reduce the risk of data loss, ensure compliance, and improve disaster recovery readiness. At Stackscale, we help companies implement tailored backup strategies using high-availability private cloud infrastructure and bare-metal servers hosted in Europe, ensuring total data control and privacy. Ready to strengthen your backup plan? Contact our team and discover the ideal backup solution for your business. --- ## Estrategia de copia de seguridad 3-2-1: guía práctica para proteger tus datos empresariales URL: https://www.stackscale.com/blog/the-3-2-1-backup-strategy-a-practical-guide-to-protecting-business-critical-data/ En un entorno digital cada vez más complejo, contar con una estrategia de backup eficaz ya no es una opción, sino una necesidad. La pérdida de datos puede tener consecuencias devastadoras: según diversos estudios, el 60 % de las empresas que sufren una pérdida de datos importante cierran en los seis meses siguientes. La **estrategia 3-2-1 de copia de seguridad**, ampliamente reconocida por su simplicidad y eficacia, se presenta como una solución sólida para minimizar estos riesgos. ## ¿En qué consiste la estrategia de backup 3-2-1? La regla 3-2-1 fue formulada originalmente por Peter Krogh, un fotógrafo especializado en flujos de trabajo digitales. Desde entonces, se ha adoptado en entornos corporativos por su enfoque claro y flexible. Esta estrategia establece que: - **3**: Debes tener al menos tres copias de tus datos (el original + dos copias de seguridad). - **2**: Las copias deben almacenarse en **dos tipos diferentes de medios**, como discos duros, NAS, cinta o almacenamiento en la nube. - **1**: Al menos una copia debe estar **fuera del sitio principal**, es decir, en una ubicación diferente física o geográficamente (por ejemplo, en la nube o en otro centro de datos). Con esta estructura se garantiza la redundancia necesaria para proteger los datos ante fallos de hardware, errores humanos o desastres naturales. ## Cómo implementar la estrategia 3-2-1 en tu empresa ### 1. Seleccionar los medios de almacenamiento adecuados Dado que la estrategia exige el uso de dos tipos distintos de medios, es importante evaluar las siguientes opciones: - **Discos duros internos o externos**: Son ideales para copias locales, pero tienen limitaciones en durabilidad. - **Sistemas NAS (Network Attached Storage)**: Permiten acceder a los backups desde distintos dispositivos dentro de la red. - **Almacenamiento en la nube**: Escalable y accesible desde cualquier lugar, aunque debe evaluarse en términos de privacidad y costes. - **Centros de datos o colocation**: Ideal para copias fuera del sitio que requieran mayor seguridad y control. ### 2. Configurar copias locales y remotas Una parte clave de la estrategia 3-2-1 es que no todas las copias estén en el mismo lugar. Por ejemplo: - Mantén una copia local en tu centro de datos o servidor principal. - Guarda otra en un almacenamiento externo, como la nube o un servidor bare-metal en otra ubicación (por ejemplo, uno de los centros de datos europeos de Stackscale). - Asegúrate de que al menos una de esas copias esté aislada de riesgos locales como incendios, inundaciones o ataques ransomware. ### 3. Elegir e instalar el software de backup adecuado El software de backup debe permitirte: - **Automatizar tareas**: para minimizar errores humanos. - **Programar copias periódicas**: según la criticidad del dato (diaria, semanal, mensual). - **Mantener versiones anteriores**: para facilitar la recuperación de versiones eliminadas o corruptas. - **Cifrar los datos**: para proteger la privacidad, especialmente si la copia está en la nube. - **Comprimir los archivos**: para ahorrar espacio. ### 4. Automatizar y programar copias de seguridad La copia de seguridad debe ser un proceso continuo. Según la sensibilidad de los datos y los requisitos normativos (por ejemplo, RGPD o normativas del sector financiero o sanitario), es recomendable ajustar la frecuencia del backup. - Para datos críticos, como información de clientes o financieros, se recomienda una copia diaria. - Las herramientas de backup modernas permiten automatizar completamente este proceso. ### 5. Verificar la integridad de los backups No basta con hacer copias: es necesario comprobar que pueden restaurarse correctamente. Para ello: - Realiza pruebas de recuperación periódicas. - Verifica que los archivos no estén corruptos mediante checksums (por ejemplo, MD5 o SHA256). - Simula escenarios de recuperación ante desastres para validar la respuesta del sistema. ## Ventajas de la estrategia 3-2-1 - **Mayor protección ante pérdida de datos**: Al tener múltiples copias en distintos medios y ubicaciones. - **Recuperación rápida y menos interrupciones**: Reduce los tiempos de inactividad tras un fallo. - **Resiliencia frente a ciberamenazas**: Especialmente útil frente a ransomware, ya que al menos una copia estará desconectada de la red. - **Cumplimiento normativo**: Facilita el cumplimiento con normas como el RGPD, ISO 27001 o PCI-DSS. - **Escalabilidad**: Puede adaptarse al crecimiento de la empresa con nuevas copias o frecuencias. ## Evolución de la estrategia: 3-2-1-1-0 En entornos donde la seguridad debe ser extrema, se está adoptando una versión extendida: - **1 copia offline e inmutable**: desconectada de la red y no modificable. - **0 errores**: validación periódica para asegurar que todos los backups son funcionales. Este enfoque es ideal para organizaciones con exigencias de alta criticidad o que operan en sectores como el sanitario, financiero o gubernamental. ## Análisis de costes y recursos El coste de implementar la estrategia 3-2-1 depende del tipo de almacenamiento y software utilizado. En Stackscale, las empresas pueden combinar almacenamiento en la nube privada con servidores bare-metal y soluciones de backup como NAKIVO o Veeam, optimizando costes y rendimiento. Además, se evitan tarifas adicionales por tráfico de salida (egress fees), comunes en proveedores de nube pública. ## Conclusión **La estrategia de copia de seguridad 3-2-1 es una solución sencilla pero poderosa para proteger la información empresari**al. Implementarla correctamente garantiza la continuidad del negocio ante cualquier incidente, desde un fallo técnico hasta un ciberataque. En Stackscale, ayudamos a las empresas a diseñar e implementar soluciones de backup personalizadas sobre cloud privado o servidores dedicados bare-metal, con soporte técnico especializado, alta disponibilidad y total soberanía del dato. ¿Estás preparado para reforzar tu estrategia de backup? Ponte en contacto con nosotros y descubre cómo podemos ayudarte. --- ## NIS2: A Threat or an Opportunity to Strengthen Cybersecurity? URL: https://www.stackscale.com/blog/nis2-a-threat-or-an-opportunity-to-strengthen-cybersecurity/ #### **The New European Framework Redefining Digital Security** The rise in cyberattacks across Europe is a growing concern. In **2023, companies experienced an average of 1,557 cyberattacks per week**, marking an **86% increase from the previous year**. The increasing interconnectivity between **IT and OT infrastructures** has expanded the attack surface for cybercriminals, who are now leveraging **Artificial Intelligence** to execute more sophisticated attacks. To address this challenge, the **European Union has introduced the NIS2 Directive**, aimed at **strengthening the security of critical infrastructures and reducing the risk of cyberattacks on key organizations**. This regulation represents a significant evolution from its predecessor, expanding requirements and obligations to enhance the resilience of businesses against cyber threats. ### **Key Changes in the NIS2 Directive** #### **Stronger Penalties and Sanctions** Organizations failing to comply with the regulation within the set timeframe could face **GDPR-like financial penalties**: - **Essential entities**: Fines of up to **€10 million** or **2% of global annual revenue**. - **Important entities**: Fines of up to **€7 million** or **1.4% of global annual revenue**. Additionally, the directive includes **administrative fines, corrective measures, and liability for damages** in cases of non-compliance. #### **Increased Executive Responsibility** C-level executives who fail to ensure NIS2 compliance may face **personal liability**, restrictions on holding executive positions, and additional sanctions. #### **Supply Chain Security** Companies must ensure that **their suppliers meet high cybersecurity standards**, implementing regular audits and contractual security requirements. ### **Guide to Implementing the NIS2 Directive** Complying with NIS2 can be complex, but a structured approach can help organizations adapt successfully. Below is a practical **step-by-step strategy** to ensure compliance: #### **1. Engage Senior Management** Executive commitment is crucial. Cybersecurity should be integrated into the company’s overall strategy, with adequate funding and resource allocation. #### **2. Establish a Project Management Team** A dedicated team with clearly defined roles and responsibilities should be assigned to oversee NIS2 compliance, ensuring efficient implementation. #### **3. Assess Current Cybersecurity Posture** Conduct an initial **risk assessment** to identify security gaps and areas for improvement, covering **technology infrastructure, processes, and internal policies**. #### **4. Implement a Risk Management Framework** Adopt a standardized risk management approach based on **ISO 27001 or IEC 62443**, ensuring proper risk evaluation and mitigation strategies. #### **5. Develop and Enforce Security Policies** Establish clear policies for **data protection, access control, incident management, and business continuity**, ensuring regular updates in response to evolving threats. #### **6. Strengthen Supply Chain Security** Verify that all suppliers and third-party vendors comply with NIS2 cybersecurity requirements by conducting **audits and security assessments**. #### **7. Deploy Technical and Operational Security Measures** Enhance security through the implementation of: - **Continuous monitoring** and real-time threat detection. - **Data encryption** for both storage and transmission. - **Multi-factor authentication (MFA)** for critical systems. - **Network segmentation** to limit the impact of potential breaches. #### **8. Develop an Incident Response and Reporting Plan** Establish a well-defined **incident response plan** to ensure quick reaction times. The NIS2 mandates that companies report major incidents to **INCIBE (Spain’s National Cybersecurity Institute)** within a set timeframe. #### **9. Conduct Cybersecurity Awareness and Training** Provide **regular training for employees and executives** on cybersecurity risks, phishing, and best practices. A well-informed workforce significantly reduces the risk of successful attacks. #### **10. Perform Regular Audits and Continuous Improvement** Schedule **internal cybersecurity audits** to evaluate the effectiveness of security measures and adjust policies as needed. Cybersecurity is an ongoing process that requires continuous updates. ### **Advanced Cybersecurity Services for NIS2 Compliance** To meet NIS2 compliance requirements, businesses can leverage **advanced cybersecurity solutions** from **Stackscale** with Grupo Aire, offering proactive protection for critical infrastructures: - **Security audits**: Comprehensive evaluation of systems and assets. - **Vulnerability management**: Identifying and mitigating risks across infrastructure. - **Continuous risk analysis**: Ongoing monitoring of digital exposure and emerging threats. - **Penetration testing**: Simulating attacks to test the effectiveness of defenses. - **Incident response services**: Rapid detection, containment, and recovery from cyberattacks. - **Employee cybersecurity training**: Programs designed to educate staff and leadership on security risks. ### **Conclusion: NIS2 as a Catalyst for Business Cybersecurity** The NIS2 Directive not only **tightens cybersecurity obligations** but also presents an **opportunity for organizations to enhance their digital resilience** and strengthen their market position. Companies that implement **advanced cybersecurity measures** will not only **avoid penalties** but also **gain customer trust and maintain a competitive edge** in an increasingly digital world. At **Stackscale** (Grupo Aire), we help businesses build a **robust security strategy** to comply with NIS2 and **protect their critical infrastructure**. **Contact us today** to learn how we can support your cybersecurity needs. --- ## NIS2: ¿Una amenaza o una oportunidad para fortalecer la ciberseguridad empresarial? URL: https://www.stackscale.com/blog/nis2-a-threat-or-an-opportunity-to-strengthen-cybersecurity/ ### **El nuevo marco europeo que redefine la seguridad digital** El incremento de ciberataques en Europa es una realidad alarmante. En 2023, se registraron **1.557 ciberataques semanales por empresa**, lo que representa un **aumento del 86 % respecto al año anterior**. La creciente interconectividad entre **infraestructuras de TI y OT** ha ampliado la superficie de ataque de los ciberdelincuentes, que además emplean herramientas avanzadas de **Inteligencia Artificial** para perfeccionar sus ataques. Ante este escenario, la **Unión Europea ha implementado la Directiva NIS2** con el objetivo de **fortalecer la seguridad de las infraestructuras críticas y reducir el riesgo de ciberataques a empresas y entidades clave**. Esta normativa supone una evolución significativa respecto a su predecesora, ampliando los requisitos y las obligaciones para mejorar la resiliencia de las organizaciones frente a las ciberamenazas. ## **Principales novedades de la Directiva NIS2** ### **Multas y sanciones reforzadas** Las organizaciones que no cumplan con la normativa dentro del plazo establecido podrán enfrentar **sanciones económicas similares a las del RGPD**: - **Entidades esenciales**: hasta **10 millones de euros** o el **2 % de la facturación anual mundial**. - **Entidades importantes**: hasta **7 millones de euros** o el **1,4 % de la facturación anual mundial**. Además, la directiva contempla **multas administrativas, medidas correctivas y responsabilidad por daños** en caso de incumplimiento. ### **Responsabilidad de la alta dirección** Los ejecutivos de nivel C que no aseguren el cumplimiento de la NIS2 podrán enfrentar **responsabilidad penal**, restricciones en sus cargos y sanciones personales. ### **Seguridad en la cadena de suministro** Las empresas deberán garantizar que **sus proveedores cumplan con altos estándares de ciberseguridad**, implementando controles y auditorías periódicas. ## **Guía para la implementación de la Directiva NIS2** El cumplimiento de la NIS2 puede resultar complejo, pero con un enfoque estructurado, las empresas pueden adaptarse con éxito. A continuación, se presenta una estrategia de implementación basada en buenas prácticas: ### **1. Implicación de la alta dirección** El compromiso de la dirección es fundamental. La ciberseguridad debe integrarse en la estrategia corporativa y contar con los recursos necesarios para su implementación. ### **2. Creación de un equipo de gestión de proyectos** Designar un equipo responsable del cumplimiento de la NIS2, con roles y responsabilidades claramente definidos, garantizará una adopción efectiva de las medidas requeridas. ### **3. Evaluación del estado actual de ciberseguridad** Realizar un diagnóstico inicial para identificar brechas de seguridad y áreas de mejora. Este análisis debe abarcar tanto la infraestructura tecnológica como los procesos y políticas internas. ### **4. Definición de un marco de gestión de riesgos** Implementar una metodología estandarizada, basada en normativas como **ISO 27001 o IEC 62443**, para evaluar y mitigar los riesgos de ciberseguridad. ### **5. Desarrollo e implementación de políticas de seguridad** Establecer políticas claras para la protección de datos, control de accesos, gestión de incidentes y continuidad del negocio. Estas deben actualizarse periódicamente según la evolución de las amenazas. ### **6. Fortalecimiento de la seguridad en la cadena de suministro** Verificar que los proveedores y socios comerciales cumplen con los requisitos de ciberseguridad establecidos en la NIS2. Implementar auditorías y cláusulas contractuales que garanticen su cumplimiento. ### **7. Implantación de medidas técnicas y operativas** Aplicar controles de seguridad en redes, sistemas y aplicaciones. Algunas de las acciones clave incluyen: - **Monitorización continua** y detección de amenazas en tiempo real. - **Cifrado de datos sensibles** en tránsito y en reposo. - **Autenticación multifactorial** para accesos a sistemas críticos. - **Segmentación de redes** para limitar el impacto de posibles ataques. ### **8. Plan de respuesta y notificación de incidentes** Establecer un protocolo de respuesta ante incidentes de ciberseguridad, asegurando la capacidad de reacción rápida. La NIS2 exige notificar incidentes significativos al **INCIBE** (Instituto Nacional de Ciberseguridad) en un plazo determinado. ### **9. Formación y concienciación en ciberseguridad** Capacitar periódicamente a empleados y directivos sobre amenazas cibernéticas, phishing y buenas prácticas de seguridad. Un personal bien informado reduce significativamente el riesgo de ataques exitosos. ### **10. Auditorías internas y mejora continua** Realizar auditorías periódicas para evaluar la efectividad de las medidas implementadas y ajustarlas según sea necesario. La ciberseguridad es un proceso dinámico que debe evolucionar constantemente. ## **Servicios avanzados de ciberseguridad para cumplir con la NIS2** Para garantizar el cumplimiento de la Directiva NIS2, las empresas pueden apoyarse en **soluciones avanzadas de ciberseguridad** como las que ofrece **Stackscale** a través de Grupo Aire, que permiten proteger la infraestructura digital con un enfoque proactivo: - **Auditorías de seguridad**: evaluación integral de sistemas y activos tecnológicos. - **Gestión de vulnerabilidades**: detección y mitigación de riesgos en toda la infraestructura. - **Análisis de riesgos continuo**: supervisión de exposición digital y amenazas emergentes. - **Penetration Testing**: pruebas de intrusión para verificar la efectividad de las defensas. - **Respuesta a incidentes**: detección, contención y recuperación ante ataques. - **Concienciación y formación**: programas de capacitación en ciberseguridad para empleados y directivos. ## **Conclusión: La NIS2 como un catalizador de la ciberseguridad empresarial** La Directiva NIS2 no solo **endurece las obligaciones en materia de ciberseguridad**, sino que también **ofrece a las empresas la oportunidad de fortalecer su resiliencia digital** y mejorar su posición en el mercado. Las organizaciones que implementen medidas avanzadas de ciberseguridad no solo evitarán sanciones, sino que ganarán confianza y competitividad en un entorno cada vez más digitalizado. En **Stackscale** y Grupo Aire, ayudamos a las empresas a desarrollar una estrategia sólida de seguridad para cumplir con la NIS2 y proteger su infraestructura crítica. **Contáctanos** para descubrir cómo podemos ayudarte a reforzar tu ciberseguridad. --- ## SEAPATH 1.0: The Open-Source Virtualization Solution for Power Substations URL: https://www.stackscale.com/blog/seapath-1-0-the-open-source-virtualization-solution-for-power-substations/ The **Linux Foundation**, through **LF Energy**, has released **SEAPATH 1.0**, an open-source hypervisor designed for the virtualization of **digital power substations** under the **IEC 61850 standard**. This solution marks a significant advancement in modernizing the energy sector, providing a **secure, scalable, and high-performance** environment for managing power grids. The increasing decentralization of power generation and the need for greater operational efficiency have made substation digitalization a **key priority** for energy companies. SEAPATH enables this transformation by delivering an **open, flexible infrastructure** aligned with the evolving demands of the industry. ### **What is SEAPATH and Why is it Crucial for Energy Digitalization?** SEAPATH, short for **Software Enabled Automation Platform and Artifacts Therein**, is an open-source hypervisor focused on virtualizing **protection, automation, and control systems** in power grids. Developed by experts in **embedded Linux, electrical engineering, IT, and cybersecurity**, it aims to bridge the gap between **operational technology (OT) and information technology (IT)**. This hypervisor is part of LF Energy’s **Digital Substation Special Interest Group**, an initiative dedicated to accelerating the **energy transition** through open-source solutions for critical infrastructure. * ### **Key Features of SEAPATH 1.0** #### **Open and Vendor-Agnostic Architecture** - **Hardware Agnostic:** Compatible with **x86 and ARM architectures**, allowing deployment on a wide range of servers. - **Vendor Independence:** Supports heterogeneous **virtual machine environments**, integrating with various hardware and software providers. - **Open-Source Licensing:** Apache-2.0 license enables **customization and integration** into critical infrastructure projects. - **Seamless Integration** with other **LF Energy projects** such as **CoMPAS, FledgePOWER, and OpenSCD**, optimizing its use in **digital substation automation**. #### **High-Performance Real-Time Capabilities** - **Deterministic Real-Time Processing** ensures optimal response times for critical applications. - **Precise Time Synchronization** via **NTP and PTP (IEEE 1588)** for accurate operation in protection and automation systems. #### **Security and Resilience for Critical Environments** - **High availability through clustering**, ensuring continuous operation even in case of hardware or software failures. - **Distributed storage with data replication**, enhancing data integrity and system reliability. - **Automated updates** allow for remote deployment of security patches and improvements without disrupting operations. #### **Automated Management and Infrastructure as Code** - **Script-Based Configuration Automation** minimizes human errors and simplifies large-scale deployments. - **Remote and Local Management** enables infrastructure control from anywhere within the network. #### **Cybersecurity-Focused with Continuous Testing** - **Over 700 daily automated tests** ensure system stability and early failure detection. - **Advanced security validation** for every system component. ### **The Role of SEAPATH in Power Grid Modernization** The **energy sector** is undergoing an **unprecedented transformation** driven by **renewable energy integration, distributed generation, and growing demands for grid flexibility**. **Digital substations** play a crucial role in improving efficiency and automation in grid management. SEAPATH enables the **virtualization of Intelligent Electronic Devices (IEDs)**, allowing them to communicate and operate under the **IEC 61850 standard**. This significantly enhances **operational efficiency**, reduces **OPEX**, and **improves grid resilience** against failures and cyber threats. ### **Deployment and Adoption in the Energy Industry** Several major **energy and technology companies** have already integrated SEAPATH into their operations. Early adopters include **GE Vernova, Alliander, ABB, Red Hat, and Enedis**. In France, **RTE has successfully deployed SEAPATH** in digital substations for over a year, proving its reliability in managing power grids. **Maxime Pelletier**, from **RTE**, stated that the technology has been instrumental in virtualizing critical substation functions, enabling greater flexibility and security in infrastructure management. From a technology perspective, **Welotec** has highlighted SEAPATH as a **scalable and efficient solution**, ideal for **substation digitalization** in the energy transition era. ### **SEAPATH’s Impact on the Energy Transition** **Power substation virtualization** is a **key enabler** in building a **more sustainable and efficient energy system**. As **renewable energy sources** continue to expand and **power production becomes more decentralized**, power grids require **greater automation and adaptability**. According to **Alex Thornton, Executive Director of LF Energy**, SEAPATH is not only designed to meet these challenges but also provides an **open-source platform for future innovations in the energy sector**. ### **A Growing Ecosystem: How to Get Involved in SEAPATH** SEAPATH has been developed with contributions from leading energy and technology companies, including **RTE, Alliander, GE Vernova, Savoir-faire Linux, Welotec, and Red Hat**. **Eloi Bail, Chair of the SEAPATH Technical Committee**, emphasized the importance of **open collaboration** and invited more organizations to join the initiative: “With advancements in AI and digitalization, it’s clear that open-source software is key to accelerating innovation while reducing costs. SEAPATH is proof that open collaboration can transform the energy industry.”* Organizations interested in **contributing to SEAPATH’s development or deploying it in their infrastructure** can get involved in various ways: - **Join the SEAPATH Technical Committee** at LF Energy. - **Explore SEAPATH documentation and tools** available on the LF Energy platform. With **SEAPATH 1.0**, **power substation virtualization** is moving toward a **more secure, efficient, and future-ready** energy landscape. --- ## SEAPATH 1.0: La virtualización de subestaciones eléctricas con código abierto URL: https://www.stackscale.com/blog/seapath-1-0-the-open-source-virtualization-solution-for-power-substations/ a Linux Foundation, a través de LF Energy, ha lanzado **SEAPATH 1.0**, un **hipervisor de código abierto diseñado para la virtualización de subestaciones eléctricas digitales** bajo el estándar IEC 61850. Esta solución representa un avance clave en la modernización del sector energético, ofreciendo un entorno seguro, escalable y optimizado para la gestión de redes eléctricas. La creciente descentralización de la generación de energía y la necesidad de mejorar la eficiencia operativa han convertido la digitalización de subestaciones en un pilar fundamental para las compañías eléctricas. SEAPATH facilita esta transformación al proporcionar una infraestructura abierta, flexible y alineada con las nuevas demandas del sector. ### **Qué es SEAPATH y por qué es clave para la digitalización de la energía** SEAPATH, acrónimo de Software Enabled Automation Platform and Artifacts Therein, es un hipervisor de código abierto enfocado en la virtualización de sistemas de protección, automatización y control en redes eléctricas. Su desarrollo ha sido impulsado por expertos en Linux embebido, ingeniería eléctrica, IT y ciberseguridad, con el objetivo de acercar las tecnologías de operación y las tecnologías de la información. Este hipervisor forma parte del Grupo de Interés Especial en Subestaciones Digitales de LF Energy, una iniciativa orientada a acelerar la transición energética mediante la digitalización de infraestructuras críticas. ### **Principales características de SEAPATH 1.0** #### **Arquitectura abierta y agnóstica** - Compatible con arquitecturas x86 y ARM, permitiendo su implementación en una amplia variedad de servidores. - Independiente de proveedores, capaz de gestionar entornos con máquinas virtuales heterogéneas. - Licencia Apache-2.0, que permite su adopción, personalización e integración con otros sistemas. - Integración con otros proyectos de LF Energy, como CoMPAS, FledgePOWER y OpenSCD, optimizando su aplicación en subestaciones digitales. #### **Alto rendimiento en tiempo real** - Soporte para procesamiento en tiempo real, garantizando tiempos de respuesta óptimos en aplicaciones críticas. - Sincronización precisa mediante NTP y PTP (IEEE 1588), fundamental para aplicaciones de protección y automatización. #### **Seguridad y resiliencia en entornos críticos** - Alta disponibilidad mediante clustering, garantizando continuidad operativa ante fallos de hardware o software. - Almacenamiento distribuido con replicación de datos para mejorar la integridad y seguridad de la información. - Sistema de actualización automática que permite aplicar mejoras y parches sin interrupciones. #### **Gestión automatizada e infraestructura como código** - Automatización de configuración mediante scripts para evitar errores manuales y facilitar despliegues masivos. - Administración remota y local para una gestión eficiente desde cualquier punto de la red. #### **Enfoque en ciberseguridad y pruebas continuas** - Más de 700 pruebas diarias para garantizar estabilidad y detección temprana de fallos. - Validaciones de seguridad avanzadas en cada componente del sistema. ### **El papel de SEAPATH en la modernización de las redes eléctricas** Las redes eléctricas están experimentando una transformación sin precedentes debido a la incorporación de energías renovables, la generación distribuida y la demanda creciente de flexibilidad en la distribución. La digitalización de subestaciones es clave para mejorar la eficiencia y automatización en la gestión de la red. SEAPATH permite la virtualización de dispositivos electrónicos inteligentes (IED), facilitando su compatibilidad con el estándar IEC 61850 para una comunicación y control más eficiente en subestaciones. Esto optimiza la gestión operativa, reduce costes y aumenta la resiliencia de la red ante posibles fallos o ciberataques. ### **Implementación y adopción en la industria energética** Empresas del sector energético y tecnológico han comenzado a implementar SEAPATH en entornos reales. Entre las primeras compañías en adoptar este hipervisor se encuentran GE Vernova, Alliander, ABB, Red Hat y Enedis. En Francia, RTE ha desplegado SEAPATH en subestaciones digitales operativas durante más de un año, demostrando su fiabilidad en la gestión de redes eléctricas. Según Maxime Pelletier, de RTE, la tecnología ha permitido virtualizar funciones críticas en subestaciones, aumentando la flexibilidad y seguridad en la infraestructura. Desde la industria tecnológica, empresas como Welotec han destacado a SEAPATH como una solución escalable y eficiente, ideal para la digitalización de subestaciones en el contexto de la transición energética. ### **Impacto de SEAPATH en la transición energética** La virtualización de subestaciones eléctricas desempeña un papel fundamental en la evolución hacia un sistema energético más sostenible y eficiente. Con el crecimiento de las energías renovables y la descentralización de la generación de energía, las redes eléctricas deben ser más flexibles y automatizadas. Según Alex Thornton, director ejecutivo de LF Energy, SEAPATH no solo responde a estos desafíos, sino que también proporciona una plataforma de código abierto para impulsar nuevas innovaciones en el sector energético. ### **Un ecosistema en crecimiento: cómo participar en SEAPATH** El desarrollo de SEAPATH ha contado con la colaboración de empresas líderes en el sector eléctrico y tecnológico, incluyendo RTE, Alliander, GE Vernova, Savoir-faire Linux, Welotec y Red Hat. Eloi Bail, presidente del Comité Técnico de SEAPATH, ha subrayado la importancia de la colaboración en código abierto y ha invitado a más organizaciones a sumarse al proyecto: “La convergencia de la inteligencia artificial y la digitalización en el sector energético es inminente. SEAPATH demuestra cómo la colaboración en software de código abierto puede transformar la industria sin incrementar los costes de innovación.” Las organizaciones interesadas en contribuir al desarrollo de SEAPATH o en implementarlo en sus infraestructuras pueden hacerlo a través de distintas iniciativas: - Participando en el Comité Técnico de SEAPATH en la Linux Foundation. - Explorando la documentación y herramientas disponibles en la plataforma de LF Energy. Con el lanzamiento de SEAPATH 1.0, la virtualización de subestaciones eléctricas da un paso decisivo hacia un futuro más seguro, eficiente y alineado con los retos de la transición energética. --- ## Protecting and Controlling Information: It’s More Than Just Backups URL: https://www.stackscale.com/blog/protecting-and-controlling-information-its-more-than-just-backups/ In today’s increasingly digital business landscape, **data protection** goes far beyond having internal documents written down or performing routine backups. To comply with **European Union cybersecurity regulations** and safeguard corporate information, more advanced and proactive measures are essential. Implementing tools like **SIEM** (Security Information and Event Management), **XDR** (Extended Detection and Response), **email filtering gateways**, or even **immutable backups** is not enough to ensure comprehensive protection against data loss or leaks. Organizations must adopt more robust solutions such as **DLP** (Data Loss Prevention), which allows for **monitoring and blocking key aspects of digital communication**. These include email exchanges, cloud data sharing (e.g., OneDrive), USB device storage, internet postings, SharePoint Online usage, instant messaging, and more. ### Why is a DLP Solution Essential? A data leak can have severe consequences, whether it involves business information or personal data. Implementing a **Data Loss Prevention (DLP)** solution not only safeguards sensitive information but also enables internal monitoring and reduces the risk of accidental or intentional breaches. **Data security** is a direct responsibility of the executive team, which must take proactive steps to protect information from external and internal threats. ### Common Examples of Data Leaks - **Replying to All****One of the most frequent errors occurs when someone inadvertently sends confidential documents to unintended recipients using the “Reply to All” function, whether via email or digital platforms. - Accidental Data Exposure****Human error or misconfigured applications can leave sensitive data publicly accessible, without the need for a cyberattack. - Physical Loss****Misplacing documents, USB drives, or devices containing sensitive information is another common cause of data leaks. - Exposed Information in Images or Videos****Confidential information may unintentionally appear in photos or videos that are later shared publicly. ### The Difference Between a Data Leak and a Data Breach - Data Leak:** Refers to the unintentional exposure of information due to human error or deliberate actions by employees, such as sharing data without proper safeguards. - **Data Breach:** Involves data being compromised through **cyberattacks**, such as ransomware, phishing, or exploiting vulnerabilities in devices. While **data leaks** are often accidental, they can cause significant financial and reputational damage. A **data breach**, on the other hand, is a targeted attack using specific methods to infiltrate systems and steal information. ### Key Examples of Data Breaches - **Ransomware Attacks****Cybercriminals encrypt data and block access until a ransom is paid. - Social Engineering Attacks****Attackers manipulate employees into revealing sensitive information, such as login credentials. - Endpoint Vulnerabilities****Devices like computers and mobile phones can be exploited to gain access to the corporate network. ### The Importance of Investing in Advanced Security Protecting corporate data requires a comprehensive approach that includes: - Advanced DLP solutions** to prevent data leaks. - Continuous monitoring and control of infrastructure. - Employee training to minimize human error. At Stackscale, we offer solutions designed to safeguard corporate information. From deploying advanced technologies like **DLP** to providing access to specialized security teams, we help organizations meet cybersecurity standards and mitigate risks of data loss or leaks. ### How Can We Help You? If you need advice or tailored solutions to protect your organization’s data, **contact us**. Our team of cybersecurity experts is ready to assist you in implementing cutting-edge technologies and strengthening your company’s defenses. Publication based on the publication Ar Telecom, a Grupo Aire company. --- ## Proteger y controlar la información: más allá de hacer copias de seguridad URL: https://www.stackscale.com/blog/protecting-and-controlling-information-its-more-than-just-backups/ En un entorno empresarial cada vez más digitalizado, **proteger los datos** ya no se reduce a tener documentos internos redactados o realizar copias de seguridad periódicas. Cumplir con los **reglamentos de ciberseguridad de la Unión Europea** y salvaguardar la información de la empresa requiere medidas más avanzadas y proactivas. No basta con implementar herramientas como **SIEM** (Gestión de Información y Eventos de Seguridad), **XDR** (Detección y Respuesta Extendida), **gateways de filtrado de correo electrónico** o incluso **backups inmutables**. Aunque esenciales, estas medidas no garantizan por sí solas una protección integral frente a la pérdida o fuga de datos. Las organizaciones necesitan adoptar soluciones más efectivas como **DLP** (Prevención de Pérdida de Datos), que permitan **monitorizar y bloquear aspectos clave de la comunicación digital**. Esto incluye correos electrónicos, compartición de datos en la nube (por ejemplo, OneDrive), almacenamiento en dispositivos USB, publicaciones en internet, uso de SharePoint Online, servicios de mensajería instantánea y más. ### ¿Por qué es esencial una solución de DLP? Una fuga de datos puede tener consecuencias graves, tanto si afecta a información empresarial como a datos personales. Adoptar una solución de **Prevención de Pérdida de Datos (DLP)** no solo protege la información sensible, sino que también contribuye a supervisar las actividades internas y reducir el riesgo de errores o acciones malintencionadas. La **seguridad de los datos** es una responsabilidad directa de los equipos ejecutivos, que deben tomar medidas proactivas para proteger la información frente a amenazas externas e internas. ### Ejemplos comunes de “data leak” (fuga de datos) - **Responder a todos****Uno de los errores más comunes es enviar, de manera inadvertida, documentos confidenciales a destinatarios incorrectos utilizando la opción “Responder a todos” en correos electrónicos o plataformas digitales. - Exposición accidental de datos****Errores humanos o configuraciones incorrectas en aplicaciones pueden dejar datos confidenciales accesibles públicamente, sin necesidad de un ataque cibernético. - Pérdida física****El extravío de documentos, dispositivos USB o equipos que contienen información sensible es otra causa habitual de fuga de datos. - Exposición en imágenes o vídeos****Información confidencial puede revelarse inadvertidamente en fotografías o vídeos que posteriormente se comparten públicamente. ### Diferencia entre “data leak” y “data breach” - Data leak:** Se refiere a fugas de datos originadas por errores humanos o acciones intencionadas de empleados, como compartir información sin las medidas adecuadas. - **Data breach:** Se produce cuando datos son comprometidos a través de **ataques cibernéticos**, como ransomware, phishing o explotación de vulnerabilidades en dispositivos. Aunque los “data leaks” suelen ser accidentales, pueden causar pérdidas económicas y de reputación significativas. Por otro lado, un **data breach** implica un ataque dirigido que utiliza vectores específicos para acceder a los sistemas y robar información. ### Ejemplos principales de “data breach” - **Ataques de ransomware****Los cibercriminales bloquean el acceso a los datos hasta que se paga un rescate. - Ataques de ingeniería social****Los atacantes manipulan a los empleados para que revelen información confidencial, como credenciales de acceso. - Vulnerabilidades en endpoints****Dispositivos como ordenadores y teléfonos móviles pueden ser explotados para acceder a la red empresarial. ### La importancia de invertir en seguridad avanzada Proteger los datos de una empresa no se limita a implementar herramientas básicas. Es necesario adoptar un enfoque integral que incluya: - DLP avanzado** para prevenir fugas de datos. - Supervisión y control continuo de la infraestructura. - Formación a los empleados para minimizar errores humanos. En Stackscale, ofrecemos soluciones diseñadas para proteger la información empresarial. Desde la implementación de tecnologías avanzadas como **DLP**, hasta la disponibilidad de equipos de seguridad especializados, ayudamos a las organizaciones a cumplir con los estándares de ciberseguridad y a mitigar riesgos de pérdida o fuga de datos. ### ¿Cómo podemos ayudarte? Si necesitas asesoramiento o soluciones específicas para proteger los datos de tu organización, **contáctanos**. Nuestro equipo experto en ciberseguridad está preparado para ayudarte a implementar tecnologías de vanguardia y reforzar la seguridad de tu empresa. Publicación basada en la publicación Ar Telecom, empresa de Grupo Aire. --- ## DeepSeek and Ollama: Advanced AI on bare-metal servers and private cloud with Stackscale URL: https://www.stackscale.com/blog/deepseek-ollama-advanced-ai/ #### **Deploying DeepSeek on Dedicated Servers and Private Cloud** Generative AI and machine learning have revolutionized how businesses process and analyze data. **DeepSeek-R1**, an open-source AI model, stands out for its **advanced reasoning capabilities, resource optimization, and security**, as it runs locally. By combining **Ollama** with **Stackscale’s infrastructure**, organizations can deploy **DeepSeek-R1 on bare-metal dedicated servers or private cloud environments**, ensuring high performance and complete data sovereignty. ### **Why Use DeepSeek-R1 on Private Infrastructure?** #### **1. Security and Privacy** DeepSeek-R1 enables **local data processing**, eliminating reliance on external servers and ensuring sensitive information remains protected. #### **2. Optimized Costs** Running DeepSeek-R1 on **dedicated GPU servers from Stackscale** reduces the need for cloud-based AI services, eliminating token-based fees or recurring monthly costs. #### **3. Enhanced Performance with NVIDIA GPUs** Stackscale’s infrastructure offers **NVIDIA Tesla T4, L4, and L40S GPUs**, designed to accelerate **AI workloads, machine learning, and high-performance computing (HPC)**. #### **4. Flexibility and Scalability** Private cloud and **bare-metal servers** allow businesses to **scale resources** based on project demand, ensuring **stability and full control over infrastructure**. ### **Installing DeepSeek-R1 with Ollama** To deploy **DeepSeek-R1 on dedicated servers or private cloud**, **Ollama** is the recommended tool for managing **local AI models**. #### **Installation Steps:** 1️⃣ **Install Ollama** ``` curl -fsSL https://ollama.com/install.sh | sh ``` 2️⃣ **Download DeepSeek-R1** ``` ollama pull deepseek-r1:8b ``` *(The 8B version provides a balance between performance and resource usage. Other versions are available depending on the GPU.)* 3️⃣ **Run DeepSeek-R1** ``` ollama run deepseek-r1:8b ``` Once started, DeepSeek-R1 will be ready to process queries within the private environment, with **no need for an internet connection**. #### **Replace 8B with the desired model version:** - **1.5B parameters:** ollama run deepseek-r1:1.5b - **7B parameters:** ollama run deepseek-r1 - **70B parameters** *(Requires 24GB+ VRAM)*: ollama run deepseek-r1:70b - **Full-scale 671B model:** ollama run deepseek-r1:671b ### **Optimizing GPU Acceleration** - Ensure **NVIDIA CUDA drivers** are installed. - Use ollama list to check installed models. - Start the service: ollama serve ### **Enhancing Performance with Open WebUI** For an improved user experience, **Open WebUI** provides a **browser-based interface** to interact with AI models running on Ollama. Key features include:**✅ Model switching** via @ commands.**✅ Conversation tagging and management.****✅ Easy model download and removal.** ## **Optimizing Performance with NVIDIA GPUs on Stackscale** For maximum **DeepSeek-R1 performance**, using optimized **GPUs** is recommended. **Stackscale** offers: **GPU****Memory****Tensor Cores****Shading Units****TFLOPS (FP32)****Tesla T4**16 GB GDDR63202,5608.1**L4**24 GB GDDR62407,02430.3**L40S**48 GB GDDR658618,17691.6 These GPUs **accelerate AI processing**, **reduce execution times**, and **optimize computing resources**. ## **Benefits of Using Stackscale for AI and Machine Learning** ✅ **100% European Infrastructure:** Servers in **Madrid and Amsterdam**, ensuring full **data sovereignty**.**✅ High Availability:** **99.90% SLA**, with **redundant power supply and ultra-fast networks**.**✅ Complete Isolation:** No resource oversubscription, ensuring **dedicated high-performance computing**.**✅ 24/7 Support:** Specialized technical assistance **in English and Spanish**. ### **Conclusion** Deploying **DeepSeek-R1 with Ollama on Stackscale’s private infrastructure** enables businesses to access an **optimized, secure AI environment with full data control**. With **high-end GPUs** and an **infrastructure designed for demanding workloads**, **Stackscale provides the ideal solution for AI and machine learning projects**. If you need **more information** about our **dedicated GPU solutions and private cloud**, contact us, and our team will **help you configure the ideal setup for your project**. --- ## DeepSeek y Ollama: IA avanzada en servidores bare-metal y cloud privado con Stackscale URL: https://www.stackscale.com/blog/deepseek-ollama-advanced-ai/ ### **Instalación de DeepSeek en servidores dedicados y cloud privado** La inteligencia artificial generativa y el aprendizaje automático han revolucionado la manera en que las empresas procesan y analizan datos. DeepSeek-R1, un modelo de IA open-source, se destaca por su capacidad de razonamiento avanzado, optimización de recursos y seguridad al ejecutarse de forma local. Con la combinación de **Ollama** y la infraestructura de **Stackscale**, las organizaciones pueden desplegar DeepSeek-R1 en **servidores dedicados bare-metal o entornos de cloud privado**, asegurando un alto rendimiento y soberanía de los datos. ### **¿Por qué usar DeepSeek-R1 en infraestructura privada?** #### **1. Seguridad y privacidad** DeepSeek-R1 permite procesar datos de forma local, evitando la dependencia de servidores externos y protegiendo la información sensible. #### **2. Costes optimizados** Ejecutar DeepSeek-R1 en servidores con GPUs dedicadas de Stackscale reduce la necesidad de pagar por servicios de IA basados en la nube, eliminando costes por token o cuotas mensuales. #### **3. Rendimiento mejorado con GPUs NVIDIA** La infraestructura de Stackscale ofrece **GPUs NVIDIA Tesla T4, L4 y L40S**, diseñadas para acelerar cargas de trabajo de IA, machine learning y computación de alto rendimiento (HPC). #### **4. Flexibilidad y escalabilidad** El cloud privado y los servidores bare-metal permiten adaptar los recursos según la demanda del proyecto, garantizando estabilidad y control sobre la infraestructura. ### **Instalación de DeepSeek-R1 con Ollama** Para desplegar DeepSeek-R1 en servidores dedicados o cloud privado, es recomendable utilizar **Ollama**, una herramienta que facilita la gestión de modelos de IA locales. #### **Pasos de instalación:** - **Instalar Ollama****curl -fsSL https://ollama.com/install.sh | sh - Descargar DeepSeek-R1****ollama pull deepseek-r1:8b*(La versión 8b es una de las más equilibradas entre rendimiento y recursos. Se pueden elegir otras variantes según la GPU disponible).* - Ejecutar DeepSeek-R1****ollama run deepseek-r1:8b Una vez iniciado, DeepSeek-R1 estará listo para procesar consultas dentro del entorno privado y sin necesidad de conexión a Internet. Sustituye 8b** por la versión del modelo deseada: - **1.5B parámetros**: ollama run deepseek-r1:1.5b - **7B parámetros**: ollama run deepseek-r1 - **70B parámetros** (Requiere más de 24 GB de VRAM): ollama run deepseek-r1:70b - **Modelo completo de 671B**: ollama run deepseek-r1:671b #### Optimización para aceleración con GPU - Asegúrate de que los controladores **NVIDIA CUDA** estén instalados. - Usa ollama list para verificar los modelos instalados. - Inicia el servicio con: ollama serve #### Mejora del rendimiento con Open WebUI Para una mayor facilidad de uso, **Open WebUI** proporciona una interfaz basada en navegador para interactuar con los modelos de IA en Ollama. Sus funciones incluyen: - Cambio de modelos mediante comandos **@**. - Etiquetado y gestión de conversaciones. - Descarga y eliminación sencilla de modelos. ### **Optimización de rendimiento con GPUs NVIDIA en Stackscale** Para maximizar el rendimiento de DeepSeek-R1, es recomendable utilizar **GPUs optimizadas**. Stackscale ofrece: **GPU****Memoria****Cores Tensor****Shading Units****TFLOPS (FP32)****Tesla T4**16 GB GDDR632025608,1**L4**24 GB GDDR6240702430,3**L40S**48 GB GDDR658618.17691,6 Estas GPUs permiten acelerar el procesamiento de IA, reduciendo tiempos de ejecución y optimizando el uso de recursos computacionales. ### **Beneficios de utilizar Stackscale para IA y Machine Learning** ✅ **Infraestructura 100 % europea**: Servidores en **Madrid y Ámsterdam** con garantía de soberanía de datos.**✅ Alta disponibilidad**: SLA del **99,90 %**, con redundancia energética y redes ultrarrápidas.**✅ Aislamiento total**: Sin sobresuscripción de recursos ni vecinos ruidosos.**✅ Soporte 24/7**: Asistencia técnica especializada en español e inglés. ### **Conclusión** El despliegue de **DeepSeek-R1 con Ollama en infraestructura privada de Stackscale** permite a las empresas acceder a un entorno de IA optimizado, seguro y con control total sobre los datos. Con GPUs de alta gama y una infraestructura preparada para cargas de trabajo exigentes, Stackscale proporciona la mejor solución para proyectos de IA y machine learning. Si deseas más información sobre nuestras soluciones de **GPUs dedicadas y cloud privado**, **contáctanos** y nuestro equipo te asesorará en la configuración ideal para tu proyecto. --- ## Data Center: Physical or Virtual? Which is the Best Option? URL: https://www.stackscale.com/blog/data-center-physical-or-virtual-which-is-the-best-option/ Choosing between a **physical data center** and a **virtual data center** is a critical decision for many businesses evaluating their IT strategy. This dilemma arises for companies just starting to manage data or those looking to rethink their current infrastructure approach. Despite the increasing digitalization of business, few companies fully understand the advantages and disadvantages of these options or how they impact corporate strategy and operational costs. While organizations often manage their core expenses effectively, they may overlook costs related to IT infrastructure, which can lead to inefficiencies. In this context, deciding between a **physical data center** and a **virtual data center** becomes essential to optimize resources and ensure success in a competitive market. ### Advantages of a Physical Data Center #### Data Remains Within the Company Data is the most valuable asset for any organization, and many companies prefer to maintain full control over it. The idea of entrusting critical business information to a third party or storing it “in the cloud” is still a concern for some executives. Having an **on-premises physical data center** provides them with a sense of security and control. #### Tailored to Business Needs Certain industries or business models require infrastructure to remain in-house due to the nature of their operations. In such cases, a **physical data center** may be the only viable option. ### Disadvantages of a Physical Data Center #### Hidden Costs **Hidden costs** are one of the biggest challenges when managing a physical data center. These include maintaining a dedicated, 24/7 team—even during downtime—and high maintenance costs. Additionally, all technical responsibilities rest solely on the company. #### Technological Obsolescence Hardware in physical data centers is not upgraded constantly, leading to outdated infrastructure over time. This can result in operational limitations and increased risks of failure. #### Underutilized Space The space allocated for a **physical data center** may not align with the company’s actual needs over time. This can lead to unnecessary fixed costs without any return on investment. ### Advantages of a Virtual Data Center #### Scalability A **virtual data center** excels in flexibility and scalability. Businesses can adjust resources as needed, avoiding over-provisioned or underutilized infrastructure. #### Guaranteed Maintenance With a virtual data center, the provider handles maintenance, monitoring, and troubleshooting. This includes 24/7 expert technical support, eliminating the need for an in-house team for these tasks. #### Investment Optimization In a **virtual data center**, clients pay only for the resources they actually use. Additionally, virtual infrastructure is tailored to the specific needs of each business, offering customized solutions with high availability and performance. ### Disadvantages of a Virtual Data Center #### Perceived Loss of Control Some managers remain hesitant about storing data outside the physical perimeter of their company. This perceived lack of control is one of the biggest barriers to adopting cloud-based solutions. #### Limited Market Knowledge Companies without a strong focus on technology may struggle to manage virtual data center service contracts effectively, especially when setting service-level agreements (SLAs) and metrics. ### Final Takeaway: Physical or Virtual? There’s no one-size-fits-all answer to this question. The right choice depends on your **business’s unique needs**, the level of security required, and the available resources. The key is to ensure a **balanced relationship between quality, cost, and needs**, enabling companies to thrive in an increasingly competitive landscape. In this context, **Stackscale** offers tailored solutions for businesses aiming to maximize their data performance. With options like bare-metal and **private cloud**, high-availability infrastructure, and optimized network storage, Stackscale provides platforms designed to meet the specific needs of each client, whether through **physical or virtual data centers**. The focus is on supporting companies in their technological evolution while ensuring **performance, security, and scalability**. ### Ready to Take the Next Step with Your Data Infrastructure? Publication based on the publication Ar Telecom, a Grupo Aire company. --- ## Centro de Datos: ¿Físico o virtual? ¿Cuál es la mejor opción? URL: https://www.stackscale.com/blog/data-center-physical-or-virtual-which-is-the-best-option/ La decisión entre un centro de datos o **data center físico o virtual** es una cuestión clave para muchas empresas que están evaluando su estrategia tecnológica. Este dilema surge tanto para quienes se adentran por primera vez en la gestión de datos como para aquellas organizaciones que desean replantear su enfoque actual. Pese a la creciente digitalización, pocas empresas comprenden realmente las ventajas y desventajas de cada una de estas opciones, así como su impacto en la estrategia empresarial y los costes operativos. Por lo general, las compañías gestionan bien sus costes “core”, pero a menudo descuidan otros gastos relacionados con la infraestructura tecnológica, lo que puede convertirse en una fuente de ineficiencia. En este contexto, decidir entre un **centro de datos físico** o un **centro de datos virtual** se convierte en un factor crítico para optimizar los recursos y garantizar el éxito en un mercado competitivo. ### Ventajas de un centro de datos físico #### Los datos permanecen dentro de la empresa Los datos son el activo más valioso de cualquier organización, y muchas empresas prefieren mantener el control total sobre ellos. El temor a confiar información crítica del negocio a terceros o a almacenarla “en la nube” sigue siendo una preocupación para ciertos gestores. Tener un **centro de datos físico interno** les proporciona una sensación de seguridad y control. #### Adaptación a las características del negocio Algunos sectores o modelos de negocio requieren mantener la infraestructura dentro de la empresa debido a la naturaleza de sus operaciones. En estos casos, contar con un **centro de datos físico** puede ser la única opción viable. ### Desventajas de un centro de datos físico #### Costes ocultos Los **costes ocultos** son una de las mayores preocupaciones en la gestión de un centro de datos físico. Estos incluyen el gasto en personal especializado disponible las 24 horas, incluso cuando no hay incidencias, y los elevados costes de mantenimiento. Además, toda la responsabilidad técnica recae en la empresa. #### Obsolescencia tecnológica Los equipos de un centro de datos físico no se renuevan constantemente, lo que puede llevar a utilizar infraestructuras desactualizadas y menos eficientes. Esto puede traducirse en limitaciones operativas y mayores riesgos de fallo. #### Espacio infrautilizado El espacio dedicado a un **centro de datos físico** puede no ajustarse a las necesidades reales de la empresa con el tiempo. Esto genera costes fijos innecesarios, sin retorno de inversión. ### Ventajas de un centro de datos virtual #### Escalabilidad Un **centro de datos virtual** destaca por su flexibilidad y escalabilidad. Las empresas pueden adaptar los recursos en función de sus necesidades en cada momento, evitando infraestructuras sobredimensionadas o subutilizadas. #### Mantenimiento garantizado En un entorno virtual, el proveedor del servicio se encarga del mantenimiento, monitorización y resolución de problemas. Esto incluye soporte técnico especializado disponible 24/7, eliminando la necesidad de gestionar personal interno para estas tareas. #### Optimización de la inversión En un **centro de datos virtual**, los clientes solo pagan por los recursos que realmente utilizan. Además, la infraestructura virtual se diseña específicamente para las necesidades de cada empresa, ofreciendo soluciones personalizadas con alta disponibilidad y rendimiento. ### Desventajas de un centro de datos virtual #### Percepción de pérdida de control Algunos gestores todavía sienten reticencia a almacenar datos fuera del perímetro físico de su empresa. Esta falta de control percibida es uno de los mayores frenos para la adopción de soluciones en la nube. #### Desconocimiento del mercado Empresas sin experiencia tecnológica pueden enfrentarse a dificultades para gestionar contratos de servicios de centro de datos virtual, especialmente al establecer métricas y acuerdos de nivel de servicio (SLA) adecuados. ### Balance final: ¿Físico o virtual? No existe una respuesta universal para esta pregunta. La decisión depende de las **características del negocio**, el nivel de seguridad requerido y los recursos disponibles. Lo importante es garantizar una **relación equilibrada entre calidad, precio y necesidades**, permitiendo a las organizaciones competir eficazmente en un mercado cada vez más exigente. En este contexto, Stackscale ofrece soluciones personalizadas para empresas que buscan maximizar el rendimiento de sus datos. Con opciones de **cloud privado** y bare-metal, infraestructura de alta disponibilidad y almacenamiento en red optimizado, Stackscale proporciona plataformas diseñadas para adaptarse a las necesidades específicas de cada cliente, ya sea mediante **centros de datos físicos o virtuales**. La clave está en acompañar a las empresas en su evolución tecnológica, garantizando **rendimiento, seguridad y escalabilidad**. ### ¿Y tú? ¿Estás listo para dar el siguiente paso con tu infraestructura de datos? Publicación basada en la publicación Ar Telecom, empresa de Grupo Aire. --- ## Data protection and sovereignty lead digital transformation in the EU URL: https://www.stackscale.com/blog/data-protection-digital-sovereignty-europe/ 28/01/2025 – Madrid **On January 28th, European Data Protection Day is celebrated to raise awareness and promote best practices around privacy and data protection. In a context of exponential data growth, driven by technologies such as IoT, artificial intelligence, and cloud computing, data protection has become a crucial element. According to IDC, the global digital data volume is expected to reach 175 zettabytes by 2025, highlighting the need to strengthen privacy and cybersecurity strategies at all levels. European providers like Stackscale also emphasize the importance of data sovereignty and the development of European technological services.** On January 28th, European Data Protection Day is celebrated to commemorate the first legally binding international data protection instrument, adopted in the Council of Europe’s **Convention 108** on the same day in 1981. Both data privacy and protection are a growing source of concern among institutions, companies and citizens. This points out the value of supporting the **development of European technological solutions and services** that respect and promote the European Union’s fundamental values. As well as promoting the development of projects strengthening the EU’s digital sovereignty. Like the **Gaia-X** initiative, focused on European digital sovereignty. **Gaia-X**, established in 2019, aims to **create a European cloud infrastructure that ensures digital sovereignty through ethical standards in data management**. Additionally, other initiatives like Horizon Europe fund innovative projects in cybersecurity and data protection technologies to strengthen the continent’s digital resilience. On this subject, the European Union establishes diverse **goals to reach by 2030** within its Digital Decade program, such as achieving that at least 80% of Europe’s population has basic digital skills, that 100% of essential public services are available online for citizens and businesses, or that cloud adoption among EU companies reaches 75% — which entails an increase above 30% compared with the average adoption rate of 2021. Furthermore, with a **38% increase in the number of weekly cyberattacks** on corporate networks compared to 2021, according to Check Point Research data, data protection and Disaster Recovery planning continue to go up in the list of business priorities. Not only from the point of view of protecting personal, confidential and critical data to prevent access by unauthorized people or purposes, but also from the point of view of durability. Additionally, sanctions under the GDPR have driven companies to strengthen their privacy policies. Since 2018, fines exceeding €1.6 billion have been imposed, including notable cases involving major tech companies penalized for opaque data handling practices. This underscores the importance of compliance, not only to avoid penalties but also to safeguard corporate reputation. According to experts, security and privacy are fundamental at all levels. David Carrero of Stackscale explains that: ** «It is essential to address security at both technical and organizational levels,** covering infrastructure, storage, and networks, as well as geo-replication, data encryption, and identity management. This is particularly important during digital transformation and cloud migration processes, where the decentralization of data and workloads requires new approaches and security models, such as **Zero Trust**, with a focus on enhancing the protection of data and applications regardless of location. Leveraging hybrid or private cloud infrastructures allows companies to ensure data sovereignty while benefiting from scalability. Technologies like geo-replication and end-to-end encryption are crucial for complying with regulations such as the GDPR and ensuring data integrity in decentralized environments.» In regards to the **digitalization of European companies**, according to Eurostat data, **56% of them had reached a basic digital intensity level in 2021** — with a significant difference between SMEs (55%) and big companies (88%). This percentage is still far from the Digital Decade program’s objective, according to which more than 90% of SMEs should have reached a basic level of digital intensity by 2030. Moreover, only 18% of them have reached a high level. **SMEs**, which **represent 99% of the European business landscape**, face additional challenges in achieving digitalization. Limited resources and technical expertise hinder their ability to implement advanced cybersecurity technologies, leaving them more vulnerable. According to ENISA, **43% of cyberattacks target small businesses**, emphasizing the need to adopt affordable and effective security measures. Aiming to offer high-end technological solutions and help companies throughout their digital transformation, Grupo Aire, to which Stackscale belongs, comprehends a wide range of cloud, connectivity and business continuity products which place **data protection and sovereignty at the core of the digital strategy**. For further information, please contact us via our contact form. At Stackscale, we work to help businesses achieve their digital transformation goals and protect their data against current and future challenges. If you’re looking for personalized advice on how to enhance the sovereignty and security of your data, don’t hesitate to contact us through our form. Together, we can design solutions tailored to your needs. --- ## La soberanía y protección de datos lideran la transformación digital en la UE URL: https://www.stackscale.com/blog/data-protection-digital-sovereignty-europe/ 28/01/2025 – Madrid **El 28 de enero se celebra el día europeo de la protección de datos para dar visibilidad y promover buenas prácticas en torno a la privacidad y la protección de los datos. En un contexto de crecimiento exponencial de los datos, impulsado por tecnologías como el IoT, la inteligencia artificial y el cloud computing, la protección de datos se ha convertido en un elemento crucial. Según IDC, el universo de datos digitales alcanzará los 175 zettabytes en 2025, lo que subraya la necesidad de reforzar las estrategias de privacidad y ciberseguridad a todos los niveles. Proveedores europeos como Stackscale también hacen hincapié en la importancia de la soberanía de datos y el desarrollo de servicios tecnológicos europeas.** El 28 de enero se celebra el día europeo de la protección de datos para conmemorar el primer instrumento internacional de protección de datos vinculante legalmente, adoptado en el **Convenio 108** del Consejo de Europa ese mismo día en 1981. Tanto la privacidad como la protección de los datos son una preocupación en auge entre las instituciones, empresas y ciudadanos. Esto pone en valor la importancia de apostar por el **desarrollo de soluciones y servicios tecnológicos europeos** que respeten y promuevan los valores fundamentales de la Unión Europea. Así como promover el desarrollo de proyectos que fortalezcan la soberanía digital de la UE. Aquí destacan iniciativas centradas en la soberanía digital europea como **Gaia-X**. **Gaia-X**, creada en 2019, **busca establecer una infraestructura cloud europea que garantice la soberanía digital** mediante estándares éticos en la gestión de datos. Además, otras iniciativas como Horizon Europe financian proyectos innovadores en ciberseguridad y tecnologías de protección de datos para fortalecer la resiliencia digital del continente. A este respecto, la Unión Europea plantea diversos **objetivos a alcanzar para 2030** dentro de su programa de la Década Digital, como conseguir que al menos el 80 % de la población tenga competencias digitales básicas, que el 100 % de los servicios públicos esenciales estén disponibles en línea para ciudadanos y empresas, o que la adopción cloud en empresas de la UE ascienda al 75 % —lo cual supone un aumento de más del 30 % respecto al índice de adopción medio de 2021—. Asimismo, con un **aumento del 38 % en el número de ciberataques** semanales a redes corporativas respecto a 2021, según datos de Check Point Research, la protección de datos y la planificación de Disaster Recovery siguen subiendo posiciones entre las prioridades empresariales. No solo desde el punto de vista de la protección de datos críticos, confidenciales o personales para evitar que estos sean accesibles para personas o fines no autorizados, sino también desde el punto de vista de la durabilidad. Además, las sanciones derivadas del RGPD han impulsado a las empresas a reforzar sus políticas de privacidad. Desde 2018, se han impuesto multas que superan los 1.600 millones de euros, destacando casos como las sanciones a gigantes tecnológicos por prácticas opacas en el tratamiento de datos. Esto pone de manifiesto la importancia de cumplir con las normativas no solo para evitar sanciones, sino también para proteger la reputación empresarial. Según los expertos, la seguridad y la privacidad son primordial a todos los niveles. David Carrero de Stackscale explica que: ** «es imprescindible abordar la seguridad tanto a nivel técnico como organizativo**, desde la infraestructura, el almacenamiento y la red hasta la georeplicación, la encriptación de datos o la gestión de identidades. Esto es especialmente importante durante los procesos de transformación digital y migración cloud, en los que la descentralización de los datos y cargas de trabajo requiere aplicar nuevos enfoques y modelos de seguridad, como el **Zero Trust**, con el foco en aumentar la protección de datos y aplicaciones independientemente de la ubicación. **El uso de infraestructuras híbridas o cloud privadas permite a las empresas garantizar la soberanía de sus datos mientras se benefician de la escalabilidad**. Tecnologías como la georeplicación y el cifrado de extremo a extremo son esenciales para cumplir con normativas como el RGPD y garantizar la integridad de los datos en entornos descentralizados.» En lo que concierne a la **digitalización de las empresas europeas**, según datos de Eurostat, **en 2021 el 56 % había alcanzado un nivel básico de intensidad digital** —con una diferencia significativa entre PYMES (55 %) y grandes empresas (88 %)—. Esta cifra aún está lejos del objetivo del programa de la Década Digital, según el cual más del 90% de las PYMES deberían haber alcanzado un nivel básico de intensidad digital para 2030. Asimismo, solo el 18 % ha alcanzado un alto nivel. Las **PYMES**, que **representan el 99 % del tejido empresarial europeo**, enfrentan desafíos adicionales para alcanzar la digitalización. La falta de recursos y experiencia técnica limita su capacidad para implementar tecnologías avanzadas de ciberseguridad, dejándolas más expuestas. Según ENISA, **el 43 % de los ciberataques tienen como objetivo pequeñas empresas**, lo que refuerza la necesidad de adoptar medidas de seguridad asequibles y efectivas. Con el objetivo de ofrecer soluciones tecnológicas de alta gama y ayudar a las empresas en su transformación digital, el Grupo Aire del que forma parte Stackscale engloba una amplia gama de productos cloud, de conectividad y continuidad del negocio con los que poner **la soberanía y la protección de datos en el centro de la estrategia digital**. Para más información puedes contactarnos a través de nuestro formulario de contacto. En Stackscale, trabajamos para **ayudar a las empresas a alcanzar sus objetivos de transformación digital y proteger sus datos frente a desafíos actuales y futuros**. Si deseas asesoramiento personalizado sobre cómo mejorar la soberanía y seguridad de tus datos, no dudes en contactarnos a través de nuestro formulario. Juntos podemos diseñar soluciones adaptadas a tus necesidades. --- ## The Linux Kernel surpasses 40 Million lines of code: A historic nilestone in Open-Source software URL: https://www.stackscale.com/blog/linux-kernel-surpasses-40-million-lines-code/ The Linux kernel, the backbone of countless open-source operating systems, has achieved an impressive milestone: surpassing **40 million lines of code**. This achievement, reached with version 6.14 rc1, reflects Linux’s steady growth and the strength of its collaborative development model, which unites thousands of developers worldwide. Since its creation in 1991 by Linus Torvalds as an academic project, the Linux kernel has evolved to power diverse technologies, from servers and supercomputers to smartphones and IoT devices. This progress reinforces its position as one of the most critical pillars in today’s technological landscape. ### Steady Growth: From the Classroom to the Technological Vanguard In 2015, the Linux kernel reached **20 million lines of code**, a significant number at the time. Ten years later, this figure has doubled, with an estimated growth rate of **400,000 additional lines of code every two months**. By the end of 2024, the kernel contained **39,819,522 lines**, reaching **40,063,856 lines** with the release of the first release candidate of Linux 6.14. This growth is no coincidence—it is the result of decades of collective work and the kernel’s ability to adapt to the needs of an increasingly diverse technological ecosystem. ### What Drives the Growth of the Linux Kernel? The continuous expansion of the Linux kernel is due to several key factors: #### 1. **Expanding Hardware Support** Linux is renowned for its **versatility** and compatibility with a wide range of devices and architectures, from x86 and ARM to RISC-V. - **Hardware architectures:** Support for these architectures alone accounts for more than **4.5 million lines of code**. - **Drivers:** The most notable example is the driver for AMD Radeon graphics cards, which includes **5 million lines of code** between the driver itself and its documentation. #### 2. **Efficient Modularity** Despite the kernel’s massive size, not all lines of code are executed on every system. Thanks to its modular design, drivers and components are only loaded when the corresponding hardware is present, optimizing resource usage. #### 3. **Documentation and Code Quality** The developer community has worked diligently to document the code and include useful comments, making it easier for new contributors to participate and ensuring the kernel’s high quality. ### The Debate Over Kernel Size: Growth vs. Bloat The kernel’s growth has sparked debates in the tech community, particularly about the concept of **“bloat”** (unnecessarily large code). - **Arguments for growth:** Adding more features and support makes Linux adaptable to a wide range of devices and environments, from enterprise servers to embedded systems. - **Criticism of bloat:** Some developers argue that the kernel could benefit from further optimization by removing redundant features. However, proposals like separating drivers into external modules have proven ineffective or even counterproductive. ### Highlights of Linux 6.14 rc1: Beyond the Numbers In addition to surpassing the 40-million-line milestone, Linux 6.14 rc1 introduces significant improvements: - **“Copilot” Key Support:** Introduced by Microsoft, this new key is now configurable in desktop environments. - **Gaming Enhancements:** The XPad driver expands compatibility with newer gaming devices. - **Audio Improvements:** Updated support for the latest audio hardware enhances multimedia experiences. - **Faster Suspend/Resume:** Optimized times for suspending and resuming systems benefit laptop users. - **Touchscreen Compatibility:** Improved support for Intel-based touchscreen devices enhances the user experience on modern hardware. ### A Collaborative Model Shaping the Future Surpassing 40 million lines of code is not just a symbolic milestone—it highlights Linux’s impact and relevance in the tech industry. From the most powerful supercomputers to tiny IoT devices, the Linux kernel continues to be a cornerstone of modern computing. This growth also underscores the strength of the **collaborative development model**, where thousands of developers, companies, and users actively contribute to its evolution. This ensures that Linux remains competitive against other operating systems, proving that open-source software can lead technological innovation on a global scale. ### Evolution of Lines of Code by Kernel Version **Year****Kernel Version****Lines of Code**19910.01~10,00019941.0.0~176,25019962.0.0~500,00020012.4.0~2,400,00020032.6.0~5,200,00020113.0.0~15,000,00020154.0.0~19,500,00020164.8.0~21,300,00020205.0.0~27,800,00020225.18.0~30,400,00020246.13.0~39,800,00020256.14 rc1~40,063,856 **Notes:** - **Estimates:** Numbers vary depending on whether comments, documentation, and blank lines are included. - **Consistent Growth:** The kernel has grown steadily due to the addition of support for new devices, architectures, and features. - **Modularity:** Despite its size, thanks to its modular design, not all lines of code are used on every system. ### Linux: A Promising Future The Linux kernel has not only reached a historic milestone but has also solidified its role as a fundamental tool in technology. As the world continues to evolve, Linux remains a model of innovation, collaboration, and resilience in open-source software. The achievement of 40 million lines of code is undoubtedly a significant step in a journey that will continue to shape the technological landscape for decades to come. **Visit the official Linux Kernel website for more details.** --- ## El kernel de Linux supera las 40 millones de líneas de código: un hito histórico en el software de código abierto URL: https://www.stackscale.com/blog/linux-kernel-surpasses-40-million-lines-code/ El kernel de Linux, núcleo de innumerables sistemas operativos basados en código abierto, ha alcanzado un logro impresionante: superar las **40 millones de líneas de código**. Este hito, logrado con la versión 6.14 rc1, es un reflejo del crecimiento constante de Linux y de la fortaleza de su modelo de desarrollo colaborativo, que reúne a miles de desarrolladores en todo el mundo. Desde su creación en 1991 por Linus Torvalds como un proyecto académico, el kernel de Linux ha evolucionado para convertirse en el motor de tecnologías tan diversas como servidores, supercomputadoras, smartphones y dispositivos IoT. Este avance refuerza su posición como uno de los pilares más relevantes en el panorama tecnológico actual. ### Crecimiento constante: del aula a la vanguardia tecnológica En 2015, el kernel de Linux alcanzó las **20 millones de líneas de código**, un número significativo en aquel momento. Diez años después, esta cifra se ha duplicado, con un ritmo de crecimiento estimado en unas **400.000 líneas de código adicionales cada dos meses**. Al cierre de 2024, el conteo exacto era de **39.819.522 líneas**, alcanzando las **40.063.856 líneas** con el lanzamiento de la primera versión candidata de Linux 6.14. Evolución de líneas de código de Linux Este crecimiento no es casual, sino resultado de décadas de trabajo colectivo y de la capacidad del kernel de adaptarse a las necesidades de un ecosistema tecnológico cada vez más diverso. ### ¿Qué impulsa el crecimiento del kernel de Linux? El incremento continuo del kernel tiene varias razones principales: #### 1. **Ampliación del soporte para hardware** Linux es conocido por su **versatilidad** y compatibilidad con una amplia gama de dispositivos y arquitecturas, desde x86 y ARM hasta RISC-V. - **Arquitecturas de hardware:** Solo el soporte para estas arquitecturas representa más de **4,5 millones de líneas de código**. - **Controladores:** El caso más notable es el controlador para tarjetas gráficas AMD Radeon, que incluye **5 millones de líneas** entre el código y su documentación. #### 2. **Modularidad eficiente** Aunque el kernel es masivo, no todas sus líneas se ejecutan en cada sistema. Gracias a su diseño modular, los controladores y componentes solo se cargan cuando el hardware correspondiente está presente, optimizando así los recursos. #### 3. **Documentación y calidad de código** La comunidad de desarrolladores ha trabajado arduamente en documentar el código y añadir comentarios útiles, facilitando la participación de nuevos colaboradores y asegurando la calidad del kernel. ### Debate sobre el tamaño del kernel: ¿crecimiento o sobrepeso? El crecimiento del kernel ha generado debates en la comunidad tecnológica, especialmente en torno al concepto de “bloat” (código innecesariamente grande). - **Argumentos a favor:** La inclusión de más funcionalidades y soporte hace que Linux sea adaptable a dispositivos y entornos variados, desde servidores empresariales hasta pequeños sistemas embebidos. - **Críticas al bloat:** Algunos desarrolladores consideran que el kernel podría beneficiarse de mayor optimización eliminando características redundantes. Sin embargo, propuestas como separar los controladores en módulos externos han demostrado ser ineficaces o incluso contraproducentes. ### Novedades de Linux 6.14 rc1: más allá de las cifras Además de superar la barrera de las 40 millones de líneas, la versión Linux 6.14 rc1 incorpora mejoras significativas: - **Tecla “Copilot”:** Introducida por Microsoft, ahora es compatible con acciones configurables en entornos de escritorio. - **Soporte para gamers:** El controlador XPad amplía la compatibilidad con dispositivos de juego más recientes. - **Mejoras de audio:** Nuevas capacidades para hardware de audio, optimizando la experiencia multimedia. - **Suspensión y reanudación más rápidas:** Se han reducido los tiempos de suspensión y reanudación, mejorando la experiencia de los usuarios de portátiles. - **Compatibilidad con pantallas táctiles:** Mejoras para dispositivos con tecnología táctil, especialmente en hardware basado en Intel. ### Un modelo colaborativo que define el futuro El logro de superar las 40 millones de líneas no solo es un dato simbólico, sino un reflejo del impacto y relevancia de Linux en la industria tecnológica. Desde las supercomputadoras más potentes hasta pequeños dispositivos IoT, el kernel de Linux continúa siendo una pieza clave en la computación moderna. Este crecimiento también pone de manifiesto la fuerza del **modelo de desarrollo colaborativo**, donde miles de desarrolladores, empresas y usuarios contribuyen activamente a su mejora. Esto asegura que Linux permanezca competitivo frente a otras opciones de sistemas operativos, demostrando que el software de código abierto es capaz de liderar la transformación tecnológica global. A continuación os mostramos una estimación de líneas de código por versiones del Kernel y como hay ido evolucionando. **Año****Versión del Kernel****Líneas de Código**19910.01~10.00019941.0.0~176.25019962.0.0~500.00020012.4.0~2.400.00020032.6.0~5.200.00020113.0.0~15.000.00020154.0.0~19.500.00020164.8.0~21.300.00020205.0.0~27.800.00020225.18.0~30.400.00020246.13.0~39.800.00020256.14 rc1~40.063.856 #### Notas: - **Estimaciones:** Los números varían dependiendo de cómo se cuenten las líneas (inclusión de comentarios, documentación y líneas en blanco). - **Crecimiento continuo:** El kernel ha crecido de forma consistente debido a la inclusión de soporte para nuevos dispositivos, arquitecturas y características. - **Modularidad:** A pesar del tamaño, gracias a su diseño modular, no todas las líneas de código se utilizan en cada sistema. ### Linux: un futuro prometedor El kernel de Linux no solo ha alcanzado un hito histórico, sino que ha consolidado su papel como herramienta fundamental en la tecnología. Mientras el mundo sigue evolucionando, Linux se mantiene como un modelo de innovación, colaboración y resiliencia en el ámbito del software de código abierto. El hito de los 40 millones de líneas de código es, sin duda, un paso más en un camino que continuará marcando el rumbo de la tecnología en las próximas décadas. Consulta la web oficial del Kernel de Linux. --- ## Take Your WordPress Blog to the Next Level: How to Handle 100,000 Daily Visitors Without Breaking a Sweat URL: https://www.stackscale.com/blog/take-your-wordpress-blog-to-the-next-level/ The growth of a WordPress blog can be an exciting journey, but it also comes with significant challenges in terms of infrastructure and performance. Reaching **100,000 daily visitors** doesn’t happen overnight, but whether your blog is experiencing steady growth or preparing for the launch of a high-traffic project, a robust setup is crucial to ensure stability and an excellent user experience. ## The Importance of High Availability When managing 100,000 daily visitors, **downtime is not an option**. Imagine thousands of users trying to access your site only to find an error page. The solution is implementing a **high availability (HA)** architecture, which ensures continuous operation even if a server fails. High availability involves distributing services across multiple servers so that, if one goes down, another seamlessly takes over. This is particularly critical for blogs handling not only static content but also dynamic features like comments or e-commerce transactions. A reliable **cloud computing provider** can simplify this process by offering **private cloud**, **bare-metal hardware**, or synchronous storage solutions, all of which ensure maximum uptime and stability. ## Load Balancing: Managing the Traffic Flow For a high-traffic blog, a **load balancer** is an absolute must. This system acts as your website’s traffic controller, intelligently distributing requests across multiple servers. Some of the best software options for load balancing include: - **HAProxy**, known for its high performance and ability to handle hundreds of thousands of requests per second. - **Nginx**, which, in addition to being an excellent web server, offers efficient load balancing capabilities. - **Apache with mod_proxy**, while less efficient than the previous options, is still viable for specific use cases. Load balancers not only distribute traffic but also monitor the health of backend servers, ensuring requests are only sent to those operating at full capacity. ## Web Server: The Backbone of Your WordPress Site When it comes to web servers, **Nginx** stands out as the top choice for handling high traffic due to its low resource consumption and ability to manage multiple simultaneous connections. It’s ideal for implementing features like **static content caching** and acting as a reverse proxy. However, a single web server won’t suffice for a blog of this scale. Depending on traffic levels and caching efficiency, a setup with **at least four web servers** is recommended. For dynamic content-heavy projects like e-commerce sites, the number of servers may need to increase significantly. ## Caching and CDNs: Speeding Things Up Caching is essential for optimizing your blog’s performance. Solutions like **Redis**, **Memcached**, or **Varnish** can store and serve static content directly from memory, reducing unnecessary requests to the server. Additionally, implementing a **Content Delivery Network (CDN)** is highly recommended. A CDN stores static assets like images and CSS/JS files on servers worldwide, significantly improving load times by serving content from the location closest to the user. Platforms like **Cloudflare** integrate seamlessly with WordPress and offer added benefits such as DDoS mitigation and basic web application firewalls. ## Centralized Storage for Dynamic Files WordPress generates dynamic files, such as media uploads and plugin updates, that need to be synchronized across servers in a multi-server environment. Using centralized storage solutions like **NFS**, **GlusterFS**, or **Ceph** ensures that all servers access the same file versions, preventing inconsistencies. ## Continuous Monitoring and Optimization Maintaining a high-performance blog requires **continuous monitoring**. Tools like **Zabbix**, **Prometheus**, or **New Relic** can track key metrics such as load times, resource usage, and database query performance. These insights allow you to identify bottlenecks and optimize your setup in real-time. ## The Key: Cloud Infrastructure Solutions For high-traffic projects, a well-designed **cloud infrastructure** is a game changer. Solutions like **private cloud**, network storage, and **high availability systems** are essential for handling critical workloads. Partnering with a trusted cloud provider can simplify infrastructure management, letting you focus solely on content creation and blog growth. In conclusion, hitting the milestone of 100,000 daily visitors is an exciting challenge that requires strategic planning and best practices in performance optimization. With the right tools and infrastructure, your WordPress blog can handle massive traffic volumes, whether you’re scaling gradually or gearing up for a major launch. Publication based on Teradisk, a Grupo Aire company. --- ## Lleva tu blog WordPress al siguiente nivel: Cómo manejar 100.000 visitas diarias sin perder el control URL: https://www.stackscale.com/blog/take-your-wordpress-blog-to-the-next-level/ El crecimiento de un blog en WordPress puede ser emocionante, pero también supone un reto importante en términos de infraestructura y rendimiento. Alcanzar las **100.000 visitas diarias** no es algo que ocurra de la noche a la mañana, pero tanto si tu blog está creciendo progresivamente como si estás preparando el lanzamiento de un proyecto de alto tráfico, necesitarás una arquitectura robusta para garantizar la estabilidad y la experiencia del usuario. ## La importancia de la alta disponibilidad Cuando hablamos de 100.000 visitas diarias, **los tiempos de inactividad no son una opción**. Imagina a miles de usuarios intentando acceder a tu sitio y encontrando un error. Una arquitectura de **alta disponibilidad (HA)** es la respuesta para evitar estos problemas. La alta disponibilidad implica distribuir los servicios en múltiples servidores. Así, si uno falla, otro entra en acción automáticamente, asegurando el funcionamiento ininterrumpido del blog. Esto es especialmente importante para blogs que no solo manejan contenido estático, sino también elementos dinámicos como comentarios o e-commerce. Una opción para lograrlo es contar con un **proveedor especializado en cloud computing** que gestione toda la infraestructura por ti. Servicios como el **cloud privado**, **hardware bare-metal** o soluciones de almacenamiento síncrono son ideales para garantizar la máxima estabilidad. ## Balanceo de carga: Controlando el flujo de tráfico Para un blog con tanto tráfico, un **balanceador de carga** es imprescindible. Este sistema actúa como el controlador de tráfico de tu sitio, distribuyendo inteligentemente las peticiones entre varios servidores. Entre las opciones de software más populares para balanceo destacan: - **HAProxy**, conocido por su alto rendimiento y capacidad para manejar cientos de miles de solicitudes por segundo. - **Nginx**, que además de ser un excelente servidor web, ofrece funcionalidades de balanceo de carga con un consumo eficiente de recursos. - **Apache con mod_proxy**, aunque menos eficiente que las opciones anteriores, sigue siendo una alternativa viable para ciertos casos. El balanceador no solo distribuye el tráfico, sino que también monitoriza la salud de los servidores backend para redirigir las solicitudes únicamente a los que están operativos. ## Servidor web: La base de tu WordPress En cuanto al servidor web, **Nginx** se presenta como la mejor opción para manejar altos volúmenes de tráfico gracias a su bajo consumo de recursos y su capacidad para gestionar múltiples conexiones simultáneamente. También es ideal para implementar funciones como **caché de contenido estático** o actuar como proxy inverso. No obstante, para blogs de gran envergadura, no basta con un solo servidor web. Dependiendo de la carga y del uso de caché, se recomienda contar con **al menos cuatro servidores**. Para proyectos con contenido dinámico, como tiendas online, este número puede incrementarse considerablemente. ## Caché y CDN: Agilizando las cargas La **caché** es una herramienta indispensable para optimizar el rendimiento de tu blog. Soluciones como **Redis**, **Memcached** o **Varnish** pueden almacenar y servir contenido estático directamente desde la memoria, evitando solicitudes innecesarias al servidor. Además, el uso de una **CDN (Red de Distribución de Contenido)** permite almacenar los recursos estáticos, como imágenes y archivos CSS/JS, en servidores distribuidos por todo el mundo. Esto no solo mejora los tiempos de carga al acercar el contenido al usuario, sino que también reduce la carga en tu infraestructura principal. Servicios como **Cloudflare** ofrecen integración con WordPress, mitigación de ataques DDoS y otras ventajas. ## Almacenamiento centralizado para ficheros dinámicos Para gestionar los ficheros dinámicos de WordPress (como imágenes o actualizaciones de plugins), es necesario implementar un sistema de almacenamiento centralizado, como **NFS**, **GlusterFS** o **Ceph**. Esto asegura que todos los servidores accedan a las mismas versiones de los archivos, evitando inconsistencias. ## Monitorización y optimización constante Finalmente, mantener un blog de alto rendimiento requiere **monitorización continua**. Herramientas como **Zabbix**, **Prometheus** o **New Relic** pueden rastrear métricas clave como tiempos de carga, uso de recursos y consultas a la base de datos. Esto te permitirá identificar cuellos de botella y optimizar tu infraestructura en tiempo real. ## La clave: soluciones de infraestructura cloud Para proyectos con tráfico elevado, una **infraestructura cloud bien diseñada** puede marcar la diferencia. Soluciones de **cloud privado**, almacenamiento en red y **sistemas de alta disponibilidad** son ideales para manejar cargas de trabajo críticas. Además, contar con un proveedor de confianza puede facilitar la gestión de toda esta infraestructura, permitiéndote centrarte únicamente en el contenido y el crecimiento de tu blog. En conclusión, alcanzar las 100.000 visitas diarias es un reto emocionante, pero requiere una planificación estratégica y la implementación de las mejores prácticas en infraestructura y rendimiento. Con las herramientas y soluciones adecuadas, tu blog WordPress estará preparado para cualquier desafío. Publicación basada en la publicación Teradisk, empresa de Grupo Aire. --- ## 19 popular web hosting control panels URL: https://www.stackscale.com/blog/popular-web-hosting-control-panels/ Web hosting control panels are **a must-have for system administrators and web hosting providers nowadays**. That is why we have created a list of the most popular web hosting control panels. **Control panels make management and automation tasks easier** for sysadmins. They allow, for instance, managing one or several servers from a single dashboard. So, as a smart tool to manage critical tasks such as patches, setups, installations, monitoring, etc., it must be properly chosen. Here is **a list of the most popular web hosting control panels on the market**. ## Plesk Plesk stands out as the most popular commercial web hosting control panel available today, offering robust solutions for both **Linux** and **Windows** platforms. Designed to meet the needs of developers, system administrators, and hosting providers, Plesk offers flexible **monthly** and **annual pricing plans**, making it ideal for managing dedicated servers and virtual private servers (VPS). #### Key Features of Plesk: - **Full Access via SSH:****Plesk provides complete SSH access, ensuring that developers and administrators can manage their servers with maximum flexibility and control. - Enhanced Security:****Security is a top priority, with advanced tools like integrated web application firewalls (WAF), fail2ban intrusion prevention, and automatic SSL/TLS certificates from Let’s Encrypt or DigiCert. - Advanced Monitoring Tools:****Plesk includes real-time monitoring of server performance, resource usage, and key metrics, helping to proactively address potential issues. - Extensive Extension Library:****Plesk boasts over 100 extensions**, offering integrations with leading third-party services like Cloudflare, Git, Docker, and SEO tools to enhance functionality and customization. - **Complete WordPress Toolkit:****A comprehensive suite for managing WordPress websites. This includes staging environments, automatic updates, cloning, and one-click security hardening, making it a go-to choice for WordPress professionals. - Developer-Friendly Environment:****Plesk supports modern technologies, such as Node.js**, **Ruby**, **Python**, **Git**, and **Docker**, enabling seamless development workflows. - **Multilingual Support:****Plesk’s intuitive interface is available in multiple languages, ensuring global usability for administrators and end-users. - Integrated Backup and Restore:****Automated backup options ensure data safety, allowing users to restore their websites or servers with just a few clicks. #### Additional Information: - Developer:** Plesk International GmbH. - **Latest Release:** Plesk Obsidian, featuring enhanced user experience, new security tools, and performance improvements. - **License:** Proprietary, ensuring top-tier support and continual updates. #### Why Choose Plesk? Plesk’s unparalleled versatility, combined with its rich feature set and comprehensive ecosystem, makes it the preferred choice for individuals and enterprises alike. Whether you’re managing a single website or an entire server, Plesk simplifies tasks, enhances security, and delivers unmatched scalability to meet modern hosting demands. ## Control Web Panel (CWP) Control Web Panel (CWP) is **a powerful, community-driven web hosting panel for dedicated servers and VPS**. It has different licensing options: - A free version. - A Pro version — with or without support. - A special Pro version for partners. CWP is developed for Linux operating systems and it includes features such as: - Modern and intuitive user interface. - Enhanced security. - Full automation of processes. - Server logs visualization. - Monitoring tools. **Developer**: Studio 2/4 host and Linanto LLC. **Control Web Panel license**: Free software under Control Web Panel License. ## ISPConfig ISPConfig is **a free, open source hosting control panel for Linux**. It supports numerous Daemons and Linux distributions, such as Ubuntu, Debian and CentOS. ISPConfig includes features such as: - Several access levels. - Web server management. - DNS server management. - Mail server management. - Numerous managed services. **Developer**: ISPConfig UG. **Latest ISPConfig release**: ISPConfig 3.2.7p1. **ISPConfig license**: BSD license. ## Virtualmin Virtualmin is **an open source website and domain hosting control panel, based on Webmin**. There are two versions of this control panel: - Virtualmin GPL, a free, open-source version. - Virtualmin Professional, a premium version available for a monthly or annual fee. Virtualmin is developed for Linux and BSD systems and includes features such as: - Advanced access control. - Easy server logs visualization. - Monitoring tools. - Numerous security features. - Comprehensive tools for managing databases. **Developer**: Virtualmin, Inc. **Latest Virtualmin release**: Virtualmin 6.13. **Virtualmin license**: GNU General Public License. ## ispmanager ispmanager is **a commercial website and web server control panel based on Linux**. It offers a free 14-day trial version and several licensing options, available for a monthly or annual fee: - Lite. - Pro. - Host. - Business. ispmanager includes features such as: - Domain management. - Built-in security tools. - Support for all popular CMS. - Backup system. - Multiple PHP versions supported on a single server. - Support for Docker. **Developer**: ispmanager. **ipsmanager license**: proprietary. ## Vesta Control Panel Vesta CP is **a free, easy-to-use web hosting control panel**. Its core functionalities are completely free, but Vesta also offers commercial plugins available for a monthly fee or a lifetime license. Its source code is publicly available to be downloaded and modified as desired. Vesta Control Panel includes features such as: - Server statistics monitoring. - Powerful backup system. - Linux PAM authentication mechanism. - Built-in firewall. - Fast web interface. **Developer**: Vesta Control Panel. **Latest Vesta CP release**: Vesta 0.9.8-26. **Vesta CP license**: GNU General Public License v3. ## DirectAdmin DirectAdmin is **an easy-to-use and powerful web hosting control panel**. It is highly customizable and offers diverse licenses: - Free 60-day trial. - Personal. - Lite. - Standard. DirectAdmin is compatible with diverse Linux distributions, such as Ubuntu, Debian and RHEL. It includes features such as: - Complete system usage statistics. - Several access levels. - Automatic SSL. - Unlimited customization abilities. - Automatic installation and configuration of selected software packages. **Developer**: JBMC Software. **Latest DirectAdmin release**: DirectAdmin 1.62.9. **DirectAdmin license**: proprietary. ## Ajenti Ajenti is **an open source web hosting control panel**, with two available options: Ajenti 1.x as a server administration panel and Ajenti 2 as a lightweight admin panel. Ajenti is developed for Linux and BSD systems and compatible with many Linux distributions. Ajenti includes features such as: - Responsive remote terminal. - Fast and secure access. - Easily extensible using Python. - Numerous plugins available. - Ajenti Core and Ajenti V. **Developer**: Ajenti Project. **Ajenti license**: MIT. ## Sentora Sentora is **a free, open source web hosting control panel**, based on the foundations of ZPanel. It is developed to work on a wide variety of linux distributions and targeted to small and medium ISPs. Sentora includes features such as: - Fully customizable control panel. - Multi-client environment. - Community and premium support. - Simplified management. - Numerous add-ons. **Developer**: The Sentora Project. **Latest Sentora release**: Sentora 1.0.3. **Sentora license**: GNU General Public License v3. ## BlueOnyx BlueOnyx is **a free, open source web hosting control panel**. It is a modernized fork of BlueQuartz. It is compatible with many Linux distributions, such as RHEL, AlmaLinux and Rocky Linux. BlueOnyx includes features such as: - User-friendly web-based interface. - Web, email, DNS and file transfer services. - IPv4, IPv6 and dual-stack support. - Reseller management. - GDPR tools. **Developer**: Solarspeed.net. **Latest BlueOnyx release**: BlueOnyx 5210R. **Blueonyx license**: Sun modified BSD license. ## cPanel cPanel is **an intuitive web and server control panel**, targeted to small and medium businesses, developers, digital agencies and hosting providers. It offers a free 15-day trial and different paying licenses: - cPanel solo. - Admin. - Pro. - Premier. Besides, cPanel offers licenses for cloud environments and bare-metal servers. It includes features such as: - Automation of all server management tasks. - Control and flexibility. - Add-ons and third-party plugins. - Tools for designing custom databases. - Secure backups. **Developer**: cPanel, L.L.C. **Latest cPanel release**: cPanel 102. **cPanel license**: proprietary. ## Froxlor Froxlor is **a lightweight, open source server control panel**, developed by experienced server administrators. It is available for free. It includes features such as: - Multistack. - Simplified management. - API based. - Advanced SSL. - Easy management of resellers and customers resources. **Developer**: Froxlor team. **Latest Froxlor release**: Froxlor 0.10.33. **Froxlor license**: General Public License (GPL). ## Easy Hosting Control Panel Easy Hosting Control Panel or EHCP is **a free, open source hosting control panel**. It supports many Linux distributions. EHCP includes features such as: - Easy customization. - Web statistics. - SSL support. - Management of domains, FTP, emails, etc. - Different user levels. **Developer**: Easy Hosting Control Panel. **Latest EHCP release**: EHCP 20.04. **EHCP license**: General Public License (GPL). ## Webmin Webmin is **one of the earliest web hosting control panels**, developed for Linux, FreeBSD, Windows and other Unix-like OS. It is a system configuration tool that can be used on any web browser. Webmin includes features such as: - Numerous built-in functions using modules. - Powerful and flexible. - SSH keys support. - Third-party modules. - Support for a wide list of systems. **Developer**: Jamie Cameron and Webmin community. **Latest Webmin release**: Webmin 1.984. **Webmin license**: BSD license. ## ApisCP ApisCP is **an open source web hosting control panel**. It offers a free 30-day trial version and diverse licenses available for a monthly or annual fee: - Pro. - Startup. - Mini. Apis control panel includes features such as: - Performance and security-focused. - Integrated monitoring. - Automation. - Intelligent updates. - Quick installation. **Developer**: Apis Networks, Inc.  **Latest ApisCP release**: ApisCP 3.2. **ApisCP license**: proprietary. ## aaPanel aaPanel is **a free, open source hosting control panel**. It offers a free license and a paying professional license, on a monthly or annual subscription. Besides, it has diverse plugins available for a monthly fee and it includes features such as: - Module-based. - Fast deployment. - Real-time monitoring. - Numerous security features. - One-click function. **Developer**: aaPanel. **Latest aaPanel release**: aaPanel 6.8.21. ## Zesle Control Panel Zesle Control Panel or ZesleCP is **a lightweight, easy-to-use web hosting control panel**. It offers diverse pricing plans, available for a monthly, annual and lifetime fee: - Solo. - Personal. - Pro. - Business.  ZesleCP includes features such as: - API support. - Multi-accounts. - One-click apps. - SSH keys management. - Easy Firewall Manager interface. **Developer**: Zesle Software Inc. **Latest ZesleCP release**: ZesleCP v3.1.11. **Zesle Control Panel license**: proprietary. ## Kloxo Kloxo is a free and open-source web hosting control panel designed for Linux servers. It offers a functional solution for small installations on virtual machines and standalone hardware. #### Key Features of Kloxo: - **Operating System Compatibility:** Rocky Linux and AlmaLinux (versions 8 and 9) and other RHEL derivatives. - **Supported Web Servers:** Nginx, Lighttpd, Hiawatha, Apache (Httpd 24), and dual or multiple web server setups. - **Web Cache Server:** Varnish. - **PHP Management:** Supports multiple PHP versions (5.6, 7.4, and all PHP 8 versions). - **Mail Servers:** Qmail-toaster (based on Qmail 1.06) and Dovecot for IMAP/POP3. - **Database Management:** MariaDB, with tools like PHPMyAdmin (upcoming options include Adminer, MyWebSQL, and SqlBuddy). - **Webmail Clients:** Afterlogic Webmail Lite, Roundcube, and Rainloop. - **FTP Server:** Pure-ftpd. - **DNS Server:** Bind (testing compatibility with others like PowerDNS, MaraDNS, and Yadifa). - **Free SSL Certificates:** Let’s Encrypt and StartAPI. - **Additional Security Modules:** ClamAV, SpamAssassin, RKHunter, and MalDetect. - **Updates and Fixes:** Includes bug fixes and security improvements from earlier Kloxo versions. #### Additional Information: - **Developer:** Kloxo Next Generation Team. - **Latest Version:** Kloxo 8. - **License:** Affero General Public License v3 (AGPLv3). Kloxo is a versatile and user-friendly tool, ideal for managing Linux servers in small to medium-sized setups. ## CyberPanel CyberPanel is **a free, open source web hosting control panel for OpenLiteSpeed**.  CyberPanel includes features such as: - Management of unlimited websites. - Active community support. - One-click SSL. - Command-line interface. - Free cache plugins included. **Developer**: CyberPanel team. **Latest CyberPanel release**: CyberPanel 2.1.2 Stable. **CyberPanel license**: General Public License v3. --- ## 19 paneles de control de hosting web populares URL: https://www.stackscale.com/blog/popular-web-hosting-control-panels/ Los paneles de control de hosting web son **una herramienta imprescindible para los administradores de sistemas y proveedores de hosting web actualmente**. Por eso hemos creado esta lista de los paneles de control de alojamiento web más populares. **Los paneles de control simplifican la gestión y automatización de tareas** a los sysadmins. Permiten, por ejemplo, gestionar uno o varios servidores desde un único *dashboard*. Así que, al tratarse de una herramienta para gestionar tareas críticas como parches, configuraciones, instalaciones, monitorización, etc., se debe elegir adecuadamente. Aquí os dejamos **una lista de los paneles de control de alojamiento web más populares del mercado**. ## Plesk * Plesk se posiciona como el panel de control de alojamiento web comercial más popular del mercado, ofreciendo soluciones sólidas tanto para plataformas **Linux** como **Windows**. Diseñado para satisfacer las necesidades de desarrolladores, administradores de sistemas y proveedores de alojamiento, Plesk cuenta con planes de precios **mensuales** y **anuales**, ideales para gestionar servidores dedicados y servidores privados virtuales (VPS). #### Principales Características de Plesk: - **Acceso Completo por SSH:****Plesk proporciona acceso completo por SSH, ofreciendo a los administradores y desarrolladores el máximo control y flexibilidad sobre sus servidores. - Seguridad Avanzada:****La seguridad es una prioridad, con herramientas integradas como firewalls de aplicaciones web (WAF), prevención de intrusiones con fail2ban y certificados SSL/TLS automáticos de Let’s Encrypt o DigiCert. - Herramientas Avanzadas de Monitorización:****Plesk permite monitorizar en tiempo real el rendimiento del servidor, el uso de recursos y otros indicadores clave, ayudando a anticipar y resolver problemas antes de que afecten al rendimiento. - Amplia Biblioteca de Extensiones:****Con más de 100 extensiones** disponibles, Plesk permite integrar servicios de terceros líderes como Cloudflare, Git, Docker y herramientas SEO, ampliando sus funcionalidades y adaptándose a cualquier necesidad. - **Completo Toolkit para WordPress:****Plesk incluye un completo conjunto de herramientas para gestionar sitios WordPress, como entornos de pruebas, actualizaciones automáticas, clonación y refuerzo de seguridad con un solo clic, convirtiéndolo en la opción preferida para los profesionales de WordPress. - Entorno Amigable para Desarrolladores:****Plesk admite tecnologías modernas como Node.js**, **Ruby**, **Python**, **Git** y **Docker**, facilitando flujos de trabajo eficientes para el desarrollo. - **Soporte Multilingüe:****Su interfaz intuitiva está disponible en varios idiomas, garantizando su usabilidad global tanto para administradores como para usuarios finales. - Respaldo y Restauración Integrados:****Las opciones de copias de seguridad automáticas aseguran la protección de los datos, permitiendo restaurar sitios o servidores de manera sencilla y rápida. #### Información Adicional: - Desarrollador:** Plesk International GmbH. - **Última Versión:** Plesk Obsidian, que introduce mejoras en la experiencia de usuario, nuevas herramientas de seguridad y optimización del rendimiento. - **Licencia:** Propietaria, asegurando soporte de alta calidad y actualizaciones constantes. #### ¿Por Qué Elegir Plesk? La versatilidad incomparable de Plesk, junto con su amplia gama de características y su ecosistema robusto, lo convierten en la elección preferida tanto para particulares como para empresas. Ya sea para gestionar un único sitio web o un servidor completo, Plesk simplifica las tareas, refuerza la seguridad y ofrece escalabilidad sin igual para satisfacer las demandas del alojamiento web moderno. ## Control Web Panel (CWP) Control Web Panel (CWP) es **un panel de control de alojamiento web potente e impulsado por la comunidad para servidores dedicados y VPS**. Tiene diferentes opciones de licenciamiento: - Versión gratuita. - Versión Pro —con o sin soporte—. - Versión Pro especial para partners. CWP está desarrollado para sistemas operativos Linux e incluye características como: - Interfaz de usuario moderna e intuitiva. - Seguridad mejorada. - Automatización completa de los procesos. - Visualización de los logs* del servidor. - Herramientas de monitorización. **Desarrollador:** Studio 2/4 host y Linanto LLC. **Licencia de Control Web Panel**: Software libre bajo licencia de Control Web Panel. ## ISPConfig * ISPConfig es **un panel de control de hosting gratuito y de código abierto para Linux**. Es compatible con numerosos Daemons y distribuciones de Linux, como Ubuntu, Debian y CentOS. ISPConfig incluye características como: - Varios niveles de acceso. - Gestión del servidor web. - Gestión del servidor DNS. - Gestión del servidor mail. - Múltiples servicios gestionados. **Desarrollador:** ISPConfig UG. **Última actualización de ISPConfig**: ISPConfig 3.2.7p1. **Licencia de ISPConfig**: licencia BSD. ## Virtualmin Virtualmin es **un panel de control de sitios web y alojamiento de dominios de código abierto, basado en Webmin**. Existen dos versiones de este panel de control: - Virtualmin GPL, una versión gratuita y de código abierto. - Virtualmin Professional, una versión premium disponible pagando una cuota mensual o anual. Virtualmin está desarrollado para sistemas Linux y BSD e incluye características como: - Control de acceso avanzado. - Visualización sencilla de los logs* del servidor. - Herramientas de monitorización. - Diversas funcionalidades de seguridad. - Herramientas completas para gestionar bases de datos. **Desarrollador:** Virtualmin, Inc. **Última actualización de Virtualmin**: Virtualmin 6.13. **Licencia de Virtualmin**: Licencia Pública General GNU. ## ispmanager * ispmanager es **un panel de control de sitios web y servidores web, comercial y basado en Linux**. Ofrece una versión de prueba gratuita de 14 días y varias opciones de licencia, disponibles pagando una cuota mensual o anual: - Lite. - Pro. - Host. - Business. ispmanager incluye características como: - Gestión de dominios. - Herramientas de seguridad integradas. - Compatible con los CMS más usados. - Sistema de backups. - Múltiples versiones de PHP soportadas en un único servidor. - Soporte para Docker. **Desarrollador:** ispmanager. **Licencia de ispmanager**: propietaria. ## Vesta Control Panel Vesta CP es **un panel de control de hosting web gratuita y fácil de usar**. Sus funcionalidades principales son totalmente gratuitas, pero Vesta también ofrece plugins comerciales disponibles con el pago de una cuota mensual o una licencia de por vida. Su código fuente está disponible públicamente para que cualquiera pueda descargarlo y modificarlo como desee. Vesta Control Panel incluye características como: - Monitorización de estadísticas del servidor. - Potente sistema de backups. - Mecanismo de autenticación Linux PAM. - Firewall integrado. - Interfaz web rápida. **Desarrollador:** Vesta Control Panel. **Última actualización de Vesta CP**: Vesta 0.9.8-26. **Licencia de Vesta CP**: Licencia Pública General GNU v3. ## DirectAdmin DirectAdmin es **un panel de control de alojamiento web potente y fácil de usar**. Se puede personalizar considerablemente y ofrece diversas licencias: - Prueba gratuita de 60 días. - Personal. - Lite. - Standard. DirectAdmin es compatible con diversas distribuciones de Linux, como Ubuntu, Debian y RHEL. Incluye características como: - Estadísticas de uso del sistema completas. - Varios niveles de acceso. - SSL automatizado. - Capacidades de personalización ilimitadas. - Instalación y configuración automática de paquetes de software seleccionados. **Desarrollador:** JBMC Software. **Última actualización de DirectAdmin**: DirectAdmin 1.62.9. **Licencia de DirectAdmin**: propietaria. ## Ajenti Ajenti es **un panel de control de hosting web de código abierto**, con dos opciones disponibles: Ajenti 1.x como panel de administración de servidor y Ajenti 2 como panel de administrador ligero. Ajenti está desarrollado para sistemas Linux y BSD y es compatible como muchas distribuciones de Linux. Ajenti incluye características como: - Terminal remoto responsive*. - Acceso seguro y rápido. - Fácilmente expandible usando Python. - Numerosos plugins disponibles. - Ajenti Core y Ajenti V. **Desarrollador:** Ajenti Project. **Licencia de Ajenti**: MIT. ## Sentora Sentora es **un panel de control de alojamiento web gratuito y de código abierto**, basado en los fundamentos de ZPanel. Está desarrollado para funcionar en una amplia variedad de distribuciones de Linux y está dirigido a ISPs pequeños y medianos. Sentora incluye características como: - Panel de control completamente personalizable. - Entorno multicliente. - Soporte de la comunidad y premium. - Gestión simplificada. - Múltiples add-ons. **Desarrollador:** The Sentora Project. **Última actualización de Sentora**: Sentora 1.0.3. **Licencia de Sentora**: Licencia Pública General GNU v3. ## BlueOnyx * BlueOnyx es **un panel de control de alojamiento web gratuito y de código abierto**. Es un fork* modernizado de BlueQuartz. Es compatible con muchas distribuciones de Linux, como RHEL, AlmaLinux y Rocky Linux. BlueOnyx incluye características como: - Interfaz web fácil de usar. - Servicios web, email, DNS y de transferencia de archivos. - Soporte IPv4, IPv6 y dual-stack. - Gestión de revendedores. - Herramientas RGPD. **Desarrollador:** Solarspeed.net. **Última actualización de BlueOnyx**: BlueOnyx 5210R. **Licencia de Blueonyx**: licencia BSD modificada por Sun. ## cPanel * cPanel es **un intuitivo panel de control de web y servidor**, dirigido a negocios, desarrolladores, agencias digitales y proveedores de hosting pequeños y medianos. Ofrece una versión de prueba gratuita de 15 días y diferentes licencias de pago: - cPanel solo. - Admin. - Pro. - Premier. Además, cPanel ofrece licencias para entornos cloud y servidores bare-metal. It incluye características como: - Automatización de todas las tareas de gestión del servidor. - Control y flexibilidad. - Plugins de terceros y add-ons. - Herramientas para diseñar bases de datos a medida. - Backups seguros. **Desarrollador:** cPanel, L.L.C. **Última actualización de cPanel**: cPanel 102. **Licencia de cPanel**: propietaria. ## Froxlor Froxlor es **un ligero panel de control de alojamiento web de código abierto**, desarrollado por administradores de sistemas con experiencia. Está disponible de forma gratuita e incluye características como: - Multistack. - Gestión simplificada. - Basado en API. - SSL avanzado. - Gestión simplificada de los recursos de revendedores y clientes. **Desarrollador:** equipo de froxlor. **Última actualización de Froxlor**: Froxlor 0.10.33. **Licencia de Froxlor**: Licencia Pública General (GPL). ## Easy Hosting Control Panel Easy Hosting Control Panel o EHCP es **un panel de control de alojamiento web gratuito y de código abierto**. Compatible con muchas distribuciones de Linux. EHCP incluye características como: - Fácil personalización. - Estadísticas web. - Soporte SSL. - Gestión de dominios, FTP, emails, etc. - Diferentes niveles de usuario. **Desarrollador:** Easy Hosting Control Panel. **Última actualización de EHCP**: EHCP 20.04. **Licencia de EHCP**: Licencia Pública General (GPL). ## Webmin Webmin es **uno de los paneles de control de hosting web más antiguos**, desarrollado para Linux, FreeBSD, Windows y otros OS de tipo Unix. Es una herramienta de configuración de sistemas que se puede usar en cualquier navegador web. Webmin incluye características como: - Numerosas funciones integradas usando módulos. - Potente y flexible. - Soporte de claves SSH. - Módulos de terceros. - Soporte para una amplia lista de sistemas. **Desarrollador:** Jamie Cameron y la comunidad de Webmin. **Última actualización de Webmin**: Webmin 1.984. **Licencia de Webmin**: licencia BSD. ## ApisCP ApisCP es **un panel de control de alojamiento web de código abierto**. Ofrece una versión de prueba gratuita de 30 días y diversas licencias disponibles pagando una cuota mensual o anual: - Pro. - Startup. - Mini. El panel de control ApisCP incluye características como: - Enfocado a la seguridad y el rendimiento. - Monitorización integrada. - Automatización. - Actualizaciones inteligentes. - Rápida instalación. **Desarrollador:** Apis Networks, Inc.  **Última actualización de ApisCP**: ApisCP 3.2. **Licencia de ApisCP**: propietaria. ## aaPanel aaPanel es **un panel de control de hosting web gratuito y de código abierto**. Ofrece una licencia gratuita y una licencia profesional de pago, con una suscripción mensual o anual. Además, proporciona varios plugins por un coste mensual e incluye características como: - Basado en módulos. - Despliegue rápido. - Monitorización en tiempo real. - Numerosas características de seguridad. - Función One-click*. **Desarrollador:** aaPanel. **Última actualización de aaPanel**: aaPanel 6.8.21. ## Zesle Control Panel * Zesle Control Panel o ZesleCP es **un panel de control de alojamiento web ligero y fácil de usar**. Ofrece diversos planes de pago, disponibles por una cuota mensual, anual o un único pago de por vida: - Solo. - Personal. - Pro. - Business.  ZesleCP incluye características como: - Soporte de API. - Múltiples cuentas. - Applicaciones One-click*. - Gestión de claves SSH. - Sencilla interfaz de gestión del firewall. **Desarrollador:** Zesle Software Inc. **Última actualización de ZesleCP**: ZesleCP v3.1.11. **Licencia de Zesle Control Panel**: propietaria. ## Kloxo Kloxo es un panel de control de alojamiento web gratuito y de código abierto diseñado para servidores Linux. Proporciona una solución funcional para instalaciones pequeñas en máquinas virtuales y hardware independiente. #### Características principales de Kloxo: - **Compatibilidad con sistemas operativos:** Rocky Linux y AlmaLinux (versiones 8 y 9) y otros derivados de RHEL. - **Servidores web soportados:** Nginx, Lighttpd, Hiawatha, Apache (Httpd 24) y configuraciones duales o múltiples de servidores web. - **Servidor de caché web:** Varnish. - **Gestión PHP:** Soporte para múltiples versiones de PHP (5.6, 7.4 y todas las versiones de PHP 8). - **Servidores de correo:** Qmail-toaster (basado en Qmail 1.06) y Dovecot para IMAP/POP3. - **Bases de datos:** MariaDB, con gestores como PHPMyAdmin (próximamente Adminer, MyWebSQL y SqlBuddy). - **Clientes de correo web:** Afterlogic Webmail Lite, Roundcube y Rainloop. - **Servidor FTP:** Pure-ftpd. - **Servidor DNS:** Bind (compatibilidad en pruebas con otros como PowerDNS, MaraDNS y Yadifa). - **Certificados SSL gratuitos:** Let’s Encrypt y StartAPI. - **Módulos de seguridad adicionales:** ClamAV, SpamAssassin, RKHunter y MalDetect. - **Actualizaciones y correcciones:** Solución de errores y problemas de seguridad presentes en versiones anteriores de Kloxo. #### Información adicional: - **Desarrollador:** Equipo de Kloxo Next Generation. - **Última actualización:** Kloxo 8. - **Licencia:** Licencia Pública General Affero v3 (AGPLv3). Kloxo se posiciona como una herramienta versátil y accesible, ideal para gestionar servidores Linux con configuraciones pequeñas o medianas. ## CyberPanel CyberPanel es **un panel de control de alojamiento web gratuito y de código abierto para OpenLiteSpeed**. CyberPanel incluye características como: - Gestión de sitios web ilimitados. - Comunidad de soporte activa. - SSL en un clic. - Interfaz de línea de comandos. - Plugins de cache gratuitos incluidos. **Desarrollador**: equipo de CyberPanel. **Última actualización de CyberPanel**: CyberPanel 2.1.2 Stable. **Licencia de CyberPanel**: Licencia Pública General v3. --- ## Global Internet traffic grows 17.2% in 2024 driven by new technologies and digital services URL: https://www.stackscale.com/blog/global-internet-traffic-grows-2024/ The *Year in Review 2024* report by Cloudflare Radar provides a comprehensive analysis of global Internet trends, **highlighting a significant 17.2% increase in global traffic compared to the previous yea**r. This growth has been fueled by the expansion of satellite connectivity services, the adoption of advanced technologies like post-quantum encryption and the HTTP/3 protocol, and the increasing use of mobile devices and IPv6. The report also addresses key issues such as network security, persistent threats, and the dominance of digital services. ## **Global traffic growth and satellite connectivity** **Global Internet traffic** continued its upward trend, **growing by 17.2% in 2024**. Notable cases include Guinea in West Africa, which experienced a 350% increase in traffic. In contrast, countries like Cuba faced significant disruptions due to power outages and damage caused by Hurricane Rafael. Government-directed Internet shutdowns, such as those in Bangladesh during student protests in July, also had a notable impact. *Starlink Wordwide traffic SpaceX’s Starlink satellite Internet service played a major role, tripling its global traffic. In Spain, traffic grew 8.5x, driven by improved connectivity in rural and underserved areas. Countries like Malawi and Georgia saw usage increase by 38x and 100x, respectively, reflecting the growing demand for alternative connectivity solutions in emerging markets. ### **Most popular digital services** In 2024, Google solidified its position as the most popular Internet service in Spain and globally, followed by Facebook, Apple, TikTok, and Microsoft. Generative AI continued to set trends, while interest in the metaverse waned. The ranking of the most popular Internet services in Spain is as follows: ## **Technological adoption: HTTP/3 and post-quantum encryption** In 2024, 20.5% of global web requests used HTTP/3, an increase from the previous year. This protocol, based on QUIC, enhances connection speed and security. In Spain, 26.7% of traffic is already utilizing HTTP/3, surpassing the global average. Additionally, 13% of global TLS 1.3 traffic adopted post-quantum encryption, a technology designed to protect data against future advances in quantum computing. This growth was driven by browsers like Chrome and Mozilla Firefox, which have begun implementing these measures by default. ## **Connection quality and IPv6 adoption** Spain stood out for its leadership in connection quality, with average download speeds exceeding 292 Mbps and low latency that ensures a smooth user experience. Regarding IPv6, while 28.5% of global traffic now uses this protocol, Spain remains behind with only 9.8% dual-stack adoption. Globally, India leads with 68.9%, followed by Malaysia with 59.6%. At **Stackscale, we are also committed to promoting the transition to IPv6**. Since our inception, we have offered full IPv6 support for all customers looking to deploy their services with this technology. ## **Security and persistent threats** The report highlights that 6.5% of global traffic was mitigated by Cloudflare’s security solutions, including Distributed Denial of Service (DDoS) attacks and advanced firewall rules. The United States accounted for more than one-third of bot traffic, while the gaming and gambling sector was the most attacked in 2024, overtaking the financial sector, which led in previous years. The Log4j vulnerability, discovered in 2021, remained one of the most exploited threats, surpassing the frequency of other critical vulnerabilities discovered this year. ## **Conclusion and outlook for 2025** The Year in Review 2024* report from Cloudflare highlights how government policies, technological innovations, and persistent threats continue to shape the global Internet ecosystem. With accelerated technological adoption and evolving security challenges, the report provides valuable insights for companies and governments to design more effective connectivity and protection strategies for the future. Cloudflare Radar positions itself as an essential tool for monitoring these trends and paving the way for a safer, faster, and more accessible Internet. --- ## El tráfico global de Internet crece un 17,2 % en 2024 impulsado por nuevas tecnologías y servicios digitales URL: https://www.stackscale.com/blog/global-internet-traffic-grows-2024/ El informe **Cloudflare Radar 2024** proporciona una visión exhaustiva de las principales tendencias y patrones de Internet en el mundo y aquí os desgranamos la información enfocada a España. Desde el crecimiento del tráfico hasta la popularidad de los servicios digitales, pasando por la calidad de la conexión y la seguridad, este análisis destaca los avances y desafíos en la evolución digital del país. ## Crecimiento del tráfico y los servicios más utilizados El año 2024 fue testigo de un aumento notable en el **tráfico global de Internet**, que **creció un 17,2 % respecto al año anterior**, consolidando el papel de la conectividad digital como pilar fundamental de la vida moderna. En España, uno de los datos más destacados fue el incremento exponencial del tráfico asociado a SpaceX Starlink, que creció 8,5 veces en comparación con 2023. Esta expansión refleja cómo las tecnologías satelitales están transformando la conectividad en áreas rurales y desatendidas, ofreciendo nuevas oportunidades para superar la brecha digital. ### Los servicios más utilizados en España El dominio de Google como el servicio de Internet más utilizado en España se mantuvo sólido, respaldado por su amplio ecosistema de herramientas y aplicaciones. Facebook, Apple, TikTok y Microsoft también destacaron entre los líderes del mercado, evidenciando su relevancia en un panorama cada vez más competitivo. Una de las tendencias más llamativas del año fue el auge imparable de la inteligencia artificial generativa, que continuó ganando terreno con nuevas herramientas y servicios que impactaron tanto a usuarios individuales como a empresas. En contraste, el interés por el metaverso, que había sido una de las grandes apuestas tecnológicas en años anteriores, disminuyó notablemente. A continuación, se detalla el ranking de los servicios de Internet más populares en España durante 2024: **Posición****Servicio**1Google2Facebook3Apple4TikTok5Microsoft6AWS7Instagram8WhatsApp9YouTube10Amazon ### Starlink y el auge de la conectividad satelital Starlink Tráfico España El impacto de SpaceX Starlink en España es un claro ejemplo del potencial de las tecnologías emergentes para transformar las infraestructuras digitales. El aumento de 8,5x en el tráfico refleja la creciente adopción de este servicio, especialmente en zonas rurales donde las opciones de conectividad tradicionales son limitadas. Esto pone de manifiesto la capacidad de Starlink para ofrecer acceso a Internet de alta velocidad y baja latencia, eliminando barreras históricas para la inclusión digital. También deja claro que los servicios de internet por satélite han llegado para quedarse y evolucionar nuestras conexiones. ### Innovación y transformación tecnológica El crecimiento del tráfico global y la consolidación de servicios clave como Google y Facebook subrayan cómo la tecnología sigue adaptándose a las necesidades cambiantes de los usuarios. Sin embargo, la proliferación de servicios impulsados por inteligencia artificial plantea nuevos retos y oportunidades, especialmente en términos de privacidad, gobernanza de datos y accesibilidad. ## Adopción tecnológica: HTTP/3 y cifrado post-cuántico En España, el **26,7 %** del tráfico de Internet ya utiliza **HTTP/3**, un protocolo que mejora tanto la velocidad como la seguridad de las conexiones. Además, el **20,1 %** del tráfico encriptado mediante TLS 1.3 implementó técnicas de **cifrado post-cuántico**, una medida clave para proteger los datos ante las futuras capacidades de los ordenadores cuánticos. ## Calidad de la conexión: velocidad y latencia en España España se posiciona como un referente en la calidad de la conexión a Internet, con una velocidad media de descarga de **293 Mbps** y una latencia en reposo de **23 ms**. Estas cifras destacan el progreso en infraestructuras como la fibra óptica y el despliegue del 5G, esenciales para sostener la creciente demanda de conectividad. **Indicadores clave de conexión en España, 2024****Valor**Velocidad media de descarga293 MbpsVelocidad media de subida192 MbpsLatencia en reposo23 msAdopción de IPv69,8 % ## Seguridad y tráfico malicioso En 2024, el **4,2 %** del tráfico de Internet en España fue mitigado por Cloudflare como potencialmente malicioso, utilizando técnicas como cortafuegos de aplicaciones web y mitigación de ataques DDoS. Además, España representó el **0,6 %** del tráfico global de bots, siendo **Telefónica** el principal operador de tráfico automatizado en el país. **Orígenes de tráfico de bots en España, 2024****Participación**Telefónica19,29 %UNI2 (Orange España)13,58 %Vodafone España8,34 % ## Dominio de Google en el mercado de motores de búsqueda en España En 2024, **Google** reafirmó su posición como el motor de búsqueda más utilizado en España, con una **cuota de mercado del 95,2 %**, consolidándose como la herramienta preferida por los usuarios para acceder a información en línea. Este dominio indiscutible refleja la capacidad de Google para ofrecer un ecosistema integrado de servicios, que van desde búsquedas rápidas hasta asistentes virtuales avanzados. A pesar de la hegemonía de Google, otras plataformas también han encontrado su espacio en el mercado español, aunque con cuotas significativamente menores. Bing, el motor de búsqueda de Microsoft, ocupa el segundo lugar con un 2,6 % del tráfico, mientras que DuckDuckGo, conocido por priorizar la privacidad del usuario, alcanza un 0,8 %. Yahoo y Brave completan el ranking con cuotas de 0,6 % y 0,4 %, respectivamente. **Motor de búsqueda****Cuota de mercado en España (2024)**Google95,2 %Bing2,6 %DuckDuckGo0,8 %Yahoo0,6 %Brave0,4 %Otros0,4 % ### Análisis por dispositivo y sistema operativo La preferencia por Google se mantiene constante tanto en dispositivos móviles como en ordenadores de sobremesa, destacando su capacidad de adaptarse a las necesidades de los usuarios en diferentes plataformas. Sin embargo, motores como Bing y DuckDuckGo tienden a ganar cuota en nichos específicos de usuarios que buscan alternativas, ya sea por sus características diferenciadoras o por preocupaciones de privacidad. Destacando que además Chrome copa el 73,5% del mercado de los navegadores seguido por Safari con un 10,1% y Edge con el 6,4%. Firefox sigue perdiendo cuota de mercado hasta el 4,7% en este año 2024. El informe subraya cómo los motores de búsqueda y los navegadores, encabezados por Google, continúan desempeñando un papel esencial en el ecosistema digital, ayudando a las empresas a llegar a sus audiencias y a los usuarios a encontrar información de manera eficiente. Este panorama, aunque dominado por un líder claro, sigue evolucionando con la entrada de nuevos actores y el cambio de prioridades entre los usuarios. ## Avances en la adopción de IPv6 en España En 2024, el 9,8 % del tráfico de contenido dual-stack en España se realizó a través de IPv6, una tecnología clave para el crecimiento y la sostenibilidad del Internet global. La **adopción de IPv6 resulta crucial debido a la limitada disponibilidad de direcciones IPv4**, que ha llevado a algunos proveedores de servicios en la nube a implementar tarifas adicionales, conocidas como “impuesto IPv4”. Desde **Stackscale también estamos comprometidos con fomentar la transición hacia IPv6**, por ello desde nuestros inicios ofrecemos soporte completo para IPv6 para todos los clientes que desean desplegar sus servicios con esta tecnología. El análisis de las solicitudes realizadas a través de IPv6 refleja un avance constante en su implementación a nivel regional, mostrando la creciente adopción por parte de los proveedores de red y empresas españolas. Aunque aún queda camino por recorrer, el incremento de IPv6 representa un paso importante hacia una red más eficiente y preparada para el futuro. ## En resumen Este informe anual subraya el **progreso de España en la adopción tecnológica y la calidad de sus conexiones**, aunque persisten desafíos en áreas como la adopción de IPv6 y la seguridad digital. La conectividad avanzada y la mejora continua en ciberseguridad serán esenciales para sostener el crecimiento y garantizar un futuro digital robusto y accesible para todos. --- ## Harlequin: An innovative tool for managing databases from terminal URL: https://www.stackscale.com/blog/harlequin-databases-terminal/ In the world of data management, having efficient and flexible tools can make a significant difference in the performance of any technical team. **Harlequin**, a SQL integrated development environment (IDE), stands out as a solution that combines power and simplicity, designed specifically to work from the terminal. This tool, created in 2023 by Ted Conbeer, has quickly become an essential resource for developers, data analysts, and system administrators. ## Table of contents - What is Harlequin? - Key advantages for enterprise environments - Highlighted features - Harlequin in Stackscale’s Cloud Infrastructure - Installation and configuration - A design that combines functionality and aesthetics - Conclusion ### **What is Harlequin?** Harlequin is a SQL IDE designed to run in terminal, offering support for databases like DuckDB, SQLite, PostgreSQL, MySQL, among others. It is an open-source tool, developed in Python and based on the Textual framework, that is fully cross-platform and compatible with operating systems such as Linux, macOS, and Windows. ### **Key advantages for enterprise environments** In enterprise environments, such as those managed by infrastructure providers like Stackscale, Harlequin represents an agile solution for exploring and managing databases directly from the terminal without needing external tools. This is especially useful in distributed infrastructures or when operating on cloud-based systems. Its main advantages include: - **Management of Multiple Databases**: Harlequin allows you to work with local, in-process, or cloud-hosted databases, making it easier to explore and manage them from a single interface. - **Resource Optimization**: Its efficient design minimizes the load on systems, making it ideal for working on remote servers or with limited connections. - **Flexibility and Customization**: The interface is highly customizable, offering everything from visual themes to configurable keyboard shortcuts, adapting to the specific needs of each technical team. ### **Highlighted features** Harlequin incorporates advanced features that facilitate real-time database operations: - **Data Catalog**: Provides a detailed view of tables, columns, and data types, allowing users to explore the structure of connected databases. - **Query Editor**: Includes autocomplete, support for multiple tabs, and options such as saving, formatting, and managing SQL queries. - **Result Viewer**: Capable of displaying over a million records in interactive tables, with options to export results in formats like CSV and JSON. - **Query History**: Maintains a log of executed queries, making it easy to reuse them for recurring projects. - **Adapter Compatibility**: Supports installing adapters for additional databases, extending its functionality to meet specific requirements. ### **Harlequin in Stackscale’s Cloud Infrastructure** In a business environment based on cloud infrastructure, such as the one offered by Stackscale, Harlequin can be a strategic tool. For example, it allows system administrators to explore databases directly from a remote server without needing additional graphical interfaces. Its compatibility with popular databases, both in the cloud and locally, facilitates integration into hybrid environments. Harlequin can also be used for quick queries on distributed databases or for debugging and data analysis tasks without relying on heavy software, optimizing workflows. ### **Installation and configuration** Harlequin is easily installed using package managers like pip or pipx, and its configuration is straightforward. Some useful commands include: - Basic installation: pipx install harlequin - Using DuckDB: harlequin "path/to/duck.db" - Using SQLite: harlequin -a sqlite "path/to/sqlite.db" Additionally, its support for custom adapters allows integration with other databases as needed. ### **A design that combines functionality and aesthetics** Harlequin’s interface is intuitive and visually appealing, offering over 20 customizable themes, ranging from classic styles like “Dracula” to modern options like “Solarized Dark.” This not only enhances the user experience but also facilitates long terminal work sessions. Harlequin Screenshot ### **Conclusion** Harlequin is more than just a database client: it is a tool that combines efficiency, customization, and compatibility across multiple platforms, making it ideal for modern enterprise environments. In companies like Stackscale, where infrastructure and data management are essential, Harlequin can play a key role in optimizing processes and simplifying technical workflows. If you’re looking for a lightweight, powerful, and flexible solution to manage databases from the terminal, Harlequin is an option worth exploring. For more information, visit its official site at harlequin.sh. Source: System administration --- ## Harlequin: Una herramienta innovadora para gestionar bases de datos desde el terminal URL: https://www.stackscale.com/blog/harlequin-databases-terminal/ En el mundo de la gestión de datos, contar con herramientas eficientes y flexibles puede marcar la diferencia en el desempeño de cualquier equipo técnico. **Harlequin**, un entorno de desarrollo integrado (IDE) para bases de datos SQL, se presenta como una solución que combina potencia y simplicidad, diseñada específicamente para trabajar desde el terminal. Esta herramienta, creada en 2023 por Ted Conbeer, se ha convertido rápidamente en un recurso esencial para desarrolladores, analistas de datos y administradores de sistemas. ## Tabla de contenidos - ¿Qué es Harlequin? - Ventajas clave para el entorno empresarial - Funciones destacadas - Harlequin en la infraestructura cloud de Stackscale - Instalación y configuración - Un diseño que combina funcionalidad y estética - Conclusión ### **¿Qué es Harlequin?** **Harlequin** es un IDE SQL pensado para ser ejecutado en el terminal, ofreciendo soporte para bases de datos como DuckDB, SQLite, PostgreSQL, MySQL, entre otras. Es una herramienta de código abierto, desarrollada en Python y basada en el marco Textual, que destaca por ser multiplataforma y compatible con sistemas operativos como Linux, macOS y Windows. Harlequin ### **Ventajas clave para el entorno empresarial** En entornos empresariales, como los gestionados por proveedores de infraestructura como Stackscale, Harlequin representa una solución ágil para explorar y gestionar bases de datos directamente desde el terminal, sin necesidad de herramientas externas. Esto resulta especialmente útil en infraestructuras distribuidas o cuando se opera sobre sistemas en la nube. Entre sus principales ventajas destacan: - **Gestión de múltiples bases de datos**: Harlequin permite trabajar con bases de datos locales, en proceso o alojadas en la nube, facilitando su exploración y gestión de forma centralizada. - **Optimización de recursos**: Su diseño eficiente minimiza la carga sobre los sistemas, lo que la hace ideal para trabajar en servidores remotos o bajo conexiones limitadas. - **Flexibilidad y personalización**: La interfaz es altamente personalizable, desde temas visuales hasta atajos de teclado, adaptándose a las necesidades específicas de cada equipo técnico. ### **Funciones destacadas** Harlequin incorpora características avanzadas que facilitan el trabajo con bases de datos en tiempo real: - **Catálogo de datos**: Ofrece una vista detallada de tablas, columnas y tipos de datos, permitiendo explorar la estructura de las bases de datos conectadas. - **Editor de consultas**: Incluye autocompletado, soporte para múltiples pestañas y opciones como guardar, formatear y gestionar consultas SQL. - **Visualización de resultados**: Es capaz de mostrar más de un millón de registros en tablas interactivas, con la opción de exportar los resultados en formatos como CSV y JSON. - **Historial de consultas**: Mantiene un registro de las consultas ejecutadas, facilitando su reutilización en proyectos recurrentes. - **Compatibilidad con adaptadores**: Soporta la instalación de adaptadores para bases de datos adicionales, ampliando su funcionalidad según las necesidades. ### **Harlequin en la infraestructura cloud de Stackscale** En un entorno empresarial basado en infraestructura cloud, como el que ofrece Stackscale, Harlequin puede ser una herramienta estratégica. Por ejemplo, permite a los administradores de sistemas explorar bases de datos directamente desde un servidor remoto sin necesidad de interfaces gráficas adicionales. Además, su compatibilidad con bases de datos populares, tanto en la nube como locales, facilita la integración en entornos híbridos. Harlequin también puede utilizarse para realizar consultas rápidas en bases de datos distribuidas o para tareas de depuración y análisis de datos sin depender de software pesado, optimizando los flujos de trabajo. ### **Instalación y configuración** Harlequin se instala fácilmente mediante gestores de paquetes como pip o pipx, y su configuración es sencilla. Algunos comandos útiles incluyen: - Instalación básica: pipx install harlequin - Uso con DuckDB: harlequin "ruta/a/duck.db" - Uso con SQLite: harlequin -a sqlite "ruta/a/sqlite.db" Además, su soporte para adaptadores personalizados permite integrar otras bases de datos según las necesidades del entorno. ### **Un diseño que combina funcionalidad y estética** La interfaz de Harlequin es intuitiva y visualmente atractiva, ofreciendo más de 20 temas personalizables, desde estilos clásicos como “Drácula” hasta opciones modernas como “Solarized Dark”. Esto no solo mejora la experiencia del usuario, sino que también facilita largas sesiones de trabajo en el terminal. ### **Conclusión** Harlequin es mucho más que un simple cliente de bases de datos: es una herramienta que combina eficiencia, personalización y compatibilidad con múltiples plataformas, ideal para entornos empresariales modernos. En compañías como Stackscale, donde la infraestructura y la gestión de datos son esenciales, Harlequin puede desempeñar un papel clave en la optimización de procesos y la simplificación del trabajo técnico. Si buscas una solución ligera, potente y flexible para gestionar bases de datos desde el terminal, Harlequin es una opción que merece la pena explorar. Para más información, visita su sitio oficial en harlequin.sh. --- ## The 500 most powerful supercomputers use Linux URL: https://www.stackscale.com/blog/most-powerful-supercomputers-linux/ The world’s most powerful supercomputers use Linux. A supercomputer is a device whose computing capabilities are by far higher than those of common computers. **The most powerful supercomputer nowadays exceeds 1,740 Petaflops** (PFlops). This is a performance no personal device can achieve. Besides, it is worth mentioning that Linux has dominated the list of the world’s 500 most powerful supercomputers since 2009. ## Table of contents - Linux: more than 20 years in the supercomputing world - The world’s 10 most powerful supercomputers - Evolution of the Top 3 supercomputers since 2000 - List of supercomputers which have ever been in the first position - Supercomputers by continent ## Linux: more than 20 years in the supercomputing world The TOP500 list has been updated twice a year (in June and November) since 1993. **Linux appeared for the first time in this list of the world’s most powerful supercomputers in June 1998**. The first supercomputer using Linux to be included in the list was the Avalon Cluster from the United States, in the 314th position. The Avalon Cluster supercomputer had 140 Alpha EV56 processors. In the nineties, commercial versions of Unix such as IRIX, UNICOS, AIX or Solaris dominated the TOP500 list. Besides, at that point, Windows and MacOS were already focused on end user devices. But, from 1998 onwards, the evolution of Linux was outstanding in the supercomputing field. Throughout the years, Linux’s growth has been unstoppable; specially between November 2002 and November 2009. During that 7-year period, Linux went from being used in 71 supercomputers to being used in 448 supercomputers. Currently, Linux is the clear leader in supercomputing. For Linux to lose the leadership, a big hardware revolution should take place. However, as time goes by, we will see if other alternatives emerge to challenge Linux’s leadership. ### Why is Linux perfect for supercomputers? There are many reasons why most supercomputers have chosen Linux. Let’s see some of the main reasons why Linux is the leader in supercomputing: - **Open operating system**. Since it is an open source system, it is 100% customizable. This feature enables the free modification of any part of the code. It is useful both for improving performance and solving any security problem. - **Lower consumption of resources**. As it is customizable, performance can be boosted by specifying that only vital applications are executed. This cannot be done with other operating systems, since they do not usually allow specific configurations. - **Modular structure**. This is one of the most important features of Linux. As it is completely open, new modules can be added without affecting other parts within the operating system. Besides, resource optimization is much easier. - **Adapted to all kinds of workloads**. Its ability to adapt to all kinds of workloads is a very important feature as well. This makes measuring the supercomputer efficiency, consumption and performance easier. - **Costs**. As it is completely free, there is no need to pay for a license to use it. So, the necessary investment is the time required to modify the OS for each project. ## The world’s 10 most powerful supercomputers These are the ten most powerful supercomputers in the world, according to the TOP500 list (November 2024 update). **Superordenador****País****System****Cores****Rmax****Rpeak****#1 El Capitan**United StatesHPE Cray EX255a, AMD 4th Gen EPYC 24C 1.8GHz, AMD Instinct MI300A, Slingshot-11, TOSS, HPE DOE/NNSA/LLNL11.039.6161.742 PFlops/s2.746,38 PFlops/s**#2 Frontier**United StatesHPE Cray EX235a, AMD Optimized 3rd Generation EPYC 64C 2GHz, AMD Instinct MI250X, Slingshot-11, HPE Cray OS, HPE DOE/SC/Oak Ridge National Laboratory9.066.1761.353 PFlops/s2.055,72 PFlops/s**#3 Aurora**United StatesHPE Cray EX – Intel Exascale Compute Blade, Xeon CPU Max 9470 52C 2.4GHz, Intel Data Center GPU Max, Slingshot-11, Intel DOE/SC/Argonne National Laboratory9.264.1281.012 PFlops/s1.980,01 PFlops/s**#4 Eagle**United StatesMicrosoft NDv5, Xeon Platinum 8480C 48C 2GHz, NVIDIA H100, NVIDIA Infiniband NDR, Microsoft Azure Microsoft Azure2.073.600561,20 PFlops/s846,84 PFlops/s**#5 HPC6**ItalyHPE Cray EX235a, AMD Optimized 3rd Generation EPYC 64C 2GHz, AMD Instinct MI250X, Slingshot-11, RHEL 8.9, HPE Eni S.p.A.3.143.520477,90 PFlops/s606,97 PFlops/s**#6 Supercomputer Fugaku**JapanSupercomputer Fugaku, A64FX 48C 2.2GHz, Tofu interconnect D, Fujitsu RIKEN Center for Computational Science442,01 PFlops/s537,21 PFlops/s**#7 Alps**SwitzerlandHPE Cray EX254n, NVIDIA Grace 72C 3.1GHz, NVIDIA GH200 Superchip, Slingshot-11, HPE Cray OS, HPE Swiss National Supercomputing Centre (CSCS)2.121.600434,90 PFlops/s353,75 PFlops/s**#8 LUMI**FinlandHPE Cray EX235a, AMD Optimized 3rd Generation EPYC 64C 2GHz, AMD Instinct MI250X, Slingshot-11, HPE EuroHPC/CSC2.752.704379,70 PFlops/s531,51 PFlops/s**#9 Leonardo**ItalyBullSequana XH2000, Xeon Platinum 8358 32C 2.6GHz, NVIDIA A100 SXM4 64 GB, Quad-rail NVIDIA HDR100 Infiniband, EVIDEN EuroHPC/CINECA1.824.768241,20 PFlops/s306,31 PFlops/s**#10 Toulumne**United StatesHPE Cray EX255a, AMD 4th Gen EPYC 24C 1.8GHz, AMD Instinct MI300A, Slingshot-11, TOSS, HPE DOE/NNSA/LLNL1.161.216208,10 PFlops/s288,88 PFlops/s Spain leaves the TOP 10 in November 2024, but the **MareNostrum 5 ACC (Accelerated Partition)** with RedHat and an Rmax of 175.30 PFlops/s and Rpeak of 249.44 PFlops/s maintains an outstanding position. ## Evolution of the Top 3 supercomputers since 2000 The following table compiles those supercomputers that have been in the top 3 positions of the TOP500 list from 2000 to 2024. **Top 1****Top 2****Top 3****June 2000**ASCI Red (United States)ASCI Blue-Pacific SST, IBM SP 604e (United States)ASCI Blue Mountain (United States)**November 2000**SP Power3 375 MHz 16 way (United States)ASCI Red (United States)ASCI Blue-Pacific SST, IBM SP 604e (United States)**June 2001**ASCI White, SP Power3 375 MHz (United States)SP Power3 375 MHz 16 way (United States)ASCI Red (United States)**November 2001**ASCI White, SP Power3 375 MHz (United States)AlphaServer SC45, 1 GHz (United States)SP Power3 375 MHz 16 way (United States)**June 2002**Earth-Simulator (Japan)ASCI White, SP Power3 375 MHz (United States)AlphaServer SC45, 1 GHz (United States)**November 2002**Earth-Simulator (Japan)ASCI Q – AlphaServer SC45, 1.25 GHz (United States)ASCI White, SP Power3 375 MHz (United States)**June 2003**Earth-Simulator (Japan)ASCI Q – AlphaServer SC45, 1.25 GHz (United States)MRC Linux Cluster Xeon 2.4 GHz – Quadrics (United States)**November 2003**Earth-Simulator (Japan)ASCI Q – AlphaServer SC45, 1.25 GHz (United States)X (United States)**June 2004**Earth-Simulator (Japan)Thunder (United States)ASCI Q – AlphaServer SC45, 1.25 GHz (United States)**November 2004**BlueGene/L beta-System (United States)Columbia (United States)Earth-Simulator (Japan)**June 2005**BlueGene/L (United States)BGW (United States)Columbia (United States)**November 2005**BlueGene/L (United States)BGW (United States)ASC Purple (United States)**June 2006**BlueGene/L (United States)BGW (United States)ASC Purple (United States)**November 2006**BlueGene/L (United States)Red Storm (United States)BGW (United States)**June 2007**BlueGene/L (United States)Jaguar (United States)Red Storm (United States)**November 2007**BlueGene/L (United States)JUGENE (Germany)SGI Altix ICE 8200 (United States)**June 2008**Roadrunner (United States)BlueGene/L (United States)Kraken XT5 (United States)**November 2008**Roadrunner (United States)Jaguar (United States)Pleiades (United States)**June 2009**Roadrunner (United States)Jaguar (United States)JUGENE (Germany)**November 2009**Jaguar (United States)Roadrunner (United States)Kraken XT5 (United States)**June 2010**Jaguar (United States)Nebulae (China)Roadrunner (United States)**November 2010**Tianhe-1A (China)Jaguar (United States)Nebulae (China)**2011**K computer (Japan)Tianhe-1A (China)Jaguar (United States)**June 2012**Sequoia (United States)K computer (Japan)Mira (United States)**November 2012**Titan (United States)Sequoia (United States)K computer (Japan)**2013**Tianhe-2A (China)Titan (United States)Sequoia (United States)**June 2014**Tianhe-2A (China)Titan (United States)Sequoia (United States)**2015**Tianhe-2A (China)Titan (United States)Sequoia (United States)**2016**Sunway TaihuLight (China)Tianhe-2A (China)Titan (United States)**2017**Sunway TaihuLight (China)Tianhe-2A (China)Piz Daint (Switzerland)**June 2018**Summit (United States)Sunway TaihuLight (China)Sierra (United States)**November 2018**Summit (United States)Sierra (United States)Sunway TaihuLight (China)**2019**Summit (United States)Sierra (United States)Sunway TaihuLight (China)**2020**Supercomputer Fugaku (Japan)Summit (United States)Sierra (United States)**2021**Supercomputer Fugaku (Japan)Summit (United States)Sierra (United States)**2022**Frontier (United States)Supercomputer Fugaku (Japan)LUMI (Finland)**June 2023**Frontier (United States)Supercomputer Fugaku (Japan)LUMI (Finland)**November 2023**Frontier (United States)Aurora (United States)Eagle (United States)**Junio 2024**Frontier (United States)Frontier (United States)Aurora (United States)**November 2024**El Capitan (United States)Frontier (United States)Aurora (United States) ## List of supercomputers which have ever been in the first position Here is a list of the supercomputers that have held the first position in the TOP500 list since 1993. - **CM-5/1024** (United States) - **Numerical Wind Tunnel** (Japan) - **XP/S140** (United States) - **SR2201/1024** (Japan) - **CP-PACS/2048** (Japan) - **ASCI Red** (United States) - **ASCI White, SP Power3 375 MHz** (United States) - **Earth-Simulator** (Japan) - **BlueGene/L beta-System** (United States) - **BlueGene/L – eServer Blue Gene Solution** (United States) - **Roadrunner** (United States) - **Jaguar** (United States) - **Tianhe-1A** (China) - **K computer** (Japan) - **Sequoia** (United States) - **Titan** (United States) - **Tianhe-2A** (China) - **Sunway TaihuLight** (China) - **Summit** (United States) - **Supercomputer Fugaku** (Japan) - **Frontier** (United States)**El Capitan** (United States) ## Supercomputers by continent This is the distribution of the most powerful supercomputers in the TOP500 list by continent, as of November 2024: - **North America**: 181 supercomputers. - **Asia**: 142 supercomputers. - **Europe**: 162 supercomputers. - **South America**: 10 supercomputers. - **Oceania**: 4 supercomputers. - **Africa**: 1 supercomputer. ### The United States: the leader in number of supercomputers From November 2017 to November 2024, China had been the leader in the number of supercomputers. However, **the United States has been the leader since the ranking published in June 2023**. As of November 2024, the US has 172 supercomputers among the world’s 500 most powerful supercomputers. It is followed by China, with 62 supercomputers, and Germany, with 41 supercomputers. **The United States is also the leader in performance**, with a Rmax of 6,475,558,900 Gigaflops (GFlops). Rmax is the acronym for “Maximal LINPACK performance achieved”. In terms of performance, the US is followed by Japan, with a Rmax of 940,710,340 GFlops, and Italy, with a Rmax of 849,088,330 GFlops. --- ## Los 500 superordenadores más potentes del mundo usan Linux URL: https://www.stackscale.com/blog/most-powerful-supercomputers-linux/ Los superordenadores más potentes del mundo utilizan Linux. Un superordenador (también conocido como supercomputador/a) es un dispositivo con una capacidad de computación que supera ampliamente a la de los ordenadores comunes. A día de hoy, **el superordenador más potente supera los 1.740 Petaflops** (PFlops). Esta potencia está muy lejos de la que puede alcanzar un equipo personal. Además, cabe mencionar que Linux domina de forma absoluta la lista de los 500 superordenadores más potentes del mundo desde 2009. ## Linux: más de 20 años en el mundo de la supercomputación La lista TOP500 se actualiza dos veces al año (en junio y noviembre) desde 1993. **Linux apareció por primera vez en esta lista de los superordenadores más potentes del mundo en junio de 1998**. El primer supercomputador con Linux en la lista de los más potentes fue el Avalon Cluster de Estados Unidos, en la posición 314. El superordenador Avalon Cluster contaba con 140 procesadores Alpha EV56. En los años noventa, la lista TOP500 estaba dominada por variantes comerciales de Unix como IRIX, UNICOS, AIX o Solaris. Además, a esas alturas, Windows y MacOS ya estaban centrados en equipos de usuarios. Sin embargo, a partir de 1998, la evolución de Linux en el ámbito de la supercomputación fue espectacular. A lo largo de los años, el crecimiento de Linux ha sido imparable; especialmente entre noviembre de 2002 y noviembre de 2009. Durante ese período de 7 años, Linux pasó de ser usado en 71 superordenadores a ser usado en 448 superordenadores. En la actualidad, Linux es el claro líder de la supercomputación y sería muy raro que perdiese ese liderazgo. Se necesitaría una gran revolución de hardware para que esto ocurriese. No obstante, el tiempo dirá si esto sigue así o si aparecerá alguna otra alternativa capaz de desafiar este liderazgo. ### ¿Por qué Linux es perfecto para los superordenadores? Son muchas las razones por las que la mayoría de los superordenadores han elegido Linux. A continuación recopilamos algunos de los motivos principales por los que Linux es el líder en supercomputación: - **Sistema operativo libre**. Al tratarse de un sistema de código abierto, se puede personalizar al 100 %. Esto permite modificar cualquier parte del código con mayor libertad. Lo cual es útil tanto para mejorar el rendimiento como para solucionar cualquier problema de seguridad. - **Menor consumo de recursos**. Al ser personalizable permite mejorar el rendimiento precisando que solo se ejecuten las aplicaciones más vitales. Esto no es posible con otros sistemas operativos, ya que no suelen permitir realizar configuraciones específicas. - **Estructura modular**. Este es uno de los factores más importantes de Linux. Al ser completamente abierto, se pueden añadir nuevos módulos sin afectar al resto del sistema operativo. Además, la optimización de los recursos es mucho más sencilla. - **Adaptado a todo tipo de *workloads***. Su capacidad de adaptarse a todo tipo de cargas de trabajo es otra de sus características más importantes. Esto permite medir de forma sencilla la eficiencia, el consumo y el rendimiento del superordenador. - **Costes**. Al ser totalmente libre, no hay que pagar ningún tipo de licencia para utilizarlo. De modo que la inversión necesaria es el tiempo necesario para modificar el sistema operativo para cada proyecto concreto. ## Los 10 superordenadores más potentes del mundo Estas son las diez supercomputadoras más potentes del mundo, según la lista TOP500 (actualización de noviembre de 2024). **Superordenador****País****Sistema****Cores****Rmax****Rpeak****#1 El Capitan**Estados UnidosHPE Cray EX255a, AMD 4th Gen EPYC 24C 1.8GHz, AMD Instinct MI300A, Slingshot-11, TOSS, HPE DOE/NNSA/LLNL11.039.6161.742 PFlops/s2.746,38 PFlops/s**#1 Frontier**Estados UnidosHPE Cray EX235a, AMD Optimized 3rd Generation EPYC 64C 2GHz, AMD Instinct MI250X, Slingshot-11, HPE Cray OS, HPE DOE/SC/Oak Ridge National Laboratory9.066.1761.353 PFlops/s2.055,72 PFlops/s**#3 Aurora**Estados UnidosHPE Cray EX – Intel Exascale Compute Blade, Xeon CPU Max 9470 52C 2.4GHz, Intel Data Center GPU Max, Slingshot-11, Intel DOE/SC/Argonne National Laboratory9.264.1281.012 PFlops/s1.980,01 PFlops/s**#4 Eagle**Estados UnidosMicrosoft NDv5, Xeon Platinum 8480C 48C 2GHz, NVIDIA H100, NVIDIA Infiniband NDR, Microsoft Azure Microsoft Azure2.073.600561,20 PFlops/s846,84 PFlops/s**#5 HPC6**ItaliaHPE Cray EX235a, AMD Optimized 3rd Generation EPYC 64C 2GHz, AMD Instinct MI250X, Slingshot-11, RHEL 8.9, HPE Eni S.p.A.3.143.520477,90 PFlops/s606,97 PFlops/s**#6 Supercomputer Fugaku**JapónSupercomputer Fugaku, A64FX 48C 2.2GHz, Tofu interconnect D, Fujitsu RIKEN Center for Computational Science7.630.848442,01 PFlops/s537,21 PFlops/s**#7 Alps**SuizaHPE Cray EX254n, NVIDIA Grace 72C 3.1GHz, NVIDIA GH200 Superchip, Slingshot-11, HPE Cray OS, HPE Swiss National Supercomputing Centre (CSCS)2.121.600434,90 PFlops/s353,75 PFlops/s**#8 LUMI**FinlandiaHPE Cray EX235a, AMD Optimized 3rd Generation EPYC 64C 2GHz, AMD Instinct MI250X, Slingshot-11, HPE EuroHPC/CSC2.752.704379,70 PFlops/s531,51 PFlops/s**#9 Leonardo**ItaliaBullSequana XH2000, Xeon Platinum 8358 32C 2.6GHz, NVIDIA A100 SXM4 64 GB, Quad-rail NVIDIA HDR100 Infiniband, EVIDEN EuroHPC/CINECA1.824.768241,20 PFlops/s306,31 PFlops/s**#10 Toulumne**Estados UnidosHPE Cray EX255a, AMD 4th Gen EPYC 24C 1.8GHz, AMD Instinct MI300A, Slingshot-11, TOSS, HPE DOE/NNSA/LLNL1.161.216208,10 PFlops/s288,88 PFlops/s España sale del TOP 10 en noviembre de 2024, pero mantiene una posición destacada el **MareNostrum 5 ACC (Accelerated Partition) **con RedHat y un Rmax de 175,30 PFlops/s y Rpeak de 249,44 PFlops/s. ## Evolución del Top 3 de superordenadores desde el 2000 La siguiente tabla recopila la clasificación de los superordenadores que han estado en los tres primeros puestos desde el 2000 hasta el 2024, según la lista TOP500.  **Top 1****Top 2****Top 3****Junio 2000**ASCI Red (Estados Unidos)ASCI Blue-Pacific SST, IBM SP 604e (Estados Unidos)ASCI Blue Mountain (Estados Unidos)**Noviembre 2000**SP Power3 375 MHz 16 way (Estados Unidos)ASCI Red (Estados Unidos)ASCI Blue-Pacific SST, IBM SP 604e (Estados Unidos)**Junio 2001**ASCI White, SP Power3 375 MHz (Estados Unidos)SP Power3 375 MHz 16 way (Estados Unidos)ASCI Red (Estados Unidos)**Noviembre 2001**ASCI White, SP Power3 375 MHz (Estados Unidos)AlphaServer SC45, 1 GHz (Estados Unidos)SP Power3 375 MHz 16 way (Estados Unidos)**Junio 2002**Earth-Simulator (Japón)ASCI White, SP Power3 375 MHz (Estados Unidos)AlphaServer SC45, 1 GHz (Estados Unidos)**Noviembre 2002**Earth-Simulator (Japón)ASCI Q – AlphaServer SC45, 1.25 GHz (Estados Unidos)ASCI White, SP Power3 375 MHz (Estados Unidos)**Junio 2003**Earth-Simulator (Japón)ASCI Q – AlphaServer SC45, 1.25 GHz (Estados Unidos)MRC Linux Cluster Xeon 2.4 GHz – Quadrics (Estados Unidos)**Noviembre 2003**Earth-Simulator (Japón)ASCI Q – AlphaServer SC45, 1.25 GHz (Estados Unidos)X (Estados Unidos)**June 2004**Earth-Simulator (Japón)Thunder (Estados Unidos)ASCI Q – AlphaServer SC45, 1.25 GHz (Estados Unidos)**Noviembre 2004**BlueGene/L beta-System (Estados Unidos)Columbia (Estados Unidos)Earth-Simulator (Japón)**Junio 2005**BlueGene/L (Estados Unidos)BGW (Estados Unidos)Columbia (Estados Unidos)**Noviembre 2005**BlueGene/L (Estados Unidos)BGW (Estados Unidos)ASC Purple (Estados Unidos)**Junio 2006**BlueGene/L (Estados Unidos)BGW (Estados Unidos)ASC Purple (Estados Unidos)**Noviembre 2006**BlueGene/L (Estados Unidos)Red Storm (Estados Unidos)BGW (Estados Unidos)**Junio 2007**BlueGene/L (Estados Unidos)Jaguar (Estados Unidos)Red Storm (Estados Unidos)**Noviembre 2007**BlueGene/L (Estados Unidos)JUGENE (Alemania)SGI Altix ICE 8200 (Estados Unidos)**Junio 2008**Roadrunner (Estados Unidos)BlueGene/L (Estados Unidos)Kraken XT5 (Estados Unidos)**Noviembre 2008**Roadrunner (Estados Unidos)Jaguar (Estados Unidos)Pleiades (Estados Unidos)**Junio 2009**Roadrunner (Estados Unidos)Jaguar (Estados Unidos)JUGENE (Alemania)**Noviembre 2009**Jaguar (Estados Unidos)Roadrunner (Estados Unidos)Kraken XT5 (Estados Unidos)**Junio 2010**Jaguar (Estados Unidos)Nebulae (China)Roadrunner (Estados Unidos)**Noviembre 2010**Tianhe-1A (China)Jaguar (Estados Unidos)Nebulae (China)**2011**K computer (Japón)Tianhe-1A (China)Jaguar (Estados Unidos)**Junio 2012**Sequoia (Estados Unidos)K computer (Japón)Mira (Estados Unidos)**Noviembre 2012**Titan (Estados Unidos)Sequoia (Estados Unidos)K computer (Japón)**2013**Tianhe-2A (China)Titan (Estados Unidos)Sequoia (Estados Unidos)**Junio 2014**Tianhe-2A (China)Titan (Estados Unidos)Sequoia (Estados Unidos)**2015**Tianhe-2A (China)Titan (Estados Unidos)Sequoia (Estados Unidos)**2016**Sunway TaihuLight (China)Tianhe-2A (China)Titan (Estados Unidos)**2017**Sunway TaihuLight (China)Tianhe-2A (China)Piz Daint (Suiza)**Junio 2018**Summit (Estados Unidos)Sunway TaihuLight (China)Sierra (Estados Unidos)**Noviembre 2018**Summit (Estados Unidos)Sierra (Estados Unidos)Sunway TaihuLight (China)**2019**Summit (Estados Unidos)Sierra (Estados Unidos)Sunway TaihuLight (China)**2020**Supercomputer Fugaku (Japón)Summit (Estados Unidos)Sierra (Estados Unidos)**2021**Supercomputer Fugaku (Japón)Summit (Estados Unidos)Sierra (Estados Unidos)**2022**Frontier (Estados Unidos)Supercomputer Fugaku (Japón)LUMI (Finlandia)**Junio 2023**Frontier (Estados Unidos)Supercomputer Fugaku (Japón)LUMI (Finlandia)**November 2023**Frontier (Estados Unidos)Aurora (Estados Unidos)Eagle (Estados Unidos)**Junio 2024**Frontier (Estados Unidos)Frontier (Estados UnidosAurora (Estados Unidos)**Noviembre 2024**El Capitan (Estados Unidos)Frontier (Estados Unidos)Aurora (Estados Unidos) ## Lista de los superordenadores que han ocupado el número 1 La siguiente lista recoge los superordenadores que han estado en el número 1 de la lista TOP500 desde 1993 hasta la fecha. - **CM-5/1024** (Estados Unidos) - **Numerical Wind Tunnel** (Japón) - **XP/S140** (Estados Unidos) - **SR2201/1024** (Japón) - **CP-PACS/2048** (Japón) - **ASCI Red** (Estados Unidos) - **ASCI White, SP Power3 375 MHz** (Estados Unidos) - **Earth-Simulator** (Japón) - **BlueGene/L beta-System** (Estados Unidos) - **BlueGene/L – eServer Blue Gene Solution** (Estados Unidos) - **Roadrunner** (Estados Unidos) - **Jaguar** (Estados Unidos) - **Tianhe-1A** (China) - **K computer** (Japón) - **Sequoia** (Estados Unidos) - **Titan** (Estados Unidos) - **Tianhe-2A** (China) - **Sunway TaihuLight** (China) - **Summit** (Estados Unidos) - **Supercomputer Fugaku** (Japón) - **Frontier** (Estados Unidos)**El Capitan** (Estados Unidos) ## Superordenadores por continente Esta es la distribución por continente de los superordenadores más potentes en la lista TOP500, a fecha de noviembre de 2024: - **Norteamérica**: 181 superordenadores. - **Asia**: 142 superordenadores. - **Europa**: 162 superordenadores. - **Sudamérica**: 10 superordenadores. - **Oceanía**: 4 superordenadores. - **África**: 1 superordenador. ### Estados Unidos: el líder en número de superordenadores Desde noviembre de 2017 a noviembre de 2024, China había dominado en número de superordenadores. Sin embargo, **Estados Unidos se ha convertido en el líder desde el ranking publicado en junio de 2023**. A fecha de noviembre de 2024, EEUU cuenta con 172 superordenadores entre los 500 más potentes del mundo. Le siguen China, con 62 superordenadores, y Alemania, con 41 superordenadores. **Estados Unidos también lidera en rendimiento**, con un Rmax de 6.475.558.900 Gigaflops (GFlops). ** Rmax es el acrónimo de *«Maximal LINPACK performance achieved*» (en español, máximo rendimiento LINPACK conseguido). En lo que se refiere a rendimiento, a EEUU le siguen Japón, con un Rmax de 940.710.340 GFlops, y Italia, con un Rmax de 849.088.330 GFlops. ## Red Española de Supercomputación La Red Española de Supercomputación (RES) cuenta con 14 nodos interconectados**, que en su conjunto exceden los 22 PFlop/s de capacidad de cómputo. Esta red está coordinada por el Barcelona Supercomputing Center (BSC). Su misión es proveer a la comunidad científica de los recursos de computación necesarios para desarrollar proyectos científicos y tecnológicos innovadores y de calidad. Estos son los nodos que forman parte de la RES: Altamira, Caesaraugusta, Caléndula, Cibeles3, FinisTerrae3, LaPalma, Lusitania, MareNostrum 5, Picasso, Pirineus III, Port d’Informació Científica (PIC), Tirant, Urederra, Xula y Turgalium. ### Superordenadores en España **Supeordenador****Centro****Altamira**Instituto de Física de Cantabria de la Universidad de Cantabria**Atlante***Instituto Tecnológico de Canarias**CaesarAugusta**Instituto de Biocomputación y Física de Sistemas Complejos (BIFI) de la Universidad de Zaragoza**Caléndula**Centro de Supercomputación de Castilla y León (SCAYLE)**Cibeles3**Universidad Autónoma de Madrid (UAM)**FinisTerrae3**Fundación Pública Galega Centro Tecnológico de Supercomputación de Galicia (CESGA)**LaPalma**Instituto de Astrofísica de Canarias (IAC)**Lusitania**Centro Extremeño de Investigación, Innovación Tecnológica y Supercomputación (CénitS – COMPUTAEX)**Magerit-3***Centro de Supercomputación y Visualización de Madrid (CeSViMa)**MareNostrum 5**Barcelona Supercomputing Center – Centro Nacional de supercomputación (BSC-CNS)**MinoTauro**Barcelona Supercomputing Center – Centro Nacional de supercomputación (BSC-CNS)**Picasso**Universidad de Málaga (UMA)**Pirineus III**Consorci de Serveis Universitaris de Catalunya (CSUC)**Port d’Informació Científica (PIC)**Port d’Informació Científica (PIC), campus de la Universitat Autònoma de Barcelona.**Teide-HPC***Centro de datos de D-ALiX**Tirant**Universitat de València (UV)**Turgalium**Centro de Investigaciones Energéticas, Medioambientales y Tecnológicas (CIEMAT)**Urederra**Navarra de Servicios y Tecnologías S.A. (Nasertic)**Xula**Centro de Investigaciones Energéticas, Medioambientales y Tecnológicas (CIEMAT) *Los supercomputadores Atlante, Magerit-3 y Teide-HPC no forman parte de la Red Española de Supercomputación. ### Superordenador MareNostrum entre los 10 más potentes del mundo En la lista de noviembre de 2024, uno de los superordenadores españoles salen del los 10 más potentes del mundo. **El supercomputador MareNostrum 5 se encuentra en la posición 11**, con un rendimiento máximo de 138.20 PFlops. En noviembre de 2004, el MareNostrum llegó a estar en el puesto número 4. Fuente: BSC Asimismo, este superordenador es el más potente y emblemático de España. El MareNostrum se usa en diferentes áreas de investigación como el cambio climático, las ondas gravitacionales y el genoma humano, entre otros. Actualmente, ya va por su quinta actualización: el MareNostrum 5 —que ha entrado en operación en 2023—. --- ## What is open source? URL: https://www.stackscale.com/blog/what-is-open-source/ **Open source** refers to a software development model where the source code is publicly available. This means anyone can view, modify, and distribute the code according to the terms of the associated license. Unlike proprietary software, open source enables users to collaborate and improve the program continuously, promoting innovation and transparency. This open philosophy is not limited to software alone; it also applies to areas like hardware and open data. ## **The history of open source** The history of open source began in the 1970s and 1980s with a community of developers who shared software freely before the concept of “proprietary software” became the norm. In 1983, **Richard Stallman launched the GNU Project, aiming to create a completely free operating system**, which laid the foundation for the free software movement and the establishment of the Free Software Foundation (FSF). In **1998**, as projects like Linux gained traction and a term that appealed to both companies and developers was needed, **the concept of “open source” was born**. That same year, the Open Source Initiative (OSI) was founded to regulate open source licenses and promote the adoption of open source software worldwide. Since then, open source has gained popularity, driven by successful projects such as Linux, Apache, Mozilla Firefox, and more recently, Kubernetes and Docker. ## **How does open source development work?** **Open source development is collaborative and decentralized**. Typically, an open source project is hosted on platforms like GitHub, GitLab, or Bitbucket, where developers can contribute code. Many projects have defined roles and structures; for example, “maintainers” are responsible for reviewing and approving code changes, while “contributors” add improvements or fix specific issues. Collaboration in open source projects usually follows a clear structure: developers identify bugs or suggest improvements, propose changes via “pull requests,” and maintainers review and approve (or reject) these contributions. Additionally, many open source projects rely on an active community that engages in forums, chats, and conferences to discuss the project’s direction and objectives. This model allows software to evolve quickly and adapt continuously to users’ needs. ## **Linux and open source** Linux is one of the most iconic and successful examples of open source software. **Created in 1991 by Linus Torvalds, Linux was developed as a free operating system** inspired by UNIX. From its inception, Linux’s code has been available for anyone to use and modify, fostering a large global community of developers and users. Linux is not just an operating system; it serves as the foundation for many modern technologies, from servers and mobile devices to supercomputers and embedded systems. Moreover, Linux has led to a wide variety of Linux distributions (such as Ubuntu, Fedora, and Debian), each tailored for different uses. The Linux community exemplifies the values of open source, where collaboration and continuous improvement are fundamental. ## **Differences between free software, closed source, and open source** - **Free Software:** Defined by the Free Software Foundation (FSF), free software emphasizes users’ freedom to run, study, modify, and distribute the software. Although free software and open source share many similarities, free software focuses more on ethics and user rights. Examples include GNU, LibreOffice, and GIMP. - **Closed Source Software:** Also known as proprietary software, closed source software has source code that is not publicly available. Only the owner or creator has the right to modify or distribute it. Users are limited to using the software according to the terms of a license, with no possibility for customization or improvement. Examples include Microsoft Windows, AutoCAD, Adobe Photoshop, and many commercial applications. - **Open Source:** Although often used interchangeably with free software, open source focuses more on the practical benefits of open code to enhance collaboration and development. Open source does not necessarily mean free of cost, but it does mean the code is accessible. Popular examples include Linux, Mozilla Firefox, and Apache. ## **Advantages of open source** Open source software offers numerous advantages for both users and businesses: - **Transparency and Control:** With access to the source code, users can verify the software’s functionality, eliminating concerns about dishonest practices like spyware or malware. This transparency is crucial for sensitive applications or enterprise environments. - **Reduced Costs:** Open source software is generally free or has very low licensing costs, allowing companies and organizations to access advanced technology without the high expenses associated with proprietary software licenses. - **Flexibility and Customization:** Organizations can tailor open source software to meet their specific needs, which is often not possible with closed-source software. - **Active Community and Support:** Large communities surrounding open source projects generate extensive documentation, tutorials, and support forums. Additionally, users benefit from the collective knowledge of thousands of developers and experts. - **Continuous Improvement and Innovation:** Thanks to contributions from multiple developers and companies, open source software tends to evolve rapidly, adapting to changing market demands and promoting constant innovation that benefits all users. - **Enhanced Security:** Although open source software is accessible to anyone, including potential attackers, it is also continuously reviewed by the community, allowing for the rapid detection and correction of vulnerabilities. This results in more secure and reliable software. In summary, **open source is much more than a development model**; it represents a philosophy of transparency, collaboration, and innovation. With the support of global communities and its growing adoption in business environments, open source continues to play a key role in modern technology, allowing individuals and companies to access powerful, flexible tools to tackle the challenges of the digital age. --- ## ¿Qué es el open source o código abierto? URL: https://www.stackscale.com/blog/what-is-open-source/ El **open source, o código abierto**, se refiere a un modelo de desarrollo de software en el que el código fuente está disponible públicamente. Esto significa que cualquier persona puede ver, modificar y distribuir el código según los términos de la licencia asociada. A diferencia del software propietario, el open source permite a los usuarios colaborar y mejorar el programa de manera continua, promoviendo la innovación y la transparencia. Esta filosofía de apertura no solo se limita al software, sino que también se aplica en áreas como el hardware y los datos abiertos. ## **La historia del open source** La historia del open source comienza en los años 70 y 80, con la comunidad de desarrolladores que compartía software libremente antes de que el concepto de “software propietario” se convirtiera en la norma. En 1983, **Richard Stallman lanzó el proyecto GNU con el objetivo de crear un sistema operativo completamente libre**, una iniciativa que dio origen al movimiento del software libre y a la Fundación para el Software Libre (FSF). En **1998**, con el crecimiento de proyectos como Linux y la necesidad de un término que fuera aceptable para empresas y desarrolladores por igual, **nació el concepto de “open source” o código abierto**. Ese mismo año, se fundó la Open Source Initiative (OSI), organización que regula las licencias de open source y promueve la adopción del software de código abierto en todo el mundo. Desde entonces, el open source ha ganado popularidad, impulsado por proyectos exitosos como Linux, Apache, Mozilla Firefox, y, en tiempos recientes, Kubernetes y Docker. ## **¿Cómo funciona el desarrollo del open source?** El **desarrollo de open source es colaborativo y descentralizado**. Normalmente, un proyecto open source tiene un repositorio en plataformas como GitHub, GitLab o Bitbucket, donde los desarrolladores pueden contribuir al código. Existen roles y estructuras definidas en muchos proyectos; por ejemplo, los “maintainers” o mantenedores son responsables de revisar y aprobar los cambios en el código, mientras que los “contributors” aportan mejoras o soluciones a problemas específicos. La colaboración en open source suele seguir una estructura clara: los desarrolladores detectan errores o sugieren mejoras, proponen cambios mediante “pull requests”, y los mantenedores revisan y aprueban (o rechazan) dichas contribuciones. Además, muchos proyectos open source dependen de una comunidad activa que se involucra en foros, chats y conferencias para discutir el rumbo y los objetivos del proyecto. Este modelo permite que el software evolucione rápidamente y que se adapte a las necesidades de los usuarios de forma continua. ## **Linux y el open source** Linux es uno de los ejemplos más icónicos y exitosos de software open source. **Creado en 1991 por Linus Torvalds, Linux se desarrolló como un sistema operativo libre**, inspirado en el sistema UNIX. Desde sus inicios, el código de Linux ha estado disponible para que cualquiera lo use y modifique, lo que ha fomentado una gran comunidad de desarrolladores y usuarios en todo el mundo. Linux no solo es un sistema operativo, sino que es la base de muchas tecnologías modernas, desde servidores y dispositivos móviles hasta supercomputadoras y sistemas embebidos. Además, Linux ha dado lugar a una amplia variedad de distribuciones Linux (como Ubuntu, Fedora y Debian), cada una con características específicas para distintos usos. La comunidad de Linux ejemplifica los valores del open source, donde la colaboración y la mejora continua son fundamentales. ## **Diferencias entre el software libre, de código cerrado y open source** - **Software libre**: El software libre, según la definición de la Free Software Foundation (FSF), se refiere a la libertad de los usuarios para ejecutar, estudiar, modificar y distribuir el software. Aunque el software libre y el open source comparten muchas similitudes, el software libre se enfoca más en la ética y los derechos de los usuarios. Ejemplos de software libre incluyen GNU, LibreOffice y GIMP. - **Software de código cerrado**: También conocido como software propietario, el software de código cerrado es aquel cuyo código fuente no está disponible para el público. Esto significa que solo el propietario o creador del software tiene derecho a modificarlo o distribuirlo. Los usuarios están limitados a utilizar el software según los términos de una licencia, sin posibilidad de personalización o mejora. Ejemplos de software propietario incluyen Microsoft Windows, Adobe Photoshop, AutoCAD y muchas aplicaciones comerciales. - **Open source**: Aunque a menudo se usa como sinónimo de software libre, el open source se enfoca más en los beneficios prácticos de la apertura del código para mejorar la colaboración y el desarrollo. El open source no necesariamente requiere que el software sea gratuito, pero sí que su código sea accesible. Ejemplos populares incluyen Linux, Mozilla Firefox y Apache. ## **Ventajas del open source** El software open source ofrece múltiples ventajas tanto para usuarios como para empresas: - **Transparencia y control**: Al tener acceso al código fuente, los usuarios pueden verificar el funcionamiento del software, eliminando posibles sospechas de prácticas deshonestas, como el espionaje o la inclusión de software malicioso. Esto es crucial en aplicaciones sensibles o en entornos empresariales. - **Costos reducidos**: En general, el software open source es gratuito o tiene costos de licencia muy bajos. Esto permite a empresas y organizaciones acceder a tecnología avanzada sin los altos costos asociados a licencias de software propietario. - **Flexibilidad y personalización**: Las organizaciones pueden adaptar el software open source para que se ajuste a sus necesidades específicas, lo que no es posible en la mayoría de los casos con software de código cerrado. - **Comunidad activa y soporte**: Las grandes comunidades en torno a los proyectos de open source generan abundante documentación, tutoriales y foros de soporte. Además, los usuarios pueden beneficiarse del conocimiento colectivo de miles de desarrolladores y expertos. - **Mejora continua e innovación**: Gracias a la colaboración de múltiples desarrolladores y empresas, el software open source tiende a evolucionar rápidamente y a adaptarse a las necesidades cambiantes del mercado. Esto promueve una innovación constante que beneficia a todos los usuarios. - **Seguridad mejorada**: Aunque el software open source es accesible para cualquiera, incluyendo posibles atacantes, también es revisado constantemente por la comunidad, lo que permite una rápida detección y corrección de vulnerabilidades. Esto resulta en un software más seguro y confiable. En resumen, el **open source es mucho más que un modelo de desarrollo**; representa una filosofía de transparencia, colaboración e innovación. Gracias al apoyo de comunidades globales y a su creciente adopción en entornos empresariales, el open source continúa desempeñando un papel clave en la tecnología moderna, permitiendo que individuos y empresas accedan a herramientas potentes y flexibles para enfrentar los retos de la era digital. --- ## One Hundred Years of Radio Time Signals: The Legacy of “PIPs” in Technological Evolution URL: https://www.stackscale.com/blog/radio-time-signals-pips/ In a world where technology is advancing by leaps and bounds, few systems have been around as long as the **Greenwich Time Signal (GTS**) and popularly **known as “the PIPs” of radio**. This system, which marks time accurately through a series of beeps, celebrates one hundred years of existence. Since its introduction in the 1920s, the time signals have evolved along with technological advances, becoming a symbol of accuracy and reliability. ## Table of contents - The origin of “PIP”: Precise time stamping - How do the time signals work? Structure of time signals - Technological evolution of “PIPs - A cultural and technological legacy - The future of time signals in the digital era - Time signals in other parts of the world - Who keeps the Internet clocks on time? - Conclusion: A Century of Accuracy and Reliability ## **The origin of “PIP”: Precise time stamping** The history of time signals, popularly known as **“PIPs” or “the PIPs”,** began in 1924, when the **British Broadcasting Corporation (BBC)** implemented a system to provide accurate time to its listeners. At a time when radio was consolidating its position as the primary means of mass communication, time accuracy became a fundamental necessity. To this end, the BBC collaborated with the **Royal Observatory at Greenwich**, the world reference for the Greenwich Meridian (GMT), to create a system that would meet this demand. The “PIPs” consisted of a series of six beeps, emitted in the five seconds before the time and at the start of the new time. Each beep is a 1 kHz tone, with the first five lasting a tenth of a second, and the sixth, longer one lasting half a second. The last beep is the one that marks the exact moment when the time changes. This system not only provided an accurate time reference, but also unified the listeners, allowing them to be synchronized at the same instant, regardless of their geographic location. The **creation of the “PIPs” was the idea of the Astronomer Royal, Sir Frank Watson Dyson, and the then director of the BBC, John Reith, who commissioned Marconi/Siemens to develop the system.** Harry Lampen Edwards, a young 18-year-old engineer, was commissioned to build the mechanism in conjunction with Greenwich Observatory. Initially, the “PIPs” were controlled by two mechanical clocks at the observatory that sent a signal every second to the BBC, converting it into the tone that was transmitted. *Greenwich Time Signal (1970). Image Wikipedia. In 1957, the Royal Observatory at Greenwich moved to Herstmonceux Castle and the **Greenwich Time Signal** equipment was modernized with an electronic clock, which improved its reliability. This technological evolution guaranteed the continuity of the service, even in the event of failures, by means of leased lines that ensured the transmission of signals to the BBC. Interestingly, the time signal was the first sound heard during the handover ceremony to the London 2012 Olympic Games, at the closing of the Beijing 2008 Games. Also, on the 90th anniversary of the “PIPs”, the BBC’s Today* program performed a special version of “Happy Birthday” using the time signal as the basis. This time signal system has endured for nearly a century and, although technology has advanced, “PIPs” remain a symbol of the importance of time accuracy in broadcasting. ## **How do the time signals work?** The operation of time signals is based on the precision of master clocks. Originally, these clocks were based on astronomical observation, but over time, they were replaced by quartz clocks and, more recently, by atomic clocks, which offer unprecedented accuracy. When signals are broadcast over the radio, they are designed to reach listeners exactly the second the new time starts. Although analog radio transmits these signals almost instantly, digital transmissions and the Internet can introduce a slight delay, which poses a challenge today. ### **Structure of time signals** This time signal or **“PIP”** consists of six short beeps that occur in the five seconds preceding the exact time and during the beginning of the new period. Each beep is a 1 kHz tone, with a specific duration: the first five beeps last for one tenth of a second, while the last one lasts for half a second. The exact moment when the time changes is marked by the last beep. On exceptional occasions, such as when a **leap second** is added just before midnight, a seventh beep is emitted. In this case, the first beep is heard at 23:59:55, followed by the sixth short beep at 23:59:60, before the long beep marking 00:00:00. This phenomenon explains why the last beep is longer than the others. In addition, although these signals are primarily associated with the hour on the hour, they are also broadcast at the 15th, 30th and 45th minutes of each hour, providing listeners with accurate synchronization at multiple times of the day. ## **Technological evolution of “PIPs** Over the years, **time signals have evolved from a simple time reference to a symbol of stability**. As technology has evolved, so have the methods for generating and transmitting the signals. With the advent of atomic clocks, accuracy increased, allowing radio stations to provide more accurate time signals. With the digitization of radio and the growing popularity of Internet broadcasting, the challenge has been to maintain that accuracy in an environment where transmission times can vary. However, time signals remain critical in systems that require precise timing, such as financial systems and aviation services. ## **A cultural and technological legacy** Beyond their technical function, time signals have left a mark on popular culture. For decades, listeners to the BBC and other **broadcasters around the world have relied on “PIPs” to tell the exact time**. For many, listening to the beeps on the radio is a daily ritual that evokes a sense of order and reliability. Even in times of crisis or change, the time signals have remained a symbol of continuity. In the technological realm, time signals have served as an example of how a seemingly simple technology can evolve and adapt over the years. Although transmission methods have changed, the original purpose of “PIPs” remains the same: to provide an accurate and accessible time reference. ## **The future of time signals in the digital era** With the advancement of digital technologies and the increasing adoption of online services, some experts have raised the possibility that time signals may become less relevant in digital media. However, they remain a key tool in industries where accuracy is vital. **Time signal-based systems still play a crucial role in industries such as shipping, aviation and financial services**. In addition, time signals continue to be used by broadcasters around the world, from local radio stations to international broadcasts. Although new challenges may arise in the digital age, time signals are likely to continue to evolve to keep up with technological and social demands. ## **Time signals in other parts of the world** Over the decades, time signals have become a reference used by broadcasters around the world, **adopting variants of the BBC’s Greenwich Time Signal (GTS) or similar systems**. These signals mark the start of the hour with different tones or frequencies, and although the format may vary between countries and broadcasters, their purpose is always the same: to provide listeners with an accurate time reference. In many cases, both public and commercial broadcasters have adapted the BBC’s six-tone system, while others have shortened the number of beeps to five, four or even three. Here are some examples of how time signals are used in different parts of the world: - **Argentina**: News and talk stations, such as Radio Nacional, Radio Mitre, and Radio Continental, broadcast six beeps every hour, similar to those of the BBC, and three beeps on the half hour, in a tradition reminiscent of that employed in Catalonia. - **Australia**: ABC Radio National and ABC Local Radio broadcast six-tone hourly time signals at 735 Hz, each lasting half a second, followed by half a second of silence. - **Brazil**: Some news stations such as Radio Bandeirantes or Radio Guaíba broadcast hourly signals every 15 minutes, with five or four beeps, respectively. - **Canada**: Until October 2023, the National Research Council of Canada’s Time Signal Service broadcast a daily signal at 12:00 on Radio-Canada Première and at 13:00 on CBC Radio One, the longest running time signal in the country. - **China**: National radio stations emit five short beeps of 800 Hz followed by a longer beep of 1600 Hz to mark the start of the new time. - **France**: France Inter broadcasts four beeps every hour, the last one marking the time o’clock, while some local stations of the France Bleu network also transmit time signals. - **Germany**: Deutschlandfunk broadcasts three beeps every hour, the last one being the longest. On weekdays, they broadcast hourly signals every half hour between 05:00 and 18:00. - **Israel**: The public radio station broadcasts five tones to count down the seconds before the hour, accompanied by a jingle that ends with the station’s sound identification “Kan”. - **Italy**: RAI stations use six tones to mark the exact time, with a variation between Radio 1, Radio 2 and Radio 3 in terms of time and frequency of broadcast. - **Japan**: NHK used to broadcast three short beeps followed by a longer beep just before the start of news programs. - **New Zealand**: RNZ National uses six beeps every hour, plus a birdsong sound before the 07:00 and 09:00 news. - **Spain**: Almost all stations, both music and non-music, broadcast time signals. Some stations, such as Los 40 Principales, customize the beeps with musical effects to create a corporate jingle. This diversity of systems around the world demonstrates how the original idea of the GTS has been adapted to local needs, while maintaining the same objective: to offer listeners a reliable tool to synchronize with the exact time, no matter where they are. ## **Who keeps the Internet clocks on time?** Time synchronization on the Internet is crucial for the functioning of the network, and this is achieved thanks to systems based on **atomic clocks**. One of the pioneers in this field is physicist **Judah Levine**, who in 1993 implemented the time distribution service on **time.gov**, allowing precise time synchronization on Internet-connected devices. The **Network Time Protocol (NTP)**, designed in 1985 by **David L. Mills**, is the oldest active protocol that manages this synchronization, used in millions of devices. In addition, **NIST** is in charge of maintaining the “official time” by means of atomic clocks that guarantee incredible precision: they only gain or lose one second every 300 million years. This system responds to more than **150,000 queries per second**, which equates to about **16 billion queries per day**. To handle this enormous demand, services such as **Pool NTP** help distribute the load among more than **4,000 servers** worldwide, ensuring that all devices can be kept in sync as accurately as possible. ## **Conclusion: A Century of Accuracy and Reliability** Radio time signals are celebrating one hundred years of accurate timekeeping, having become an essential part of the radio experience. What began as a simple technical necessity to synchronize listeners in 1924 has evolved into a symbol of accuracy and technological tradition. In an ever-changing world, **“PIPs”** remain a reminder that some technological solutions, however simple they may seem, can endure over time, adapting without losing their essence. This legacy, which combines both technology and culture, is proof of how seemingly simple advances can have a lasting impact. Over the course of a century, time signals have not only set the pace of everyday life, but have also accompanied technological progress, proving that in a fast-paced world, **accuracy and reliability** remain invaluable. Today, while atomic clocks and protocols such as **NTP (Network Time Protocol)** ensure accurate time on the Internet, the tradition of synchronizing time remains essential. **NIST** and servers such as **time.gov** are responsible for keeping network clocks synchronized with maximum accuracy, thanks to ingenious systems connected to atomic clocks. Like radio time signals, these advances continue to ensure that **accurate time** remains a constant in our digital lives, proving that time synchronization, whether via radio waves or the Internet, remains a fundamental pillar of technological evolution. References: Wikipedia, Curious Minds and The Pip. --- ## Cien años de señales horarias en la radio: El legado de los “PIP” en la evolución tecnológica URL: https://www.stackscale.com/blog/radio-time-signals-pips/ En un mundo donde la tecnología avanza a pasos agigantados, pocos sistemas han logrado mantenerse vigentes durante tanto tiempo como las señales horarias, el **Greenwich Time Signal (GTS**) y popularmente **conocidas como “the PIPs” (los pitidos) de la radio**. Este sistema, que marca el tiempo de forma precisa a través de una serie de pitidos, celebra cien años de existencia. Desde su introducción en la década de 1920, las señales horarias han evolucionado junto a los avances tecnológicos, convirtiéndose en un símbolo de exactitud y fiabilidad. ## Tabla de contenidos - El origen de los “PIP”: Marcar la hora con precisión - ¿Cómo funcionan las señales horarias? Estructura de las señales horarias - La evolución tecnológica de los “PIP” - Un legado cultural y tecnológico - El futuro de las señales horarias en la era digital - Señales horarias en otros lugares del mundo - ¿Quién mantiene los relojes de Internet en hora? - Conclusión: Un siglo de precisión y confiabilidad ## **El origen de los “PIP”: Marcar la hora con precisión** La historia de las señales horarias, popularmente conocidas como **“PIP” o “the PIPs”**, comienza en 1924, cuando la **British Broadcasting Corporation (BBC)** implementó un sistema para ofrecer la hora exacta a sus oyentes. En una época en la que la radio se consolidaba como el principal medio de comunicación masiva, la precisión temporal se convirtió en una necesidad fundamental. Para ello, la BBC colaboró con el **Real Observatorio de Greenwich**, la referencia mundial del Meridiano de Greenwich (GMT), para crear un sistema que cumpliera con esta demanda. Los “PIP” consistían en una serie de seis pitidos, emitidos en los cinco segundos anteriores a la hora y al inicio de la nueva hora. Cada pitido es un tono de 1 kHz, donde los primeros cinco tienen una duración de una décima de segundo, y el sexto, más largo, dura medio segundo. El último pitido es el que marca el momento exacto en el que la hora cambia. Este sistema no solo ofrecía una referencia temporal precisa, sino que unificaba a los oyentes, permitiéndoles estar sincronizados en un mismo instante, sin importar su ubicación geográfica. La **creación de los “PIP” fue idea del Astrónomo Real, Sir Frank Watson Dyson, y del entonces director de la BBC, John Reith, quienes encargaron a Marconi/Siemens el desarrollo del sistema**. Harry Lampen Edwards, un joven ingeniero de 18 años, fue el encargado de construir el mecanismo junto con el Observatorio de Greenwich. Inicialmente, los “PIP” estaban controlados por dos relojes mecánicos del observatorio que enviaban una señal cada segundo a la BBC, convirtiéndola en el tono que se transmitía. *Greenwich Time Signal (1970). Imagen Wikipedia. En 1957, el Real Observatorio de Greenwich se trasladó al Castillo de Herstmonceux y el equipo del **Greenwich Time Signal** se modernizó con un reloj electrónico, lo que mejoró su fiabilidad. Esta evolución tecnológica garantizó la continuidad del servicio, incluso en caso de fallos, mediante líneas alquiladas que aseguraban la transmisión de las señales a la BBC. Curiosamente, la señal horaria fue el primer sonido que se escuchó durante la ceremonia de traspaso a los Juegos Olímpicos de Londres 2012, en la clausura de los Juegos de Beijing 2008. Además, en el 90.º aniversario de los “PIP”, el programa Today* de la BBC realizó una versión especial de “Happy Birthday” utilizando la señal horaria como base. Este sistema de señal horaria ha perdurado durante casi un siglo y, aunque la tecnología ha avanzado, los “PIP” siguen siendo un símbolo de la importancia de la precisión horaria en la radiodifusión. ## **¿Cómo funcionan las señales horarias?** El funcionamiento de las señales horarias está basado en la precisión de los relojes maestros. Originalmente, estos relojes se basaban en la observación astronómica, pero con el tiempo, fueron reemplazados por relojes de cuarzo y, más recientemente, por relojes atómicos, que ofrecen una precisión sin precedentes. Cuando las señales se emiten por radio, están diseñadas para llegar a los oyentes exactamente en el segundo en que comienza la nueva hora. Aunque la radio analógica transmite estas señales casi al instante, las transmisiones digitales e internet pueden introducir un pequeño retraso, lo que plantea un reto en la actualidad. ### **Estructura de las señales horarias** Esta señal horaria o **“PIP”** consiste en seis pitidos breves que ocurren en los cinco segundos anteriores a la hora exacta y durante el inicio del nuevo periodo. Cada pitido es un tono de 1 kHz, con una duración específica: los cinco primeros pitidos duran una décima de segundo, mientras que el último se extiende por medio segundo. El momento exacto en que cambia la hora es marcado por el último pitido. En ocasiones excepcionales, como cuando se añade un **segundo intercalar** justo antes de la medianoche, se emite un séptimo pitido. En este caso, el primer pitido se escucha a las 23:59:55, seguido del sexto pitido corto a las 23:59:60, antes del pitido largo que marca las 00:00:00. Este fenómeno explica por qué el último pitido es más largo que los demás. Además, aunque estas señales se asocian principalmente con la hora en punto, también se emiten en los minutos 15, 30 y 45 de cada hora, facilitando a los oyentes una sincronización precisa en múltiples momentos del día. ## **La evolución tecnológica de los “PIP”** A lo largo de los años, las **señales horarias han pasado de ser una simple referencia temporal a convertirse en un símbolo de estabilidad**. A medida que la tecnología ha evolucionado, también lo han hecho los métodos para generar y transmitir las señales. Con la llegada de los relojes atómicos, la precisión se incrementó, permitiendo a las estaciones de radio ofrecer señales horarias más exactas. Con la digitalización de la radio y la creciente popularidad de las transmisiones por internet, el reto ha sido mantener esa precisión en un entorno donde los tiempos de transmisión pueden variar. Sin embargo, las señales horarias siguen siendo fundamentales en sistemas que requieren sincronización precisa, como los sistemas financieros y los servicios de aviación. ## **Un legado cultural y tecnológico** Más allá de su función técnica, las señales horarias han dejado una huella en la cultura popular. Durante décadas, los oyentes de la BBC y otras **emisoras de todo el mundo han confiado en los “PIP” para saber la hora exacta**. Para muchos, escuchar los pitidos en la radio es un ritual cotidiano que evoca una sensación de orden y fiabilidad. Incluso en tiempos de crisis o cambio, las señales horarias se han mantenido como un símbolo de continuidad. En el ámbito tecnológico, las señales horarias han servido como un ejemplo de cómo una tecnología aparentemente simple puede evolucionar y adaptarse a lo largo de los años. Aunque los métodos de transmisión han cambiado, el propósito original de los “PIP” sigue siendo el mismo: proporcionar una referencia temporal precisa y accesible. ## **El futuro de las señales horarias en la era digital** Con el avance de las tecnologías digitales y la creciente adopción de servicios en línea, algunos expertos han planteado la posibilidad de que las señales horarias pierdan relevancia en los medios digitales. No obstante, siguen siendo una herramienta clave en sectores donde la precisión es vital. **Los sistemas basados en señales horarias aún juegan un papel crucial en industrias como la navegación, la aviación y los servicios financieros**. Además, las señales horarias continúan siendo utilizadas en emisoras de todo el mundo, desde estaciones de radio locales hasta transmisiones internacionales. Aunque puedan aparecer nuevos retos en la era digital, es probable que las señales horarias sigan evolucionando para mantenerse al día con las demandas tecnológicas y sociales. ## **Señales horarias en otros lugares del mundo** A lo largo de las décadas, las señales horarias se han convertido en una referencia utilizada por emisoras de todo el mundo, **adoptando variantes del Greenwich Time Signal (GTS) de la BBC o sistemas similares**. Estas señales marcan el inicio de la hora con diferentes tonalidades o frecuencias, y aunque el formato puede variar entre países y emisoras, su propósito es siempre el mismo: proporcionar a los oyentes una referencia precisa del tiempo. En muchos casos, emisoras tanto públicas como comerciales han adaptado el sistema de seis tonos de la BBC, mientras que otras han acortado el número de pitidos a cinco, cuatro o incluso tres. A continuación, algunos ejemplos de cómo se utilizan las señales horarias en diferentes partes del mundo: - **Argentina**: Las emisoras de noticias y conversación, como Radio Nacional, Radio Mitre, y Radio Continental, emiten seis pitidos cada hora, similares a los de la BBC, y tres pitidos a la media hora, en una tradición que recuerda a la empleada en Cataluña. - **Australia**: La ABC Radio National y ABC Local Radio emiten señales horarias de seis tonos cada hora, siendo estas de 735 Hz y con una duración de medio segundo cada una, seguidas de medio segundo de silencio. - **Brasil**: Algunas emisoras de noticias como Radio Bandeirantes o Radio Guaíba emiten señales horarias cada 15 minutos, con cinco o cuatro pitidos, respectivamente. - **Canadá**: Hasta octubre de 2023, el Servicio de Señal Horaria del Consejo Nacional de Investigación de Canadá emitía una señal diaria a las 12:00 en Radio-Canada Première y a las 13:00 en CBC Radio One, siendo la señal horaria de mayor duración en el país. - **China**: Las emisoras de radio nacionales emiten cinco pitidos cortos de 800 Hz seguidos de un pitido más largo de 1600 Hz para marcar el inicio de la nueva hora. - **Francia**: La emisora France Inter emite cuatro pitidos cada hora, siendo el último el que marca la hora en punto, mientras que algunas emisoras locales de la red France Bleu también transmiten señales horarias. - **Alemania**: Deutschlandfunk emite tres pitidos cada hora, siendo el último más largo. Entre semana, emiten señales horarias cada media hora entre las 05:00 y las 18:00. - **Israel**: La emisora pública de radio emite cinco tonos para contar los segundos antes de la hora, acompañados de un jingle que finaliza con la identificación sonora de la emisora “Kan”. - **Italia**: Las estaciones de la RAI utilizan seis tonos para marcar la hora exacta, con una variación entre Radio 1, Radio 2 y Radio 3 en cuanto a la hora y frecuencia de emisión. - **Japón**: La NHK solía emitir tres pitidos cortos seguidos de un pitido más largo justo antes del comienzo de los programas de noticias. - **Nueva Zelanda**: RNZ National utiliza seis pitidos cada hora, y además un sonido de canto de pájaros antes de las noticias de las 07:00 y las 09:00. - **España**: Casi todas las emisoras, tanto musicales como no musicales, emiten señales horarias. Algunas emisoras, como Los 40 Principales, personalizan los pitidos con efectos musicales para crear un jingle corporativo. Esta diversidad de sistemas en todo el mundo demuestra cómo la idea original del GTS se ha adaptado a las necesidades locales, manteniendo siempre el mismo objetivo: ofrecer a los oyentes una herramienta confiable para sincronizarse con la hora exacta, sin importar dónde se encuentren. ## **¿Quién mantiene los relojes de Internet en hora?** La sincronización de la hora en Internet es crucial para el funcionamiento de la red, y esto se logra gracias a sistemas basados en **relojes atómicos**. Uno de los pioneros en este campo es el físico **Judah Levine**, quien en 1993 implementó el servicio de distribución horaria en **time.gov**, permitiendo sincronizar la hora de manera precisa en dispositivos conectados a Internet. El **Network Time Protocol (NTP)**, diseñado en 1985 por **David L. Mills**, es el protocolo más antiguo en activo que gestiona esta sincronización, utilizado en millones de dispositivos. Además, el **NIST** es el encargado de mantener la “hora oficial” mediante relojes atómicos que garantizan una precisión increíble: solo ganan o pierden un segundo cada 300 millones de años. Este sistema responde a más de **150.000 consultas por segundo**, lo que equivale a unos **16 mil millones de consultas diarias**. Para manejar esta enorme demanda, servicios como **Pool NTP** ayudan a distribuir la carga entre más de **4.000 servidores** a nivel mundial, garantizando que todos los dispositivos puedan mantenerse sincronizados con la máxima precisión posible. ## **Conclusión: Un siglo de precisión y confiabilidad** Las señales horarias en la radio celebran cien años de marcar el tiempo con precisión, habiéndose convertido en una parte esencial de la experiencia radiofónica. Lo que comenzó como una simple necesidad técnica para sincronizar a los oyentes en 1924, ha evolucionado hasta convertirse en un símbolo de exactitud y tradición tecnológica. En un mundo en constante transformación, los **“PIP”** siguen siendo un recordatorio de que algunas soluciones tecnológicas, por simples que parezcan, pueden perdurar a lo largo del tiempo, adaptándose sin perder su esencia. Este legado, que combina tanto tecnología como cultura, es una prueba de cómo los avances aparentemente sencillos pueden tener un impacto duradero. A lo largo de un siglo, las señales horarias no solo han marcado el ritmo de la vida cotidiana, sino que también han acompañado el progreso tecnológico, demostrando que en un mundo que avanza a un ritmo vertiginoso, la **precisión y la fiabilidad** siguen siendo invaluables. Hoy en día, mientras los relojes atómicos y protocolos como el **NTP (Network Time Protocol)** garantizan la precisión de la hora en Internet, la tradición de sincronizar el tiempo sigue siendo esencial. El **NIST** y servidores como **time.gov** se encargan de mantener los relojes de la red sincronizados con la máxima exactitud, gracias a ingeniosos sistemas conectados a relojes atómicos. Al igual que las señales horarias de la radio, estos avances continúan garantizando que la **hora exacta** siga siendo una constante en nuestras vidas digitales, demostrando que la sincronización del tiempo, ya sea a través de ondas de radio o de Internet, sigue siendo un pilar fundamental en la evolución tecnológica. Referencias: Wikipedia, Mentes Curiosas y The Pip. --- ## 39 popular Linux distributions URL: https://www.stackscale.com/blog/popular-linux-distributions/ In the following list, we have gathered **some of the most popular Linux distributions** and some growing distros too. GNU/Linux operating systems are Unix-like and open source, and based on the Linux kernel. **Among the long list of Linux distributions, there are a number of distros that clearly stand out among the others** — in terms of number of users, community, features, etc. Discover some details about some of the top Linux distributions. ## Ubuntu **Ubuntu** is a Linux distribution based on Debian. It is developed by Canonical and a community of developers. It has 3 official editions: *Desktop*, *Server* and *Core*, which can either run on a computer or on a VM. More than 34% of the websites using Linux use Ubuntu, according to W3Techs data. Its growth since 2010 has been amazing. It is also a popular distribution among cloud computing projects. **Ubuntu License**: GPL and other licenses. **Latest LTS release (September 2026)**: Ubuntu 26.04 LTS “Resolute Raccoon”, released on 23 April 2026. Ubuntu 24.04 LTS remains supported until May 2029. ## Debian **Debian** is an open source operating system. This distribution was first announced by Ian Murdock in 1993 as the “Debian Linux Release”. The Debian Project is a community of developers and users that maintain the GNU OS based on open source software. Currently, Debian systems use the Linux kernel or the FreeBSD kernel. However, they are also working on providing Debian for other kernels. Primarily, GNU Hurd. **Debian License**: BSD, GPL and other open licenses. **Latest release (September 2026)**: Debian 13 “Trixie”, released on 9 August 2025; current point release 13.6. ## CentOS Linux **CentOS Linux** is a distribution based on the source code of the commercial distribution Red Hat Enterprise Linux (RHEL). It was launched in 2004 and is backed up by a growing community. It is a safe bet for those looking for high-quality code. But CentOS 8 will be its last version. In 2019, Red Hat announced that CentOS Linux would be replaced by CentOS Stream — an upstream development platform for RHEL. New open source alternatives have appeared due to this change of strategy. For instance, Rocky Linux, founded by Gregory Kurtzer, founder of the CentOS project. **CentOS Linux License**: GNU GPL. **Discontinued project**: CentOS Linux 8 reached end of life on 31 December 2021 and CentOS Linux 7 on 30 June 2024. There is no successor under that name — the alternatives are AlmaLinux, Rocky Linux or CentOS Stream. ## CentOS Stream **CentOS Stream** is an upstream development platform for Red Hat Enterprise Linux (RHEL). It is a midstream between Fedora Linux and RHEL. This platform aims to take advantage of open-source innovation for shaping upcoming stable RHEL releases. **CentOS Stream License**: GNU GPL. **Latest release (September 2026)**: CentOS Stream 10, released on 12 December 2024 and supported until May 2030. CentOS Stream 9 is supported until May 2027. ## Red Hat Enterprise Linux (RHEL) **Red Hat Enterprise Linux** (RHEL) is a commercial Linux distribution developed by Red Hat. It has a server version and a desktop version. As it uses open source software, published under a General Public License, they make their code available to the public via CentOS. Red Hat has sponsored the CentOS project since 2014. **RHEL License**: GPL. **Latest release (September 2026)**: RHEL 10, released on 20 May 2025; current minor releases are 10.2 and 9.8. ## Gentoo **Gentoo** is a Linux distribution that features a rolling release model. Gentoo Linux was originally created by Daniel Robbins. It was named after the fast-swimming “gentoo penguin”, to reflect its potential. It is an attractive choice for Linux users looking for full control of the software. Gentoo users have great control over the services installed and running on their computer. They can immensely customize and optimize their system. **Gentoo License**: Free software. **Gentoo Releases**: rolling release. ## Fedora **Fedora** is a Linux distribution developed by the Fedora Project — sponsored mainly by Red Hat, with support from other companies. It is developed and maintained by the community and it is an upstream source of the commercial RHEL distribution. Fedora usually has more modern software versions, considered as “non stable”, that are later included in RHEL. There are different Fedora editions available: *Workstation*, *Server*, *CoreOS*, *Silverblue* and *IoT*. Fedora Linux was launched in 2003. **Fedora License**: GPL and other licenses. **Latest release (September 2026)**: Fedora Linux 44, released on 28 April 2026. ## OpenSUSE **OpenSUSE** is a Linux distribution sponsored by SUSE Software Solutions Germany GmbH and other companies. It was formerly known as SUSE Linux. OpenSUSE has a rolling release version, Tumbleweed, and a regular release version, Leap. **OpenSUSE License**: GNU GPL and other licenses. **Latest release (September 2026)**: openSUSE Leap 16.0, released on 1 October 2025. ## Scientific Linux **Scientific Linux** is another Linux distribution based on RHEL’s free and open source software. It is produced by Fermilab, CERN, DESY and ETH Zurich. In April 2019, they announced its discontinuation. Nevertheless, its last version, Scientific Linux 7, will have maintenance updates until June 2024. **Scientific Linux License**: GNU GPL and other licenses. **Discontinued project**: Scientific Linux 7 reached end of life on 30 June 2024. Fermilab recommends migrating to AlmaLinux or CentOS Stream. ## CloudLinux **CloudLinux** is a Linux distribution developed by CloudLinux, Inc. It is based on CentOS and uses the OpenVZ kernel and the RPM Package Manager. It is targeted to shared hosting providers and data centers. It stands out for improving server stability, density and security. The first version of CloudLinux OS was released in 2010. **Latest release (September 2026)**: CloudLinux OS 10.2, released on 26 May 2026. From the 10 series onwards it is installed on top of AlmaLinux using *cldeploy*, with no installation image of its own. ## Elementary OS **Elementary OS** is a Linux distribution based on Ubuntu. The OS is developed and maintained by Elementary, Inc. It aims to be a fast, open and privacy-respecting alternative to Windows and MacOS. It features a pay-what-you-want (PWYW) model. **Elementary OS License**: GNU GPL and other licenses. **Latest release (September 2026)**: elementary OS 8.1.1 “Circe”, released on 27 February 2026. ## Linux Mint **Linux Mint** is a community-driven Linux distribution based on Ubuntu. This distribution started in 2006. The Linux Mint project was initially created by Clément Lefèbvre. Linux Mint OS’ source code is available on GitHub. Most of the OS development is done in Python.  **Linux Mint License**: GPL. **Latest release (September 2026)**: Linux Mint 22.3 “Zena”, released on 11 January 2026 and supported until April 2029. ## Arch Linux **Arch Linux** is a Linux distribution based on 5 principles: simplicity, modernity, pragmatism, user centrality and versatility. It features a rolling release model. **Arch Linux License**: GNU GPL and other licenses. **Arch Linux Release**: rolling release. ## Manjaro **Manjaro**** **is a free Linux distribution based on Arch Linux. It is specially focused on accessibility and user-friendliness. It features a rolling release model. Its simplicity, stability and performance makes it a suitable alternative OS to MacOS and Windows. It offers multiple desktop environments. **Manjaro License**: GPL and other open licenses. **Latest release (September 2026)**: Manjaro 26.1, released in August 2026. ## Oracle Linux **Oracle Linux** (OL) is a Linux distribution packaged and distributed by Oracle; under GNU GPL since late 2006. It was formerly known as Oracle Enterprise Linux (OEL). It is based on RHEL’s source code. Oracle Linux is available with two Linux kernels: the Red Hat Compatible Kernel (RHCK) and the Unbreakable Enterprise Kernel (UEK). **Oracle Linux License**: GNU GPL and other licenses. **Latest release (September 2026)**: Oracle Linux 10, released in June 2025; current update 10.2. ## Slackware **Slackware** is one of the oldest Linux distributions, created by Patrick Volkerding in 1993. Many Linux distributions have been based on Slackware; for instance, the first versions of the SUSE Linux distribution. It was originally based on the Softlanding Linux System (SLS), one of the most popular original Linux distributions. **Slackware License**: GNU GPL. **Latest release (September 2026)**: Slackware 15.0, released on 3 February 2022 and still the current stable version. ## Mageia **Mageia** is an open source, Unix-like operating system that started as a fork of Mandriva Linux back in 2010. It was created by former employees of Mandriva S.A. and some members of the Mandriva community. It stands out for being a secure, stable and sustainable OS. Besides, it provides a really large software repository. Its first version, Mageia 1, was released in June 2011. **Mageia License**: GPL and other licenses. **Latest release (September 2026)**: Mageia 10, released on 29 June 2026. ## Clear Linux **Clear Linux** is an open source Linux distribution created by Intel. It is updated following a rolling release model. The OS is optimized for performance and security from the cloud to the Edge; as well as for Intel products. Clear Linux’s main targets are IT, DevOps, Cloud and AI professionals; it is not designed as a general-purpose distribution. Its source code is available on GitHub. **Clear Linux License**: GPL and other licenses. **Discontinued project**: on 18 July 2025 Intel announced the end of Clear Linux OS. It has received no security patches or maintenance since that date, and its repository was archived in read-only mode. ## Rocky Linux **Rocky Linux** is an open source Linux distribution, based on the source code of the commercial distribution RHEL. This Linux distribution is led by Gregory Kurtzer — founder of CentOS, together with Rocky McGaugh. Rocky Linux aims to fill the gap CentOS will leave as a community-supported, downstream of RHEL, after CentOS 8’s discontinuation by December 2021. As explained on Rocky Linux’s Wiki, this distribution aims to be “**a solid, stable and transparent alternative for production environments, developed by the community for the community**”. Stackscale provides two of its public mirrors in Madrid and Amsterdam. **Rocky Linux License**: BSD and other licenses. **Latest release (September 2026)**: Rocky Linux 10.2, released on 28 May 2026. ## AlmaLinux **AlmaLinux**** **is a free, open source Linux distribution; compatible with RHEL. It is focused on long-term stability and governed by the community; with regular releases. AlmaLinux OS is sponsored by CloudLinux Inc. and supported by other sponsors. It is also a good alternative for those who are currently using CentOS, after its discontinuation by the end of 2021. **AlmaLinux License**: GPLv2 and other licenses. **Latest release (September 2026)**: AlmaLinux OS 10.2, released on 26 May 2026. AlmaLinux and Rocky Linux are today the two usual choices for RHEL-compatible enterprise workloads without a subscription cost. Both deploy without friction on dedicated bare-metal servers, which is where this kind of system performs most predictably. ## Asahi Linux **Asahi Linux** is a Linux distribution that intends to port Linux to Apple Silicon Mac computers. The goal is to make Linux run on Apple Silicon Mac computers so as to be used as a daily OS. This distro is developed by a community of free and open source software developers. Asahi Linux’s first Alpha version was released in March, 2022. **Asahi Linux License**: General Public License v2 or MIT. **Latest release (September 2026)**: Fedora Asahi Remix 44, generally available since 28 April 2026. The project is no longer in alpha. ## Lubuntu **Lubuntu** is a Linux distribution based on Ubuntu and developed by the Lubuntu community. It stands out for being lightweight, fast and offering great compatibility with many formats and applications. Besides, it offers a Software Center with a large number of free apps that can be safely downloaded. **Lubuntu License**: GNU GPL and other licenses. **Latest release (September 2026)**: Lubuntu 26.04 LTS, released on 23 April 2026. ## SUSE Linux **SUSE Linux**, also known as SUSE Linux Enterprise Server, is a Linux distribution, adaptable to any environment and optimized for security, reliability and performance. Originally based on Slackware, its first version was released in 1994. As Slackware, SUSE Linux is one of the oldest Linux distributions. **Latest release (September 2026)**: SUSE Linux Enterprise Server 16, generally available since 4 November 2025. The last service pack in the 15 series is SP7. ## Knoppix **Knoppix** is a free, open source Linux distribution based on Debian, developed by Klaus Knopper. It was mainly designed to be used as a Live CD, but it can also be installed on a hard disk like any other OS. **Knoppix License**: free software licenses. **Latest release**: Knoppix 9.2, from 2021. The project has published no further releases since then. ## VzLinux **VzLinux** is a free and open source Linux distribution. It is a 1:1 clone of Red Hat Enterprise Linux and offers an easy conversion from CentOS. It can also be used as a guest OS in different hypervisors. **Inactive project**: there is no record of any release or announcement after 2021. ## Peppermint OS **Peppermint OS** is a lightweight Linux distribution based on Debian Stable. It changed from Ubuntu to Debian in 2022. This OS is a beginner-friendly distribution, intuitive and easy to use. **Peppermint License**: free software licenses. **Latest release (September 2026)**: the project no longer numbers its releases and publishes dated images instead. It maintains two branches: one based on Debian 13 and one without *systemd*, built on Devuan 6, from June 2026. ## Zorin OS **Zorin OS** is a Linux distribution based on Ubuntu, designed as a powerful and secure alternative to Windows and MacOS. Zorin OS is easy to use and its Appearance app allows users to change the desktop layout to the OS environment appearance they are familiar with — Windows, MacOS or Linux. **Zorin OS License**: free software. **Latest release (September 2026)**: Zorin OS 18.1, released on 15 April 2026. ## BlackArch Linux **BlackArch Linux** is an open source Linux distribution based on Arch Linux. It is especially designed for penetration testers and security researchers and it provides a lot of cybersecurity tools. The last version was released in September, 2021. **BlackArch Linux License**: several licenses. ## SUSE Liberty Linux **SUSE Liberty Linux** is an enterprise-grade Linux distribution born to be an alternative to CentOS Linux, which has been replaced by a rolling release. It is focused on providing a secure distribution for mixed Linux environments. This new distro is developed by SUSE, using its Open Build Service tool. Besides, it is based on the SUSE Linux Enterprise Server kernel (SLES kernel). **The brand no longer exists**: SUSE folded Liberty Linux into its *SUSE Multi-Linux Support* offering, which continues to support RHEL and CentOS installations. ## Navy Linux **Navy Linux** is a minimalistic installation of the Linux OS, based on Red Hat Enterprise Linux. This open source distribution was founded in January 2021 by UnixLab, as a replacement for CentOS Linux. It is focused on minimizing hardware resources requirements to build a stable and secure Linux distro. **Navy Linux License**: GNU GPL. **Inactive project**: the latest release, Navy Linux 8.6, dates from May 2022. ## Tizen **Tizen** is an open-source, mobile operating system based on Linux. It was released in 2012 and it is developed by Samsung and backed by the Linux Foundation. The Tizen OS is primarily used in Samsung’s smart devices — TVs, smartwatches, etc. It is intended to provide seamless connectivity and user experience between connected devices. **Tizen License**: GPLv2, LGPL, Apache License 2.0, BSD, Flora License and Freeware. **Latest release (September 2026)**: Tizen 10.0, shipping on Samsung’s 2026 television range. ## Immutable and container-oriented distributions The distributions above are general-purpose systems. Since 2020 a second family has grown around a different premise: **immutable-root** systems, with no traditional package manager, updated atomically and configured declaratively. They are not administered so much as deployed, they underpin much of today’s container infrastructure, and they deserve a section of their own. ## Alpine Linux **Alpine Linux** is a minimal distribution built on musl libc and BusyBox rather than glibc and the GNU coreutils. That decision brings a base image down to a few megabytes, which has made it the de facto starting point for container images: a large share of what runs on Docker and Kubernetes today boots from an Alpine layer. It uses its own package manager, *apk*, and OpenRC as its init system. Its size and reduced attack surface explain its adoption, but musl is not fully glibc-compatible and some applications shipping precompiled binaries need adjustments. **Alpine Linux License**: GNU GPL and other licenses. **Latest release (September 2026)**: Alpine Linux 3.24, released on 9 June 2026. ## NixOS **NixOS** takes infrastructure as code all the way down to the operating system: the machine’s entire configuration — packages, services, users and networking — is declared in files and the system is built from them. Two machines with the same configuration are identical, and every change produces a new bootable generation, so rolling back a failed update means picking the previous generation from the boot menu. It has the steepest learning curve on this list, because it requires learning the Nix language, but it solves configuration drift at the root. **NixOS License**: MIT. **Latest release (September 2026)**: NixOS 26.05 “Yarara”, released on 30 May 2026. ## Fedora CoreOS **Fedora CoreOS** is a minimal, immutable, automatically updating operating system built exclusively to run containers. The root filesystem is read-only, updates are applied atomically through rpm-ostree, and initial configuration is declared with Ignition on first boot rather than by hand. It is the successor to Container Linux within the Fedora ecosystem, and the proving ground where Red Hat matured the image-based model it later brought to RHEL. **Fedora CoreOS License**: GNU GPL and other licenses. **Latest release (September 2026)**: a rolling stream built on Fedora Linux 44. It publishes no long-term support releases. ## Flatcar Container Linux **Flatcar Container Linux** is the open continuation of Container Linux after its discontinuation, maintained as a CNCF project. It shares Fedora CoreOS’s approach — immutable, no package manager, container-dedicated — but updates atomically through A/B partitions: the new version is written to the inactive partition and activated on reboot, so a failure reverts to the previous boot. **Flatcar Container Linux License**: Apache License 2.0. **Latest stable release (September 2026)**: Flatcar 4593.2.5, from 13 August 2026. ## Talos Linux **Talos Linux** is an operating system designed for one job: being a Kubernetes node. It has no shell, no SSH and no package manager; it is administered entirely through an authenticated gRPC API. That removes a large part of a conventional node’s attack surface and makes cluster configuration reproducible by definition. The trade-off is rigidity: you do not log into a Talos node to debug something by hand. It suits hardened, homogeneous clusters rather than general-purpose servers. **Talos Linux License**: Mozilla Public License 2.0. **Latest release (September 2026)**: Talos Linux 1.14.0, from 3 September 2026. ## SUSE Linux Micro **SUSE Linux Micro** is SUSE’s immutable offering for edge deployments and as a container host. It uses transactional updates on Btrfs: each change is applied in a separate snapshot that only becomes the running system after a successful reboot, with automatic rollback if anything fails. It completes SUSE’s portfolio alongside SUSE Linux Enterprise Server 16, and has a community counterpart in openSUSE Leap Micro. **SUSE Linux Micro License**: GNU GPL and other licenses. **Latest release (September 2026)**: SUSE Linux Micro 6.2. ## Amazon Linux **Amazon Linux** is the distribution AWS maintains and tunes for its own instances, with direct integration into the provider’s services and tooling. Amazon Linux 2023 is the current generation, with major releases every two years and five years of support. It is worth keeping in mind for a practical reason: **Amazon Linux 2 reached end of life on 30 June 2026**, so any workload still running on that version is now unsupported and pending migration. **Amazon Linux License**: Amazon licence based on open source software. **Latest release (September 2026)**: Amazon Linux 2023, supported until 30 June 2029. ## Proxmox VE **Proxmox Virtual Environment** is not a general-purpose distribution but a virtualisation platform built on Debian, combining KVM for virtual machines and LXC for system containers, with Ceph distributed storage and high availability built in and managed from its own web interface. It has become a European reference point in the conversation about open alternatives to proprietary virtualisation platforms, and its Debian base keeps the underlying administration familiar. At Stackscale we deploy and operate Proxmox VE on dedicated private cloud infrastructure. **Proxmox VE License**: GNU AGPLv3. **Latest release (September 2026)**: Proxmox VE 9.2, from 21 May 2026. ## List of popular Linux distributions Here is the list of popular Linux distributions organized alphabetically: **Linux distribution****License****Latest release (as of September 2026)**AlmaLinuxGPLv2 and other licensesAlmaLinux OS 10.2 (May 2026)Alpine LinuxGNU GPL and other licensesAlpine Linux 3.24 (June 2026)Amazon LinuxAmazon licence based on open source softwareAmazon Linux 2023Arch LinuxGNU GPL and other licensesRolling releaseAsahi LinuxGeneral Public License v2 or MITFedora Asahi Remix 44 (April 2026)BlackArch LinuxSeveral licensesRolling releaseCentOS LinuxGNU GPLDiscontinued — EOL 31/12/2021CentOS StreamGNU GPLCentOS Stream 10 (December 2024)Clear LinuxGPL and other licensesDiscontinued — Intel, 18/07/2025CloudLinux–CloudLinux OS 10.2 (May 2026)DebianBSD, GPL and other open licensesDebian 13 “Trixie” (August 2025)Elementary OSGNU GPL and other licenseselementary OS 8.1.1 “Circe” (February 2026)FedoraGPL and other licensesFedora Linux 44 (April 2026)Fedora CoreOSGNU GPL and other licensesFedora CoreOS 44 (rolling stream)Flatcar Container LinuxApache License 2.0Flatcar 4593.2.5 (August 2026)GentooFree softwareRolling releaseKnoppixFree software licensesKnoppix 9.2 (2021) — inactiveLinux MintGPLLinux Mint 22.3 “Zena” (January 2026)LubuntuGNU GPL and other licensesLubuntu 26.04 LTS (April 2026)MageiaGPL and other licensesMageia 10 (June 2026)ManjaroGPL and other open licensesManjaro 26.1 (August 2026)Navy LinuxGNU GPLInactive — last release 8.6 (2022)NixOSMITNixOS 26.05 “Yarara” (May 2026)OpenSUSEGNU GPL and other licensesopenSUSE Leap 16.0 (October 2025)Oracle LinuxGNU GPL and other licensesOracle Linux 10 (June 2025)Peppermint OSFree software licensesDated images (Debian 13 / Devuan 6)Proxmox VEGNU AGPLv3Proxmox VE 9.2 (May 2026)Red Hat Enterprise LinuxGPLRHEL 10 (May 2025)Rocky LinuxBSD and other licensesRocky Linux 10.2 (May 2026)Scientific LinuxGNU GPL and other licensesDiscontinued — EOL 30/06/2024SlackwareGNU GPLSlackware 15.0 (February 2022)SUSE Liberty Linux–Folded into SUSE Multi-Linux SupportSUSE Linux–SUSE Linux Enterprise Server 16 (November 2025)SUSE Linux MicroGNU GPL and other licensesSUSE Linux Micro 6.2Talos LinuxMozilla Public License 2.0Talos Linux 1.14 (September 2026)TizenGPLv2, LGPL, Apache License 2.0, BSD, Flora License and FreewareTizen 10.0 (2026)UbuntuGPL and other licensesUbuntu 26.04 LTS (April 2026)VzLinux–Inactive — last release 8.5 (2021)Zorin OSFree softwareZorin OS 18.1 (April 2026) On the following webpage, you can find the statistics of the most used Linux distributions over the last decade. And to check up-to-date versions, release dates and end-of-life dates for each system, the Linux Gratis directory keeps a continuously updated entry for each of more than two hundred operating systems. Dutch version: 19 populaire Linux-distributies. --- ## 39 distribuciones de Linux populares URL: https://www.stackscale.com/blog/popular-linux-distributions/ En la siguiente lista hemos recopilado **algunas de las distribuciones de Linux populares** y también algunas distros que vienen pisando fuerte. Los sistemas operativos GNU/Linux son de tipo Unix y de código abierto, y están basados en el kernel de Linux. **Entre la larga lista de distribuciones de Linux, hay unas cuantas que destacan entre el resto** —a nivel de número de usuarios, comunidad, características, etcétera—. Descubre algunos detalles de algunas de las principales distribuciones de Linux. ## Ubuntu **Ubuntu** es una distribución de Linux basada en Debian. Está desarrollada por Canonical y una comunidad de desarrolladores. Tiene tres ediciones oficiales: *Desktop*, *Server* y *Core*, que pueden ejecutarse tanto en ordenador como en una máquina virtual. Más del 34 % de los sitios web Linux utilizan Ubuntu, según los datos de W3Techs. Su crecimiento desde 2010 ha sido asombroso. También es la distribución más popular entre los proyectos de cloud computing. **Licencia de Ubuntu**: GPL y otras licencias. **Última versión LTS (septiembre de 2026)**: Ubuntu 26.04 LTS «Resolute Raccoon», publicada el 23 de abril de 2026. Ubuntu 24.04 LTS mantiene soporte hasta mayo de 2029. ## Debian **Debian** es un sistema operativo (OS) de código abierto. Esta distribución fue anunciada inicialmente por Ian Murdock en 1993 como «Debian Linux Release». El proyecto Debian es una comunidad de desarrolladores y usuarios que mantienen el OS GNU basado en software de código abierto. Actualmente, los sistemas Debian utilizan el kernel de Linux o el kernel de FreeBSD. Sin embargo, también están trabajando en ofrecer Debian para otros kernels. Principalmente, GNU Hurd. **Licencia de Debian**: BSD, GPL y otras licencias libres. **Última versión (septiembre de 2026)**: Debian 13 «Trixie», publicada el 9 de agosto de 2025; revisión actual 13.6. ## CentOS Linux **CentOS Linux** es una distribución de Linux basada en el código fuente de la distribución comercial Red Hat Enterprise Linux (RHEL). Se lanzó en 2004 y está respaldado por una creciente comunidad. Es una apuesta segura para los que buscan un código de gran calidad. Pero CentOS 8 será su última versión. En 2019, Red Hat anunció que CentOS Linux sería reemplazado por CentOS Stream —una plataforma de desarrollo upstream para RHEL—. A partir de este cambio de estrategia han aparecido nuevas alternativas *open source*; como** Rocky Linux**, fundado por Gregory Kurtzer, fundador del proyecto CentOS. **Licencia de CentOS**: GNU GPL. **Proyecto discontinuado**: CentOS Linux 8 llegó a su fin de vida el 31 de diciembre de 2021 y CentOS Linux 7 el 30 de junio de 2024. No hay sucesor con ese nombre: las alternativas son AlmaLinux, Rocky Linux o CentOS Stream. ## CentOS Stream **CentOS Stream** es una plataforma de desarrollo *upstream* para Red Hat Enterprise Linux (RHEL). Es una *midstream* entre Fedora Linux y RHEL. Esta plataforma tiene como objetivo aprovechar la innovación de código abierto para dar forma a las siguientes actualizaciones estables de RHEL. **Licencia de CentOS Stream**: GNU GPL. **Última versión (septiembre de 2026)**: CentOS Stream 10, publicada el 12 de diciembre de 2024, con soporte hasta mayo de 2030. CentOS Stream 9 lo mantiene hasta mayo de 2027. ## Red Hat Enterprise Linux (RHEL) **Red Hat Enterprise Linux** (RHEL) es una distribución comercial de Linux desarrollada por Red Hat. Tiene una versión de servidor y una versión de escritorio. Como utiliza un software de código abierto, publicado bajo Licencia Pública General, ponen el código a disposición del público a través de CentOS. Red Hat ha patrocinado el proyecto CentOS desde 2014. **Licencia de RHEL**: GPL. **Última versión (septiembre de 2026)**: RHEL 10, publicada el 20 de mayo de 2025; revisiones vigentes 10.2 y 9.8. ## Gentoo **Gentoo** es una distribución de Linux con un modelo de *rolling release* (liberación continua). Gentoo Linux fue creado originalmente por Daniel Robbins. Recibe su nombre del «pingüino gentoo», que se caracteriza por nadar rápido, como un guiño a su potencial. Es una opción interesante para usuarios de Linux que buscan un control absoluto del software. Los usuarios de Gentoo tienen un gran control sobre los servicios instalados y en ejecución en su ordenador. Pueden personalizar y optimizar enormemente el sistema. **Licencia de Gentoo**: software libre. **Actualizaciones de Gentoo**: *rolling release*. ## Fedora **Fedora** es una distribución de Linux desarrollada por el proyecto Fedora —patrocinado principalmente por Red Hat, con soporte de otras compañías—. Está desarrollada y mantenida por la comunidad y es una fuente upstream de la distribución comercial RHEL. Fedora suele disponer de versiones más modernas del software, consideradas «no estables», que luego se incluyen en RHEL. Hay diferentes ediciones de Fedora disponibles: *Workstation*, *Server*, *CoreOS*, *Silverblue* y *IoT*. Fedora Linux se lanzó en 2003. **Licencia de Fedora**: GPL y otras licencias. **Última versión (septiembre de 2026)**: Fedora Linux 44, publicada el 28 de abril de 2026. ## OpenSUSE **OpenSUSE** es una distribución de Linux patrocinada por SUSE Software Solutions Germany GmbH y otras compañías. Anteriormente se conocía como SUSE Linux. OpenSUSE tiene una versión con *rolling release*, Tumbleweed, y una versión con actualizaciones normales, Leap. **Licencia de OpenSUSE**: GNU GPL y otras licencias. **Última versión (septiembre de 2026)**: openSUSE Leap 16.0, publicada el 1 de octubre de 2025. ## Scientific Linux **Scientific Linux** es otra distribución de Linux basada en el software libre y de código abierto de RHEL. Desarrollado por Fermilab, CERN, DESY y ETH Zurich. En abril de 2019, anunciaron su descontinuación. No obstante, su última versión, Scientific Linux 7, contará con actualizaciones de mantenimiento hasta junio de 2024. **Licencia de Scientific Linux**: GNU GPL y otras licencias. **Proyecto discontinuado**: Scientific Linux 7 llegó a su fin de vida el 30 de junio de 2024. Fermilab recomienda migrar a AlmaLinux o CentOS Stream. ## CloudLinux **CloudLinux** es una distribución de Linux desarrollada por CloudLinux, Inc. Está basada en CentOS y utiliza el kernel de OpenVZ y el gestor de paquetes RPM. Está destinado a proveedores de hosting compartido y centros de datos. Destaca por mejorar la estabilidad, densidad y seguridad del servidor. La primera versión de CloudLinux OS se lanzó en 2010. **Última versión (septiembre de 2026)**: CloudLinux OS 10.2, publicada el 26 de mayo de 2026. Desde la serie 10 se instala sobre AlmaLinux mediante *cldeploy*, sin imagen de instalación propia. ## Elementary OS **Elementary OS** es una distribución de Linux basada en Ubuntu. El OS está desarrollado y mantenido por Elementary, Inc. Su objetivo es ser una alternativa rápida, abierta y respetuosa con la privacidad a Windows y MacOS. Está disponible bajo un modelo *pay-what-you-want* (PWYW) o «pague lo que quiera». **Licencia de Elementary OS**: GNU GPL y otras licencias. **Última versión (septiembre de 2026)**: elementary OS 8.1.1 «Circe», del 27 de febrero de 2026. ## Linux Mint **Linux Mint** es una distribución impulsada por la comunidad y basada en Ubuntu. Esta distribución comenzó en 2006. El proyecto Linux Mint lo creó inicialmente Clément Lefèbvre. El código fuente de Linux Mint OS está disponible en GitHub. La mayor parte del desarrollo del sistema operativo está hecho en Python. **Licencia de Linux Mint**: GPL. **Última versión (septiembre de 2026)**: Linux Mint 22.3 «Zena», del 11 de enero de 2026, con soporte hasta abril de 2029. ## Arch Linux **Arch Linux** es una distribución de Linux basada en 5 principios: la simplicidad, la modernidad, el pragmatismo, el usuario en el centro y la versatilidad. Las actualizaciones siguen un modelo de *rolling release*. **Licencia de Arch Linux**: GNU GPL y otras licencias. **Actualizaciones de Arch Linux**: *rolling release*. ## Manjaro **Manjaro** es una distribución de Linux libre basada en Arch Linux. Se centra especialmente en la accesibilidad y la facilidad de uso. Las actualizaciones siguen un modelo de *rolling release*. Su simplicidad, estabilidad y rendimiento lo convierten en un buen OS alternativo a MacOS y Windows. Ofrece múltiples entornos de escritorio. **Licencia de Manjaro**: GPL y otras licencias libres. **Última versión (septiembre de 2026)**: Manjaro 26.1, de agosto de 2026. ## Oracle Linux **Oracle Linux** (OL) es una distribución de Linux empaquetada y distribuida por Oracle; bajo licencia GNU GPL desde 2006. Anteriormente se conocía como Oracle Enterprise Linux (OEL). Está basada en el código fuente de RHEL. Oracle Linux está disponible con dos kernels de Linux: el *Red Hat Compatible Kernel* (RHCK) y el *Unbreakable Enterprise Kernel* (UEK). **Licencia de Oracle Linux**: GNU GPL y otras licencias. **Última versión (septiembre de 2026)**: Oracle Linux 10, de junio de 2025; revisión actual 10.2. ## Slackware **Slackware** es una de las distribuciones de Linux más antiguas, creada por Patrick Volkerding en 1993. Muchas distribuciones se han basado en Slackware; por ejemplo, las primeras versiones de la distribución SUSE Linux. En sus orígenes se basó en el Softlanding Linux System (SLS), una de las distribuciones originales de Linux más populares. **Licencia de Slackware**: GNU GPL. **Última versión (septiembre de 2026)**: Slackware 15.0, del 3 de febrero de 2022, que sigue siendo la versión estable vigente. ## Mageia **Mageia** es un sistema operativo de tipo Unix y de código abierto que comenzó como un *fork* de Mandriva Linux en 2010. Fue creado por antiguos empleados de Mandriva S.A. y algunos miembros de la comunidad Mandriva. Destaca por ser un OS seguro, estable y sostenible. Además, proporciona un repositorio de software realmente grande. Su primera versión, Mageia 1, se lanzó en junio de 2011. **Licencia de Mageia**: GPL y otras licencias. **Última versión (septiembre de 2026)**: Mageia 10, del 29 de junio de 2026. ## Clear Linux **Clear Linux** es una distribución de Linux de código abierto creada por Intel. Se actualiza siguiendo un modelo de *rolling release*. El OS está optimizado para rendimiento y seguridad desde la nube hacia el Edge; así como para los productos de Intel. Clear Linux está dirigido a profesionales IT, DevOps, Cloud y AI; no está diseñada como una distribución de uso general. Su código fuente está disponible en GitHub. **Licencia de Clear Linux**: GPL y otras licencias. **Proyecto discontinuado**: Intel anunció el 18 de julio de 2025 el fin de Clear Linux OS. Desde esa fecha no recibe parches de seguridad ni mantenimiento, y su repositorio quedó archivado en modo solo lectura. ## Rocky Linux **Rocky Linux** es una distribución de Linux open source, basada en el código fuente de la distribución comercial RHEL. Esta distribución de Linux está liderada por Gregory Kurtzer —fundador de CentOS, junto con Rocky McGaugh—. Rocky Linux tiene como objetivo llenar el hueco que deja Linux como distribución downstream de RHEL, mantenida por la comunidad, tras la discontinuación de CentOS 8 en diciembre de 2021. Tal y como se explica en su Wiki, tiene como objetivo ser «**una alternativa sólida, estable y transparente para entornos de producción, desarrollada por la comunidad para la comunidad**». Stackscale proporciona dos de sus mirrors públicos en Madrid y Ámsterdam. **Licencia de Rocky Linux**: BSD y otras licencias. **Última versión (septiembre de 2026)**: Rocky Linux 10.2, del 28 de mayo de 2026. ## AlmaLinux  **AlmaLinux **es una distribución de Linux de código abierto y libre compatible con RHEL. Se centra en la estabilidad a largo plazo y está gobernada por la comunidad; con actualizaciones regulares. AlmaLinux OS está patrocinada por CloudLinux Inc. y respaldada por otros sponsors. También es una buena alternativa para quien actualmente utiliza CentOS, tras su discontinuación a finales de 2021. **Licencia de AlmaLinux**: GPLv2 y otras licencias. **Última versión (septiembre de 2026)**: AlmaLinux OS 10.2, del 26 de mayo de 2026. AlmaLinux y Rocky Linux son hoy las dos opciones habituales para cargas empresariales compatibles con RHEL sin coste de suscripción. Ambas se despliegan sin fricción sobre servidores bare-metal dedicados, que es donde este tipo de sistema rinde de forma más previsible. ## Asahi Linux **Asahi Linux** es una distribución de Linux que tiene como objetivo portar Linux a los Mac Apple Silicon. Su objetivo es hacer funcionar Linux en ordenadores Mac a fin de que pueda usarse como sistema operativo diario. Esta distro está desarrollada por una comunidad de desarrolladores de software libre. La primera versión Alpha de Asahi Linux se publicó en marzo de 2022. **Licencia de Asahi Linux**: Licencia Pública General v2 o MIT. **Última versión (septiembre de 2026)**: Fedora Asahi Remix 44, disponible desde el 28 de abril de 2026. El proyecto ya no está en fase alfa. ## Lubuntu **Lubuntu** es una distribución de Linux basada en Ubuntu y desarrollada por la comunidad Lubuntu. Esta distro destaca por ser ligera, rápida y ofrecer gran compatibilidad con muchos formatos y aplicaciones. Además ofrece un *Software Center* con un amplio número de aplicaciones gratuitas que se pueden descargar de forma segura. **Licencia de Lubuntu**: GNU GPL y otras licencias. **Última versión (septiembre de 2026)**: Lubuntu 26.04 LTS, del 23 de abril de 2026. ## SUSE Linux **SUSE Linux**, también conocido como SUSE Linux Enterprise Server, es una distribución de Linux que se adapta a cualquier entorno y está optimizada en términos de seguridad, fiabilidad y rendimiento. Originalmente estaba basada en Slackware y su primera versión se publicó en 1994. Al igual que Slackware, SUSE Linux es una de las distribuciones de Linux más antiguas. **Última versión (septiembre de 2026)**: SUSE Linux Enterprise Server 16, disponible desde el 4 de noviembre de 2025. El último *service pack* de la serie 15 es el SP7. ## Knoppix **Knoppix** es una distribución de Linux libre y de código abierto basada en Debian y desarrollada por Klaus Knopper. Se diseñó principalmente para ser usada como Live CD, pero también se puede instalar en un disco duro como cualquier otro sistema operativo. **Licencia de Knoppix**: licencias de software libre. **Última versión**: Knoppix 9.2, de 2021. El proyecto no ha publicado novedades desde entonces. ## VzLinux **VzLinux** es una distribución de Linux libre y de código abierto. Es un clon 1:1 de Red Hat Enterprise Linux y ofrece una conversión sencilla desde CentOS. También se puede usar como OS invitado en diferentes hipervisores. **Proyecto sin actividad**: no consta ninguna versión ni anuncio posterior a 2021. ## Peppermint OS **Peppermint OS** es una distribución de Linux ligera, basada en Debian Stable. Cambió de Ubuntu a Debian en 2022. Este SO es una distribución apta para principiantes, intuitiva y fácil de usar. **Licencia de Peppermint**: licencias de software libre. **Última versión (septiembre de 2026)**: el proyecto ha dejado de numerar versiones y publica imágenes fechadas. Mantiene dos ramas: una basada en Debian 13 y otra sin *systemd* sobre Devuan 6, de junio de 2026. ## Zorin OS **Zorin OS** es una distribución de Linux basada en Ubuntu, diseñada como una alternativa potente y segura a Windows y MacOS. Zorin OS es fácil de usar y su aplicación *Appearance* permite a los usuarios cambiar el diseño del escritorio al aspecto del entorno de sistema operativo al que estén habituados —Windows, MacOS o Linux—. **Licencia de Zorin OS**: software libre. **Última versión (septiembre de 2026)**: Zorin OS 18.1, del 15 de abril de 2026. ## BlackArch Linux **BlackArch Linux** es una distribución open source de Linux basada en Arch Linux. Está especialmente diseñada para *penetration testers* («expertos en prueba de penetración») e investigadores de seguridad, y proporciona muchas herramientas de ciberseguridad. La última versión fue publicada en septiembre de 2021.  **Licencia de BlackArch Linux**: varias licencias. ## SUSE Liberty Linux **SUSE Liberty Linux** es una distribución de Linux de nivel empresarial que surge como una alternativa a CentOS Linux, que ha sido reemplazada por una *rolling release*. Se centra en proporcionar una distribución segura par entornos de Linux mixtos. Esta nueva distro la desarrolló SUSE, con su herramienta Open Build Service. Además, está basada en el kernel de SUSE Linux Enterprise Server (SLES kernel). **La marca ha desaparecido**: SUSE integró Liberty Linux en su oferta *SUSE Multi-Linux Support*, que mantiene el soporte para instalaciones RHEL y CentOS. ## Navy Linux **Navy Linux** es una instalación minimalista del sistema operativo Linux, basada en Red Hat Enterprise Linux. Esta distribución de código abierto la fundó UnixLab en enero de 2021, como sustituto de CentOS Linux. Está centrada en minimizar los requisitos de recursos de hardware para construir una distro de Linux segura y estable. **Licencia de Navy Linux**: GNU GPL. **Proyecto sin actividad**: la última versión, Navy Linux 8.6, es de mayo de 2022. ## Tizen **Tizen** es un sistema operativo móvil de código abierto, basado en Linux. Se lanzó en 2012 y está desarrollado por Samsung y respaldado por la Fundación Linux (*Linux Foundation* en inglés). El SO Tizen se usa principalmente en dispositivos inteligentes de Samsung —TVs, *smartwatches*, etc.—. Está diseñado para proporcionar una experiencia de usuario y conectividad sin interrupciones entre dispositivos conectados. **Licencia de Tizen**: GPLv2, LGPL, Apache License 2.0, BSD, Flora License y Freeware. **Última versión (septiembre de 2026)**: Tizen 10.0, presente en los televisores Samsung de 2026. ## Distribuciones inmutables y orientadas a contenedores El grupo anterior recoge distribuciones de propósito general. Desde 2020 ha crecido una segunda familia con un planteamiento distinto: sistemas de **raíz inmutable**, sin gestor de paquetes tradicional, que se actualizan de forma atómica y se configuran de manera declarativa. No se administran, se despliegan. Son las que sostienen buena parte de la infraestructura de contenedores actual y merecen su propio apartado. ## Alpine Linux **Alpine Linux** es una distribución minimalista construida sobre musl libc y BusyBox en lugar de glibc y las GNU coreutils. Esa decisión reduce una imagen base a unos pocos megabytes, lo que la ha convertido en el punto de partida de facto para imágenes de contenedor: buena parte de lo que se ejecuta hoy en Docker y Kubernetes arranca desde una capa Alpine. Usa su propio gestor de paquetes, *apk*, y OpenRC como sistema de init. Su tamaño y su reducida superficie de ataque explican su adopción, pero musl no es totalmente compatible con glibc y algunas aplicaciones con binarios precompilados requieren ajustes. **Licencia de Alpine Linux**: GNU GPL y otras licencias. **Última versión (septiembre de 2026)**: Alpine Linux 3.24, publicada el 9 de junio de 2026. ## NixOS **NixOS** lleva la idea de infraestructura como código hasta el propio sistema operativo: la configuración completa de la máquina —paquetes, servicios, usuarios y red— se declara en ficheros y el sistema se construye a partir de ellos. Dos máquinas con la misma configuración son idénticas, y cada cambio genera una nueva generación arrancable, de modo que revertir una actualización fallida consiste en elegir la generación anterior en el menú de arranque. Es la distribución con la curva de aprendizaje más pronunciada de esta lista, porque obliga a aprender el lenguaje Nix, pero resuelve de raíz el problema de la deriva de configuración. **Licencia de NixOS**: MIT. **Última versión (septiembre de 2026)**: NixOS 26.05 «Yarara», publicada el 30 de mayo de 2026. ## Fedora CoreOS **Fedora CoreOS** es un sistema operativo mínimo, inmutable y de actualización automática pensado exclusivamente para ejecutar contenedores. El sistema de ficheros raíz es de solo lectura, las actualizaciones se aplican de forma atómica mediante rpm-ostree y la configuración inicial se declara con Ignition en el primer arranque, no a mano. Es el sucesor de Container Linux dentro del ecosistema de Fedora y el laboratorio donde Red Hat ha madurado el modelo de imagen que después ha llevado a RHEL. **Licencia de Fedora CoreOS**: GNU GPL y otras licencias. **Última versión (septiembre de 2026)**: rama continua sobre Fedora Linux 44. No publica versiones con soporte a largo plazo. ## Flatcar Container Linux **Flatcar Container Linux** es la continuación abierta de Container Linux tras su descontinuación, mantenida como proyecto de la CNCF. Comparte planteamiento con Fedora CoreOS —sistema inmutable, sin gestor de paquetes, dedicado a contenedores— pero con actualizaciones atómicas por particiones A/B: la nueva versión se escribe en la partición inactiva y se activa al reiniciar, de modo que un fallo revierte al arranque anterior. **Licencia de Flatcar Container Linux**: Apache License 2.0. **Última versión estable (septiembre de 2026)**: Flatcar 4593.2.5, del 13 de agosto de 2026. ## Talos Linux **Talos Linux** es un sistema operativo diseñado para una sola cosa: ser nodo de Kubernetes. No tiene shell, ni SSH, ni gestor de paquetes; se administra íntegramente mediante una API gRPC autenticada. Eso elimina de golpe buena parte de la superficie de ataque de un nodo convencional y hace que la configuración del clúster sea reproducible por definición. El precio es la rigidez: en un nodo Talos no se entra a depurar nada a mano. Es la opción para quien busca clústeres endurecidos y homogéneos, no servidores de propósito general. **Licencia de Talos Linux**: Mozilla Public License 2.0. **Última versión (septiembre de 2026)**: Talos Linux 1.14.0, del 3 de septiembre de 2026. ## SUSE Linux Micro **SUSE Linux Micro** es la propuesta inmutable de SUSE para *edge* y como anfitrión de contenedores. Utiliza actualizaciones transaccionales sobre Btrfs: cada cambio se aplica en una instantánea independiente que solo pasa a ser el sistema activo tras un reinicio correcto, con reversión automática si algo falla. Completa la cartera de SUSE junto a SUSE Linux Enterprise Server 16 y tiene un equivalente comunitario en openSUSE Leap Micro. **Licencia de SUSE Linux Micro**: GNU GPL y otras licencias. **Última versión (septiembre de 2026)**: SUSE Linux Micro 6.2. ## Amazon Linux **Amazon Linux** es la distribución que AWS mantiene y optimiza para sus propias instancias, con integración directa con los servicios y las herramientas del proveedor. Amazon Linux 2023 es la generación actual, con versiones mayores cada dos años y cinco de soporte. Conviene tenerla presente por un motivo práctico: **Amazon Linux 2 llegó a su fin de vida el 30 de junio de 2026**, de modo que las cargas que sigan sobre esa versión están hoy sin soporte y pendientes de migración. **Licencia de Amazon Linux**: licencia propia basada en software de código abierto. **Última versión (septiembre de 2026)**: Amazon Linux 2023, con soporte hasta el 30 de junio de 2029. ## Proxmox VE **Proxmox Virtual Environment** no es una distribución de propósito general sino una plataforma de virtualización construida sobre Debian, que combina KVM para máquinas virtuales y LXC para contenedores de sistema, con almacenamiento distribuido Ceph y alta disponibilidad integrados, administrados desde una interfaz web propia. Se ha convertido en una referencia europea en la conversación sobre alternativas abiertas a las plataformas de virtualización propietarias, y su base Debian hace que la administración subyacente resulte familiar. En Stackscale desplegamos y operamos Proxmox VE sobre infraestructura de cloud privado dedicada. **Licencia de Proxmox VE**: GNU AGPLv3. **Última versión (septiembre de 2026)**: Proxmox VE 9.2, del 21 de mayo de 2026. ## Lista de distribuciones de Linux populares A continuación va una lista de distribuciones de Linux populares ordenadas alfabéticamente: **Distribución de Linux****Licencia****Última versión (a fecha de septiembre de 2026)**AlmaLinuxGPLv2 y otras licenciasAlmaLinux OS 10.2 (mayo de 2026)Alpine LinuxGNU GPL y otras licenciasAlpine Linux 3.24 (junio de 2026)Amazon LinuxLicencia de Amazon basada en código abiertoAmazon Linux 2023Arch LinuxGNU GPL y otras licenciasRolling releaseAsahi LinuxLicencia Pública General v2 o MITFedora Asahi Remix 44 (abril de 2026)BlackArch LinuxVarias licenciasRolling releaseCentOS LinuxGNU GPLDiscontinuada — EOL 31/12/2021CentOS StreamGNU GPLCentOS Stream 10 (diciembre de 2024)Clear LinuxGPL y otras licenciasDiscontinuada — Intel, 18/07/2025CloudLinux–CloudLinux OS 10.2 (mayo de 2026)DebianBSD, GPL y otras licencias libresDebian 13 «Trixie» (agosto de 2025)Elementary OSGNU GPL y otras licenciaselementary OS 8.1.1 «Circe» (febrero de 2026)FedoraGPL y otras licenciasFedora Linux 44 (abril de 2026)Fedora CoreOSGNU GPL y otras licenciasFedora CoreOS 44 (rama continua)Flatcar Container LinuxApache License 2.0Flatcar 4593.2.5 (agosto de 2026)GentooSoftware libreRolling releaseKnoppixLicencias de software libreKnoppix 9.2 (2021) — sin actividadLinux MintGPLLinux Mint 22.3 «Zena» (enero de 2026)LubuntuGNU GPL y otras licenciasLubuntu 26.04 LTS (abril de 2026)MageiaGPL y otras licenciasMageia 10 (junio de 2026)ManjaroGPL y otras licencias libresManjaro 26.1 (agosto de 2026)Navy LinuxGNU GPLSin actividad — última 8.6 (2022)NixOSMITNixOS 26.05 «Yarara» (mayo de 2026)OpenSUSEGNU GPL y otras licenciasopenSUSE Leap 16.0 (octubre de 2025)Oracle LinuxGNU GPL y otras licenciasOracle Linux 10 (junio de 2025)Peppermint OSLicencias de software libreImágenes fechadas (Debian 13 / Devuan 6)Proxmox VEGNU AGPLv3Proxmox VE 9.2 (mayo de 2026)Red Hat Enterprise LinuxGPLRHEL 10 (mayo de 2025)Rocky LinuxBSD y otras licenciasRocky Linux 10.2 (mayo de 2026)Scientific LinuxGNU GPL y otras licenciasDiscontinuada — EOL 30/06/2024SlackwareGNU GPLSlackware 15.0 (febrero de 2022)SUSE Liberty Linux–Integrada en SUSE Multi-Linux SupportSUSE Linux–SUSE Linux Enterprise Server 16 (noviembre de 2025)SUSE Linux MicroGNU GPL y otras licenciasSUSE Linux Micro 6.2Talos LinuxMozilla Public License 2.0Talos Linux 1.14 (septiembre de 2026)TizenGPLv2, LGPL, Apache License 2.0, BSD, Flora License y FreewareTizen 10.0 (2026)UbuntuGPL y otras licenciasUbuntu 26.04 LTS (abril de 2026)VzLinux–Sin actividad — última 8.5 (2021)Zorin OSSoftware libreZorin OS 18.1 (abril de 2026) En la siguiente página web puedes ver las estadísticas de las distribuciones de Linux más usadas durante la última década. Y para consultar versiones, fechas de lanzamiento y fin de soporte al día de cada sistema, el directorio de Linux Gratis mantiene una ficha por distribución con más de doscientos sistemas operativos, actualizada de forma continua. --- ## GPUs vs. CPUs: The evolution of computing for AI and cloud URL: https://www.stackscale.com/blog/gpus-vs-cpus-evolution/ In the world of computing, **central processing units (CPUs)** have long been the cornerstone of computational power, driving everything from personal computers and dedicated servers to public and private clouds and a wide range of electronic devices. However, with the rapid growth of artificial intelligence (AI) and the increasing complexity of web hosting platforms, bare-metal servers, and clouds, **graphics processing units (GPUs)** have emerged as a clear competitor in many areas, challenging the traditional dominance of CPUs. This article examines the comparative roles of GPUs and CPUs in the context of AI and web hosting, exploring their respective strengths, weaknesses, and the scenarios in which each excels. ## **Architectural and functional differences: CPUs vs. GPUs** To understand why CPUs and GPUs are suited for different tasks, it is essential to grasp their fundamental architectural differences. **CPUs: Versatility and Performance in Diverse Tasks** CPUs are designed as general-purpose processors capable of performing a wide variety of tasks efficiently. Due to their complex control logic and large caches, CPUs excel in tasks requiring high single-thread performance. A typical CPU features between 4 and 64 cores, each capable of executing multiple instructions per cycle. This makes them ideal for processes requiring high precision and a range of operations. **GPUs: The Power of Parallel Processing** Originally designed for rendering graphics, GPUs contain thousands of smaller, simpler cores designed for parallel processing. This architecture allows GPUs to handle multiple tasks simultaneously, making them extremely efficient for operations that can be performed in parallel. While a CPU may excel in sequential tasks, a GPU’s architecture shines in scenarios requiring massive parallelism. ## **Applications in AI: The rise of GPUs** Artificial intelligence, especially deep learning, has revolutionized numerous industries. Training neural networks, which involves performing millions of matrix multiplications, is a task well-suited to GPUs’ parallel architecture. For example, NVIDIA’s Tesla and AMD’s Radeon Instinct series are designed for AI and deep learning tasks, providing massive computational power that significantly speeds up training processes compared to CPUs. **Inference and Balance: CPUs and GPUs in Action** In the inference phase, where predictions are made using a trained model, both CPUs and GPUs can be effective depending on the specific requirements. CPUs may be more advantageous for real-time inference due to their superior single-thread performance and lower latency, while GPUs still hold a significant edge for batch-processing inference tasks. ## **Web hosting platforms, servers, and cloud: The domain of CPUs** Web hosting platforms, servers, and clouds, which form the backbone of the internet, have traditionally relied on CPUs due to their ability to perform a wide range of tasks simultaneously. Web servers handle various tasks, such as processing HTTP requests, running application logic, and interacting with databases, all of which can benefit from the superior single-thread performance of CPUs. **Virtualization and Containerization: The CPU Advantage** Modern virtualization and containerization technologies, key in web hosting, create isolated environments for running applications, allowing for better resource utilization and scalability. CPUs, with their robust support for virtualization and advanced instruction sets, are well-suited for these tasks, ensuring efficient management of virtual machines and containers. ## **The future: Synergy between CPUs and GPUs** While CPUs and GPUs each have distinct advantages, the most powerful systems often combine both strengths. In AI and ML infrastructures, CPUs and GPUs work together to optimize performance. CPUs orchestrate tasks, preprocess data, and feed GPUs for heavy parallel computations. Once the GPUs process the data, the CPUs handle the final stages of analysis and decision-making. **Hybrid Solutions and Emerging Trends** In the cloud computing landscape, hybrid solutions that combine the power of CPUs and GPUs are gaining popularity. Cloud service providers like AWS, Google Cloud, and Microsoft Azure offer instances that combine GPUs’ computational power with CPUs’ versatility, ideal for applications requiring intensive computation and general-purpose processing. However, shared GPUs can be costly, which is why Stackscale offers exclusive GPU server solutions with costs tailored to each project. ## **Conclusion: Valuing both processors** The debate between GPUs and CPUs is not about which is superior overall but rather which is better suited for specific tasks. GPUs dominate in AI due to their superior parallel processing capability, while CPUs remain the backbone of web hosting platforms, providing the versatility and single-thread performance needed to handle diverse and dynamic workloads. As technology advances, the harmonious integration of CPUs and GPUs, along with emerging technologies, will drive the next wave of innovation. Leveraging the strengths of each to tackle increasingly complex and varied computational challenges will be key to future computing success. For those interested in optimizing their servers for AI projects, machine learning, or large language models (LLMs), GPUs may be the right solution. In the context of cloud computing, bare-metal servers, hosting, and web services, CPUs will continue to play a vital role. --- ## GPUs vs. CPUs: La evolución en la computación para inteligencia artificial y la nube URL: https://www.stackscale.com/blog/gpus-vs-cpus-evolution/ En el mundo de la computación, los **procesadores de propósito general (CPUs)** han sido durante mucho tiempo la piedra angular del poder de computación, impulsando desde computadoras personales hasta servidores dedicado, las nubes públicas y nubes privadas y una amplia gama de dispositivos electrónicos. Sin embargo, con el rápido crecimiento de la inteligencia artificial (IA) y la creciente complejidad de las plataformas de alojamiento web, servidores bare-metal y nubes, los **procesadores gráficos (GPUs)** han emergido como un competidor claro para muchas áreas, desafiando el dominio tradicional de los CPUs. Este artículo examina los roles comparativos de GPUs y CPUs en el contexto de la IA y el alojamiento web, explorando sus respectivas fortalezas, debilidades y los escenarios en los que cada uno sobresale. ## **Diferencias arquitectónicas y funcionales: CPUs vs. GPUs** Para entender por qué los CPUs y GPUs son adecuados para diferentes tareas, es esencial comprender las diferencias arquitectónicas fundamentales entre ambos. **CPUs: Versatilidad y Rendimiento en Tareas Diversas** Los CPUs están diseñados como procesadores de propósito general capaces de realizar diversas tareas de manera eficiente. Gracias a su lógica de control compleja y a sus grandes cachés, los CPUs sobresalen en tareas que requieren un alto rendimiento de un solo hilo. Un CPU típico cuenta con entre 4 y 64 núcleos, cada uno capaz de ejecutar múltiples instrucciones por ciclo. Esto los convierte en ideales para procesos que requieren alta precisión y una variedad de operaciones. **GPUs: La Fuerza del Procesamiento Paralelo** Diseñados inicialmente para renderizar gráficos, los GPUs contienen miles de núcleos más pequeños y simples diseñados para el procesamiento paralelo. Esta arquitectura permite a los GPUs manejar múltiples tareas simultáneamente, haciéndolos extremadamente eficientes en operaciones que se pueden realizar en paralelo. Mientras que un CPU puede sobresalir en tareas secuenciales, la arquitectura de un GPU brilla en escenarios que requieren un procesamiento masivo en paralelo. ## **Aplicaciones en IA: El reinado de los GPUs** La inteligencia artificial, especialmente el aprendizaje profundo, ha revolucionado numerosas industrias. El entrenamiento de redes neuronales, que involucra realizar millones de multiplicaciones de matrices, es una tarea ideal para la arquitectura paralela de los GPUs. Por ejemplo, las series NVIDIA Tesla y AMD Radeon Instinct están diseñadas para tareas de IA y aprendizaje profundo, proporcionando un poder computacional masivo que acelera significativamente los procesos de entrenamiento en comparación con los CPUs. **Inferencia y Balance: CPUs y GPUs en Acción** En la fase de inferencia, donde se realizan predicciones utilizando un modelo entrenado, tanto CPUs como GPUs pueden ser efectivos, dependiendo de los requisitos específicos. Los CPUs pueden ser más ventajosos para la inferencia en tiempo real debido a su mejor rendimiento en un solo hilo y menor latencia, mientras que los GPUs aún tienen una ventaja significativa en tareas de inferencia por lotes. ## **Plataformas de alojamiento web, servidores y la nube: El dominio de las CPUs** Las plataformas de alojamiento web, servidores y las nubes, que forman la columna vertebral de Internet, han dependido tradicionalmente de las CPUs debido a su capacidad para realizar una amplia gama de tareas simultáneamente. Los servidores web manejan diversas tareas, como procesar solicitudes HTTP, ejecutar lógica de aplicación e interactuar con bases de datos, todas las cuales pueden beneficiarse del rendimiento superior en un solo hilo de los CPUs. **Virtualización y Contenerización: La Ventaja de los CPUs** La virtualización y la contenerización modernas, tecnologías clave en el alojamiento web, crean entornos aislados para ejecutar aplicaciones, permitiendo una mejor utilización y escalabilidad de los recursos. Los CPUs, con su robusto soporte para virtualización y conjuntos de instrucciones avanzados, son ideales para estas tareas, garantizando una gestión eficiente de las máquinas virtuales y contenedores. ## **El futuro: Sinergia entre CPUs y GPUs** Aunque los CPUs y GPUs tienen ventajas distintas, los sistemas más potentes a menudo combinan ambos puntos fuertes. En infraestructuras de IA y ML, los CPUs y GPUs trabajan juntos para optimizar el rendimiento. Los CPUs orquestan tareas, preprocessan datos y alimentan a los GPUs para cálculos paralelos pesados. Una vez que los GPUs procesan los datos, los CPUs manejan las etapas finales de análisis y toma de decisiones. **Soluciones Híbridas y Tendencias Emergentes** En el paisaje de la computación en la nube, las soluciones híbridas que combinan la potencia de CPUs y GPUs están ganando popularidad. Los proveedores de servicios en la nube, como AWS, Google Cloud y Microsoft Azure, ofrecen instancias que combinan el poder computacional de los GPUs con la versatilidad de los CPUs, ideales para aplicaciones que requieren computación intensiva y procesamiento general. Pero son GPUs de uso compartido a unos costes demasiado elevados, por ello desde **Stackscale contamos con soluciones de servidores con GPUs de uso exclusivo y costes adaptados a cada proyecto**. ### **Conclusión: Valorando ambos procesadores** El debate entre GPUs y CPUs no es sobre cuál es superior en términos generales, sino cuál es más adecuado para tareas específicas. Los GPUs dominan en IA gracias a su superior capacidad de procesamiento paralelo, mientras que los CPUs siguen siendo la columna vertebral de las plataformas de alojamiento web, proporcionando la versatilidad y el rendimiento en un solo hilo necesarios para manejar cargas de trabajo diversas y dinámicas. A medida que la tecnología avanza, la integración armoniosa de CPUs y GPUs, junto con tecnologías emergentes, impulsará la próxima ola de innovación. Aprovechar las fortalezas de cada uno para abordar desafíos computacionales cada vez más complejos y variados será clave para el éxito en el futuro de la computación. Para aquellos interesados en optimizar sus servidores para proyectos de IA, aprendizaje automático o modelos de lenguaje extensos, los GPUs pueden ser la solución adecuada. En el contexto de cloud computing, servidores bare-metal, hosting y servicios web, los CPUs seguirán desempeñando un papel esencial. --- ## How to achieve high availability with data center redundancy URL: https://www.stackscale.com/blog/how-to-achieve-high-availability-with-data-center-redundancy/ The ability to maintain a continuously operational environment is essential for ensuring business continuity and minimizing costly service interruptions. Achieving high availability is fundamental to any robust technology and infrastructure strategy, as it translates into efficient user experiences and the delivery of quality services. - The importance of redundancy in data centers - Key components requiring redundancy - The role of redundancy in enhancing high availability - Redundancy models: N+1, 2N, and 2N+1 - The relationship between redundancy levels and data center tiers In this article, we will explore the **crucial role that redundancy plays in data centers as a strategy to strengthen high availability**. We will also analyze how different redundancy models contribute to this goal and how to balance cost against reliability to achieve an optimal solution. ## The importance of redundancy in data centers Redundancy in data centers is a vital strategy that involves duplicating components or functions within a system to enhance its reliability. This practice acts as an insurance policy in terms of hardware and protocols, designed to maintain operational functionality even when parts of the infrastructure fail. Designing a system with redundancy ensures that if **one component fails, another can immediately take its place without interrupting service.** According to an Uptime Institute survey on data center resiliency, 80% of data center managers and technicians have faced some form of interruption in the last three years, which can have severe repercussions. An example of this is the **2007 incident at Los Angeles International Airport**, where a computer failure led to the disruption of international flights for nine hours, highlighting the cascading effects of system failures. Another example in the aviation sector is the **2017 British Airways outage in the United Kingdom**, where a massive issue affected their data center, leading to the cancellation of hundreds of flights and impacting more than 75,000 passengers. The cause was attributed to a power supply failure and a problematic system recovery process, underscoring the importance of proper infrastructure management and redundancy in data centers. The reliability of a data center is the silent guardian against data loss catastrophes, a buffer against downtime, and an efficiency catalyst for operations. Beyond data protection, redundancy ensures business continuity, fosters customer trust and satisfaction by providing an uninterrupted experience, and shields against potential financial losses due to operational outages. Although the initial costs of implementing redundancy measures may seem high, it’s vital to shift the perspective: **investing in redundancy is not just an expense, but a safeguard**. It is a proactive measure to prevent the potentially devastating consequences of system failures, which can cost far more in the long run than the initial investment in redundant systems. ## Key components requiring redundancy To ensure high availability, several data center components must have redundancy: - **Computing nodes or servers**: Redundancy in these computing nodes or dedicated servers allows for a smooth transition to backup servers without service interruption in the event of failures. While this aspect depends on each client and project, whenever it is necessary to have an RTO and RPO close to or equal to zero, it will be necessary to have multiple nodes, even distributed across several data centers. - **Redundant storage systems**: These ensure that there is no single point of failure within the data storage infrastructure, protecting against data loss and allowing for rapid recovery and continuity. - **Redundant cooling systems**: These are essential given the heat generated by high-power computing. Systems like CRAC (Computer Room Air Conditioning) in data centers prevent overheating and ensure optimal performance. - **Network redundancy**: This minimizes the risk of connectivity loss due to a single point of failure in the network. Stackscale exemplifies this with its geographically dispersed data centers featuring redundant network connections. - **Redundant power supplies**: Multiple UPS units and redundant battery rooms, such as those in Stackscale, ensure that even in the face of power supply interruptions, the data center continues to operate smoothly. By weaving a network of redundancy across servers (nodes), storage, power, cooling, and network systems, data centers like those operated by Stackscale are ideal for ensuring high availability. This multi-layered approach adds an extra layer of protection and ensures continuous service with maximum uptime, making it ideal for all types of mission-critical solutions. ## The role of redundancy in enhancing high availability High availability refers to a system’s ability to remain operational and accessible, minimizing the possibility of downtime that could disrupt business operations. It is a key performance metric for any data center, reflecting its reliability and efficiency. The relationship between redundancy and high availability is one of mutual reinforcement. Redundancy acts as a safety mechanism, where if one component fails, another immediately replaces it, mitigating risks and improving fault tolerance. For example, in a system with network redundancy, if a network link fails, data flow is instantly redirected through alternative routes, maintaining connectivity. Without redundancy, a single point of failure could lead to significant downtime, disrupting services and causing financial and reputational damage. Stackscale’s infrastructure solutions offer high availability. The company’s infrastructure is designed to minimize downtime through a robust and redundant environment that ensures operational continuity even when individual components fail. ## Redundancy models: N+1, 2N, and 2N+1 Redundancy models in data center design dictate the reliability and robustness of the infrastructure. Understanding the technical details of these models is crucial for tailoring the data center design to a business’s operational requirements and risk tolerance. - **N+1**: This provides a straightforward approach to redundancy, where “N” represents the number of components required to operate the system under normal conditions, and the “+1” indicates an additional backup component. - **2N**: This involves having a complete set of duplicated components for each one required, ensuring that even multiple simultaneous failures can be handled without issues. - **2N+1**: This model goes a step beyond the 2N model by adding an extra layer of protection, ideal for systems where downtime is extremely costly or dangerous. ## The relationship between redundancy levels and data center tiers Redundancy levels in data centers are closely related to data center tiers, which are typically classified from Tier 1 to Tier 4, depending on their availability and performance. These levels define the redundancy features and uptime that can be expected from a data center. Stackscale stands out for its infrastructure designed with full redundancy to provide a high-quality infrastructure experience, backed by a guaranteed uptime of 99.9%. In summary, implementing an optimal redundancy strategy is essential for ensuring high availability and fault tolerance in data centers. Stackscale positions itself as an ideal partner in the quest for a reliable and redundant infrastructure solution, offering resilient infrastructure and premium services that ensure operational continuity and business growth. --- ## Cómo lograr alta disponibilidad con redundancia en centros de datos URL: https://www.stackscale.com/blog/how-to-achieve-high-availability-with-data-center-redundancy/ La capacidad de mantener un entorno operativo de forma continua es esencial para garantizar la continuidad de negocio y minimizar interrupciones de servicio muy costosas. Alcanzar una alta disponibilidad es fundamental de cualquier estrategia de tecnología e infraestructura robusta, ya que se traduce en experiencias de usuario eficientes y en la entrega de servicios de calidad. - La importancia de la redundancia en los centros de datos - Componentes clave que requieren redundancia - El papel de la redundancia en la mejora de la alta disponibilidad - Modelos de redundancia: N+1, 2N y 2N+1 - Relación entre los niveles de redundancia y las categorías de centros de datos En este artículo, exploraremos el **papel crucial que juega la redundancia en los centros de datos como estrategia para fortalecer la alta disponibilidad**. Además, analizaremos cómo diferentes modelos de redundancia contribuyen a este objetivo y cómo equilibrar el coste frente a la fiabilidad para lograr una solución óptima. ### La importancia de la redundancia en los centros de datos La redundancia en centros de datos es una estrategia esencial que implica la duplicación de componentes o funciones dentro de un sistema para mejorar su fiabilidad. Esta práctica actúa como una póliza de seguro en términos de hardware y protocolos, diseñada para mantener la funcionalidad operativa, incluso cuando partes de la infraestructura fallan. Diseñar un sistema con redundancia garantiza que, **si un componente falla, otro pueda tomar su lugar de inmediato sin interrumpir el servicio**. Según una encuesta de Uptime Institute sobre la resiliencia de los centros de datos, el 80% de los directivos y técnicos de centros de datos han enfrentado algún tipo de interrupción en los últimos tres años, lo que puede tener repercusiones graves. Un ejemplo de ello es el incidente ocurrido en **2007 en el Aeropuerto Internacional de Los Ángeles**, donde un fallo en una computadora provocó la interrupción de vuelos internacionales durante nueve horas, resaltando los efectos en cascada de las fallas en los sistemas. También en el **sector aéreo la interrupción de British Airways en 2017 en Reino Unido**, donde un problema masivo afectó a su centro de datos provocando la cancelación de cientos de vuelos y afectando a más de 75.000 pasajeros. La causa se atribuyó a un fallo en el suministro eléctrico y el proceso de restablecimiento del sistema, de aquí la importancia de una buena gestión de la infraestructura y redundancia en los centros de datos. La fiabilidad de un centro de datos es el guardián silencioso contra las catástrofes de pérdida de datos, un amortiguador ante el tiempo de inactividad y un catalizador de eficiencia para las operaciones. Más allá de la protección de datos, la redundancia asegura la continuidad del negocio, fomenta la confianza y satisfacción del cliente al proporcionar una experiencia sin interrupciones, y protege contra las posibles pérdidas financieras derivadas de paradas operativas. Aunque los costes iniciales de implementar medidas de redundancia pueden parecer elevados, es vital cambiar la perspectiva:** invertir en redundancia no es solo un gasto, sino una salvaguarda**. Es una medida proactiva para evitar las consecuencias potencialmente devastadoras de las fallas del sistema, que pueden costar mucho más a largo plazo que la inversión inicial en sistemas redundantes. ### Componentes clave que requieren redundancia Para garantizar una alta disponibilidad, es fundamental que varios componentes del centro de datos cuenten con redundancia: - **Servidores o nodos de computación**: La redundancia en estos nodos de computación o servidores dedicados permite una transición fluida a servidores de respaldo sin interrupción del servicio en caso de fallos. Si bien esta parte depende de cada cliente y proyecto, siempre que sea necesario contar con un RTO y RPO igual a cero o cercano será necesario contar con múltiples nodos, incluso repartidos en varios centros de datos. - **Sistemas de almacenamiento redundantes**: Aseguran que no haya un único punto de fallo dentro de la infraestructura de almacenamiento de datos, protegiendo contra la pérdida de datos y permitiendo una rápida recuperación y continuidad. - **Sistemas de refrigeración redundantes**: Son esenciales, dado el calor generado por la computación de alta potencia. Sistemas como los CRAC (Computer Room Air Conditioning) en centros de datos evitan el sobrecalentamiento y aseguran un rendimiento óptimo. - **Redundancia de red**: Minimiza el riesgo de pérdida de conectividad debido a un único punto de fallo en la red. Stackscale ejemplifica esto con sus centros de datos geográficamente dispersos que cuentan con conexiones de red redundantes. - **Suministros de energía redundantes**: Como los múltiples UPS y salas de baterías redundantes en Stackscale, garantizan que, incluso ante interrupciones en el suministro eléctrico, el centro de datos siga operando sin problemas. Tejiendo una red de redundancia a través de servidores (nodos), almacenamiento, energía, refrigeración y sistemas de red, los centros de datos como los operados por Stackscale son ideales para garantizar alta disponibilidad. Este enfoque de múltiples capas añade una protección adicional y asegura un servicio continuo con el máximo tiempo de actividad, ideal para todo tipo de soluciones de misión crítica. ### El papel de la redundancia en la mejora de la alta disponibilidad La alta disponibilidad se refiere a la capacidad de un sistema para permanecer operativo y accesible, minimizando la posibilidad de inactividad que pueda interrumpir las operaciones comerciales. Es una métrica clave del rendimiento de cualquier centro de datos, reflejando su fiabilidad y eficiencia. La relación entre la redundancia y la alta disponibilidad es de refuerzo mutuo. La redundancia actúa como un mecanismo de seguridad, donde si un componente falla, otro lo reemplaza de inmediato, mitigando riesgos y mejorando la tolerancia a fallos. Por ejemplo, en un sistema con redundancia de red, si un enlace de red falla, el flujo de datos se redirige instantáneamente a través de rutas alternativas, manteniendo la conectividad. Sin redundancia, un único punto de fallo podría llevar a un tiempo de inactividad significativo, interrumpiendo servicios y causando daños financieros y de reputación. Las soluciones de infraestructura de Stackscale ofrecen alta disponibilidad. La infraestructura de la empresa está diseñada para minimizar el tiempo de inactividad mediante un entorno robusto y redundante que asegura la continuidad operativa incluso cuando fallan componentes individuales. ### Modelos de redundancia: N+1, 2N y 2N+1 Los modelos de redundancia en el diseño de centros de datos dictan la fiabilidad y robustez de la infraestructura. Comprender los detalles técnicos de estos modelos es crucial para adaptar el diseño del centro de datos a los requisitos operativos y la tolerancia al riesgo de un negocio. - **N+1**: Proporciona un enfoque sencillo a la redundancia, donde “N” representa el número de componentes necesarios para operar el sistema en condiciones normales, y el “+1” indica un componente de respaldo adicional. - **2N**: Implica tener un conjunto completo de componentes duplicados para cada uno necesario, asegurando que incluso múltiples fallos simultáneos puedan ser manejados sin problemas. - **2N+1**: Va un paso más allá del modelo 2N, añadiendo una capa extra de protección, ideal para sistemas donde el tiempo de inactividad es extremadamente costoso o peligroso. ### Relación entre los niveles de redundancia y las categorías de centros de datos Los niveles de redundancia en los centros de datos están estrechamente relacionados con las categorías de centros de datos, que se suelen clasificar de Tier 1 a Tier 4, en función de su disponibilidad y rendimiento. Estos niveles definen las características de redundancia y el tiempo de actividad que se puede esperar de un centro de datos. Stackscale destaca por su infraestructura diseñada con redundancia completa para proporcionar una experiencia de infraestructura de alta calidad, respaldada por un tiempo de actividad garantizado del 99,9%. En resumen, implementar una estrategia de redundancia óptima es esencial para garantizar una alta disponibilidad y tolerancia a fallos en los centros de datos. Stackscale se posiciona como un socio ideal en la búsqueda de una solución de infraestructura confiable y redundante, ofreciendo una infraestructura resiliente y servicios premium que aseguran la continuidad operativa y el crecimiento empresarial. --- ## ARM: una revolución para los servidores dedicados y la nube URL: https://www.stackscale.com/blog/arm-a-revolution-for-dedicated-servers-and-the-cloud/ La **arquitectura ARM**, conocida durante mucho tiempo por su predominio en dispositivos móviles, está dando un salto significativo hacia nuevas áreas tecnológicas. Recientes datos indican una tendencia creciente en la adopción de ARM en otros campos como los centros de datos, desafiando las concepciones tradicionales sobre su uso. De acuerdo con las últimas estadísticas, más del 12% de los PCs vendidos actualmente están basados en ARM, con los Macs de Apple destacándose particularmente. Pero quizás lo más sorprendente es que más del 10% de los servidores a nivel mundial ya utilizan esta arquitectura. La mayoría de estos servidores se encuentran en las granjas de hiperescalares como Amazon, que representa el 50%, y en diversas compañías chinas que suman un 40%. Son muchas las empresas las que están mostrando un gran interés por esta arquitectura para sus servidores dedicados. Creando algunas divisiones exclusivas para crear chips basados en ARM como Graviton de AWS, que están democratizando la infraestructura con esta tecnología para centros de datos. Sin embargo, la exploración y adopción de ARM no se limita solo a las grandes corporaciones. En una entrevista en “Administración de Sistemas” con David Carrero Fernández-Baillo, cofundador de Stackscale, se reveló que la tendencia hacia ARM no está pasando desapercibida en otros sectores. Carrero mencionó que muchos proveedores de infraestructura y servicios de nube privada están trabajando activamente en la integración y adopción de ARM en sus respectivos servicios y productos. Estas acciones subrayan la versatilidad y el potencial de ARM más allá de los móviles. El movimiento hacia ARM en el mundo de los servidores parece ser solo el inicio de una transformación más amplia en el panorama tecnológico. A medida que empresas como Oracle, IBM, Google o Microsoft planean migrar sus granjas de servidores a ARM en los próximos años, y gigantes tecnológicos como Apple, Amazon, Samsung, Nvidia e Intel muestran interés en invertir en ARM, es evidente que esta arquitectura tiene un futuro prometedor. También en Stackscale estamos con las últimas tecnologías y trabajando para poder ofrecer a futuro soluciones basadas en procesadores ARM para complementar la propuesta de soluciones de infraestructura de uso exclusivo para nube privada y bare-metal. ARM ya no es solo un nombre asociado con smartphones y tabletas. Su avance en el mundo de los servidores y PCs es una prueba clara de su capacidad para adaptarse y dominar en diversos nichos del mercado tecnológico. Con cada adopción y adaptación, ARM está redefiniendo las reglas del juego y mostrando que es una fuerza con la que hay que contar en el futuro de la tecnología. ## Historia y evolución de ARM, desde los móviles a los centros de datos La **historia de ARM (Advanced RISC Machines) comienza en 1983**, cuando Acorn Computers, una empresa británica de computadoras, empezó a desarrollar un procesador basado en la arquitectura RISC (Reduced Instruction Set Computing). Este procesador, conocido como Acorn RISC Machine, fue diseñado para ser más eficiente y poderoso que los procesadores CISC (Complex Instruction Set Computing) predominantes en ese momento. En 1990, Acorn Computers, Apple y VLSI Technology fundaron una empresa conjunta llamada Advanced RISC Machines Ltd., posteriormente renombrada como ARM Holdings. Esta nueva entidad tenía como objetivo desarrollar y licenciar la arquitectura ARM a otros fabricantes, en lugar de producir sus propios chips. ### Desarrollo y crecimiento Durante la década de 1990, ARM se centró en el mercado de dispositivos móviles y embebidos. Su arquitectura de bajo consumo de energía y alto rendimiento se convirtió en una elección ideal para teléfonos móviles, consolas de videojuegos portátiles y otros dispositivos electrónicos. Uno de los hitos más significativos para ARM fue la adopción de sus procesadores por Nokia en sus teléfonos móviles, lo que catapultó a ARM a una posición dominante en el mercado de la telefonía móvil. A lo largo de los años, ARM continuó innovando y mejorando su arquitectura, lanzando sucesivas generaciones de procesadores más potentes y eficientes. ### La era de los smartphones La llegada del iPhone en 2007 marcó un punto de inflexión para ARM. Apple eligió utilizar procesadores basados en ARM para sus dispositivos iOS, lo que consolidó aún más la posición de ARM en el mercado de los smartphones. Este éxito se extendió a otros fabricantes de teléfonos inteligentes y tablets, haciendo de ARM la arquitectura dominante en el mercado de dispositivos móviles. ### Expansión a nuevos mercados En la última década, ARM ha comenzado a expandirse más allá de los dispositivos móviles. La arquitectura ARM ha encontrado aplicaciones en una variedad de mercados, incluyendo la electrónica de consumo, automóviles, y más recientemente, en servidores y centros de datos. Uno de los desarrollos más destacados en este sentido ha sido la adopción de ARM en los servidores de Amazon Web Services (AWS) con sus chips Graviton, desarrollados por la división Annapurna Labs de Amazon. Estos chips han demostrado ofrecer un rendimiento competitivo y eficiencia energética, lo que ha llevado a una creciente adopción en el ámbito de la computación en la nube. ### ARM en el futuro El futuro de ARM parece prometedor. NVIDIA intentó adquirir ARM Holdings en 2020, pero finalmente los organismo de regulación no permitieron que la operación llegase a buen puerto. Finalmente en agosto de 2023 el holding de ARM salió a cotizar al Nasdaq americano. Desde sus humildes comienzos en el Reino Unido hasta convertirse en una fuerza dominante en la tecnología móvil y más allá, la evolución de ARM ha sido un viaje de innovación constante y adaptación al cambio. Con su continua expansión en nuevos mercados y aplicaciones, ARM está bien posicionada para seguir influenciando el futuro de la tecnología en múltiples frentes. --- ## ARM: A revolution for dedicated servers and the cloud URL: https://www.stackscale.com/blog/arm-a-revolution-for-dedicated-servers-and-the-cloud/ The **ARM architecture**, long known for its dominance in mobile devices, is making a significant leap into new technological areas. Recent data indicates a growing trend in the adoption of ARM in other fields, such as data centers, challenging traditional conceptions about its use. According to the latest statistics, over 12% of PCs sold today are based on ARM, with Apple’s Macs particularly standing out. But perhaps even more surprising is that over 10% of servers worldwide already use this architecture. Most of these servers are found in hyperscaler farms like Amazon, which accounts for 50%, and various Chinese companies, which together make up 40%. Many companies are showing great interest in this architecture for their dedicated servers. Some have created exclusive divisions to develop ARM-based chips, such as AWS’s Graviton, which are democratizing infrastructure with this technology for data centers. However, the exploration and adoption of ARM are not limited to large corporations alone. In an interview with David Carrero Fernández-Baillo, co-founder of Stackscale, revealed that the trend towards ARM is not going unnoticed in other sectors. Carrero mentioned that many infrastructure and private cloud service providers are actively working on integrating and adopting ARM in their respective services and products. These actions highlight the versatility and potential of ARM beyond mobile devices. The movement towards ARM in the server world seems to be just the beginning of a broader transformation in the technological landscape. As companies like Oracle, IBM, Google, and Microsoft plan to migrate their server farms to ARM in the coming years, and tech giants like Apple, Amazon, Samsung, Nvidia, and Intel show interest in investing in ARM, it is clear that this architecture has a promising future. At Stackscale, we are also staying abreast of the latest technologies and working to offer ARM-based solutions in the future to complement our infrastructure solutions for private cloud and bare-metal use. ARM is no longer just a name associated with smartphones and tablets. Its advancement in the world of servers and PCs is clear proof of its ability to adapt and dominate in various niches of the technology market. With each adoption and adaptation, ARM is redefining the rules of the game and showing that it is a force to be reckoned with in the future of technology. ## History and evolution of ARM: From mobile devices to data centers The **history of ARM (Advanced RISC Machines) begins in 1983** when Acorn Computers, a British computer company, started developing a processor based on the RISC (Reduced Instruction Set Computing) architecture. This processor, known as the Acorn RISC Machine, was designed to be more efficient and powerful than the predominant CISC (Complex Instruction Set Computing) processors at the time. In 1990, Acorn Computers, Apple, and VLSI Technology founded a joint venture called Advanced RISC Machines Ltd., later renamed ARM Holdings. The new entity aimed to develop and license the ARM architecture to other manufacturers instead of producing its own chips. ### Development and growth During the 1990s, ARM focused on the mobile and embedded device market. Its low-power, high-performance architecture became an ideal choice for mobile phones, handheld gaming consoles, and other electronic devices. One of the most significant milestones for ARM was Nokia’s adoption of its processors in their mobile phones, which catapulted ARM to a dominant position in the mobile phone market. Over the years, ARM continued innovating and improving its architecture, releasing successive generations of more powerful and efficient processors. ### The smartphone era The arrival of the iPhone in 2007 marked a turning point for ARM. Apple chose to use ARM-based processors for its iOS devices, further solidifying ARM’s position in the smartphone market. This success extended to other smartphone and tablet manufacturers, making ARM the dominant architecture in the mobile device market. ### Expansion into new markets In the past decade, ARM has begun expanding beyond mobile devices. The ARM architecture has found applications in various markets, including consumer electronics, automobiles, and more recently, in servers and data centers. One of the most notable developments in this regard has been the adoption of ARM in Amazon Web Services (AWS) servers with their Graviton chips, developed by Amazon’s Annapurna Labs division. These chips have demonstrated competitive performance and energy efficiency, leading to increasing adoption in the cloud computing realm. ### ARM in the future The future of ARM looks promising. NVIDIA attempted to acquire ARM Holdings in 2020, but the regulatory bodies ultimately blocked the deal. Finally, in August 2023, ARM Holdings went public on the American Nasdaq. From its humble beginnings in the United Kingdom to becoming a dominant force in mobile technology and beyond, ARM’s evolution has been a journey of constant innovation and adaptation to change. With its continued expansion into new markets and applications, ARM is well-positioned to continue influencing the future of technology on multiple fronts. --- ## Bare Metal as a Service: Direct access to physical servers URL: https://www.stackscale.com/blog/bare-metal-as-a-service-direct-access-to-physical-servers/ When a company needs to support its IT infrastructure, it must evaluate all available options to determine the most suitable one. The chosen solution should allow the company to be competitive and adapt flexibly to market needs. One of the most notable alternatives is **Bare Metal as a Service (BMaaS)**, a cloud solution that offers excellent results in terms of performance and flexibility. But what exactly is it, and how can it help your company achieve its technological goals? In this article, we explore this technology in depth and analyze how it can transform your infrastructure. ## What is Bare Metal as a Service (BMaaS)? Bare Metal as a Service (BMaaS) is a cloud-based IT infrastructure provision model that allows companies to rent dedicated physical servers without compromising flexibility and scalability. Unlike traditional virtualization, where hardware resources are shared among multiple users, BMaaS provides direct access to physical servers, ensuring optimal performance and enhanced security. ## Common use cases for Bare Metal as a Service (BMaaS) - **High-Performance Applications:** Companies running applications that require high performance and low latency, such as high-performance databases, real-time data analysis, or financial transaction processing, can significantly benefit from BMaaS. With direct access to dedicated physical servers, these applications can operate more efficiently and predictably, always guaranteeing optimal performance. - **Software Development and Testing:** For software development teams needing isolated and scalable development and testing environments, this is an ideal solution. By renting dedicated physical servers in the cloud, development teams can create customized environments according to their specific needs without worrying about the impact of other workloads on performance. - **Security-Sensitive Workloads:** Companies handling sensitive data or critical applications can opt for BMaaS to ensure a higher level of security and control over their infrastructure. With dedicated physical servers, they can implement customized security measures and maintain a greater degree of isolation between their workloads and those of other users in the cloud. - **High-Performance Real-Time Applications:** Sectors such as the gaming industry, online media streaming, and computational simulation require exceptional performance and low latency to provide an optimal user experience. BMaaS provides the processing power necessary to run these applications efficiently and predictably, ensuring fast response times and a seamless user experience. - **Legacy Workload Migration:** For companies looking to migrate legacy applications or monolithic workloads to the cloud, BMaaS can be an attractive option, allowing the deployment of any legacy application or monolithic workload. These are just a few examples of use cases for Bare Metal as a Service. In general, any workload that requires consistent performance, control over server configuration, or enhanced security can benefit from this solution. ## When to use Bare Metal as a Service? BMaaS is best suited for companies that require consistent and predictable performance and have specific needs for configuration and control over their infrastructure. It is ideal for resource-intensive workloads and performance-sensitive applications, such as high-speed databases or real-time data analysis applications. Compared to the public cloud, BMaaS is better suited for companies looking for a highly scalable and flexible solution and can tolerate some performance variability. It is ideal for variable workloads and applications that can benefit from the elasticity and wide range of services offered by cloud computing service providers. ## An example Imagine a rapidly growing e-commerce company. With increased traffic on its platform due to a successful campaign, the company faced challenges in maintaining site performance and availability. They opted to use Bare Metal as a Service to quickly scale their infrastructure and ensure an optimal user experience during peak demand. As a result, the company was able to meet its customers’ needs without compromising service quality. ## BMaaS solution on the rise According to a report published by Gartner in 2024, the Bare Metal as a Service market is expected to register significant growth in the coming years, driven by the growing demand for cloud infrastructure solutions that offer superior performance and greater flexibility. The adoption of this solution has been further accelerated by the global pandemic as companies seek solutions that allow them to quickly adapt to changes in the business environment. As we move into the future, Bare Metal as a Service is expected to continue playing a crucial role in the digital transformation of businesses. With benefits such as uncompromised performance, flexibility, and enhanced security, it is becoming an increasingly popular choice for companies of all sizes and sectors. In summary, Bare Metal as a Service offers an attractive solution for companies looking to optimize their technological infrastructure and remain competitive in an ever-evolving market. With its ability to deliver excellent results in terms of performance and flexibility, it can help your company achieve its technological goals and face future challenges with confidence. --- ## Bare Metal as a Service: Acceso directo a servidores físicos URL: https://www.stackscale.com/blog/bare-metal-as-a-service-direct-access-to-physical-servers/ Cuando una empresa necesita soportar su infraestructura informática, debe evaluar todas las opciones disponibles para determinar cuál es la más adecuada. La solución elegida debe permitir a la empresa ser competitiva y adaptarse de manera flexible a las necesidades del mercado. Una de las alternativas más destacadas es el **Bare Metal as a Service (BMaaS)**, una solución en la nube que ofrece excelentes resultados en términos de rendimiento y flexibilidad. ¿Pero qué es exactamente y cómo puede ayudar a su empresa a alcanzar sus objetivos tecnológicos? En este artículo, exploramos esta tecnología en profundidad y analizamos cómo puede transformar su infraestructura. ## ¿Qué es el Bare Metal as a Service (BMaaS)? El Bare Metal as a Service (BMaaS) es un modelo de provisión de infraestructuras de TI basado en la nube que permite a las empresas alquilar servidores físicos dedicados, sin comprometer la flexibilidad y escalabilidad. A diferencia de la virtualización tradicional, donde los recursos de hardware se comparten entre varios usuarios, BMaaS proporciona acceso directo a servidores físicos, garantizando un rendimiento óptimo y una seguridad reforzada. ## Casos de uso comunes para Bare Metal as a Service (BMaaS) - **Aplicaciones de Alto Rendimiento:** Empresas que ejecutan aplicaciones que requieren alto rendimiento y baja latencia, como bases de datos de alto desempeño, análisis de datos en tiempo real o procesamiento de transacciones financieras, pueden beneficiarse significativamente del BMaaS. Con acceso directo a servidores físicos dedicados, estas aplicaciones pueden operar de manera más eficiente y predecible, garantizando siempre un rendimiento óptimo. - **Desarrollo y Pruebas de Software:** Para los equipos de desarrollo de software que necesitan entornos de desarrollo y prueba aislados y escalables, esta es una solución ideal. Al alquilar servidores físicos dedicados en la nube, los equipos de desarrollo pueden crear entornos personalizados según sus necesidades específicas, sin preocuparse por el impacto de otras cargas de trabajo en el rendimiento. - **Cargas de Trabajo Sensibles en Términos de Seguridad:** Las empresas que manejan datos sensibles o aplicaciones críticas pueden optar por BMaaS para asegurar un nivel más alto de seguridad y control sobre su infraestructura. Con servidores físicos dedicados, pueden implementar medidas de seguridad personalizadas y mantener un mayor grado de aislamiento entre sus cargas de trabajo y las de otros usuarios en la nube. - **Aplicaciones en Tiempo Real de Alto Rendimiento:** Sectores como la industria de los videojuegos, el streaming de medios en línea y la simulación computacional requieren un rendimiento excepcional y baja latencia para ofrecer una experiencia de usuario óptima. BMaaS proporciona la capacidad de procesamiento necesaria para ejecutar estas aplicaciones de manera eficiente y predecible, asegurando tiempos de respuesta rápidos y una experiencia de usuario sin problemas. - **Migración de Cargas de Trabajo Legadas:** Para empresas que desean migrar aplicaciones legadas o cargas de trabajo monolíticas a la nube, BMaaS puede ser una opción atractiva, permitiendo la implementación de cualquier aplicación legada o carga de trabajo monolítica. Estos son solo algunos ejemplos de casos de uso del Bare Metal as a Service. En general, cualquier carga de trabajo que requiera un rendimiento consistente, control sobre la configuración del servidor o mayor seguridad puede beneficiarse de esta solución. ## ¿Cuándo utilizar el Bare Metal as a Service? BMaaS es más adecuado para empresas que requieren un rendimiento consistente y predecible, y que tienen necesidades específicas de configuración y control sobre su infraestructura. Es ideal para cargas de trabajo con uso intensivo de recursos y aplicaciones sensibles al rendimiento, como bases de datos de alta velocidad o aplicaciones de análisis de datos en tiempo real. En comparación con la nube pública, BMaaS es más adecuado para empresas que buscan una solución altamente escalable y flexible, y que pueden tolerar cierta variabilidad de rendimiento. Es ideal para cargas de trabajo y aplicaciones variables que pueden beneficiarse de la elasticidad y la amplia gama de servicios ofrecidos por los proveedores de servicios de computación en la nube. ## Un ejemplo Imagine el caso de una empresa de comercio electrónico en rápido crecimiento. Con el aumento del tráfico en su plataforma debido a una campaña exitosa, la empresa enfrentó desafíos para mantener el rendimiento y la disponibilidad del sitio. Optaron por utilizar Bare Metal as a Service para escalar rápidamente su infraestructura y garantizar una experiencia de usuario óptima durante los picos de demanda. Como resultado, la empresa fue capaz de satisfacer las necesidades de sus clientes sin comprometer la calidad del servicio. ## Solución BMaaS en ascenso De acuerdo con un informe publicado por Gartner en 2024, se espera que el mercado de Bare Metal as a Service registre un crecimiento significativo en los próximos años, impulsado por la creciente demanda de soluciones de infraestructura en la nube que ofrezcan un rendimiento superior y una mayor flexibilidad. La adopción de esta solución se ha acelerado aún más por la pandemia global, ya que las empresas buscan soluciones que les permitan adaptarse rápidamente a los cambios en el entorno empresarial. A medida que avanzamos hacia el futuro, se espera que Bare Metal as a Service continúe desempeñando un papel fundamental en la transformación digital de las empresas. Con beneficios como el rendimiento sin compromisos, la flexibilidad y la seguridad reforzada, está convirtiéndose en una opción cada vez más popular para empresas de todos los tamaños y sectores. En resumen, Bare Metal as a Service ofrece una solución interesante para las empresas que buscan optimizar su infraestructura tecnológica y mantenerse competitivas en un mercado en constante evolución. Con su capacidad de proporcionar resultados excelentes en términos de rendimiento y flexibilidad, puede ayudar a su empresa a alcanzar sus objetivos tecnológicos y enfrentar los desafíos del futuro con confianza. --- ## Preparing for the arrival of the NIS2 Directive URL: https://www.stackscale.com/blog/preparing-for-the-arrival-of-the-nis2-directive/ The NIS2 Directive (Network and Information Systems Directive 2) represents a crucial step in the evolution of cybersecurity in the European Union. Introduced to enhance and expand the protection provided by the 2016 NIS Directive, NIS2 addresses the increasing sophistication of cyber threats and the need for more robust and comprehensive defense. ### Key Changes in NIS2 The NIS2 Directive introduces several significant improvements: - **Expanded Scope**: The new directive covers a broader range of sectors and entities, including digital service providers, critical infrastructures, public services, and the private sector performing essential functions for society and the economy. - **Stricter Requirements**: More detailed and rigorous cybersecurity and risk management requirements are imposed. Companies must implement appropriate technical and organizational measures to prevent, detect, and respond to cyber incidents. - **Incident Reporting**: Incident reporting obligations have been strengthened, requiring entities to report significant incidents to the competent authorities within tighter deadlines and with more detail. - **Harsher Penalties**: NIS2 introduces more severe penalties for non-compliance, including substantial fines, forcing companies to take compliance seriously to avoid severe penalties. ### Measures Required by NIS2 To comply with the NIS2 Directive, entities must address aspects such as: - Risk analysis and security policies. - Comprehensive incident management. - Crisis and business continuity planning. - Supply chain security. - Vulnerability management and disclosure. - Use of cryptography and encryption. ### Affected Sectors and Entities NIS2 applies to a wide range of public and private entities that perform essential functions or manage critical infrastructures. This includes operators of essential services such as energy, transport, health, potable water, and digital infrastructures, as well as digital service providers and medium to large companies in key sectors like finance, banking, and telecommunications. ### Effective Date The NIS2 Directive must be transposed into national legislation by October 17, 2024. Companies should begin preparing to meet these new requirements to ensure the security and resilience of their operations. ### Preparations with Stackscale At Stackscale, we are ready to help companies navigate the requirements of the NIS2 Directive. We offer technological solutions designed to ensure your company complies with the new regulations. Don’t put off until tomorrow what you can do today: protect your company’s future with our data protection solutions. --- ## Preparándose para la llegada de la Directiva NIS2 URL: https://www.stackscale.com/blog/preparing-for-the-arrival-of-the-nis2-directive/ La **Directiva NIS2 (Network and Information Systems Directive 2)** representa un paso crucial en la evolución de la ciberseguridad en la Unión Europea. Introducida para mejorar y ampliar la protección proporcionada por la Directiva NIS de 2016, la NIS2 responde a la creciente sofisticación de las amenazas cibernéticas y la necesidad de una defensa más robusta y abarcadora. ## Cambios clave en la NIS2 La Directiva NIS2 introduce varias mejoras significativas: - **Ampliación del Ámbito**: La nueva directiva abarca una gama más amplia de sectores y entidades, incluyendo proveedores de servicios digitales, infraestructuras críticas, servicios públicos y el sector privado con funciones esenciales para la sociedad y la economía. - **Requisitos Más Rigurosos**: Se imponen exigencias más detalladas en términos de ciberseguridad y gestión de riesgos. Las empresas deben implementar medidas técnicas y organizativas adecuadas para prevenir, detectar y responder a incidentes cibernéticos. - **Notificación de Incidentes**: Las obligaciones de notificación de incidentes se han reforzado, requiriendo que las entidades reporten incidentes significativos a las autoridades competentes dentro de plazos más estrictos y con mayor detalle. - **Sanciones Más Severas**: La NIS2 introduce sanciones más contundentes por incumplimiento, incluyendo multas sustanciales, obligando a las empresas a tomarse muy en serio la conformidad para evitar penalizaciones graves. ## Medidas requeridas por la NIS2 Para cumplir con la Directiva NIS2, las entidades deben abordar aspectos como: - Análisis de riesgos y políticas de seguridad. - Gestión integral de incidentes. - Planificación de crisis y continuidad del negocio. - Seguridad en la cadena de suministro. - Gestión y divulgación de vulnerabilidades. - Uso de criptografía y cifrado. ## Sectores y entidades afectadas La NIS2 se aplica a una amplia gama de entidades tanto públicas como privadas que desempeñan funciones esenciales o gestionan infraestructuras críticas. Esto incluye operadores de servicios esenciales como energía, transporte, salud, agua potable e infraestructuras digitales, así como proveedores de servicios digitales y empresas de tamaño medio y grande en sectores clave como financiero, bancario y telecomunicaciones. ## Fecha de entrada en vigor La Directiva NIS2 debe ser transpuesta a la legislación nacional antes del 17 de octubre de 2024. Las empresas deben comenzar a prepararse para cumplir con estas nuevas exigencias para garantizar la seguridad y resiliencia de sus operaciones. ## Preparativos con Stackscale En Stackscale, estamos listos para ayudar a las empresas a navegar por las exigencias de la Directiva NIS2. Ofrecemos soluciones tecnológicas diseñadas para asegurar que su empresa cumpla con las nuevas regulaciones. No deje para mañana lo que puede hacer hoy: proteja el futuro de su empresa con nuestras soluciones de protección de datos. --- ## Proxmox vs VMware: Virtualization platforms comparison URL: https://www.stackscale.com/blog/proxmox-vs-vmware-virtualization-platforms-comparison/ In modern IT infrastructure, virtualization is essential to reduce costs, improve security, and facilitate management. In this article, we compare two of the leading virtualization platforms: VMware, the market leader, and Proxmox VE, an open-source solution that has gained much popularity in recent years. ## Table of contents - VMware vSphere and VMware ESXi - Proxmox Virtual Environment (VE) - Feature comparison: VMware vSphere vs Proxmox VE - Storage component comparison: VMware vSphere vs Proxmox VE - Use cases for VMware and Proxmox VE Proxmox VE use cases - VMware vSphere use cases - Which solution to choose? Looking for a cloud solution adapted to your business? ## VMware vSphere and VMware ESXi VMware offers two key products: vSphere and ESXi. VMware vSphere is a comprehensive virtualization platform that transforms data centers into aggregated computing infrastructures. vSphere manages these resources as a unified operating environment and provides tools for data center management. The main components are ESXi, the hypervisor, and vCenter Server, the management platform. VMware ESXi, a Type 1 hypervisor, used to be free, but following VMware’s acquisition by Broadcom in November 2023, the free version of ESXi is no longer available. It is now part of VMware’s commercial offerings, fully integrating with VMware’s management tools and supporting advanced features and clustering. ## Proxmox Virtual Environment (VE) Proxmox VE is an open-source server virtualization management platform that integrates the KVM hypervisor, Linux Containers (LXC), software-defined storage (CEPH), and networking functionality on a single platform. Proxmox VE is managed through an intuitive web interface, allowing the administration of virtual machines, containers, high-availability clusters, and integrated disaster recovery tools. Proxmox also offers a backup server for backing up and restoring virtual machines and containers, supporting incremental backups, deduplication, standard compression, and authenticated encryption. This solution is free with community support, although paid support is also offered. ## Feature comparison: VMware vSphere vs Proxmox VE This comparative table highlights the main differences and similarities between VMware vSphere and Proxmox VE, helping users determine which virtualization platform best fits their specific needs. At Stackscale, we can help you select the optimal solution for each project. FeatureProxmox VEVMware vSphereHypervisorKVM for VMs and LXC for containersESXiManagement InterfaceWeb InterfacevCenter ServerStorage OptionsLVM, ZFS, NFS, iSCSI, Ceph, Gluster FSVMFS, NFS, iSCSI, FC, NVMe-oF, VMware vSANHigh AvailabilitySupportedSupported, with advanced features like DRSFault ToleranceNot supportedSupportedBackup and Data ProtectionIntegrated backup utility: Proxmox VBSThird-party tools, vSphere Data ProtectionContainer SupportNative support for Linux containers (LXC)Container support via vSphere Integrated Containers (VIC)ScalabilityMinimum HA Cluster size: 3 nodesMinimum HA Cluster size: 2 nodes“Best practices” minimum size: 5 nodes“Best practices” minimum size: 3 nodesLicensing ModelOpen-source, with paid support subscriptionProprietary, subscription-based ## Storage component comparison: VMware vSphere vs Proxmox VE This table provides an overview of the storage capabilities of Proxmox VE and VMware vSphere, allowing for an easy comparison of features and functionalities for software-defined storage management. At Stackscale, we also advocate for network storage solutions that eliminate node dependency for your data in case of failure, making the replacement of computing much faster. FeatureProxmox VEVMware vSphereNetwork StorageSoftware-Defined Storage (SDS)CephVMware vSANNetApp SystemsFile SystemsZFS, CephFS, POSIX file systemsVMFSWAFL (Write Anywhere File Layout)Storage ProtocolsiSCSI, FC, NVMe-oF, NFSiSCSI, FC, NVMe-oF, NFSNFS, iSCSIBackups and Geo-replicationNot by defaultNot by defaultIncluded with geo-replication in other data centersSynchronous replication between data centersN/AN/AYes, availableSnapshots and CloningSupported with ZFSSupportedSupportedStorage MigrationSupportedSupportedSupportedStorage ScalabilityScales by adding disks or nodes. Flexibility depends on Ceph configurationScales by adding disks or nodesYesPerformance OptimizationCaching, cache tieringAdvanced storage performance features with DRS, Storage I/O ControlAvailable Premium, Flash Plus, Flash Standard, and Archive solutionsDeduplication and CompressionSupportedSupportedSupportedSDS LicensingOpen-source, with optional commercial supportProprietary, subscription-basedIncluded in Stackscale service ## Use cases for VMware and Proxmox VE The platforms have much in common and offer an excellent virtualization experience. The reality is that both solutions can support the same use cases, and the final decision will depend on the project details and the decisions of the technical teams. Here are some examples of use cases for both solutions, but all use cases are possible with both hypervisors. Contact us at Stackscale for advice on the best solution. ### Proxmox VE use cases - **Small and Medium-Sized Businesses (SMBs):** Due to its cost-effectiveness and open-source nature, Proxmox is ideal for SMBs that require a robust virtualization solution without significant investment. - **Educational Institutions and NGOs:** Organizations with limited budgets find Proxmox appealing because it offers a comprehensive set of features at a lower cost. - **DevOps and Containers:** Proxmox provides strong support for containerized applications using LXC, making it suitable for DevOps environments where containerization is a priority. - **Organizations Preferring Open Source:** Companies that prefer open-source solutions for customization, transparency, or to avoid vendor lock-in. ### VMware vSphere use cases - **Large Enterprises and Data Centers:** VMware vSphere is a standard in many large enterprises and data centers due to its scalability, robustness, and extensive feature set. - **Mission-Critical Applications:** Organizations running applications that require advanced fault tolerance and seamless disaster recovery. - **Organizations with Windows Guest VMs:** VMware’s ESXi hypervisor is known for its excellent performance and integration with Windows-based systems, making it a preferred choice in Windows-dominant environments. - **Complex, Multi-Site Environments:** vSphere’s advanced networking, storage capabilities, and extensive third-party integrations make it suitable for complex, geographically dispersed infrastructure. - **Businesses Requiring Advanced Resource Management:** Enterprises needing sophisticated resource scheduling, balancing, and optimization. - **Cloud Integration:** VMware’s strong cloud integration features, including support for hybrid cloud environments, make it ideal for organizations pursuing a cloud-first strategy. ## Which solution to choose? There is no single ideal platform among VMware vSphere, Proxmox VE, and other virtualization solutions. Choosing the right platform depends on your organization’s specific needs and requirements. Each platform offers enterprise-grade features and can be tailored to different use cases. VMware vSphere is often chosen for large-scale, complex deployments due to its robust feature set and extensive support. It is ideal for organizations that require high performance, advanced management tools, and scalability. Proxmox VE is favored for smaller, budget-conscious environments. It provides a comprehensive set of features and is open-source, making it an attractive option for organizations that need powerful virtualization capabilities without the associated costs of commercial solutions. - Dutch version: Proxmox vs VMware: Vergelijking van virtualisatieplatforms - Spanish version: Proxmox vs VMware: Comparativa de plataformas de virtualización - French version: Proxmox vs VMware : Comparaison des plateformes de virtualisation - German version: Proxmox vs VMware: Vergleich der Virtualisierungsplattformen ### Looking for a cloud solution adapted to your business? Tell us about your project and we will help you find a solution that adapts to your needs. Solutions form EN Newsletter NameEmailPhoneTell us about your needs I give my consent to receiving customized commercial communications about Stackscale products and services (including the newsletter), by any channel, including electronic ones. I have read and accept the privacy policy. Submit The Stackscale Group processes the information you provide in order to respond to your request regarding the services we deliver and the products we provide. The data provided will be stored while we stay in contact and deleted when the request is closed, unless you consent to receiving sales communications, in which case your data will be stored until the previously given consent is revoked. As part of the Group to which Stackscale belongs, we inform you that your data will be communicated to the companies of Grupo Aire for corporate reasons. You can consult the companies integrating Grupo Aire at: https://grupoaire.es. You can exercise your rights of access, rectification, erasure, disagreement, limitation of the processing and, when legally appropriate, portability, by sending a request to Stackscale to the address dp*@********le.com, indicating the right you exercise and providing a double-sided photocopy of your identification. Additionally, you will be able to present a complaint to the Dutch Data Protection Authority, especially when you are not content with the exercise of your rights, via https://autoriteitpersoonsgegevens.nl/en. --- ## Proxmox vs VMware: Comparativa de plataformas de virtualización URL: https://www.stackscale.com/blog/proxmox-vs-vmware-virtualization-platforms-comparison/ En la infraestructura IT moderna, la virtualización es esencial para reducir costes, mejorar la seguridad y facilitar la gestión. En este artículo, comparamos dos de las plataformas de virtualización más destacadas: **VMware**, líder del mercado, y **Proxmox VE**, una solución de código abierto que ha ganado mucha popularidad en los últimos años. ## VMware vSphere y VMware ESXi VMware ofrece dos productos clave: **vSphere y ESXi**. VMware vSphere es una plataforma integral de virtualización que convierte los centros de datos en infraestructuras de computación agregadas. vSphere administra estos recursos como un entorno operativo unificado y proporciona herramientas para la administración de centros de datos. Los componentes principales son ESXi, el hipervisor, y vCenter Server, la plataforma de gestión. **VMware ESXi**, un hipervisor de tipo 1, solía ser gratuito, pero tras la adquisición de VMware por Broadcom en noviembre de 2023, la versión gratuita de ESXi ya no está disponible. Ahora forma parte de las ofertas comerciales de VMware, integrándose completamente con las herramientas de gestión de VMware y soportando características avanzadas y de clustering. ## Proxmox Virtual Environment (VE) **Proxmox VE** es una plataforma de gestión de servidores de virtualización de código abierto que integra el hipervisor KVM, contenedores Linux (LXC), almacenamiento definido por software (CEPH) y funcionalidad de red en una sola plataforma. Proxmox VE se gestiona a través de una interfaz web intuitiva, permitiendo la administración de máquinas virtuales, contenedores, alta disponibilidad de clústeres y herramientas integradas de recuperación ante desastres. Proxmox también ofrece un servidor de respaldo para realizar copias de seguridad y restauración de máquinas virtuales y contenedores, soportando backups incrementales, deduplicación, compresión estándar y encriptación autenticada. Esta solución es gratuita con soporte comunitario, aunque también se ofrece soporte de pago. ## Comparativa de características: VMware vSphere vs Proxmox VE Esta tabla comparativa destaca las principales diferencias y similitudes entre VMware vSphere y Proxmox VE, ayudando a los usuarios a determinar cuál plataforma de virtualización se adapta mejor a tus necesidades específicas. Si bien desde Stackscale podemos ayudarte a seleccionar la solución óptima para cada proyecto. **Característica****Proxmox VE****VMware vSphere****Hipervisor**KVM para VMs y LXC para contenedoresESXi**Interfaz de Gestión**Interfaz WebvCenter Server**Opciones de Almacenamiento**LVM, ZFS, NFS, iSCSI, Ceph, Gluster FSVMFS, NFS, iSCSI, FC, NVMe-oF, VMware vSAN**Alta Disponibilidad**SoportadaSoportada, con características avanzadas como DRS**Tolerancia a Fallos**No soportadaSoportada**Respaldo y Protección de Datos**Utilidad de respaldo integrada: Proxmox VBSHerramientas de terceros, vSphere Data Protection**Soporte para Contenedores**Soporte nativo para contenedores Linux (LXC)Soporte de contenedores a través de vSphere Integrated Containers (VIC)**Escalabilidad**Tamaño mínimo del clúster HA: 3 nodosTamaño mínimo del clúster HA: 2 nodos“Mejores prácticas” tamaño mínimo: 5 nodos“Mejores prácticas” tamaño mínimo: 3 nodos**Modelo de Licencia**Código abierto, con suscripción de soporte pagadoPropietario, basado en suscripción ## Comparativa de componentes de almacenamiento: VMware vSphere vs Proxmox VE Esta tabla ofrece una visión general de las capacidades de almacenamiento de Proxmox VE y VMware vSphere, permitiendo una fácil comparación de las características y funcionalidades para la gestión de almacenamiento definido por software. Pero en Stackscale también **apostamos por las soluciones de almacenamiento en red que eliminan la dependencia de los nodos para tus datos en caso de fallo**, y que la sustitución de la computación pueda ser mucho más rápida. **Característica****Proxmox VE****VMware vSphere****Almacenamiento en red****Almacenamiento Definido por Software (SDS)**CephVMware vSANCabinas NetApp**Sistemas de Archivos**ZFS, CephFS, sistemas de archivos POSIXVMFSWAFL (Write Anywhere File Layout)**Protocolos de Almacenamiento**iSCSI, FC, NVMe-oF, NFSiSCSI, FC, NVMe-oF, NFSNFS, iSCSI**Backups y Georeplicación**No por defectoNo por defectoIncluido con georeplicación en otro centros de datos**Replicación sincrona entre centros de datos**N/AN/ASi, disponible.**Instantáneas y Clonación**Soportado con ZFSSoportadoSoportado**Migración de Almacenamiento**SoportadoSoportadoSoportado**Escalabilidad del Almacenamiento**Escala añadiendo discos o nodos. La flexibilidad depende de la configuración de CephEscala añadiendo discos o nodosSí**Optimización del Rendimiento**Caching, cache tieringCaracterísticas avanzadas de rendimiento de almacenamiento con DRS, Control de E/S de almacenamientoDisponibles soluciones Premium, Flash Plus, Flash Standard y Archive**Desduplicación y Compresión**SoportadoSoportadoSoportado**Licenciamiento de SDS**Código abierto, con soporte comercial opcionalPropietario, basado en suscripciónIncluido en servicio de Stackscale ## Casos de uso para VMware y Proxmox VE Las plataformas tienen mucho en común y ofrecen una excelente experiencia de virtualización, la realidad es que ambas soluciones pueden soportar los mismo casos de uso y la decisión final dependerá de los detalles del proyecto, así como de las decisiones de los equipos técnicos. Aquí os damos algunos ejemplos de uso en ambas soluciones, pero todos los casos de uso son posibles en ambos hipervisores. **Escríbenos para que desde Stackscale podamos asesorarte en la mejor solución.** ### Casos de uso de Proxmox VE - **Pequeñas y medianas empresas (PYMEs):** Debido a su rentabilidad y naturaleza de código abierto, Proxmox es ideal para PYMEs que requieren una solución de virtualización robusta sin una inversión significativa. - **Instituciones educativas y ONGs:** Organizaciones con presupuestos limitados encuentran a Proxmox atractivo porque ofrece un conjunto de características completas a un costo más bajo. - **DevOps y contenedores:** Proxmox proporciona un fuerte soporte para aplicaciones en contenedores utilizando LXC, lo que lo hace adecuado para entornos DevOps donde la contenedorización es una prioridad. - **Organizaciones que prefieren código abierto:** Empresas que prefieren soluciones de código abierto para personalización, transparencia o para evitar el bloqueo del proveedor. ### Casos de uso de VMware vSphere - **Grandes empresas y centros de datos:** VMware vSphere es un estándar en muchas grandes empresas y centros de datos debido a su escalabilidad, robustez y amplio conjunto de características. - **Aplicaciones críticas:** Organizaciones que ejecutan aplicaciones que requieren tolerancia a fallos avanzada y recuperación ante desastres sin problemas. - **Organizaciones con máquinas virtuales de Windows:** El hipervisor ESXi de VMware es conocido por su excelente rendimiento e integración con sistemas basados en Windows, lo que lo hace una opción preferida en entornos dominados por Windows. - **Entornos complejos y multisitio:** Las capacidades avanzadas de red, almacenamiento y amplias integraciones de terceros de vSphere lo hacen adecuado para infraestructuras complejas y dispersas geográficamente. - **Empresas que requieren gestión avanzada de recursos:** Empresas que necesitan programación sofisticada de recursos, balanceo y optimización. - **Integración con la nube:** Las fuertes características de integración con la nube de VMware, incluido el soporte para entornos de nube híbrida, lo hacen ideal para organizaciones que persiguen una estrategia de nube primero. ## ¿Qué solución elegir? No existe una plataforma ideal única entre VMware vSphere, Proxmox VE y otras soluciones de virtualización. Elegir la plataforma adecuada depende de las necesidades y requisitos específicos de tu organización. Cada plataforma ofrece características de grado empresarial y puede adaptarse a diferentes casos de uso. VMware vSphere a menudo se elige para implementaciones a gran escala y complejas debido a su robusto conjunto de características y amplio soporte. Es ideal para organizaciones que requieren alto rendimiento, herramientas de gestión avanzadas y escalabilidad. Proxmox VE es preferido para entornos más pequeños y conscientes del presupuesto. Proporciona un conjunto completo de características y es de código abierto, lo que lo convierte en una opción atractiva para organizaciones que necesitan capacidades de virtualización potentes sin los costes asociados a las soluciones comerciales. - Versión inglés: Proxmox vs VMware: Virtualization platforms comparison - Versión holandés: Proxmox vs VMware: Vergelijking van virtualisatieplatforms - Versión francés: Proxmox vs VMware : Comparaison des plateformes de virtualisation - Versión Alemán: Proxmox vs VMware: Vergleich der Virtualisierungsplattformen ### ¿En busca de una solución cloud que se adapte a tu negocio? Cuéntanos tu proyecto y te ayudamos a encontrar una solución que se adapte a tus necesidades. Solutions form ES Contact NombreEmailTeléfonoCuéntanos qué necesitas Acepto el envío de comunicaciones comerciales personalizadas sobre los productos y servicios de Stackscale (incluida la newsletter), por cualquier medio, incluidos los electrónicos. He leído y acepto la política de privacidad. Enviar El Grupo Stackscale trata la información que nos facilita con el fin de dar respuesta a la solicitud realizada en relación con los servicios que prestamos y los productos que suministramos. Los datos proporcionados se conservarán mientras se mantenga el contacto siendo eliminados una vez finalizada la solicitud, a no ser que consienta el envío de comunicaciones comerciales, donde sus datos se conservarán hasta la revocación del consentimiento previamente otorgado. En el marco del Grupo al que pertenece Stackscale, se le informa de que sus datos serán comunicados a las empresas de Grupo Aire por motivos corporativos. Puede consultar las empresas que forman parte del Grupo Aire en: https://grupoaire.es. Usted puede ejercitar sus derechos de acceso, rectificación, supresión, oposición, limitación del tratamiento y, cuando legalmente proceda, portabilidad, mediante el envío a Stackscale de una solicitud a la dirección dp*@********le.com, indicando el derecho que ejercita y aportando una fotocopia por las dos caras de su DNI o documento legal de identificación de su identidad. Igualmente, podrá presentar una reclamación ante la Agencia Española de Protección de Datos, especialmente cuando no haya obtenido la satisfacción en el ejercicio de sus derechos, a través de la sede electrónica en www.aepd.es. --- ## Protección de datos y soberanía de datos en la economía digital URL: https://www.stackscale.com/blog/data-protection-sovereignty-digital-economy/ La protección de datos y la soberanía de datos son cada vez más importantes en la economía digital — tanto que incluso existe el día de la privacidad de datos, que se celebra cada 28 de enero, desde 2007—. ## ¿Por qué? Porque a medida que los datos se vuelven cada vez más valiosos para los individuos, las organizaciones y las instituciones, la soberanía, la protección y la privacidad de los datos se han convertido en **aspectos clave para generar confianza y crear valor añadido**. Dado el papel protagonista de los datos en la economía moderna, la protección y privacidad de datos se ha convertido en **un derecho esencial**. Lo cual también ha impulsado la adopción de medidas en torno a la soberanía de datos en todo el mundo a fin de proteger los datos de los ciudadanos. Aunque, por supuesto, este enfoque proactivo de la gestión de los datos no solo beneficia a los individuos sino también a las empresas y naciones. ## ¿Qué es la protección de datos? ** La protección de datos** hace referencia al proceso de **salvaguardar datos importantes, confidenciales y personales **para evitar que se corrompan, se comprometan o se pierdan. También se conoce como privacidad de los datos o privacidad de la información. La protección de datos también consiste en **asegurar que los datos solo sean accesibles para fines autorizados** y que puedan restaurarse en caso de que, por algún motivo, se vuelvan inutilizables o inaccesibles. A este respecto, las soluciones de Disaster Recovery también están en auge. Durante los últimos años **muchos países y regiones han aprobado reglamentos de protección de datos**. El Reglamento General de Protección de Datos (RGPD) de la Unión Europea es uno de los más conocidos, pero hay muchos otros como la Ley de protección de datos personales en Canadá (*Privacy Act* en inglés) o la Ley general de protección de datos personales en Brasil (*Lei Geral de Proteção de Dados Pessoais* en portugués). ### Día de la Privacidad de Datos **El Día de la Protección de Datos o Día de la Privacidad de Datos se celebra internacionalmente el 28 de enero**, desde 2007. Su objetivo es promover buenas prácticas y concienciar sobre la importancia de proteger los datos personales y confidenciales. Este día conmemora el primer instrumento internacional legalmente vinculante sobre protección de los datos, adoptado en el Convenio 108 en el Consejo de Europa el 28 de enero de 1981 en Estrasburgo. #### Convenio 108 y 108+ El Convenio 108 o «**Convenio para la protección de las personas con respecto al tratamiento automatizado de datos de carácter personal**» es el primer instrumento legal internacional creado para proteger a los individuos de los abusos derivados de la recopilación y el procesamiento de los datos personales. También regula la transferencia transfronteriza de datos personales a ubicaciones geográficas que no estén amparadas por una protección legal equivalente. Este convenio **se actualizó en 2018 como Convenio 108+**. ## ¿Qué es la soberanía de datos? ** La soberanía de datos** es un concepto que se refiere al hecho de que **los datos que procesa una organización están sujetos a las leyes y regulaciones del país o región en el que están ubicados**. Es decir, las empresas deben cumplir con las regulaciones, normas y buenas prácticas de privacidad de datos de la ubicación en la que se encuentran o prestan servicios. La soberanía de datos también hace referencia a la **capacidad de las organizaciones de operar de forma independiente** y proteger sus datos frente a posibles injerencias.  Durante los últimos años, **muchos gobiernos han aprobado leyes relativas a cómo se almacenan, protegen y usan los datos**. No solo para proteger los datos de sus ciudadanos, sino también para evitar que otras naciones puedan obtenerlos. Ya que las regulaciones de datos también delimitan el modo en que los negocios y organizaciones pueden transferir datos personales al extranjero. En este sentido, el marco regulatorio Europeo —que limita la transferencia de datos personales fuera de la Unión Europea— se ha convertido en un estándar y es un paso adelante en lo que respecta a la soberanía de datos. ** La protección y la soberanía de datos son aspectos importantes a la hora de migrar a la nube**. Al externalizar la infraestructura IT, las empresas deben saber dónde están alojados sus datos, así como confiar en servicios y centros de datos que les permitan cumplir con las regulaciones de las ubicaciones en las que operan. ### ¿Por qué es importante la soberanía de datos? La soberanía de datos es importante porque **ayuda a los países a proteger los datos privados y confidenciales de ciudadanos y empresas**, así como a evitar que otros países adquieran dichos datos. La protección de la privacidad de los datos es más importante que nunca y las empresas deben garantizar que la información sensible de sus clientes y empleados esté protegida independientemente de dónde se almacene y se comparta. ### Soberanía de datos vs. Residencia de los datos Cuando hablamos de soberanía de datos, los conceptos «residencia de los datos» y «localización de los datos» suelen aparecer en la conversación. Así que veámos cuál es la **diferencia entre soberanía de los datos, residencia de los datos y localización de los datos**. - La **residencia de los datos **hace referencia a la ubicación geográfica en la que las organizaciones especifican que recopilan, procesan y almacenan sus datos. - La **localización de los datos** se refiere al hecho de que los datos deben permanecer dentro de las fronteras del país o región en el que han sido creados. - La **soberanía de los datos** se refiere al hecho de que los datos están sujetos a las leyes y regulaciones del país o región en el que se almacenan físicamente. ## ¿Qué es la soberanía digital? ** La soberanía digital**, también conocida como «soberanía tecnológica», es la capacidad de un Estado o región para controlar sus recursos digitales, manteniéndolos alejados de influencias externas. La soberanía digital en la Unión Europea se ve como un asunto estratégico a fin de fortalecer el rol de la UE en la economía digital; promoviendo y protegiendo los valores fundamentales de la Unión. El concepto de soberanía digital se centra en conseguir una **menor dependencia en infraestructuras, plataformas y puntos de acceso a Internet extranjeros**, entre otras cosas. ### Soberanía digital vs soberanía de datos Ambos conceptos destacan la importancia de proteger los datos y recursos digitales frente a posibles interferencias externas. Sin embargo, mientras la soberanía digital se centra en la capacidad de mantener el control de los recursos digitales y tecnológicos, la soberanía de datos se centra en el cumplimiento de las regulaciones y directrices de datos dentro de las ubicaciones geográficas en las que operan las empresas. ## Estrategia digital de la UE La estrategia digital de la UE está enfocada en **fortalecer la soberanía digital europea y establecer estándares**. A fin de crear una economía digital fuerte y competitiva, se centra en aspectos como: - Impulsar el **potencial de crecimiento de la economía digital**, adoptando tecnologías que respeten los valores europeos. - **Empoderar a los ciudadanos a tomar conciencia de cómo actúan e interactúan con los datos**, tanto online como offline. - Construir una **economía climáticamente neutra y con eficiencia de recursos**. - Mejorar el **acceso a los bienes y servicios digitales por toda Europa**, tanto para los consumidores como para las empresas. - Apoyar el desarrollo, despliegue y adopción de una **Inteligencia Artificial** confiable. ### Década Digital de Europa El marco de trabajo de la Década Digital de Europa tiene como objetivo guiar la transformación digital de la Unión Europea, con el foco en cuatro áreas: conectividad, competencias digitales, negocios digitales y servicios públicos digitales. Con el fin de permitir que todo el mundo saque partido de las oportunidades y beneficios de la sociedad digital. El marco de trabajo incluye: - **Metas** u objetivos medibles relativos a las áreas mencionadas antes. Los objetivos principales se pueden resumir de la siguiente manera: Una población con competencias digitales y profesionales digitales altamente cualificados. - Infraestructuras digitales seguras y sostenibles. - Transformación digital de las empresas. - Digitalización de los servicios públicos. - **Objetivos** que ayuden a guiar las acciones de los Estados Miembros. - Un **programa político** que permita alcanzar las metas y objetivos de la Década Digital, y que facilite la colaboración entre la UE y los Estados Miembros. - **Proyectos plurinacionales** que permitan a los Estados Miembros poner en común las inversiones y lanzar proyectos transfronterizos. - **Derechos y principios** que reflejen los valores de la Unión Europea. #### Objetivos para 2030 La lista de objetivos a alcanzar para 2030 incluye, entre otros: - Que el 100 % de los **servicios públicos esenciales** estén disponibles en línea, tanto para los ciudadanos como paras las empresas. - Que el 100 % de los ciudadanos europeos tengan **acceso a informes sanitarios electrónicos**. - Que el 75 % de las empresas de la UE usen **servicios cloud, Big Data e Inteligencia Artificial** (IA). Cabe destacar que en 2021, el índice de adopción cloud en la Unión Europea entre las empresas era de en torno al 41 %. - Que al menos el 80 % de la población de Europa tenga **competencias digitales básicas**. ### Ley de Servicios Digitales y Ley de Mercados Digitales La Ley de Servicios Digitales (DSA, por las siglas en inglés de *Digital Services Act*) y la Ley de Mercados Digitales (DMA, por las siglas en inglés de *Digital Markets Act*) son propuestas legislativas de la Comisión Europea que juegan un papel importante dentro de la estrategia digital europea. La DSA y la DMA forman un paquete de nuevas normas aplicables en toda la Unión Europea para **crear un espacio digital más seguro, competitivo y abierto**. ## Normativa de soberanía de datos de la UE A raíz del lanzamiento de su regulación principal en 2016, el Reglamento General de Protección de Datos (RGPD), la Unión Europea es **líder en protección de datos a nivel mundial**. Tras esta regulación, la UE ha aprobado otras leyes como el reglamento sobre la libre circulación de datos no personales (FFD) en 2018 y el Reglamento Europeo de Ciberseguridad y la Directiva sobre datos abiertos en 2019. ### Reglamento General de Protección de datos (RGPD) El Reglamento General de Protección de datos (RGPD) unifica las **regulaciones de la protección de datos dentro de la Unión Europea**. Establece normas estrictas sobre cómo se deben almacenar, recolectar y procesar los datos personales de los ciudadanos de la UE; tanto dentro como fuera de la Unión Europea. El RGPD entró en vigor en mayo de 2016, con mayo de 2018 como fecha límite para que cada Estado miembro lo incorporara a su legislación. Este reglamento reemplazó a la Directiva Europea de Protección de Datos de 1995. El RGPD aplica tanto a los controladores de datos —organizaciones que usan servicios cloud que procesan datos de ciudadanos de la UE— como a los procesadores de datos —organizaciones que proporcionan servicios cloud que procesan datos de ciudadanos de la UE—. ### Directiva sobre protección de datos en el ámbito penal (LED) La directiva sobre protección de datos en el ámbito penal (LED, por las siglas en inglés *Law Enforcement Directive*), es una legislación que establece las normas para procesar datos por parte de las autoridades policiales y judiciales, y para el libre movimiento de dichos datos. Entró en vigor en mayo de 2016, con mayo de 2018 como fecha límite para que cada Estado miembro la incorporara a su legislación. ### Reglamento sobre la libre circulación de datos no personales (FFD) El objetivo del reglamento sobre la libre circulación de datos no personales es impulsar los beneficios de la economía de datos. Está vigente desde mayo de 2019. El FFD contribuye a la creación de una economía digital competitiva dentro de la UE. Junto con el RGPD, busca garantizar el libre movimiento de datos no personales entre los Estados miembros de la Unión Europea. ### Reglamento Europeo de Ciberseguridad El Reglamento Europeo de Ciberseguridad establece un marco de certificación de ciberseguridad en la UE para productos, servicios y procesos digitales. Además de fortalecer a la Agencia de la Unión Europea para la Ciberseguridad (ENISA). ### Directiva sobre datos abiertos La Directiva sobre datos abiertos proporciona un marco legal común para facilitar la reutilización de la información del sector público. Además, tiene como objetivo poner los datos de alto valor a disposición para su reutilización y reforzar la transparencia. La directiva entró en vigor en julio de 2019. ### Ley de Gobernanza de Datos La Ley de Gobernanza de Datos, adoptada por la Comisión Europea en noviembre de 2020, tiene como objetivo impulsar que se compartan datos entre sectores y Estados miembros para aprovechar el potencial de los datos en beneficio de los ciudadanos y organizaciones de la UE. ### Ley de IA La Ley de IA se centra en establecer normas para garantizar una Inteligencia Artificial confiable que respete los derechos fundamentales y la democracia, al mismo tiempo que permite a los negocios aprovechar las oportunidades y beneficios que puede aportar. En resumen, no cabe duda de que **la protección y la soberanía de datos son una prioridad** hoy en día. El sector IT está en continua evolución y las nuevas tendencias y tecnologías como el cloud, la Internet de las cosas o la IA están cada vez más presentes en nuestro día a día. Un ejemplo claro es cómo la adopción cloud entre las empresas de la UE sigue creciendo. En este sentido, la UE está haciendo grandes esfuerzos para proteger la soberanía digital, e impulsar la innovación y la competitividad en la Unión Europea. En Stackscale, la protección y seguridad de los datos también son una prioridad. Por eso desarrollamos productos y servicios con **la seguridad, la privacidad, la transparencia y la eficiencia** siempre en mente. Además, nos sentimos orgullosos de poder decir que usamos estándares y protocolos abiertos para desarrollar nuestras soluciones de Cloud Privado y Bare Metal, para que **los clientes puedan mantener un mayor control sobre su entorno IT**. --- ## Data protection and data sovereignty in the digital economy URL: https://www.stackscale.com/blog/data-protection-sovereignty-digital-economy/ Data protection and data sovereignty are increasingly important in the digital economy — so much that there is even a Data Privacy Day, celebrated every January 28th, since 2007. ## Why is it so? Because as data becomes more and more valuable for individuals, organizations and institutions, data sovereignty, protection and privacy have become** key aspects for building trust and creating added value**. Due to the leading role of data in our modern economy, data protection and data privacy have become **an essential right**. As a result, data sovereignty measures have also been adopted around the world to protect citizens’ data. Although it goes without saying that this proactive approach to data management does not only benefit individuals but also companies and nations. ## What is data protection? ** Data protection** refers to the process of **safeguarding important, confidential and personal data **to prevent it from getting corrupted, compromised or lost. It is also known as data privacy and information privacy. Data protection also consists of **ensuring that data is only accessible for authorized purposes** and that it can be restored in the event of being rendered unusable or inaccessible for some reason. In this regard, Disaster Recovery solutions are also on the rise. During the past years, **many countries and regions have passed data protection regulations**. The European Union’s General Data Protection Regulation (GDPR) is one of the most well-known rules, but there are many others, such as the Privacy Act in Canada or the General Personal Data Protection Law in Brazil (*Lei Geral de Proteção de Dados Pessoais* in Portuguese). ### Data Privacy Day **The Data Protection Day or Data Privacy Day has been celebrated internationally on January 28th**, since 2007. Its goal is to promote best practices and raise awareness about the importance of protecting personal and confidential data. This day commemorates the first legally binding international instrument on data protection, adopted in the Council of Europe’s Convention 108 on January 28th, 1981 in Strasbourg. #### Convention 108 and 108+ The Convention 108 or “**Convention for the protection of individuals with regard to the automatic processing of personal data**” is the first legal instrument created to protect individuals against abuses derived from the collection and processing of personal data. It also regulates the transborder transfer of personal data to geographical locations that do not provide an equivalent legal protection. This convention was **updated in 2018 as Convention 108+**. ## What is data sovereignty? ** Data sovereignty** is a concept that refers to the fact that **data processed by an organization is subject to the laws and regulations of the country or region where it is located**. It is to say, businesses must comply with data privacy regulations, guidelines and best practices within their location or the location where they provide their services. Data sovereignty also refers to **the organizations’ ability to operate independently** and to protect their data against potential interferences.  During the last years, **many governments have passed laws regarding how data is stored, protected and used**. Not only to protect their citizens’ data, but also to avoid other nations acquiring it. Since data regulations also limit how businesses and organizations can transfer personal data abroad. On this matter, the European regulatory framework — limiting personal data transfer outside the European Union — has become a standard and is a step forward in respect to data sovereignty. ** Data protection and sovereignty are important aspects to consider when migrating to the cloud**. When outsourcing their IT infrastructure, companies must know where their data is hosted, as well as relying on services and data centers that enable them to comply with the regulations of the locations they are operating in. ### Why is data sovereignty important? Data sovereignty is important because **it helps countries to protect their citizens and companies’ private and confidential data**, as well as to avoid other countries acquiring that data. Data privacy protection is more important than ever and companies must ensure their customers and employees’ sensitive data is safe wherever that data is stored and shared. ### Data sovereignty vs Data residency When talking about data sovereignty, the concepts of “data residency” and “data localisation” often come up in the conversation. So, let’s see what’s the **difference among data sovereignty, data residency and data localisation**. - **Data residency **refers to the geographical location where organizations specify their data is collected, processed and stored. - **Data localisation** refers to the fact data must stay within the borders of the country or region where it was created. - **Data sovereignty** refers to the fact that data is also subject to the laws and regulations of the country or region where it is physically stored. ## What is digital sovereignty? ** Digital sovereignty**, also known as “technological sovereignty”, is the ability of a State or region to control their digital resources, keeping them away from external influences. Digital sovereignty in the European Union is seen as a strategic matter in order to strengthen the EU’s role in the digital economy, promoting and protecting the Union’s fundamental values. The concept of digital sovereignty is focused on achieving **a lower dependence on overseas infrastructures, platforms, Internet access points**, etc. ### Digital sovereignty vs data sovereignty Both concepts highlight the importance of protecting data and digital assets against potential external interference. However, while digital sovereignty focuses on the ability to keep control of digital and technological resources, data sovereignty focuses on the compliance with data regulations and guidelines within the geographical locations businesses operate in. ## EU Digital Strategy The EU’s digital strategy is focused on **strengthening European digital sovereignty as well as on setting standards**. In order to create a strong, competitive digital economy, it focuses on aspects such as: - Boosting the **growth potential of the digital economy**, while adopting technologies that respect European values. - **Empowering citizens to be aware of how they act and interact with data**, both online and offline. - Building a **climate-neutral and resource-efficient economy**. - Improving **access to digital goods and services across Europe**, both for consumers and businesses. - Supporting the development, deployment and adoption of a trustworthy **Artificial Intelligence**. ### Europe’s Digital Decade Europe’s Digital Decade framework aims to guide the digital transformation of the European Union, focusing on four areas: connectivity, digital skills, digital businesses and digital public services. Thus enabling everyone to leverage the opportunities and benefits of the digital society. The framework includes: - **Targets** or measurable goals regarding the aforementioned areas. The main goals can be summarized as follows: A digitally skilled population and highly skilled digital professionals. - Secure and sustainable digital infrastructures. - Digital transformation of businesses. - Digitalisation of public services. - **Objectives** that help guide Member State actions. - A **policy programme** to allow reaching the Digital Decade targets and objectives, enabling collaboration between the EU and Member States. - **Multi-country projects** to allow Member States to pool investments and launch cross-border projects. - **Rights and principles** that reflect European Union values. #### Goals for 2030 The list of goals to be achieved by 2030 includes, but is not limited to: - 100% of **essential public services** should be available online, both for citizens and businesses. - 100% of European citizens should have **access to electronic health records**. - 75% of EU enterprises should use **cloud services, Big Data and Artificial Intelligence** (AI). It is worth noting that in 2021, the European Union’s cloud adoption rate among enterprises was around 41%. - At least 80% of Europe’s population should have **basic digital skills**. ### Digital Services Act and Digital Markets Act The Digital Services Act (DSA) and the Digital Markets Act (DMA) are legislative proposals by the European Commission, playing an important role within the European Digital strategy. The DSA and DMA form a package of new rules applicable across the whole European Union to **create a safer, more competitive and open digital space**. ## EU Data sovereignty regulations Following the release of their main regulation in 2016, the General Data Protection Regulation (GDPR), the European Union is a **leader in data protection worldwide**. After this regulation, the EU has passed other laws such as the free flow of non-personal data (FFD) in 2018 and the EU Cybersecurity Act and the Open Data Directive in 2019. ### The General Data Protection Regulation (GDPR) The General Data Protection Regulation (GDPR) unifies **data protection regulations within the European Union**. It establishes strict rules on how EU citizens’ personal data must be stored, collected and processed; both within and outside the European Union. The GDPR entered into force in May 2016, establishing May 2018 as the deadline for Member States to put it into effect. This regulation replaced the 1995 European Data Protection Directive. The GDPR applies both to data controllers — organizations using cloud services that process EU citizens’ data — and data processors — organizations providing cloud services that process EU citizens’ data. ### The Data Protection Law Enforcement Directive (LED) The Data Protection Law Enforcement Directive (LED) is a piece of legislation that establishes rules on the processing of personal data by criminal law enforcement authorities and on the free movement of such data. It entered into force in May 2016, establishing May 2018 as the deadline for Member States to put it into effect. ### The regulation on the free flow of non-personal data (FFD) The goal of the regulation on the free flow of non-personal data is to boost the benefits of the data economy. It is applicable from May 2019. The FFD contributes to the creation of a competitive digital economy within the EU. Together with the GDPR, it aims to guarantee the free movement of non-personal data across the Member States of the European Union. ### The EU Cybersecurity Act The EU Cybersecurity Act establishes a UE cybersecurity certification framework for digital products, services and processes. In addition to strengthening the EU Agency for cybersecurity (ENISA). ### The Open Data Directive The Open Data Directive provides a common legal framework to facilitate the reuse of public sector information. It also aims to make high-value data available for reuse and strengthen transparency. It entered into force in July 2019. ### The Data Governance Act The Data Governance Act, adopted by the European Commission in November, 2020, aims to boost data sharing across sectors and Member States to leverage the potential of data for the benefit of EU citizens and organizations. ### The AI Act The AI Act is focused on establishing rules for ensuring a trustworthy Artificial Intelligence that respects fundamental rights and democracy, while enabling businesses to leverage the opportunities and benefits it can bring. To sum up, there is no doubt that **data protection and data sovereignty are a priority** nowadays. The IT sector is continuously evolving and new trends and technologies such as cloud, IoT or AI are becoming increasingly relevant in our daily lives. A clear example of this is how cloud adoption among enterprises in the EU keeps growing. On this matter, the EU is making great efforts to protect digital sovereignty, and boost innovation and competitiveness within the European Union. At Stackscale, data protection and security are a priority as well. That is why we always develop our products and services with **security, privacy, transparency and efficiency** in mind. Besides, we are proud to say that we opt for open standards and protocols to develop our Bare Metal and Private Cloud solutions, so that **customers can keep greater control over their IT environment**. --- ## Repatriación desde la nube a soluciones de TI dedicadas URL: https://www.stackscale.com/blog/cloud-repatriation/ La repatriación desde la nube sigue ganando popularidad entre CIOs y CTOs para **conseguir mayor rendimiento, control y rentabilidad** a medida que los proyectos evolucionan y escalan. Es una valiosa herramienta para reubicar cargas de trabajo cuando el equilibrio entre costes y beneficios no es el deseado. La repatriación suele implicar la migración a una solución dedicada que se ajuste mejor a las cargas de trabajo de la empresa. ## ¿Qué es la repatriación desde la nube? La repatriación desde la nube consiste en **mover cargas de trabajo y aplicaciones desde nubes públicas hiperescala a otras soluciones de TI** —servidores dedicados, entornos de nube privada, instalaciones de housing, proveedores de servicios gestionados o proveedores locales de nube pública—. De modo que no implica necesariamente devolver las cargas de trabajo a la infraestructura *in-house* de la empresa, sino reubicarlas en una más adecuada. Asimismo, no tiene por qué conllevar la reubicación de todas las cargas de trabajo y sistemas. ## ¿Por qué están repatriando cargas de trabajo las empresas? El hecho de sacar algunas de las cargas de trabajo de las nubes públicas hiperescala no tiene porqué implicar descontento, sino la necesidad de reubicar ciertas cargas de trabajo a un entorno más eficiente.  ** Mientras que los costes del cloud público hiperescala son bajos en fases iniciales, pueden crecer sin control al ritmo que las empresas escalan y crecen. Así que, hacer un seguimiento del gasto en cloud no solo es esencial, sino que también sirve como una métrica de rendimiento. Algunas de las razones detrás de la repatriación desde el cloud** son: - El control de los sobrecostes. - La optimización del rendimiento. - El aumento general de la visibilidad y el control. - La gestión de los problemas relativos al gobierno y la protección de los datos. - Los problemas de compatibilidad. ## Planificar la repatriación desde la nube La planificación es indispensable para la repatriación desde la nube, al igual que en cualquier otra decisión crítica para el negocio. Las organizaciones necesitan dar respuesta a cuestiones como: - A qué entorno se van a mover las cargas de trabajo. - Qué cargas de trabajo hay que reubicar. - Cómo gestionar y reducir la complejidad en caso de optar por un enfoque híbrido o multicloud. Asimismo, es recomendable **tener en cuenta la posibilidad de la repatriación en fases iniciales**. Es importante invertir en una arquitectura que facilite la migración de cargas de trabajo entre soluciones de TI; no solo para evitar el *vendor lock-in*, sino también para **hacer uso del entorno que mejor se adapte a cada etapa del ciclo de vida del negocio**. ### Estrategia de repatriación desde la nube Una estrategia de repatriación desde la nube requiere de una adecuada planificación para maximizar su eficacia y minimizar riesgos. Esto incluye: - La evaluación de las especificaciones y requisitos particulares de cada empresa. - La creación de un plan de migración. - El diseño y despliegue de una infraestructura que se adapte a las necesidades reales de la organización y que, de igual manera, contribuya a optimizar el presupuesto de TI. - El testeo y validación del nuevo entorno. ## Repatriar cargas de trabajo desde la nube pública hiperescala A menudo se eligen soluciones de nube pública hiperescala en fases iniciales a fin de acelerar la innovación con mayor agilidad. Sin embargo, la nube privada y otras soluciones dedicadas entran en escena cuando los negocios desean aumentar el rendimiento, la predictibilidad de los costes y el control. Estos son algunos de los beneficios que las empresas pueden aprovechar al **repatriar cargas de trabajo desde soluciones hiperescala a soluciones de infraestructura y cloud dedicadas**. ### Rendimiento predecible La mayoría de cargas de trabajo empresariales son predecibles, y también debería serlo el rendimiento. Por eso, a medida que los negocios maduran, los CTOs evalúan soluciones de TI dedicadas y especializadas para **conseguir un rendimiento alto y predecible**, y optimizar el coste de los ingresos. Las infraestructuras dedicadas permiten optimizar el gasto en cloud, ya que evita el sobreaprovisionamiento y aumenta la visibilidad sobre los costes. Además, en combinación con un almacenamiento en red de baja latencia y completamente redundante, se puede conseguir un rendimiento alto constante, sin vecinos ruidosos, y mejor disponibilidad de los datos. ** Las organizaciones deberían conocer el rendimiento que pueden esperar de su entorno de TI en todo momento. Junto con tarifas transparentes, las empresas deberían tener acceso completo a los detalles técnicos** de la infraestructura en la que depositan su confianza. Esto ayuda tanto a optimizar el rendimiento como a minimizar riesgos. ### Control sobre los costes La escalada de los costes es una de las razones principales por las que las empresas repatrian cargas de trabajo y aplicaciones a servidores dedicados y entornos de nube privada. Aunque los servicios de nube pública hiperescala ofrecen costes iniciales relativamente bajos, los gastos tienden a dispararse con el tiempo. Si bien la relación costes-beneficios depende de las especificaciones de cada proyecto, **los costes operativos en servicios cloud hiperescala tienden a escalarse al ritmo que lo hace el consumo en la nube y el almacenamiento**. En muchos casos, esto tiene como resultado unos gastos más elevados de lo esperado, que a menudo provocan una pérdida de control sobre el presupuesto de TI de las empresas. Por lo tanto, además de buscar herramientas de gestión de costes cloud para optimizar el presupuesto cloud, las empresas también están optando por la repatriación para **distribuir mejor las cargas de trabajo y sistemas de TI**. En este sentido, desde nuestra experiencia, los entornos de cloud privado ofrecen una mejor relación coste-rendimiento en casi todos los casos, ya que la mayoría de las cargas de trabajo empresariales son predecibles. **Hay muchas alternativas a los servicios de cloud pública hiperescala** que permiten migrar de on-premise a cloud, para aprovechar los beneficios del modelo OPEX. Por ejemplo, los entornos de nube privada y los servidores bare-metal ofrecen mayor rentabilidad y predictibilidad en el tiempo, lo que aumenta el control tanto sobre los costes como sobre el rendimiento. ### Seguridad y cumplimiento de la regulación El gobierno y la protección de datos se ha convertido en una prioridad en la economía digital, y las soluciones de infraestructura locales están cobrando relevancia en este aspecto. Las organizaciones se enfocan cada vez más en **adoptar medidas estrictas de seguridad y privacidad**, no solo para cumplir con la regulación, sino también para garantizar la continuidad del negocio. Otra de las preocupaciones detrás de la repatriación desde el cloud público hiperescala es la **ubicación de los datos**. Los negocios deben cumplir con normativas de seguridad y privacidad, y buenas prácticas dentro de la ubicación en la que operan. Por eso, por ejemplo, optar por proveedores cloud que alojen sus servicios en centros de datos europeos ayuda a las empresas a cumplir con el marco regulatorio de la UE con más facilidad. Además de reducir la latencia. ## Implementación de un enfoque híbrido o multicloud Al repatriar cargas de trabajo, muchas organizaciones optan por un enfoque híbrido o multicloud. En dichos casos, es importante **reducir la complejidad para aprovechar los beneficios y evitar problemas**. Un enfoque multicloud ofrece un nivel de agilidad adicional, especialmente en proyectos grandes y complejos, pero requiere un mayor nivel de gestión. Si se gestiona adecuadamente, **un enfoque híbrido aumenta la resiliencia** en caso de fallo grave, ya que las empresas cuentan con diversos proveedores cloud. Asimismo, junto con una estrategia de Disaster Recovery y backups potente, también mejora la fiabilidad y disponibilidad de los datos, y limita el impacto de tiempo de inactividad debido a un fallo o cualquier otra incidencia. En resumen, es probable que la repatriación desde la nube y la movilidad entre entornos se convierta en una práctica estándar para optimizar rendimiento y costes a lo largo del tiempo. A medida que los proyectos evolucionan y los equipos de TI se familiarizan con el ciclo de vida cloud, es más fácil **determinar cuál es el mejor modelo de despliegue para cada carga de trabajo**, en cada etapa. --- ## Cloud repatriation to dedicated IT solutions URL: https://www.stackscale.com/blog/cloud-repatriation/ Cloud repatriation is gaining popularity among CIOs and CTOs** **to **achieve higher performance, control and cost efficiency **as projects evolve and scale. It is a valuable tool to relocate workloads when the balance between costs and benefits is not as expected. Repatriation generally involves migrating to a dedicated solution that works best for running the business workloads. ## What is cloud repatriation? Cloud repatriation, also known as “uncloud”, consists of **moving workloads and applications from hyperscale public clouds to other IT solutions** — dedicated servers, hosted private cloud environments, colocation facilities, managed service providers or a local public cloud provider. Therefore, it does not necessarily involve taking workloads back to the company’s in-house infrastructure, but relocating them to a more suitable one. Furthermore, it may not entail the relocation of all systems and workloads. ## Why are companies repatriating workloads?  Taking some workloads away from hyperscale public clouds does not necessarily imply dissatisfaction, but the need to relocate certain workloads to a more efficient environment.  ** While hyperscale public cloud’s costs are low in the early stages, they can grow uncontrollably as companies scale and grow. So, tracking cloud spend is not only vital, but it also serves as a performance metric. Some of the reasons behind cloud repatriation** are: - Controlling cost overruns. - Optimizing performance. - Increasing overall visibility and control. - Addressing data governance and security issues. - Compatibility problems. ## Planning for cloud repatriation Planning is indispensable for cloud repatriation, as for any other business-critical decision. Organizations need to answer to questions such as: - Which environment they are moving their workloads to. - Which workloads are to be relocated. - How to manage and reduce complexity in case of opting for a hybrid or multicloud approach. Moreover, it is recommended to **consider the potential for repatriation early on**. It is important to invest in an architecture that makes it easy to migrate workloads between IT solutions; not only to avoid vendor lock-in, but to **leverage the most suitable environment at each stage of the business lifecycle**. ### Cloud repatriation strategy A cloud repatriation strategy requires proper planification to maximize effectiveness and minimize risks. It includes: - The assessment of particular business specifications and requirements. - The creation of a migration plan. - The design and deployment of an infrastructure that adapts to the real needs of the organization and thus contributes to optimize the IT budget. - The testing and validation of the new environment. ## Repatriating workloads from hyperscalers Hyperscale public cloud solutions are often chosen at early stages as a way to accelerate innovation with increased agility. However, private cloud and other dedicated solutions come into play when businesses wish to increase performance, cost predictability and control. These are some of the benefits companies can leverage when **repatriating workloads from hyperscalers to dedicated infrastructure and cloud solutions**. ### Predictable performance Most business workloads are predictable, and so should be performance. That is why, as businesses mature, CTOs look into** **dedicated and specialized infrastructure solutions to **achieve predictable high performance **and optimize the cost of revenue. A dedicated infrastructure allows organizations to optimize cloud spend by avoiding overprovisioning and increasing cost visibility. Besides, in combination with a completely redundant, low-latency network storage, they can achieve constant high performance, without noisy neighbors, and better data availability. ** Organizations should know the performance they can expect from their IT environment at any time. Together with transparent pricing, companies should have full access to the technical details** of the infrastructure they are relying on. This helps both optimizing performance and minimizing risks. ### Control over costs Cost escalation is one of the main reasons why companies repatriate workloads and applications to dedicated servers and private cloud environments. Even though hyperscale public cloud services offer relatively low upfront costs, expenses tend to rocket over time. Although the cost-benefits ratio depends on each project’s specifications, **operational costs in hyperscale cloud services tend to scale along with storage and cloud usage**. This results in higher than expected expenses in many cases, often making companies lose control over their IT budget.  So, in addition to looking for cloud cost management tools to optimize the cloud budget, companies are also looking towards repatriation to **better distribute their workloads and IT systems**. In this regard, from our experience, private cloud environments offer a better cost-performance ratio in most cases, as the majority of business workloads are predictable. **There are many alternatives to hyperscale public cloud services** that allow migrating from on-premise to cloud, leveraging the benefits of an OPEX model. For example, private cloud environments and bare-metal servers offer higher cost-efficiency and predictability over time, increasing control both over costs and performance. ### Regulatory compliance and security Data protection and governance has become a priority in the digital economy, and local infrastructure solutions are gaining relevance in this regard. Organizations are increasingly focusing on **adopting strict privacy and security measures**, not only for regulatory compliance, but also for business continuity reasons. Another concern behind hyperscale public cloud repatriation is **data location**. Businesses must comply with security and privacy regulations, and best practices within the location they operate in. That is why, for instance, opting for cloud providers that host their services in European data centers makes it easier for companies to comply with the EU’s regulatory framework. In addition to reducing latency. ## Implementing a hybrid or multicloud approach When repatriating workloads, many organizations opt for a hybrid or multicloud approach. In such cases, it is important to **reduce complexity to leverage the benefits and avoid issues**. A multicloud approach offers an additional level of agility, especially for big and complex projects, but it demands a greater amount of management. If properly managed, **a hybrid approach increases resilience** in case of a major outage, as companies rely on diverse cloud providers. Moreover, together with a strong Disaster Recovery and backups strategy, it also improves reliability and data availability, limiting the impact of a downtime due to a failure or any other incident. To sum up, cloud repatriation and mobility between environments will probably become a standard practice to optimize performance and costs over time. As projects evolve and IT teams become familiar with the cloud lifecycle, it is easier for them to **determine which is the best deployment model for each workload**, at each stage. --- ## Copias de seguridad: programación, frecuencia y tipos URL: https://www.stackscale.com/blog/backups/ **Los backups o copias de seguridad son una forma simple de *****disaster recovery*** (DR) o recuperación ante desastres que sirve como protección frente a contingencias como pérdida o corrupción de datos, fallos de sistema, actualizaciones defectuosas o ciberataques. La integración sin prisa pero sin pausa del mundo digital en nuestro día a día personal y profesional impulsa a un aprendizaje constante sobre cómo usar, almacenar y gestionar los datos para garantizar su seguridad y durabilidad. Los datos y servicios están disponibles y son accesibles desde cualquier lugar y **las copias de seguridad ya no son una opción sino un requisito**. ## ¿Qué es un backup y para qué sirve? ** Un backup es una copia de datos que se realiza y se almacena en una ubicación diferente** para que, en caso de que se produzca un incidente de pérdida de datos, sea posible recuperarlos y restaurarlos. Un sistema de backups siempre debería contener al menos una copia de todos los datos que se consideran críticos. Además, los dispositivos de almacenamiento deberían estar organizados de modo que proporcionen seguridad de datos, portabilidad y dispersión geográfica. Contar con una programación básica de backups es importante para asegurar la durabilidad de los datos y la recuperación ante desastres. En este sentido, la **periodicidad de los programas de backups** está estrechamente relacionada con los objetivos principales de los planes de DR y varía según la criticidad de los datos, aplicaciones y cargas de trabajo.  ### ¿De qué se debe hacer copias de seguridad? Es esencial **definir con claridad de qué datos y sistemas se debe crear copias de seguridad**. A fin de reducir el riesgo de pérdida de datos, las empresas deberían pensar en realizar backups de todos los elementos de TI, desde archivos y bases de datos a sistemas operativos, aplicaciones y VMs. ## ¿Por qué las empresas necesitan tener un backup? En realidad, para ser precisos, la pregunta debería ser: **¿por qué las empresas necesitan tener AL MENOS un backup?** ** Las copias de seguridad permiten a las empresas proteger sus datos críticos, reducir el tiempo de inactividad en caso de que se produzca un incidente y aumentar la confianza de los clientes. Como mencionamos al principio, los backups son un elemento importante de cualquier plan  de contingencia** o plan de recuperación ante desastres. Además de ayudar a las empresas a proteger sus datos críticos y a garantizar la durabilidad de los datos, las copias de seguridad reducen el tiempo de inactividad en caso de contingencia. Porque las empresas pueden **reanudar sus operaciones más rápido durante un fallo de hardware o cualquier otra emergencia**, restaurando sus backups en otro servidor o un *cold spare*. Asimismo, las copias de seguridad son una acción básica que las empresas pueden adoptar para reducir el riesgo de pérdida y robo de datos, así como para aumentar la confianza de los clientes. ### ¿Cuántos backups debería tener una empresa? Para garantizar una mayor durabilidad de los datos, se recomienda **guardar al menos un backup en una ubicación remota**, diferente a la de los sistemas principales de la empresa. De este modo los datos también estarán protegidos frente a desastres que puedan dañar los sistemas físicos, como podría ser una inundación o un incendio. En este sentido, **las organizaciones pueden basar su estrategía de backups en la regla «3-2-1»**. Según esta regla, las organizaciones deberían: - Tener **al menos 3 copias de sus datos**. - Estas copias se deberían almacenar en **2 tipos de almacenamiento diferentes**. - **1 copia debería estar ubicada fuera** de las instalaciones principales, en una ubicación remota. Asimismo, esta regla se suele actualizar como la regla «3-2-2-1» para incluir al menos una copia inmutable de datos. ## Tipos de copias de seguridad Hay diversos tipos de backups o métodos para crear copias de seguridad, como: - **Copia de seguridad continua o protección continua de datos**. - **Copia de seguridad completa**. - **Copia de seguridad incremental**. - **Copia de seguridad diferencial**. - **Copia de seguridad incremental inversa**. ### Copia de seguridad continua El método de backup continuo, también conocido como protección continua de datos o CDP, consiste en **realizar una copia de respaldo cada vez que se hace un cambio**, de modo que mantiene un diario continuo de cambios que permite restaurar un sistema a cualquier momento previo en el tiempo. También se conoce como **backup en tiempo real**. Un verdadero CDP proporciona un objetivo de punto de recuperación (RPO) igual a cero. ### Copia de seguridad completa El método de backup completo consiste en **hacer una copia completa de todos los datos, archivos o sistemas en intervalos predefinidos**, que se envía a una ubicación diferente. Es el tipo de backup más básico pero suele requerir de mayor espacio de almacenamiento. El hecho de hacer una copia de seguridad de todo, siempre, exige muchos recursos económicos y de tiempo, especialmente cuando se manejan grandes cantidades de datos. ### Copia de seguridad incremental El método de backup incremental consiste en **realizar una copia de los cambios que se han hecho desde el último backup**, ya sea completo o incremental. Para restaurar el estado más reciente del sistema, hay que aplicar todos los backups incrementales al último backup completo. Este tipo de backup consume menos espacio de almacenamiento pero conlleva un mayor tiempo de recuperación, dado que es necesario acceder a un mayor número de backups. En entornos Proxmox, Proxmox Backup Server trabaja sobre este modelo: copias incrementales y deduplicadas con cifrado en el cliente, lo que reduce tanto el espacio de almacenamiento ocupado como la ventana de backup. ### Copia de seguridad diferencial El método de backup diferencial consiste en **realizar una copia de los cambios que se han hecho desde el último backup completo**. Este tipo de copia de seguridad también consume menos espacio de almacenamiento, ya que el volumen de datos que se debe respaldar entre los intervalos establecidos es menor. Así que ayuda a ahorrar recursos económicos y de tiempo, pero los tiempos de restauración también son más largos en comparación con los backups completos. ### Copia de seguridad incremental inversa El método del backup incremental inverso consiste en **realizar una copia de los datos modificados y aplicarla a la última copia de seguridad completa**, de modo que crea un backup completo sintético. En resumen, no hay que pasar por alto la importancia del DR y los backups. No cabe duda de que todas las organizaciones deberían tener backups o copias de seguridad de sus datos. En este aspecto, es necesario evaluar los diferentes tipos de backups adecuadamente de acuerdo a las necesidades de cada negocio; sobre todo teniendo en cuenta que los datos suelen residir en múltiples ubicaciones. En Stackscale somos conscientes de la importancia que tiene hoy en día contar con copias de seguridad. Por eso nuestros volúmenes de almacenamiento en red —Flash Premium, Flash Plus y Standard— incluyen una programación básica de backups y réplicas por defecto. Además de esto, también ofrecemos Archive, un volumen de almacenamiento en red especialmente diseñado para copias de seguridad y archivado. ### ¿En búsqueda de soluciones para mejorar la estrategia de backups y DR de tu empresa? Solutions form ES Notify NombreEmailTeléfonoCuéntanos qué necesitas Acepto el envío de comunicaciones comerciales personalizadas sobre los productos y servicios de Stackscale (incluida la newsletter), por cualquier medio, incluidos los electrónicos. He leído y acepto la política de privacidad. Enviar El Grupo Stackscale trata la información que nos facilita con el fin de dar respuesta a la solicitud realizada en relación con los servicios que prestamos y los productos que suministramos. Los datos proporcionados se conservarán mientras se mantenga el contacto siendo eliminados una vez finalizada la solicitud, a no ser que consienta el envío de comunicaciones comerciales, donde sus datos se conservarán hasta la revocación del consentimiento previamente otorgado. En el marco del Grupo al que pertenece Stackscale, se le informa de que sus datos serán comunicados a las empresas de Grupo Aire por motivos corporativos. Puede consultar las empresas que forman parte del Grupo Aire en: https://grupoaire.es. Usted puede ejercitar sus derechos de acceso, rectificación, supresión, oposición, limitación del tratamiento y, cuando legalmente proceda, portabilidad, mediante el envío a Stackscale de una solicitud a la dirección dp*@********le.com, indicando el derecho que ejercita y aportando una fotocopia por las dos caras de su DNI o documento legal de identificación de su identidad. Igualmente, podrá presentar una reclamación ante la Agencia Española de Protección de Datos, especialmente cuando no haya obtenido la satisfacción en el ejercicio de sus derechos, a través de la sede electrónica en www.aepd.es. --- ## Backups: schedules, frequency and types URL: https://www.stackscale.com/blog/backups/ **Backups are a simple form of disaster recovery** (DR) to be protected against contingencies like data corruption or deletion, system failures, faulty updates or cyberattacks.  As the digital world slowly but surely integrates into our daily personal and professional lives, we have to learn to change the way we use, store and manage data in order to ensure its protection and durability. Data and services are available and accessible from anywhere and **backups are no longer an option but a requirement**. ## What is a backup and what is it used for? ** A backup is a copy of data that is taken and stored somewhere else** so that, in case of a data loss incident, data can be recovered and restored. A backup system should always contain at least a copy of all data considered to be critical. Besides, storage devices should be arranged in a way they can provide data security, portability and geographical dispersion. Relying on a basic backup schedule is important to ensure data durability and disaster recovery. In this regard, the **periodicity of backup schedules** is closely related to the main objectives of DR plans and it varies depending on the data, applications and workloads’ criticality. ### What systems and data must be backed up? It is essential to **clearly** **define what data and systems must be backed up**. In order to reduce the risk of data loss, companies should think of backing up every IT element from files and databases to operating systems, applications and VMs. ## Why do companies need to have backups? Actually, a more accurate question would be: **why do companies need to have AT LEAST one backup?**  ** Backups allow companies to safeguard critical data, reduce downtime in case of an incident and increase customer confidence. As mentioned at the beginning, backups are an important element of any contingency plan** or disaster recovery plan. In addition to helping companies safeguard critical data and ensure data durability, backups can reduce downtime in case of contingency. By restoring their backups in a different server or a cold spare, companies can **resume operations faster during a hardware failure or any other emergency**. Furthermore, backups are a basic action companies can take to reduce the risk of data losses and data thefts, as well as to increase customer confidence. ### How many backups should a company have? For guaranteeing further data durability, it is recommended to **store at least one backup in a remote location**, different to the company’s main systems. This way data will also be protected against disasters that can damage physical systems, such as a flood or fire. On this matter, **organizations can base their backup strategy on the “3-2-1” rule**. According to this rule, organizations should: - Have **at least 3 copies of their data**. - These copies should be stored in **2 different types of storage**. - **1 copy should be located offsite**, in a remote location. Moreover, this rule is often upgraded as the “3-2-2-1” rule to include at least one immutable copy of data. ## Types of backups There are diverse types of backups or methods to create backups, such as: - **Continuous backup or Continuous Data Protection (CDP)**. - **Full backup**. - **Incremental backup**. - **Differential backup**. - **Reverse incremental backup**. ### Continuous backup The continuous backup method, also known as continuous data protection or CDP, consists of **making a copy of data on a system every time a change is made**, maintaining a continuous journal of changes that allows restoring a system to any previous point in time. It is also known as **real-time backup**. A true CDP provides a Recovery Point Objective (RPO) equal to zero. ### Full backup The full backup method consists of **making a comprehensive copy of data, files or systems on established intervals**, which are sent to a different location. It is the most basic type of backup but it usually demands larger storage space. Backing up everything, all the time, demands a lot of economic and time resources, especially when dealing with large volumes of data. ### Incremental backup The incremental backup method consists of **backing up the changes that have been made since the last backup**, either a full or incremental one. To restore the most recent state of the system, all the incremental backups must be applied to the last full backup. This type of backup consumes less storage space but entails a longer recovery time, since it is necessary to access a higher number of backups. In Proxmox environments, Proxmox Backup Server works on this model: incremental and deduplicated backups with client-side encryption, which keeps both the storage footprint and the backup window down. ### Differential backup The differential backup method consists of **backing up the changes that have been made since the last full backup**. This type of backup also consumes less storage space, since the volume of data that must be backed up between the established intervals is smaller. Thus, it helps save time and financial resources, but restoration times are also longer compared to full backups. ### Reverse incremental backup The reverse incremental backup method consists of **backing up modified data and applying it to the last full backup**, creating a synthetic full backup. To sum up, the importance of DR and backups is not to be neglected. There is no doubt all organizations should have backups of their data. On this matter, the diverse types of backups must be properly assessed depending on business needs; especially considering that data usually resides in multiple locations. At Stackscale, we are aware of the importance of backups nowadays. That is why our network storage volumes — Flash Premium, Flash Plus and Standard — include a basic backup and replica schedule by default. In addition to this, we also offer Archive, a network storage volume specially designed for backups and archival. ### Looking for solutions to improve your company’s backups and DR strategy? Solutions form EN Notify NameEmailPhoneTell us about your needs I give my consent to receiving customized commercial communications about Stackscale products and services (including the newsletter), by any channel, including electronic ones. I have read and accept the privacy policy. Submit The Stackscale Group processes the information you provide in order to respond to your request regarding the services we deliver and the products we provide. The data provided will be stored while we stay in contact and deleted when the request is closed, unless you consent to receiving sales communications, in which case your data will be stored until the previously given consent is revoked. As part of the Group to which Stackscale belongs, we inform you that your data will be communicated to the companies of Grupo Aire for corporate reasons. You can consult the companies integrating Grupo Aire at: https://grupoaire.es. You can exercise your rights of access, rectification, erasure, disagreement, limitation of the processing and, when legally appropriate, portability, by sending a request to Stackscale to the address dp*@********le.com, indicating the right you exercise and providing a double-sided photocopy of your identification. Additionally, you will be able to present a complaint to the Dutch Data Protection Authority, especially when you are not content with the exercise of your rights, via https://autoriteitpersoonsgegevens.nl/en. --- ## ¿Qué es un centro de datos o data center? URL: https://www.stackscale.com/blog/what-is-a-data-center/ Un *data center* o un **centro de procesamiento de datos** (CPD) es la ubicación física donde se concentran los recursos necesarios de computación de una organización o proveedor de servicios. También es conocido como «*Internet Data Center*» (IDC) en inglés, **centro de cómputo** en Latinoamérica, y **centro de cálculo o centro de datos** en España. Los términos «centro de datos» y «*data center*» cada vez se escuchan más gracias al papel que juegan en muchas de nuestras actividades diarias. Gran parte de los datos que recibimos y enviamos a través de nuestros móviles, tabletas y ordenadores acaban almacenados en estos centros de datos; en lo que muchos llaman, de forma genérica, «la nube» o «el cloud». ## Salas privadas y salas técnicas del datacenter Un centro de datos dispone de **espacios de uso exclusivo** donde las empresas mantienen y operan sus infraestructuras IT. En estos espacios se pueden alojar los servidores y sistemas de almacenamiento para ejecutar las aplicaciones que procesan y almacenan datos de empresas. Algunas empresas disponen de una jaula o de uno o varios racks (bastidores). Otras pueden llegar a disponer de salas privadas para alojar un número determinado de armarios rack. El espacio dependerá del tamaño de la empresa. El data center proporciona un **espacio técnico que está preparado con falso suelo**. Por **debajo de este falso suelo se instalan las tomas eléctricas para conectar los bastidores**. Por lo tanto, todo debe estar cuidadosamente controlado y protegido. Para ello, los grandes centros de datos implementan numerosos mecanismos de seguridad, como: - Sistemas de alimentación eléctrica redundantes. - Generadores diesel de respaldo. - Sistemas de refrigeración redundantes y altamente eficientes. - Detección y extinción de incendios. - Detectores de fugas de agua y controles de seguridad. ## Monitorización y gestión de centros de datos Los centros de datos modernos son realmente complejos desde el punto de vista tecnológico y requieren de **gestión y monitorización constante para poder operar de manera segura y eficiente**. Por eso la continuidad de negocio y la eficiencia energética son aspectos críticos en la gestión de los centros de datos, como explicamos más adelante en el artículo. Por ejemplo, mantener unos parámetros de temperatura y humedad correctos es esencial para **garantizar el correcto funcionamiento y la integridad operativa de los sistemas alojados**. ## Centros de datos virtuales Un centro de datos virtual, *virtual data center* en inglés, es **una arquitectura de centro de datos que elimina muchos de los desafíos de los data centers tradicionales**. Los centros de datos virtuales aumentan la agilidad TI y reduce la complejidad y los costes. También se conocen como nubes privadas, *Cloud Data Centers* o centros de datos definidos por software. **Un único centro de datos físico puede alojar varios data centers virtuales**. Cada centro de datos cloud es completamente independiente, lo que asegura máxima seguridad, alta disponibilidad y flexibilidad. La abstracción del centro de datos físico mediante virtualización permite a los proveedores de servicio ser más competitivos y proporcionar recursos de computación, almacenamiento y red como servicio a sus clientes. ## Continuidad de negocio en centros de datos La planificación de la recuperación ante desastres y la continuidad de negocio son clave para los centros de datos, ya que sus servicios son críticos para muchas organizaciones y sectores esenciales. Por eso **los centros de datos implementan numerosas medidas de seguridad y redundancia para asegurar la continuidad de negocio** ante cualquier situación. La siguiente lista recopila algunas de las medidas que implementan los data centers para garantizar la continuidad del servicio: - Monitorización 24/7 y personal de seguridad in situ 24/7 y videovigilancia. - Doble acometida eléctrica. - Sistemas UPS online respaldados por generadores diésel en configuración 2N ó N+1. - Refrigeración redundante. - Control de acceso multicapa mediante lectores biométricos, tarjetas de proximidad y esclusas de seguridad. - Mecanismos de seguridad contra incendios, como la detección temprana de incendios (VESDA) con sistemas de extinción mediante gas o agua nebulizada. - Detección de fugas de agua. ## Medidas de eficiencia en centros de datos Los centros de datos líderes trabajan constantemente en mejorar su eficiencia energética. Puesto que **la sostenibilidad es uno de los grandes retos de la industria** actualmente. En este sentido, el uso del hardware físico está mucho más optimizado en los grandes centros de datos que en los centros de datos tradicionales alojados en las instalaciones propias de las empresas. Sin embargo, al igual que aumenta la necesidad de disponer de servicios de computación más complejos y rápidos, también lo hace la necesidad de reducir la huella de los centros de datos. A continuación enumeramos algunas de las **medidas de eficiencia energética que los centros de datos están adoptando para reducir su huella de carbono**: - Modernizar los sistemas de refrigeración. - Adoptar el **método de *****free-cooling***** o enfriamiento gratuito**. - Aislamiento en salas IT en **configuración pasillo-frío/pasillo-caliente**. - Recuperar y reutilizar el exceso de calor de los centros de datos para calentar hogares, oficinas y escuelas cercanas. - Usar **Inteligencia Artificial** para predecir el consumo energético, optimizar los sistemas de refrigeración y, así, mejorar el valor PUE. Descubre más sobre las medidas de eficiencia energética que adoptan los grandes CPDs.  ## ¿Cómo es un centro de datos por dentro? El siguiente vídeo de Interxion MAD2, uno de los data centers en los que Stackscale tiene infraestructura, muestra cómo es un centro de datos por dentro (la infraestructura eléctrica, el cableado, la arquitectura modular, las salas técnicas, etc.). Para los más curiosos, es una buena manera de conocer más sobre sobre una de nuestros centros de datos en Madrid y Ámsterdam. En Stackscale seleccionamos **centros de datos de referencia en cada ubicación geográfica** que ponemos en funcionamiento. Hoy disponemos de infraestructura en Interxion MAD2, Interxion MAD3 y Equinix MD2 en Madrid, y en Equinix AM5 y NorthC Almere en Ámsterdam. ### ¿Buscas soluciones de housing o infraestructura como servicio? Solutions form ES Newsletter NombreEmailTeléfonoCuéntanos qué necesitas Acepto el envío de comunicaciones comerciales personalizadas sobre los productos y servicios de Stackscale (incluida la newsletter), por cualquier medio, incluidos los electrónicos. He leído y acepto la política de privacidad. Enviar El Grupo Stackscale trata la información que nos facilita con el fin de dar respuesta a la solicitud realizada en relación con los servicios que prestamos y los productos que suministramos. Los datos proporcionados se conservarán mientras se mantenga el contacto siendo eliminados una vez finalizada la solicitud, a no ser que consienta el envío de comunicaciones comerciales, donde sus datos se conservarán hasta la revocación del consentimiento previamente otorgado. En el marco del Grupo al que pertenece Stackscale, se le informa de que sus datos serán comunicados a las empresas de Grupo Aire por motivos corporativos. Puede consultar las empresas que forman parte del Grupo Aire en: https://grupoaire.es. Usted puede ejercitar sus derechos de acceso, rectificación, supresión, oposición, limitación del tratamiento y, cuando legalmente proceda, portabilidad, mediante el envío a Stackscale de una solicitud a la dirección dp*@********le.com, indicando el derecho que ejercita y aportando una fotocopia por las dos caras de su DNI o documento legal de identificación de su identidad. Igualmente, podrá presentar una reclamación ante la Agencia Española de Protección de Datos, especialmente cuando no haya obtenido la satisfacción en el ejercicio de sus derechos, a través de la sede electrónica en www.aepd.es. --- ## What is a data center? URL: https://www.stackscale.com/blog/what-is-a-data-center/ A **Data Center or Internet Data Center** is a facility where an organization or a service provider centralizes their necessary computing resources. The term “data center” has become very common due to the role it plays in many of our daily activities. Most of the data we receive and send through our mobile phones, tablets and computers ends up stored in these data centers — which many people refer to as “the Cloud”, in a more generic way. ## Data center private suites and technical space Data centers have **exclusive use spaces** where companies keep and operate their IT infrastructures. In these spaces, servers and storage systems can be hosted in order to execute applications that process and store the companies’ data. Some companies have a cage or one or several racks, while others can have private suites to host a given number of racks. It will depend on the company’s size. Data centers provide a **technical space prepared with a raised floor under which electrical sockets are installed to connect the racks**. So, everything must be carefully controlled and secured. For doing so, large-scale data centers implement numerous safety mechanisms, such as: - Redundant power supply systems. - Diesel backup generators. - Redundant and very efficient cooling systems. - Fire detection and extinguishment. - Water leak detectors and security controls. ## Datacenter management and monitoring Modern data centers are really complex from a technological point of view and they require **constant monitoring and management in order to run safely and efficiently**. That is why business continuity and energy efficiency are critical aspects for data center management, as we explain later on in the article. For instance, maintaining the right temperature and humidity parameters is essential to **ensure the correct functioning and operative integrity of the hosted systems**. ## Virtual data centers A virtual data center is **a data center architecture that eliminates many of the challenges of traditional data centers**. Virtual data centers increase IT agility and reduce complexity and costs. They are also known as Private Clouds, Cloud Data Centers or Software-defined data centers (SSDC). **A single, physical data center can host several virtual data centers**. Each cloud data center is completely independent, ensuring maximum security, high-availability and flexibility. The abstraction of the physical data center using virtualization allows service providers to be more competitive and provide computing, storage and networking resources as a service to customers. ## Business continuity in data centers Business continuity and disaster recovery planning are key for data centers, because their services are critical to many organizations and essential sectors. Therefore, **data centers implement numerous redundancy and security measures to ensure business continuity** in any situation. Here is a list of some of the measures data centers implement for guaranteeing service continuity: - 24/7 monitoring and on site 24/7 security staff and video surveillance. - Dual power supplies. - Online UPS systems backed up by diesel generators with 2N or N+1 configuration. - Cooling redundancy. - Multilayer access control using biometric authentication, proximity cards and mantraps. - Fire safety mechanisms, such as early fire detection (VESDA) using nebulized water or gas-based fire suppression systems. - Water leak detection. ## Efficiency measures in data centers Leader data centers are constantly working on improving their energy efficiency. As **sustainability is one of the biggest challenges in the industry** nowadays. On this matter, the utilization of physical hardware is much more optimized in large-scale data centers than in traditional, on-premise data centers. However, as the need for faster and more complex computing services increases, so does the need to reduce the data centers’ footprint. Here is a list of some of the **energy efficiency measures data centers are adopting to reduce their carbon footprint**: - Modernizing cooling systems. - Adopting the **free cooling**. - IT rooms’ isolation with a **cold aisle/hot aisle configuration**. - Recovering and reusing data centers’ excess heat to warm nearby households, offices and schools. - Using **Artificial Intelligence** for predicting power usage, optimizing cooling systems and, thus, improving the PUE ratio. - Prioritizing the use of 100% clean and renewable energies. Learn more about the energy efficiency measures adopted by large data centers. ## What does a data center look like? The following video from Interxion MAD2, one of the data centers where Stackscale hosts its infrastructure, shows what a data center looks like (power infrastructure, wiring, modular architecture, technical space, etc.). For the most curious readers, it is a great way of discovering more about one of our data centers in Madrid and Amsterdam. **At Stackscale, we select reference data centers in every geographic location** we implement. Today, we have infrastructure in Interxion MAD2, Interxion MAD3 and Equinix MD2 in Madrid, and in Equinix AM5 and NorthC Almere in Amsterdam. ### Looking for colocation or infrastructure as a service solutions? Solutions form EN Notify NameEmailPhoneTell us about your needs I give my consent to receiving customized commercial communications about Stackscale products and services (including the newsletter), by any channel, including electronic ones. I have read and accept the privacy policy. Submit The Stackscale Group processes the information you provide in order to respond to your request regarding the services we deliver and the products we provide. The data provided will be stored while we stay in contact and deleted when the request is closed, unless you consent to receiving sales communications, in which case your data will be stored until the previously given consent is revoked. As part of the Group to which Stackscale belongs, we inform you that your data will be communicated to the companies of Grupo Aire for corporate reasons. You can consult the companies integrating Grupo Aire at: https://grupoaire.es. You can exercise your rights of access, rectification, erasure, disagreement, limitation of the processing and, when legally appropriate, portability, by sending a request to Stackscale to the address dp*@********le.com, indicating the right you exercise and providing a double-sided photocopy of your identification. Additionally, you will be able to present a complaint to the Dutch Data Protection Authority, especially when you are not content with the exercise of your rights, via https://autoriteitpersoonsgegevens.nl/en. Dutch version: Wat is een datacenter? --- ## Estrategias de migración a la nube y desafíos URL: https://www.stackscale.com/blog/cloud-migration-strategies/ Hay diferentes estrategias de migración a la nube entre las que las organizaciones pueden elegir cuando deciden externalizar su infraestructura. Así como diversos desafíos a los que suelen tener que enfrentarse. ## Principales estrategias de migración cloud Una estrategia de migración cloud es **un plan para mover datos, aplicaciones y cargas de trabajo a la nube**. Las estrategias de migración a la nube se refieren generalmente a migrar aplicaciones, datos y cargas de trabajo desde una infraestructura y arquitectura on-premise. Aunque la migración también se puede llevar a cabo entre diferentes soluciones o tipos de cloud. **Cada empresa tiene una razón diferente para migrar de on-premise a cloud o entre diferentes soluciones cloud** —la optimización de costes, la seguridad, el rendimiento, el soporte, la ubicación real de los datos, etc.—. Veamos cuáles son las principales estrategias de migración a la nube entre las que pueden elegir las empresas: - *Rehost* o «*Lift and Shift*» - *Refactor* o «*Lift, Tinker and Shift*» - Revisar - Reconstruir - Reemplazar * ### Rehost* o «*Lift and Shift*» La estrategia de migración conocida como *rehosting* o «*Lift and Shift*» —«realojar» o «levantar y mover» en español— consiste en **mover cargas de trabajo y aplicaciones a la nube manteniéndolas exactamente igual a como se encuentran en la infraestructura on-premise**. En otras palabras, las empresas simplemente sacan las aplicaciones del centro de datos in-house y las trasladan a un entorno cloud, sin realizar cambios significativos. Esta estrategia de migración cloud es la más conservadora. También es **la estrategia más rápida y menos costosa para mover aplicaciones a la nube**, ya que se puede realizar sin implementar cambios en el código. Al elegir este enfoque, las empresas suelen planear modificar la arquitectura u optimizar lo que sea necesario una vez que la infraestructura esté ya en funcionamiento en la nube. Esto también permite al equipo mejorar gradualmente sus competencias. La estrategia *Lift and Shift* también es la que ofrece el ROI (retorno de la inversión) más rápido. **Solo con realojar sus cargas de trabajo y aplicaciones las empresas pueden reducir considerablemente sus gastos de TI**. Permite reducir los costes de ejecutar cargas de trabajo y aplicaciones al mismo tiempo que se aumenta el rendimiento, la seguridad y la escalabilidad. La estrategia conocida como *rehosting* es también la más usada para migrar aplicaciones o sistemas legacy que las organizaciones necesitan o desean seguir usando. ### *Refactor* o «*Lift, Tinker and Shift*» La estrategia de migración conocida como *refactoring* o «*Lift, Tinker and Shift*» —«reconsiderar» o «levantar, remendar y mover» en español— consiste en **adaptar parcialmente y optimizar aplicaciones para que se adecuen al entorno cloud**. Sin embargo, sólo implica realizar algunos cambios y optimizaciones cloud, sin modificar la arquitectura principal. Este enfoque de migración a la nube se suele elegir para añadir unas funcionalidades, un rendimiento o una escalabilidad que no es posible conseguir en la infraestructura on-premise ya existente. Permite aprovechar en mayor medida las capacidades de la nube. Sin embargo, no hay una solución perfecta para todos. Según los objetivos del negocio, es posible realojar algunas aplicaciones y cargas de trabajo y adaptar parcialmente otras. ### Revisar Esta estrategia de migración —conocida como «*revising*» en inglés— consiste en **implementar grandes cambios en la arquitectura y el código de las aplicaciones y sistemas que se van a migrar al cloud**. Su objetivo es poder aprovechar completamente los servicios disponibles en la nube. ### Reconstruir Esta estrategia de migración —conocida como «*rebuilding»* en inglés— consiste en **descartar y reemplazar el código existente**. Al requerir una mayor inversión de tiempo y dinero, este enfoque solo se plantea cuando la solución existente ya no satisface las necesidades del negocio. ### Reemplazar Esta estrategia de migración —conocida como «*repurchasing*» o «*replacing*» en inglés— consiste en **migrar a una solución o producto diferente**. Al escoger este enfoque, simplemente los datos se suelen migrar a una aplicación de terceros ofrecida por un proveedor. Esta incluye la **estrategia de migración entre soluciones cloud** —«*cloud to cloud migration*» en inglés—, que consiste en mover aplicaciones y cargas de trabajo de un proveedor cloud a otro. Ya sea porque las necesidades y objetivos de la empresa han cambiado y otro proveedor resulta más adecuado, o porque busca cambiar a un tipo de cloud o modelo de servicio cloud diferente. ## Desafíos de migrar a la nube A continuación hemos recopilado una lista de los desafíos más habituales a los que se enfrentan las organizaciones cuando planifican una migración cloud: - **Falta de estrategia**. Tener en cuenta los requisitos específicos de cada aplicación y carga de trabajo es esencial. Así que es importante definir una estrategia clara para asegurar que la migración a la nube sea un éxito. - **Inactividad o interrupción del servicio durante la migración**. En este sentido, llevar a cabo pruebas de migración es importante para asegurarse de que la migración final se ejecuta sin impacto, o con el mínimo impacto posible, en el servicio. - **Pérdida de datos y seguridad**. Para evitar riesgos de filtración y pérdida de datos durante una migración a la nube, es importante implementar medidas de seguridad como la gestión de acceso con privilegios y el cifrado de apps. Así como contar con un buen plan de recuperación ante desastres. - **Gestión de recursos**. Migrar a la nube suele conllevar la contratación de nuevos perfiles de gestión de TI. - **Gestión de costes**. Desde gastos de migración a futuros costes recurrentes, tener en cuenta todos los costes asociados a una migración cloud es importante para evitar sorpresas en el futuro. Asimismo, mantener los costes cloud bajo control también es esencial. - **Interoperabilidad**. Es necesario adaptar los procesos para que las aplicaciones puedan comunicarse adecuadamente dentro del nuevo entorno cloud. - **Competencias**. Es importante confiar en un equipo especializado, ya sea interno o externo, para garantizar que la migración sea un éxito. ## Plan de migración a la nube Las empresas deben planificar minuciosamente su migración a la nube para sacarle el máximo partido y garantizar que la migración sea segura. El proceso de migración varía según el proyecto. Pero para realizar una migración con éxito es importante: - **Diseñar un plan de migración hacia la nube**, que debería empezar por evaluar la infraestructura actual e identificar los requisitos de la infraestructura cloud. - **Elegir una solución y proveedor de servicios cloud adecuados** que encajen en las necesidades y objetivos del proyecto. - **Realizar tests de migración** para que la migración final no tenga impacto en el servicio, o tenga el mínimo impacto posible. - **Probar y analizar** que todo funciona como se había planeado. - **Garantizar una monitorización y administración de sistemas constante** para que todo funcione sin interrupciones, y para identificar problemas y amenazas de forma proactiva. La estrategia más adecuada dependerá en gran medida del tamaño y la complejidad del entorno que la empresa planea migrar. **¿Estás planeando una migración hacia la nube?** Te ayudamos a alcanzar los objetivos de tu empresa con éxito. Contacta con nosotros para saber más sobre nuestras soluciones de migración cloud. --- ## Cloud migration strategies and challenges URL: https://www.stackscale.com/blog/cloud-migration-strategies/ There are different cloud migration strategies among which organizations can choose when they decide to outsource their infrastructure. As well as diverse challenges that they often have to overcome. ## Main cloud migration strategies A cloud migration strategy is **a plan to move data, applications and workloads into the cloud**. Cloud migration strategies generally refer to migrating applications, data and workloads from an on-premises infrastructure and architecture. Although the migration can also be done among different cloud solutions or types. **Each company has different reasons to migrate from on-premise to cloud or between different cloud solutions** — cost optimization, security, performance, support, real data location, etc. Let’s go through the main cloud migration strategies among which companies can choose: - Rehost or “Lift and Shift” - Refactor or “Lift, Tinker and Shift” - Revise - Rebuild - Replace ### Rehost or “Lift and Shift” The rehosting or “Lift and Shift” migration strategy consists of **moving workloads and applications into the cloud exactly as they are in the on-premise infrastructure**. In other words, companies basically “lift” applications from its in-house data center and “shift” them to a cloud environment, without significant changes. Rehosting is the most conservative cloud migration strategy. It is also **the fastest and least expensive strategy for moving applications to the cloud**, since it can be done without implementing code changes. When choosing the rehost approach, companies often plan to optimize and re-architect whatever is necessary once the infrastructure is up and running in the cloud. This also allows the team to gradually improve their skills. Lift and Shift is also the strategy with the quickest ROI (return on investment). **Just by rehosting their workloads and applications companies can significantly reduce IT expenses**. It allows to reduce the costs of running workloads and applications while increasing performance, security and scalability. The rehosting strategy is also commonly used for migrating legacy systems or applications that organizations need or wish to keep using. ### Refactor or “Lift, Tinker and Shift” The refactoring migration strategy consists of **partially adapting and optimizing applications, so that they better fit the cloud environment**. However, it only involves a few cloud optimizations and adjustments, without modifying the core architecture. It is also known as “Lift, Tinker and Shift”. This cloud migration approach is usually chosen to add certain features, performance or scalability, which it is not possible to get in the existing on-premise infrastructure. It allows leveraging further cloud capabilities. Nevertheless, there is no one-size-fits-all approach. Depending on business objectives, some applications and workloads can be rehosted while others can be refactored. ### Revise The revising migration strategy consists of** implementing major changes to the systems and applications’ code and architecture being migrated to the cloud**. So that they can fully leverage the services available in the cloud. ### Rebuild The rebuilding migration strategy consists of **discarding and replacing the existing code**. As it involves a bigger time and monetary investment, this approach is only considered when an existing solution no longer meets the business needs. ### Replace The replacing migration strategy, also known as “repurchasing”, consists of **migrating to a different solution or product**. When choosing this approach, data is usually just migrated to a third-party application offered by a provider. This includes the **cloud-to-cloud migration strategy**, which consists of moving applications and workloads from one cloud provider to another. Either because the company’s needs and goals have changed and another cloud provider is more suitable, or because it aims to change to a different type of cloud or cloud service model. ## Challenges when migrating to the cloud Here is a list of some of the most common challenges organizations face when planning a cloud migration: - **Lack of strategy**. Taking into account the specific requirements of each application and workload is essential. Thus, it is important to define a clear strategy to ensure a successful migration to the cloud.  - **Downtime or outage during the migration**. On this matter, conducting migration tests is important to ensure that the final migration has no impact, or minimal impact possible, on the service. - **Data losses and security**. To avoid breach risks and data losses during a cloud migration, it is important to implement security measures such as privileged access management and app encryption. As well as relying on the right Disaster Recovery plan. - **Resource management**. Migrating to the cloud usually entails hiring new IT management roles. - **Cost management**. From migration costs to future recurring expenses, considering all costs associated with a cloud migration is important to avoid surprises in the future. Additionally, keeping control of cloud costs is also essential. - **Interoperability**. It is necessary to adapt processes so that applications can communicate properly within the new cloud environment. - **Skills**. It is important to rely on a specialized team, either internally or externally, to ensure the migration is a success. ## Cloud migration plan Companies must carefully plan their migration to the cloud in order to make the most of it and ensure a secure migration. The migration process varies depending on the project. But a successful migration should include: - **Designing a cloud migration plan**, that should start by assessing the current infrastructure and determining the requirements of the cloud infrastructure. - **Choosing a suitable cloud solution and service provider** that fits your project’s needs and goals. - **Performing migration tests** so that the final migration has no impact on the service, or the minimum impact possible. - **Testing and assessing** that everything has gone as planned. - **Guaranteeing constant system management and monitoring** to keep everything running smoothly, and proactively identify issues and threats. The most suitable strategy will depend to a large extent on the size and complexity of the environment the company is planning to migrate. **Planning a migration to the cloud?** We can help you meet your company’s goals successfully. Contact us for further details about our cloud migration solutions. --- ## Hipervisores: definición, tipos y soluciones URL: https://www.stackscale.com/blog/hypervisors/ Los hipervisores son una parte esencial de la tecnología detrás del cloud computing. Existen **dos tipos de hipervisores** —tipo 1 o bare-metal y tipo 2 o alojado—, y numerosas soluciones en el mercado. En este post hablaremos de ambos tipos e incluiremos una lista de **hipervisores populares** —tanto comerciales como open source—. Pero primero empecemos por definir qué es un hipervisor. ## ¿Qué es un hipervisor? Un hipervisor, también conocido como **monitor de máquinas virtuales** (VMM, del inglés *Virtual Machine Monitor*) es **una capa de virtualización de software** que permite crear y ejecutar varias máquinas virtuales dentro de un único servidor, así como diferentes sistemas operativos. El servidor físico en el que el hipervisor ejecuta una o más máquinas virtuales se conoce como «***host machine***», mientras que cada VM individual se conoce como «***guest machine***». ** El término «hipervisor», acuñado en los años 70, nació a partir de otro término que se usaba tradicionalmente para hacer referencia al kernel de un sistema operativo: «supervisor». Al usar el prefijo «hiper-», el «hipervisor» se considera el supervisor de los «supervisores». Los hipervisores se encargan de separar los recursos de la máquina virtual del sistema de hardware** y de distribuirlos adecuadamente. Dado que son una parte esencial de la tecnología que respalda al cloud, facilitan la migración a la nube y, por lo tanto, también la reducción de los gastos de hardware y el aumento de la accesibilidad y la escalabilidad propios del cloud. ### ¿Qué beneficios proporcionan los hipervisores? Al ejecutar múltiples máquinas virtuales en un servidor físico con un hipervisor, las empresas pueden aprovechar diversos beneficios, como: - **Un uso más eficiente de los servidores físicos**, lo cual contribuye a reducir costes y aumentar la eficiencia. - **Mayor flexibilidad para ejecutar cargas de trabajo en diferentes tipos de hardware**, ya que el hipervisor separa los recursos de la máquina virtual del sistema de hardware. En este sentido, los hipervisores también facilitan la portabilidad y la distribución de recursos. Ambos tipos de hipervisores pueden ejecutar múltiples máquinas virtuales en el mismo servidor bare-metal. En este sentido, mientras en las nubes públicas el hipervisor ejecuta varias VMs para múltiples inquilinos dentro de un mismo servidor, en la nube privada, cada servidor bare-metal es de uso exclusivo para cada inquilino, lo cual ofrece un nivel de rendimiento y seguridad similar al de un servidor dedicado. ## Tipos de hipervisores Según Gerald J. Popek y Robert P. Goldberg, como se especifica en su artículo *Formal Requirements for Virtualizable Third Generation Architectures* de 1974, **hay dos tipos de hipervisores**. Aunque la distinción entre ambos tipos no siempre está completamente clara. ### Hipervisores de tipo 1 o hipervisores bare-metal Los hipervisores de tipo 1 o bare-metal, también conocidos como hipervisores nativos, **se ejecutan directamente en el servidor** y gestionan el sistema o sistemas operativos invitados. El software de virtualización se instala directamente en el hardware. Algunos ejemplos de hipervisores de tipo 1 son: - **Hipervisores bare-metal de código abierto**: KVM, Proxmox VE y Xen. - **Hipervisores bare-metal comerciales**: Citrix Hypervisor, Hyper-V y VMware ESXi. Este tipo de hipervisor es el que se suele desplegar para necesidades de computación de centros de datos. Por lo general ofrecen un rendimiento mejor y más eficiente que los hipervisores alojados. Del mismo modo que ofrecen mayor seguridad, al estar aislados del OS, que suele ser más propenso a sufrir ataques. ### Hipervisores de tipo 2 o hipervisores alojados Los hipervisores de tipo 2 o hipervisores alojados **se ejecutan como una capa de software por encima del sistema operativo** de la *host machine*; y también se pueden instalar sistemas operativos adicionales por encima. Se usan para abstraer los sistemas operativos invitados del OS principal. Algunos ejemplos de hipervisores de tipo 2 son: - **Hipervisores alojados de código abierto**: QEMU y VirtualBox. - **Hipervisores alojados comerciales**: Parallels Desktop, VMware Workstation Player y VMware Fusion. ## Lista de hipervisores de tipo 1 ### Proxmox VE **Proxmox VE (PVE), abreviatura de *Proxmox Virtual Environment***, es una plataforma de virtualización de código abierto basada en Debian. Soporta tanto la virtualización basada en contenedores con LXC y virtualización completa con KVM. Desde Stackscale somos expertos en como migrar de Vmware a Proxmox para simplificar la transición entre hipervisores. **Desarrollador**: Proxmox Server Solutions. **Licencia**: GNU AGPL v3.  **Última versión**: Proxmox VE 9.1. Más detalles en la web de Proxmox. ### KVM **KVM, abreviatura de *****Kernel-based Virtual Machine***, es un módulo de virtualización dentro del kernel de Linux que permite que este funcione como un hipervisor bare-metal. KVM fue desarrollado a mediados de 2006 por Avi Kivity en Qumranet (una startup tecnológica que en 2008 sería adquirida por Red Hat) y se integró en la línea principal del kernel de Linux en 2007 (versión 2.6.20). **Desarrollador**: The Linux Kernel community. **Licencia**: GNU GPL o LGPL. Más detalles en la web de Linux KVM. ### LXC **LXC, abreviatura de *****Linux Containers***, es una plataforma de virtualización a nivel del sistema operativo, de código abierto, diseñada para desarrollar tecnologías de contenedores para Linux. **Desarrollador**: Virtuozzo, IBM, Google, Eric Biederman y otros (kernel); Daniel Lezcano, Serge Hallyn, Stéphane Graber y otros (espacio de usuario). **Licencia**: GNU LGPLv2.1+. **Última versión**: LXC 5.0. Más detalles en la web de Linux Containers. ### VMware ESXi **VMware ESXi o VMware ESXi Hypervisor, antes VMware ESX**, es un hipervisor bare-metal de nivel empresarial que forma parte de la suite de virtualización vSphere de VMware. Este cuenta con su propio kernel y otros componentes esenciales del sistema operativo. En 2010, con la versión 4.1, cambió de nombre de VMware ESX a VMware ESXi. El cambio en la política de licencias está haciendo que muchas infraestructuras se decidan por Proxmox VE como alternativa real. **Desarrollador**: VMware, adquirido por Broadcom en noviembre de 2023. **Licencia**: propietaria. **Última versión**: VMware ESXi 9.0. Más detalles en la página sobre ESXi de VMware. ### OpenStack **OpenStack** es una plataforma cloud de código abierto, que se despliega tanto en cloud público como en cloud privado. Fue desarrollado inicialmente por Rackspace Hosting y la NASA en 2010. **Desarrollador**: Open Infrastructure Foundation and community. **Licencia**: Apache License 2.0. **Última versión**: OpenStack Bobcat, 2023.2. Más detalles en la web de OpenStack. ### Red Hat Virtualization (RHV) **RHV, abreviatura de *****Red Hat Virtualization***, es una plataforma de virtualización de nivel empresarial basada en KVM. **Desarrollador**: Red Hat. **Última versión**: RHV 4.4. Más detalles en la página web de RHV de Red Hat. ### Hyper-V **Hyper-V o Microsoft Hyper-V** es un hipervisor bare-metal, desarrollado por Microsoft. **Desarrollador**: Microsoft. Más detalles en la página de Hyper-V de Wikipedia. ### XEN **XEN o XEN Project** es un hipervisor bare-metal desarrollado inicialmente por el departamento de tecnología y ciencias de la computación de la Universidad de Cambridge, liderado por el académico senior Ian Pratt y su estudiante de doctorado Keir Fraser, en 2003. Actualmente el desarrollo y mantenimiento de XEN lo lleva a cabo la fundación Linux con apoyo de empresas como Intel, Citrix y AMD. **Desarrollador**: Fundación Linux con apoyo de algunas empresas. **Licencia**: GNU GPL. **Última versión**: Xen 4.18. Más detalles en la web de XEN Project. ### Citrix Hypervisor **Citrix Hypervisor, antes conocido como Citrix XenServer**, es el hipervisor bare-metal de Citrix, basado en XEN. **Desarrollador**: Citrix. Más detalles en la página sobre Citrix Hypervisor. ## Lista de hipervisores de tipo 2 ### VirtualBox **VirtualBox o Oracle VM VirtualBox**, conocido anteriormente como Innotek VirtualBox, Sun VirtualBox y Sun xVM VirtualBox, es un hipervisor alojado de código abierto. Inicialmente fue creado por Innotek, que en 2008 fue adquirido por Sun Microsystems (que Oracle compró a su vez en 2010). **Desarrollador**: Oracle Corporation. **Licencia**: GPLv2 y licencia propietaria. **Última versión**: VirtualBox 7.0. Más detalles en la web de VirtualBox. ### QEMU **QEMU** es un hipervisor alojado gratuito y de código abierto, escrito originalmente por Fabrice Bellard y disponible con una licencia pública general de GNU. Actualmente su desarrollo y mantenimiento lo lleva a cabo el equipo de QEMU. QEMU se puede usar como emulador y como virtualizador. **Desarrollador**: equipo de QEMU: Peter Maydell y otros. **Licencia**: GPLv2 y otras licencias. **Última versión**: QEMU 8.2.2. Más detalles en la web de QEMU. ### VMware Workstation Player **VMware Workstation Player, antes VMware Player**, es un hipervisor alojado para ejecutar máquinas virtuales en Microsoft Windows o Linux PC. VMware Player y VMware Workstation fueron integrados dentro de un mismo paquete en 2015. Cuenta con una versión gratuita para uso no comercial y personal, y una licencia comercial para empresas. **Desarrollador**: VMware, adquirido por Broadcom en noviembre de 2023. **Licencia**: propietaria. **Última versión**: VMware Workstation 17.0 Player. Más detalles en la página sobre Workstation Player de VMware. ### VMware Fusion **VMware Fusion** es un hipervisor de escritorio para ejecutar máquinas virtuales en Mac OS. **Desarrollador**: VMware, adquirido por Broadcom en noviembre de 2023. **Licencia**: propietaria. **Última versión**: VMware Fusion 13. Más detalles en la página sobre sobre VMware Fusion. ### Parallels Desktop **Parallels Desktop** es un hipervisor alojado que permite ejecutar Windows en Mac sin necesidad de reiniciar. **Desarrollador**: Parallels. **Licencia**: propietaria. **Última versión**: Parallels Desktop 19. Más detalles en la web de Parallels. **¿En busca de una solución de infraestructura completamente configurable?** Aprovecha las ventajas de los recursos de computación dedicados con nuestros servidores bare-metal. Implementa los sistemas de virtualización y orquestadores que quieras para tu proyecto. --- ## Hypervisors: definition, types and solutions URL: https://www.stackscale.com/blog/hypervisors/ Hypervisors are an essential part of the technology supporting cloud computing. There are **two types of hypervisors** — type 1 or bare-metal and type 2 or hosted, and numerous solutions in the market. In this post we are going to cover both types, including a list of **well-known hypervisor solutions** — both commercial and open-source. But let’s start by defining what a hypervisor is. ## What is a hypervisor? A hypervisor, also known as a **Virtual Machine Monitor (VMM),** is **a layer of virtualization software** that allows the creation and running of several virtual machines within a single server, as well as different operating systems. The physical server where the hypervisor runs one or more virtual machines is commonly known as a “**host machine**”, while each individual virtual machine is commonly known as a “**guest machine**”. ** The term “hypervisor”, coined in the 70s, was born from another term traditionally used to refer to the kernel of an operating system: “supervisor”. By using the prefix “hyper-”, the “hypervisor” is considered the supervisor of “supervisors”. Hypervisors are in charge of separating the resources of the virtual machine from the hardware system**, as well as of distributing them properly. As an essential part of the technology supporting the cloud, hypervisors make the migration to the cloud easier, enabling the reduction of hardware expenditures and the increase of accessibility and scalability inherent to the cloud. ### Which benefits do hypervisors provide? By running multiple virtual machines in a physical server using a hypervisor, businesses can leverage diverse benefits, such as: - **More efficient usage of physical servers**, thus contributing to reducing costs and increasing efficiency. - **Increased flexibility to run workloads on different types of hardware**, since the hypervisor separates the resources of the virtual machine from the hardware system. In this regard, hypervisors also facilitate portability and resource allocation. Both types of hypervisors can run multiple virtual machines in the same bare-metal server. In this regard, while in public clouds, the hypervisor runs several VMs for multiple tenants in the same server, in a private cloud, each bare-metal server is dedicated to each single tenant, offering a level of performance and security similar to dedicated servers. ## Types of hypervisors According to Gerald J. Popek and Robert P. Goldberg, as specified in their article *Formal Requirements for Virtualizable Third Generation Architectures* from 1974, **there are two types of hypervisors**. Although the distinction between both of them is not always completely clear. ### Type 1 hypervisors or bare-metal hypervisors Type 1 or bare-metal hypervisors, also known as native hypervisors, **run directly on the server** and manage guest operating systems. The virtualization software is installed directly on the hardware. Here are some examples of type 1 hypervisors: - **Open source bare-metal hypervisors**: KVM, Proxmox and Xen. - **Commercial bare-metal hypervisors**: Citrix Hypervisor, Hyper-V and VMware ESXi. This type of hypervisor is the most commonly deployed for data center computing needs. It generally performs better and more efficiently than hosted hypervisors. In addition to being more secure, as it is isolated from the OS, which is usually more prone to attacks. ### Type 2 hypervisors or hosted hypervisors Type 2 or hosted hypervisors, also known as client hypervisors, **run as a software layer on top of the operating system** of the host machine; and additional operating systems can be installed on top of it as well. They are used to abstract guest operating systems from the host OS. Here are some examples of type 2 hypervisors: - **Open source hosted hypervisors**: QEMU and VirtualBox. - **Commercial hosted hypervisors**: Parallels Desktop, VMware Workstation Player and VMware Fusion. This type of hypervisor is commonly used for purposes that do not require particularly low latency. ## List of type 1 hypervisors ### Proxmox VE **Proxmox VE (PVE), short for Proxmox Virtual Environment**, is an open source virtualization platform based on Debian. It supports both container-based virtualization with LXC and full virtualization with KVM. **Developer**: Proxmox Server Solutions. **License**: GNU AGPL v3.  **Latest version**: Proxmox 8.1. More details on Proxmox’s website. ### KVM **KVM, short for Kernel-based Virtual Machine**, is a virtualization module within the Linux kernel allowing it to work as a bare-metal hypervisor. KVM was developed by Avi Kivity at Qumranet (a tech startup company that would be acquired by Red Hat in 2008) in mid-2006 and it was merged into the mainline Linux kernel in 2007 (version 2.6.20). **Developer**: The Linux Kernel community. **License**: GNU GPL or LGPL. More details on Linux KVM’s website. ### LXC **LXC, short for Linux Containers**, is an open source OS-level virtualization platform designed for developing Linux container technologies. **Developer**: Virtuozzo, IBM, Google, Eric Biederman and others (kernel); Daniel Lezcano, Serge Hallyn, Stéphane Graber and others (userspace). **License**: GNU LGPLv2.1+. **Latest version**: LXC 5.0. More details on Linux Containers website. ### VMware ESXi **VMware ESXi or VMware ESXi Hypervisor, formerly VMware ESX**, is an enterprise-class, bare-metal hypervisor part of VMware’s vSphere virtualization suite. It includes its own kernel and other vital OS components. It was renamed from VMware ESX to VMware ESXi in version 4.1 in 2010. **Developer**: VMware, acquired by Broadcom in November 2023. **License**: proprietary. **Latest version**: VMware ESXi 8.0 Update 2. More details on VMware’s ESXi webpage. ### OpenStack **OpenStack **is an open source cloud platform, deployed both in public and private cloud. It was first developed by Rackspace Hosting and NASA in 2010. **Developer**: Open Infrastructure Foundation and community. **License**: Apache License 2.0. **Latest version**: OpenStack Bobcat, 2023.2. More details on OpenStack’s website. ### Red Hat Virtualization (RHV) **RHV, short for Red Hat Virtualization**, is an enterprise virtualization platform based on KVM and Red Hat Enterprise Linux. It was formerly known as Red Hat Enterprise Virtualization. **Developer**: Red Hat. **Latest version**: RHV 4.4. More details on Red Hat’s RHV web page. ### Hyper-V **Hyper-V or Microsoft Hyper-V** is a bare-metal hypervisor, developed by Microsoft. **Developer**: Microsoft. More details on Hyper-V’s Wikipedia page. ### XEN **XEN or XEN Project** is a bare-metal hypervisor originally developed by the University of Cambridge’s Department of Computer Science and Technology (former Computer Laboratory), led by the senior lecturer Ian Pratt and his PhD student Keir Fraser, in 2003. XEN is currently developed and maintained by the Linux Foundation with support from companies such as Intel, Citrix and AMD. **Developer**: Linux Foundation with support from some companies. **License**: GNU GPL. **Latest version**: Xen 4.18. More details on XEN Project’s website. ### Citrix Hypervisor **Citrix Hypervisor, formerly known as Citrix XenServer**, is Citrix’s bare-metal hypervisor based on XEN.  **Developer**: Citrix. More details on Citrix’s Hypervisor web page. ## List of type 2 hypervisors ### VirtualBox **VirtualBox or Oracle VM VirtualBox**, formerly known as Innotek VirtualBox, Sun VirtualBox and Sun xVM VirtualBox, is a free, open source hosted hypervisor. It was originally created by Innotek, which was later acquired by Sun Microsystems in 2008 (acquired by Oracle in 2010). **Developer**: Oracle Corporation. **License**: GPLv2 and proprietary license. **Latest version**: VirtualBox 7.0. More details on VirtualBox’s website. ### QEMU **QEMU** is a free, open source hosted hypervisor, originally written by Fabrice Bellard and licensed under the GNU General Public License. It is currently developed and maintained by the QEMU team. QEMU can be used as a machine emulator and as a virtualizer. **Developer**: QEMU team: Peter Maydell and others. **License**: GPLv2 and other licenses. **Latest version**: QEMU 8.2.2. More details on QEMU’s website. ### VMware Workstation Player **VMware Workstation Player, formerly VMware Player**, is a hosted hypervisor for running virtual machines on Microsoft Windows or Linux PC. VMware Player and VMware Workstation were combined within a single package in 2015. It has a free version for non-commercial, personal use and a commercial license for commercial organizations. **Developer**: VMware, acquired by Broadcom in November 2023. **License**: proprietary. **Latest version**: VMware Workstation 17.0 Player. More details on VMware’s Workstation Player webpage. ### VMware Fusion **VMware Fusion** is a desktop hypervisor for running virtual machines on Mac OS. **Developer**: VMware, acquired by Broadcom in November 2023. **License**: proprietary. **Latest version**: VMware Fusion 13. More details on VMware Fusion’s webpage. ### Parallels Desktop **Parallels Desktop** is a hosted hypervisor that allows running Windows on Mac without rebooting. **Developer**: Parallels. **License**: Proprietary. **Latest version**: Parallels Desktop 19. More details on Parallels’ website. **Looking for a fully customizable infrastructure solution?** Leverage the advantage of dedicated computing resources with our bare-metal servers. Implement the virtualization systems and orchestrators you want for your project. --- ## WordPress de alta disponibilidad: 12 aspectos clave URL: https://www.stackscale.com/blog/high-availability-wordpress-website/ Esta **guía sobre cómo conseguir un sitio web WordPress de alta disponibilidad** (HA) aborda los principales aspectos a tener en cuenta para garantizar una alta disponibilidad, rendimiento y resiliencia en un sitio web corporativo en WordPress o un comercio electrónico basado en WooCommerce. El tiempo de inactividad no sólo puede tener un impacto negativo en los ingresos de un negocio, sino que también puede dañar gravemente la reputación de la marca. Es un aspecto que no se debe descuidar, así que entremos en los detalles. ## Elementos básicos de un sitio WordPress de alta disponibilidad La siguiente guía recoge los **elementos clave de una configuración de alta disponibilidad en WordPress**, empezando de abajo arriba. Como expertos en soluciones de infraestructura de TI, tenemos claro que la alta disponibilidad comienza a nivel de infraestructura. ### Infraestructura HA Como partner tecnológico estratégico y de misión crítica, el proveedor de alojamiento en la nube es un gran aliado para alcanzar sus objetivos. Así que, es importante asegurarse de contar con un proveedor fiable que ayude a tu empresa a desplegar una infraestructura HA que pueda seguir funcionando bajo cualquier circunstancia. En Stackscale, recomendamos contar con una infraestructura de nube privada para conseguir **alta disponibilidad, redundancia y seguridad**. Pero existen muchas soluciones en el mercado que se adaptan a las necesidades de cada proyecto. ### Almacenamiento Como parte de la infraestructura, un clúster de HA también debe incluir los sistemas de almacenamiento necesarios. Nosotros recomendamos volúmenes de almacenamiento en red centralizados en distintas cabinas redundantes, ya que son ideales para diversos tipos de archivos. Adicionalmente, para **obtener una alta disponibilidad real sobre los datos**, también se pueden mantener dos volúmenes en diferentes data centers para mantener copias síncronas de los datos, así como un clúster entre dos CPDs en la base de datos. ### Ancho de banda **Garantizar un ancho de banda suficiente**, que se adapte a las necesidades del proyecto en todo momento, también es importante para poder absorber picos de tráfico sin interrupciones. Así como contar con una red de comunicaciones avanzada, con las medidas de seguridad necesarias para absorber una gran cantidad de tráfico e incluso ataques DDoS. Por supuesto, como mencionamos más abajo, también se puede complementar con un servicio de CDN. ### Balanceo de carga El balanceo de carga también es esencial. En este sentido, destacamos **HAProxy como una solución de balanceo de código abierto** que proporciona balanceadores en alta disponibilidad para servicios web normales y seguros con SSL. Esta aplicación cuenta con una amplia reputación entre las empresas y la comunidad de administración de sistemas. Es capaz de gestionar millones de peticiones para proyectos de alto tráfico y muchos grandes proyectos de Internet la utilizan, entre ellos: GitHub, Stack Overflow, Reddit, Tumblr y Twitter. No obstante, existen **otras muchas soluciones de balanceo de hardware o virtuales** como F5 o similares. ### Mecanismos de caché Implementar mecanismos de caché también es recomendable para reducir la carga en los servidores web y evitar sobrecostes. En lo que se refiere a caché, **Varnish Cache** es posiblemente la mejor solución para cachear y acelerar páginas web. Algunos proyectos incluso lo usan como balanceador de carga. Varnish Cache se instala delante de cualquier servidor web y se configura para almacenar una copia de las páginas solicitadas en la caché del servidor. Gracias a esto, después se puede **servir el contenido de manera mucho más rápida y eficiente**. Lo usan muchos sitios web de alta demanda y tráfico como The New York Times, The Guardian o Corriere della Sera; así como plataformas de contenidos y redes sociales como Wikipedia, Facebook o Vimeo. Asimismo, **Redis caché** también resulta útil para mejorar la caché de sesiones, entre otros aspectos. ### Red de distribución de contenidos Una solución de CDN también se puede usar para cachear contenido y servirlo a los usuarios desde ubicaciones más cercanas. Las redes de distribución de contenidos ayudan a reducir la cantidad de datos que el servidor de origen debe proporcionar a los usuarios finales. De modo que también contribuyen a **disminuir el uso y costes de ancho de banda**. Asimismo, una CDN puede ser un complemento especialmente útil si el proyecto recibe tráfico de múltiples partes del mundo. ### Servidores web NGINX + PHP-FPM **NGINX es un servidor web de alto rendimiento y muy ligero**. Aunque NGINX es de código abierto, bajo licencia BSD, también cuenta con una versión comercial denominada NGINX plus. Una larga lista de empresas y sitios webs utiliza este servidor —desde WordPress a otras muy conocidas como Facebook, Netflix, GitHub y SourceForge—. Este servidor web se puede complementar con el módulo PHP-FPM, que es una potente alternativa al PHP FastCGI y cuenta con características especiales pensadas para sitios webs de mucho tráfico. Por supuesto, también existen **otros servidores web aptos para soluciones de WordPress** como puede ser Apache HTTP o LiteSpeed Web Server. La mejor solución dependerá de cada proyecto en concreto. ### Clúster de base de datos MySQL MySQL es la **base de datos de código abierto más popular del mercado** y cuenta con alternativas como MariaDB o Percona MySQL. Su rendimiento probado, fiabilidad y facilidad de uso la han hecho realmente popular. Millones de sitios web utilizan esta base de datos; entre ellos, grandes plataformas como Twitter, Youtube o Facebook. Al desplegar un clúster de base de datos con MySQL o Percona podrás conseguir una **alta disponibilidad de los datos**; además de conseguir un mayor rendimiento y una disponibilidad del 99,999 %. Una arquitectura distribuida, *multi-tenant* y sin puntos de error con MySQL en clúster te proporcionará escalabilidad para grandes necesidades de manejo de datos. Adicionalmente, contar con una solución de distribución geográfica también permite separar un clúster entre varios data centers, con latencias inferiores a 1 ms entre ellos, para mejorar la HA y la resiliencia de la plataforma. En este punto también es importante contar con un buen **equipo de administración de sistemas y bases de datos**. Este se encargará de desarrollar los procedimientos para que funcione en las situaciones más críticas y para que pueda crecer cuando sea necesario. ### Infraestructura para desarrollo y despliegues Si es posible, es recomendable **adoptar despliegues con soluciones de gestión de versiones de código como GIT o similares**, en lugar de FTP. Asimismo, es importante no pasar por alto la importancia de disponer de un entorno de desarrollo, que sirva de copia simplificada del entorno de producción real para desplegar y probar nuevas funcionalidades. ### Backups y redundancia Definir una completa **política de copias de seguridad y snapshots** es esencial para garantizar la disponibilidad y continuidad del negocio. En Stackscale, tenemos programas de backup personalizados disponibles a petición, además de los backups y snapshots incluidos por defecto en nuestros sistemas de almacenamiento en red. Además, recomendamos guardar **una réplica en un centro de datos geográficamente distante** para aumentar la redundancia. La georedundancia es otro mecanismo para conseguir alta disponibilidad. Al replicar los datos y la infraestructura IT en múltiples data centers remotos, es posible reforzar la protección de los datos y minimizar el tiempo de inactividad. ### Seguridad Sobra decir que la seguridad debe ser una prioridad absoluta para cualquier proyecto hoy en día. Definir una **política de seguridad y Anti-DDoS** sólida es clave para estar preparado para mitigar un ataque potencial en el futuro. Esta también se puede complementar con soluciones de CDN y WAF. En estrecha relación con la seguridad, la administración de sistemas y monitorización 24/7 también son esenciales. ### Acceso seguro al panel de gestión de la infraestructura Por último, pero no menos importante, garantizar la seguridad de acceso a la administración de tu WordPress, así como a cualquier otro panel de administración, es indispensable. Puedes renombrar o no el directorio «wp-admin» de tu WordPress, pero es importante que el acceso al mismo esté **protegido mediante contraseña del servidor web**. Además de su propia protección de usuario y password. Siempre recomendamos proteger todos los elementos de gestión mediante una VPN para garantizar conexiones cifradas y seguras. ## ¿Qué debería incluir un clúster WordPress de HA? En resumen, un clúster WordPress de alta disponibilidad debería incluir al menos: - Una infraestructura de HA bare-metal o cloud con al menos 2 nodos de computación en dos centros de datos distintos, con baja latencia. - Volúmenes de almacenamiento, con réplicas de datos en 2 centros de datos. - Suficiente ancho de banda. - Balanceo de carga. - Mecanismos de caché. - Servidor web. - Base de datos. - Backups y redundancia. - Administración de sistemas y monitorización 24/7. ## WordPress HA en un entorno de nube privada A la hora de configurar una infraestructura altamente disponible y redundante, es importante pensar en la evolución y necesidades de tu futura web. Si estimas que tu plataforma con WordPress tendrá que soportar miles e incluso millones de visitas cada día, la infraestructura es clave y debe estar preparada. A continuación compartimos un ejemplo de **infraestructura de nube privada de alta disponibilidad desplegada en dos centros de datos diferentes**. En el ejemplo anterior, sugerimos el despliegue de 2 nodos físicos de nube privada, en 2 centros de datos diferentes, para **conseguir una alta disponibilidad real** y al mismo tiempo beneficiarse de las ventajas de disponer de dos ubicaciones físicas. Este ejemplo de infraestructura ubicada en dos de nuestros centros de datos en Madrid funciona como una sola e incluye también varios sistemas de almacenamiento en red centralizados en cabinas redundantes. No obstante, desde nuestra experiencia, es imprescindible estudiar cada proyecto para **construir una infraestructura adaptada a sus necesidades reales**. Trabajamos en diferentes tipos de proyectos y sectores, y sabemos que cada proyecto es diferente y único. Así que, no dudes en contactar con nosotros si necesitas ayuda para definir una infraestructura de alta disponibilidad para tu proyecto. --- ## High Availability WordPress: 12 key aspects URL: https://www.stackscale.com/blog/high-availability-wordpress-website/ This **guide on how to achieve a High Availability WordPress website** addresses the main aspects to consider to ensure high availability, performance and resilience for a WordPress corporate website or WooCommerce-based eCommerce. Downtime cannot only have a negative impact on business revenues but can also seriously damage your brand reputation. It is not to be neglected, so let’s delve into the details. ## Basic elements in a High Availability WordPress site The following guide collects the **key elements of a WordPress High Availability Setup**, starting from the bottom up. As experts in IT infrastructure solutions, we are convinced High Availability starts at the infrastructure level. ### High Availability Infrastructure As a mission-critical and strategic technological partner, your cloud hosting provider is a great ally to achieve your goals. Therefore, make sure you choose a reliable provider that helps you deploy a High Availability infrastructure that can keep running under any circumstances. At Stackscale, we recommend relying on a private cloud infrastructure for achieving **High Availability, redundancy and security**. But there are numerous options in the market that adapt to each project’s needs. ### Storage As part of the infrastructure, a HA cluster should also include the necessary storage systems. We recommend centralized network storage volumes in different redundant arrays, since they are ideal for diverse types of files. Additionally, businesses can **achieve real high availability over data** by maintaining two volumes in different data centers to keep synchronous copies of data, as well as a cluster between two data centers in the database. ### Bandwidth **Guaranteeing sufficient bandwidth**, that adapts to the project’s needs at all times, is also important in order to be able to stand traffic spikes without downtime. As well as relying on an advanced communications network, with the necessary security measures to support great amounts of traffic and even DDoS attacks. Of course, as we mention later on, this can also be reinforced by a CDN service. ### Load Balancing Load balancing is essential as well. In this regard, we highlight **HAProxy as an open source load balancing solution** that provides High Availability load balancers for normal and secure SSL web servers. This application has an outstanding reputation among companies and the system administrators’ community. It is able to manage millions of requests for high-traffic projects and many big Internet projects use it, for instance: GitHub, Stack Overflow, Reddit, Tumblr and Twitter. Nevertheless, there are **many other virtual or hardware balancing solutions** such as F5 or similar ones. ### Caching mechanisms Implementing caching mechanisms is also advisable to reduce the load on web servers and avoid overspend. In terms of caching, **Varnish Cache** is probably the best solution to cache and accelerate web pages. Some projects even use it as a load balancer. Varnish Cache can be installed on any web server and be set up to store a copy of the requested pages in the server cache. By doing so, **content can be served faster and more efficiently**. It is used by many high-traffic websites, such as The New York Times, The Guardian or Corriere della Sera; as well as social media and content platforms such as Wikipedia, Facebook or Vimeo. Additionally, **Redis cache** is also useful to improve session cache, among other aspects. ### Content Delivery Network A CDN solution can also be used to cache content and serve it to users from closer locations. Content Delivery Networks help reduce the amount of data the source server must provide to end users. Thus also contributing to **cutting down bandwidth usage and costs**. Furthermore, a CDN can be a particularly useful tool if the project receives traffic from multiple parts of the world. ### NGINX Web Servers + PHP-FPM **NGINX is a very light high-performance web server**. Although NGINX is open source, under BSD license, there is also a commercial version known as NGINX Plus. A long list of companies and websites use this server —from WordPress to other well-known companies such as Facebook, Netflix, GitHub and SourceForge. Besides, this web server can be completed with the PHP-FPM module, which is a powerful alternative to PHP FastCGI and includes special features designed for high-traffic websites. Naturally, there are also **other web servers suitable for WordPress solutions** such as Apache HTTP or LiteSpeed Web Server. The best solution will depend on each particular project. ### MySQL cluster **MySQL is the most popular open source database in the market**. It has become really popular thanks to its proven performance, reliability and ease of use. Millions of websites use this database; among them, big platforms such as Twitter, Youtube or Facebook. MariaDB and Percona MySQL are some of its alternatives.  By deploying a MySQL or Percona cluster, you will be able to ensure **data High Availability**; in addition to getting a higher performance and 99,999% availability. A distributed, multi-tenant and without points of error architecture with MySQL cluster will provide you the necessary scalability for big data processing needs. Additionally, relying on a geographical distribution solution also allows dividing a cluster among several data centers, with latencies below 1 ms, to improve platform HA and resilience. At this point, it is also important to have a good **database and system administration team**. They will be responsible for developing the procedures to make it work during the most critical scenarios and to enable it to grow whenever necessary. ### Infrastructure for development and deployment If possible, it is recommended to **adopt GIT deployments or similar solutions**, instead of FTP. Moreover, let’s not overlook the importance of having a development environment, which serves as a simplified copy of the real production environment for deploying and testing new functionalities. ### Backups and redundancy Defining a complete **backups and snapshots policy** is vital in order to ensure availability and business continuity. At Stackscale, custom backup schedules are available on request, in addition to the backups and snapshots included by default in network storage systems. Besides, we recommend keeping **a replica in a geographically distant data center** for further redundancy. Geo-redundancy is another mechanism to achieve HA. By replicating data and IT infrastructure in multiple remote data centers, businesses can reinforce data protection and minimize downtime. ### Security It goes without saying that security must be a top priority for any project nowadays. Defining a strong **security and Anti-DDoS policy** is key to be prepared to mitigate a potential attack in the future. It can also be completed with CDN and WAF solutions. Closely related to security, 24/7 monitoring and system administration is definitely essential as well. ### Secure access to the infrastructure management dashboard Last but not least, ensuring a secure access to your WordPress administration dashboard, as well as to any other management dashboard, is indispensable. You may or may not rename your WordPress’ “wp-admin” directory, but it is important you **protect its access by using a password for the web server**. In addition to the default user and password protection. We always recommend protecting all management elements using a VPN to ensure encrypted and secure connections. ## What should a HA WordPress Cluster include? To sum up, a High Availability WordPress Cluster should at least include: - A HA bare-metal or cloud infrastructure with at least 2 computing nodes in two different data centers, with low latency. - Storage volumes, with data replication in two data centers. - Sufficient bandwidth. - Load balancing. - Cache mechanisms. - Web server. - Database. - Backups and redundancy. - 24/7 monitoring and system administration. ## WordPress High Availability in a private cloud environment When setting up a redundant and High Availability infrastructure,** **it is important to think about the evolution and needs of your future platform. If you consider your WordPress site will have to support thousands or even millions of daily visits, the infrastructure is essential and must be ready. Here is an example of **High Availability private cloud infrastructure deployed in two different data centers**. In the example above, we suggest the deployment of 2 physical private cloud nodes, in 2 different data centers, in order to **achieve** **real High Availability** while benefiting from the advantages of having two physical locations. This example infrastructure located in two of our data centers in Madrid runs as a single one and also includes several centralized network storage systems in redundant arrays. Nevertheless, from our experience, every project should be evaluated in order to **build an infrastructure adapted to its real needs**. We work in different types of projects and sectors, and every project is different and unique. So, please do not hesitate to contact us if you need help defining a High Availability infrastructure for your project. --- ## Eficiencia energética en centros de datos URL: https://www.stackscale.com/blog/energy-efficiency-measures-data-centers/ **La eficiencia energética es esencial para construir soluciones sostenibles y asegurar un crecimiento sostenible a largo plazo**. Maximizar los beneficios de la tecnología al mismo tiempo que se reduce su impacto en el planeta es **uno de los principales desafíos de los centros de datos a día de hoy**. Los centros de datos necesitan una gran cantidad de energía para su funcionamiento. De modo que la eficiencia energética es una prioridad, no solo a nivel de sostenibilidad, sino también a nivel de costes —especialmente si tenemos en cuenta el aumento de la factura de la electricidad a lo largo del tiempo—. ## Gestión de la energía en el centro de datos No cabe duda de que la gestión de la energía en centros de datos es uno de los desafíos más complejos en la industria. Hay muchos métodos que los data centers pueden implementar para aumentar la eficiencia energética, y también siguen surgiendo nuevos sistemas. Además, aspectos como la ubicación del centro de datos en climas más frescos también pueden ayudar a reducir considerablemente el consumo de energía y los costes. Por eso **los ****grandes centros de datos especializados**** trabajan constantemente en mejorar su eficiencia energética**. Para ello implementan todo tipo de técnicas innovadoras para reducir su PUE. ## ¿Qué es el PUE del data center? **El PUE, acrónimo de *****Power Usage Effectiveness***, es el valor que resulta de dividir la cantidad total de energía que usan las instalaciones de un centro de datos entre la energía que se suministra al equipamiento de IT del centro de datos. Elementos como la iluminación o la refrigeración entran dentro de la categoría de energía que usan las instalaciones de un centro de datos. ** PUE = Energía total de las instalaciones / Energía del equipamiento IT * El valor PUE indica cómo de eficiente es el uso de la energía en un centro de datos y, más concretamente, cuánta energía utiliza el equipamiento IT**. Un valor ideal sería un PUE de 1,0. Este método fue desarrollado originalmente por The Green Grid, una organización IT sin ánimo de lucro, en 2007. Al igual que cualquier otro método, tiene tanto aspectos positivos como negativos. Pero, con todo, es el método más popular y el más efectivo para medir la eficiencia en los centros de datos actualmente. Se publicó como estándar global bajo la ISO/IEC 30134-2:2016 y como estándar europeo bajo la EN 50600-4-2:2016, en 2016. ### Valor PUE medio a nivel mundial Según la encuesta global de centros de datos del Uptime Institute de 2023, el PUE medio anualizado a nivel mundial fue 1,58. De hecho, merece la pena mencionar que el PUE medio global está estancado desde 2018, entre 1,55 y 1,60 —con un ligero aumento hasta llegar a 1.67 en 2019—. ¿A qué se debe este estancamiento? Una de las razones detrás de este estancamiento es probablemente el hecho de que la encuesta haya ampliado su alcance a más territorios. Mientras antes solía estar dominada por centros de datos de Norteamérica y Europa, ahora ofrece una visión más global. En este sentido, aspectos como la mayor demanda de sistemas de refrigeración en los climas más cálidos contribuyen a esta tendencia. En climas más cálidos y húmedos como Oriente Medio y Latinoamérica, el valor PUE medio es superior a 1,70. Sin embargo, hay causas adicionales que impiden que el valor PUE medio a nivel global se siga reduciendo, como pueden ser el alto coste y la complejidad técnica de mejorar la eficiencia en centros de datos antiguos y de menor tamaño. Según la encuesta, los centros de datos construidos durante los últimos cinco años son más eficientes. A modo de ejemplo, las nuevas construcciones en Norteamérica y Europa cuentan con un valor PUE por debajo de 1.40.   ## Medidas de eficiencia energética en centros de datos En comparación con los centros de datos tradicionales on-premise, los grandes centros de datos tienen un efecto positivo en el consumo energético destinado a la computación**, **ya que el uso del hardware físico está mucho más optimizado. Sin embargo, al igual que aumenta la necesidad de disponer de servicios de computación más complejos y rápidos, también lo hace la necesidad de reducir la huella de los centros de datos. Estas son **algunas de las medidas de eficiencia energética más comunes que los centros de datos pueden implementar (e implementan) para reducir su consumo energético**. Así como para asegurar un servicio resiliente y eficiente. ### Free cooling Los operadores de centros de datos pueden ahorrar una gran cantidad de energía optimizando los sistemas de enfriamiento. En este sentido, uno de los más populares y eficientes actualmente es el «free cooling». El método de free cooling* o enfriamiento gratuito consiste en **utilizar las bajas temperaturas exteriores para enfriar las instalaciones de un centro de datos**. Su adopción se ha incrementado rápidamente gracias a sus múltiples beneficios a nivel de eficiencia energética y costes. ** Los sistemas de enfriamiento en los datacenters pueden llegar a representar casi la mitad del consumo de electricidad total. #### ¿Cómo funciona exactamente el *free cooling*? El sistema de *free cooling* se enciende cuando la temperatura exterior es más baja que la temperatura interior proporcionada por el sistema de aire acondicionado. Por lo tanto, cuando desciende hasta la temperatura indicada, el sistema de *free cooling* se pone en funcionamiento. Entonces, una válvula moduladora permite que todo o parte del agua pase a través del sistema de *free cooling* en lugar de pasar por el sistema de aire acondicionado. El *free cooling* puede ser directo o indirecto: - *Free cooling***** directo**. El flujo de aire empuja el aire exterior frío hacia dentro del centro de datos y el aire interior caliente hacia fuera. Sin embargo, a pesar de poder parecer sencillo, el aire exterior se debe filtrar y ajustar a los parámetros de temperatura y humedad del data center. - ***Free cooling***** indirecto**. Uno o dos intercambiadores de calor se usan para transportar el aire hacia fuera. Los sistemas de *free cooling* indirecto en una etapa transfieren el aire a través de un intercambiador de calor aire-aire. Los sistemas de *free cooling* indirecto en dos etapas usan un intercambiador de calor para transmitir el calor a un líquido y otro transporta el aire hacia fuera. **Los centros de datos ahorran mucha energía al** **usar una fuente natural de refrigeración** para enfriar, en lugar de un sistema eléctrico. Esto es especialmente importante si tenemos en cuenta que los sistemas de aire acondicionado en los centros de datos pueden llegar a suponer casi la mitad del consumo de electricidad total. ### Gestión de la temperatura Además del *free-cooling*, existen muchas otras medidas para conseguir una gestión de la temperatura más sostenible en los centros de datos. Estos son algunos ejemplos: - **Contención del aire frío y caliente**. Implementar barreras físicas para evitar que el aire de los pasillos fríos se mezcle con el aire de los pasillos calientes. - **Refrigerantes naturales**. Usar refrigerantes naturales para enfriar, en lugar de hidroclorofluorocarbonos (HCFC) e hidrofluorocarbonos (HFC). Ya que, al contrario que los refrigerantes HCFC y HFC, los refrigerantes naturales como el agua (R718) o el amoníaco (R717) no deterioran la capa de ozono. - **Enfriamiento líquido directo (DLC o *****Direct Liquid Cooling*****, en inglés)**. Un método de enfriamiento que usa líquidos, en lugar de aire, para eliminar el calor del equipamiento TI. Esto reduce significativamente la dependencia de los sistemas de aire acondicionado. Aunque el *free cooling* sigue siendo predominante, se estima que el DLC crecerá en los próximos años, según Uptime Intelligence. - **Temperatura de refrigeración más alta**. Aumentar la temperatura de refrigeración en los centros de datos disminuye el consumo energético y alarga la vida útil de los sistemas de refrigeración. - **Reciclaje y recuperación del calor**. Reutilizar el exceso de calor de los centros de datos para calentar hogares, oficinas y escuelas cercanas puede reducir las emisiones significativamente. La recuperación del calor es una forma ingeniosa de minimizar el desperdicio energético y optimizar el consumo de energía. Especialmente si se tiene en cuenta que los sistemas y el equipamiento IT alojados en los centros de datos generan una gran cantidad de calor excedente. - **Modernización del sistema de refrigeración**. Solo con actualizar los sistemas de refrigeración, los centros de datos pueden mejorar su eficiencia energética de forma considerable. Como ejemplo, Interxion renovó sus sistemas de refrigeración en su CPD de Madrid MAD1 y consiguió aumentar las horas de free-cooling de 2.700 a 7.700 horas al año. ### Inteligencia artificial y aprendizaje automático El uso de la inteligencia artificial (IA) en los centros de datos también puede aportar beneficios considerables a nivel de rendimiento, costes y eficiencia. Los grandes centros de datos ya utilizan la IA y el aprendizaje automático para identificar nuevas mejoras de eficiencia. Los centros de datos utilizan redes neuronales artificiales y *deep learning* para: - **optimizar los sistemas de refrigeración,** - **predecir el uso energético,** - **y mejorar los valores PUE y la gestión del centro de datos** en general.  La aplicación de la IA para mejorar y optimizar la gestión de los centros de datos tiene un potencial inmenso. Los CPDs ya usan la Inteligencia Artificial para mejorar muchos otros aspectos, como: analizar riesgos, predecir la demanda, mejorar el mantenimiento del equipamiento u optimizar el diseño y las operaciones de los centros de datos. Asimismo, la IA se puede usar incluso para encontrar soluciones a problemas más complejos, como mejorar la integración de los centros de datos dentro de las ciudades. ### Energías renovables En relación al consumo de energía, usar energías 100 % renovables y limpias también es una prioridad entre los grandes data centers. Durante los últimos años, han trabajado constantemente para reducir su dependencia de los combustibles fósiles. Además de invertir muchos recursos en incrementar la eficiencia y reducir su huella medioambiental. Esta es una de las razones por las que confiamos en centros de datos especializados, de calidad; **muy comprometidos a proporcionar el mejor equilibrio entre calidad, seguridad y eficiencia**. En resumen, los centros de datos pueden implementar numerosas medidas para aumentar su eficiencia energética. Aunque siempre hay trabajo por hacer, nuevas medidas innovadoras aparecen constantemente para impulsar la eficiencia y reducir el consumo energético en los centros de datos. Fuentes: Uptime Institute y Uptime Intelligence. --- ## Improving energy efficiency in data centers URL: https://www.stackscale.com/blog/energy-efficiency-measures-data-centers/ **Energy efficiency is essential for building sustainable solutions and ensuring long-term sustainable growth**. Maximizing the benefits of technology while reducing its impact on the planet is **one of the main challenges of data centers nowadays**. Data centers require a vast amount of energy to keep running. Therefore, energy efficiency is a priority, not only in terms of sustainability, but also in terms of costs — especially considering energy bills have rocketed over time. ## Data center power management There is no doubt that data center power management is one of the most complex challenges in the industry. There are many methods data centers can implement to increase energy efficiency, and new systems also continue to enter the market. Besides, aspects such as locating data centers in cooler climates can also help to considerably reduce energy consumption and costs. That is why **large, specialized data centers**** are constantly working on improving their energy efficiency**. For doing so, they implement all kinds of innovative techniques in order to reduce their PUE. ## What is the data center PUE? **PUE, acronym for Power Usage Effectiveness**, is the value derived from dividing the total amount of energy used by a data center facility by the energy delivered to the data center’s computing equipment. Elements such as lighting or cooling fall into the category of energy used by a data center facility. ** PUE = Total facility power / IT equipment power The PUE ratio indicates how efficiently a data center uses energy and, more precisely, how much energy the computing equipment uses**. An ideal value would be a PUE of 1.0. This method was originally developed by The Green Grid, a non-profit IT organization, in 2007. As any other method, it has both positive and negative features. But, all in all, it is the most popular and the most effective method to measure efficiency in data centers nowadays. It was published as a global standard under ISO/IEC 30134-2:2016 and as a European standard under EN 50600-4-2:2016, in 2016. ### Average data center PUE globally  According to the Uptime Institute Global Data Center Survey 2023, the average annualized PUE globally was 1.58. In fact, it is worth noting that the average PUE globally has been stalled since 2018, between 1.55 and 1.60 — with a slight increase up to 1.67 in 2019.  Why is it so? One of the reasons for this stagnation is probably the fact that the survey has expanded its reach into additional territories. While it used to be dominated by North American and European data centers, it now offers a more global overview. In this regard, aspects such as more demanding cooling systems in warmer climates contribute to this trend. In warmer and more humid climates such as the Middle East and Latin America, the average PUE is above 1.70. Nevertheless, there are additional causes that prevent the global average PUE to continue decreasing, such as the high costs and technical complexity of improving efficiency in old and smaller data centers. According to the survey, data centers built during the past five years are more efficient. As an example, new constructions in North America and Europe hold a PUE ratio below 1.40. ## Data centers energy efficiency measures When compared to traditional on-premise data centers, large data centers have a positive effect on power consumption for computing; since the utilization of physical hardware is much more optimized. However, as the need for faster and more complex computing services increases, so does the need to reduce the data centers’ footprint. Let’s see **some of the most common energy efficiency measures data centers can (and do) put in place to reduce their power consumption**. As well as to ensure a resilient and efficient service. ### Free cooling Data center operators can save a great amount of energy by optimizing cooling systems. On this matter, one of the most popular, efficient systems nowadays is “free cooling”. The free cooling method consists of **using low outdoor temperatures to cool data center facilities**. Its adoption has quickly grown thanks to its numerous benefits in terms of cost and energy efficiency.  ** Cooling systems in data centers can account for almost a half of the whole electricity use. #### How does free cooling exactly work? The free cooling system turns on when outdoor temperatures are lower than the indoor temperature achieved by the air conditioning system. So, when dropping to the set temperature, the free cooling system starts working. Then, a modulating valve allows all or part of the water to go through the free cooling system; instead of going through the air conditioning system’s chiller. Free cooling can either be direct or indirect: - Direct free cooling**. The air flow pushes cold outdoor air inside the data center and warm indoor air outside. However, as simple as it might sound, outdoor air must be filtered and adjusted to the datacenter’s temperature and humidity parameters. - **Indirect free cooling**. One or two heat exchangers are used to transport outside air. Single-stage indirect free cooling systems convey indoor air through an air/air heat exchanger. Two-stage indirect free cooling systems use a heat exchanger to transfer heat into a liquid and a second one to convey air to the outside. **Data centers save a lot of energy by using a natural cooling source** for air conditioning, instead of an electrical chiller. This is especially important considering that cooling systems can account for almost a half of the whole data center energy consumption. ### Cooling and heat management Apart from free cooling, there are many other measures for achieving a more sustainable cooling and heat management in data centers. Here are some examples: - **Cold air and hot air containment**. Implementing physical barriers to avoid that cold air in supply aisles mix with hot air in exhaust aisles. - **Natural refrigerants**. Using natural refrigerants for cooling; instead of hydrochlorofluorocarbon (HCFC) and hydrofluorocarbon (HFC). Since, unlike HCFC and HFC refrigerants, natural refrigerants such as water (R718) or ammonia (R717) do not deplete the ozone layer. - **Direct Liquid Cooling (DLC)**. It is a cooling method that uses liquids, instead of air, to remove heat on IT equipment. This significantly reduces the dependence on air conditioning systems. Although free cooling is still predominant, DLC is expected to grow over the coming years, according to Uptime Intelligence. - **Higher cooling temperature setpoint**. Raising temperature setpoints in data centers lowers power consumption and extends the cooling systems’ lifespan.  - **Heat recovery and recycling**. Reusing data centers’ excess heat to warm nearby households, offices and schools can significantly reduce emissions. Heat recovery is a smart way of minimizing energy waste and optimizing energy consumption. Especially when taking into account that data centers generate a huge amount of excess heat from all the equipment and systems they host. - **Cooling system modernization**. Simply by updating cooling systems, data centers can considerably improve energy efficiency. As an example, Interxion updated its cooling systems in Madrid’s data center MAD1 and increased the free cooling hours from 2,700 to 7,700 hours per year. ### Artificial Intelligence and Machine Learning The use of Artificial Intelligence (AI) in data centers can also bring considerable benefits in terms of performance, costs and efficiency. Large data centers already use AI and Machine Learning (ML) for identifying new efficiency improvements. Data centers use deep learning and artificial neural networks for: - **optimizing cooling systems,** - **predicting power use,** - **and improving PUE ratios and data center management** in general.  The potential to improve and optimize data center management by applying AI is huge. Data centers already use AI for improving many other aspects, such as: analyzing risks, forecasting demand, improving equipment maintenance or optimizing data centers’ design and operations. Besides, AI can even be used to find solutions to more complex issues, such as better integrating data centers in cities. ### Renewable energies Regarding energy consumption, using 100% clean and renewable energies is also a priority among major data centers. During the past years, they have been working hard on reducing their reliance on fossil fuels. As well as they have invested a lot of resources in increasing efficiency and reducing their environmental footprint. That is one of the reasons why we rely on high-quality, specialized data centers; **deeply committed to deliver the best performance, security and efficiency balance**. To sum up, data centers can implement numerous measures to increase their energy efficiency. Even though there is always room for improvement, new innovative measures are constantly appearing for boosting efficiency and reducing energy consumption in data centers. Sources: Uptime Institute and Uptime Intelligence. --- ## Tipos de cloud computing: privado, público, híbrido y multicloud URL: https://www.stackscale.com/blog/types-of-cloud/ Hay cuatro **tipos de cloud computing principales**: cloud privado, cloud público, cloud híbrido y multicloud. Cada uno de estos modelos de desarrollo cloud ofrece diferentes características y ventajas. Así que, el modelo adecuado para cada empresa dependerá de sus objetivos y necesidades reales. Disponer de un centro de datos virtualizado aporta muchos beneficios a las organizaciones, pero no todas las soluciones son iguales. De hecho, dos soluciones cloud, incluso aunque pertenezcan a un mismo tipo, tampoco son iguales. A la hora de elegir el modelo adecuado para un proyecto es necesario tener en cuenta diversos aspectos como el rendimiento, los costes y la seguridad, entre otros. ## Cloud privado **El cloud privado o la nube privada** es un modelo de despliegue de cloud computing en el que el entorno y los recursos de computación son de uso exclusivo del cliente. Al tratarse de una infraestructura *single-tenant*, es **comparable a disponer de un centro de datos propio en una empresa**, pero permite escalar los servicios en base a nuestra demanda gracias a la virtualización. ** El concepto «cloud datacenter» se usa a menudo para hacer referencia a la nube privada. Las soluciones de cloud privado ofrecen mayor seguridad y control **a las empresas, ya que estas no tienen que compartir sus recursos con otros clientes. De este modo, el rendimiento cloud no se ve afectado por la actividad de vecinos ruidosos. Además, al contar con un proveedor de nube privada especializado, las empresas se pueden olvidar por completo de la gestión de los servidores físicos. Originalmente las nubes privadas solían estar alojadas en un centro de datos on-premise en las instalaciones de las empresas, pero este modelo cada vez es menos habitual. ¿Por qué? Porque optar por una **nube privada alojada** en un centro de datos especializado aporta mucho más valor y ventajas a las empresas. ### Tipos de nube privada Hay diferentes tipos de nube privada que ofrecen diferentes ventajas a los negocios: * - **Nube privada ****on-premise***. Este tipo de nube privada consiste en crear un entorno virtualizado, privado dentro del centro de datos *on-premise* de la organización. - **Nube privada alojada por un proveedor**. Este tipo de nube privada ofrece recursos dedicados a las organizaciones, de la mano de un proveedor externo como Stackscale. Los servidores siguen siendo de uso exclusivo para cada organización e independientes de las actividades de otros clientes. - **Nube privada virtual o VPC**. Este tipo de nube privada usa un entorno aislado dentro de una nube pública. Esto permite a las organizaciones ejecutar sus cargas de trabajo usando recursos privados pero los servidores siguen siendo compartidos con otros clientes. ### Costes de la nube privada Al contrario de lo que algunas empresas puedan pensar, **una nube privada no es necesariamente más cara que una nube pública**. De hecho, dado que la mayoría de las cargas de trabajo empresariales son predecibles, suele ser más rentable ejecutarlas en un cloud privado. Las soluciones de nube privada permiten a los negocios eliminar la gran inversión inicial en adquisición de equipamiento (CAPEX) y reducir los costes de su gestión (OPEX). Ambas cosas sin renunciar a las ventajas de disponer de recursos de computación dedicados. Además, los proveedores de cloud privado se encargan de garantizar la evolución tecnológica de las infraestructuras, de modo que las empresas tampoco necesitan asumir ese sobrecoste. En Stackscale derribamos el mito de las nubes privadas costosas ofreciendo **soluciones de cloud privada realmente competitivas**. Diseñamos y desarrollamos entornos de nube privada de alto rendimiento para que las compañías no necesiten realizar grandes inversiones en hardware. ### Casos de uso del cloud privado **Los entornos de cloud privado son ideales para todo tipo de organizaciones y proyectos**, como: - aplicaciones corporativas, - administraciones públicas, - proveedores de servicios de TI, - sitios web de alto tráfico, etc. Las soluciones de nube privada son especialmente idóneas para casos de uso en los que un alto rendimiento, el cumplimiento normativo y la optimización de costes sean esenciales. Asimismo, la nube privada es el modelo de despliegue cloud más común para alojar **datos y aplicaciones de misión crítica**. ## Cloud público **El cloud público o la nube pública** es un modelo de despliegue de cloud computing en el que un proveedor de servicios cloud ofrece recursos a través de Internet en un modelo de pago por uso. Es un modelo *multi-tenant*. Cada cliente tiene un entorno de computación virtualizado separado de otros usuarios dentro de una infraestructura compartida entre múltiples clientes. Esto puede afectar negativamente al rendimiento debido a la actividad de usuarios vecinos, cuando el proveedor cloud sobresuscribe recursos. El modelo de despliegue de nube pública es conocido por ser extremadamente flexible y escalable, lo cual lo convierte en una buena opción para hacer frente a picos de carga. Sin embargo, a pesar de lo que se tiende a pensar, no siempre es la opción más económica. ### Costes de la nube pública El modelo de pago por uso de la nube pública, que permite a las empresas pagar solo por los recursos que usan, **suele suponer un importante ahorro de costes en fases iniciales de un proyecto**. Sin embargo, a medida que evoluciona la plataforma esta ventaja económica tiende a desaparecer. La sobresuscripción limita el control sobre los recursos y, como consecuencia, sobre los costes cloud. El rápido aprovisionamiento y la falta de visibilidad y control puede llevar a contratar más recursos de los realmente necesarios. ** «La gestión de costes se debe enfocar de forma diferente al cambiar a una solución off-premises. El rápido aprovisionamiento en la nube se debe gestionar adecuadamente para mantener el control sobre los gastos en el tiempo.» A medida que los proyectos crecen, es fácil que los costes de la nube pública se vuelvan difíciles de controlar y que los negocios puedan incurrir en costes innecesarios. **De modo que en los proyectos alojados en entornos de cloud público es muy importante llevar un control cuidadoso de los recursos contratados. No solo para optimizar costes, sino también para mantenerlos bajo control. ### Casos de uso del cloud público El cloud público **puede ser un buen punto de partida para proyectos pequeños y startups**, ya que permite un despliegue muy rápido. No obstante, como comentamos más arriba, a medida que la empresa y el proyecto crecen, los costes corren el riesgo de dispararse. De ahí que cada vez más empresas opten por combinar entornos de cloud privado y de cloud público para aprovechar las ventajas de ambos modelos, como explicamos a continuación. ## Cloud híbrido **El cloud híbrido o la nube híbrida** es un modelo de despliegue de cloud en el que se combinan **recursos de computación privados y recursos de computación públicos**. Un ejemplo de infraestructura de nube híbrida puede ser la combinación de una nube privada para garantizar un alto rendimiento, seguridad y control para datos y aplicaciones de misión crítica, y una nube privada para contar con la máxima escalabilidad para asumir picos de demanda puntuales. De modo que este modelo híbrido combina las ventajas de la nube privada y las de la pública para proporcionar flexibilidad adicional a las empresas. **La clave de un buen entorno híbrido es garantizar una buena interoperabilidad entre ambos entornos**, para que la gestión sea ágil y eficiente. Estos son algunos de los puntos que es importante controlar porque pueden ser críticos en un entorno de cloud híbrido: - **Seguridad**: hay que controlar el flujo de transferencia de datos con el uso de soluciones de cifrado y VPNs. En Stackscale ofrecemos soluciones para interconectar las soluciones de infraestructura y nube privada de nuestros clientes con soluciones de nube pública como Amazon Web Services (AWS), Microsoft Azure o Google Cloud. - **Hipervisor**: es posible que el hipervisor del cloud privado y el del cloud público sean diferentes. Así que es necesario utilizar alguna solución para simplificar la interoperabilidad entre ambos. - **Visión de la plataforma y servicio**: hay que tener clara la visión de cómo está desplegada la infraestructura en uno o varios centros de datos. Para ello, se pueden desarrollar vía API soluciones para controlar este punto o utilizar algún software de terceros que facilite esta gestión. ### Costes de la nube híbrida Los entornos híbridos pueden ayudar a optimizar costes a las empresas, ya que permiten colocar las diferentes aplicaciones y cargas de trabajo en los entornos cloud más adecuados para cada una de ellas. No obstante, es esencial **diseñar, desplegar y gestionar adecuadamente el entorno para evitar gastos innecesarios**. Entender y monitorear los costes cloud a nivel global es especialmente importante al optar por soluciones de nube híbrida. Para facilitar la gestión de los costes, **elegir un proveedor que ofrezca una facturación transparente puede ser muy útil**. En este aspecto, en Stackscale ofrecemos una política de precios y facturación que permite a nuestros clientes conocer de antemano sus gastos en infraestructura. Esto les permite controlar los gastos de su entorno cloud sin necesidad de cálculos o fórmulas complejas y sin sorpresas a fin de mes. ### Casos de uso del cloud híbrido La nube híbrida puede ser una opción útil para empresas que requieren una infraestructura basada en la nube privada, para un mayor control de la misma tanto a nivel de costes como de recursos, pero que puntualmente necesitan desbordar servicios en una plataforma de nube pública.  ## Multicloud **El multicloud o la multinube** es un modelo de despliegue cloud en el que se combinan servicios en la nube —privados y públicos— de varios proveedores de servicios cloud. Este modelo de despliegue de cloud computing permite combinar **los beneficios de diferentes tipos de cloud con las ventajas específicas de varios proveedores de servicios**. Una infraestructura multinube puede estar compuesta, por ejemplo, por 2 entornos de nube privada y 1 entorno de nube pública. Una de las soluciones cloud se puede usar, por ejemplo, como infraestructura reservada para Disaster Recovery. Asimismo, combinando diferentes proveedores cloud regionales, las empresas pueden operar más cerca de sus clientes. Lo cual puede ser útil para reducir la latencia, cumplir con las normativas de regulación y soberanía de datos, etc.  Este tipo de cloud ofrece un nivel adicional de flexibilidad y **es probable que vaya ganando fuerza con el tiempo**. No solo reduce la dependencia de un solo proveedor, sino que también refuerza los procesos de transformación digital. Sin embargo, al tratarse de una solución cloud compleja, **exige un gran nivel de gestión y seguridad** que no todas las empresas pueden asumir. ### Costes de la multinube Al igual que los entornos de nube híbrida, los entornos multinube pueden ayudar a las empresas a optimizar costes al elegir la solución cloud más adecuada para cada carga de trabajo y aplicación. No obstante, esto también requiere de **una gestión y visibilidad adecuada de los costes** para evitar un gasto excesivo. Entender y monitorear los costes cloud a nivel global es especialmente importante al optar por una infraestructura multicloud. ### Casos de uso del multicloud Aunque son aptas para una gran variedad de casos de uso, las infraestructuras multicloud se desplieguen especialmente en en proyectos de gran tamaño y complejidad que también requieren soluciones más complejas. Pero, como mencionamos anteriormente, es probable que su uso sea cada vez más frecuente. ## Breve comparación de los tipos de cloud computing * Como hemos visto, cada tipo de cloud computing ofrece unas características y ventajas diferentes, y la mejor opción dependerá de las necesidades de cada empresa en particular. **Tipo de cloud computing****Principales características y ventajas****Nube privada** - Single tenancy*. - Acceso completamente aislado. - Rendimiento predecible. - Costes controlados en el tiempo. - Mayor nivel de seguridad y privacidad. - Mayor visibilidad y control sobre la infraestructura. **Nube pública** - *Multi tenancy*. - Acceso a través de Internet. - Modelo de pago por uso. - Despliegue y aprovisionamiento rápido. - Gran escalabilidad para soportar picos de carga. - Visibilidad y control limitado de los datos. **Nube híbrida** - Las ventajas de diferentes soluciones y proveedores. - Cost optimization. - Great flexibility. **Multinube** - Las ventajas de diferentes soluciones y proveedores. - Optimización de costes. - Gran flexibilidad. - Reducción del riesgo de dependencia de un proveedor. ### ¿En busca de una solución cloud que se adapte a tu negocio? Cuéntanos tu proyecto y te ayudamos a encontrar una solución que se adapte a tus necesidades. Solutions form ES Updates NombreEmailTeléfonoCuéntanos qué necesitas Acepto el envío de comunicaciones comerciales personalizadas sobre los productos y servicios de Stackscale (incluida la newsletter), por cualquier medio, incluidos los electrónicos. He leído y acepto la política de privacidad. Enviar El Grupo Stackscale trata la información que nos facilita con el fin de dar respuesta a la solicitud realizada en relación con los servicios que prestamos y los productos que suministramos. Los datos proporcionados se conservarán mientras se mantenga el contacto siendo eliminados una vez finalizada la solicitud, a no ser que consienta el envío de comunicaciones comerciales, donde sus datos se conservarán hasta la revocación del consentimiento previamente otorgado. En el marco del Grupo al que pertenece Stackscale, se le informa de que sus datos serán comunicados a las empresas de Grupo Aire por motivos corporativos. Puede consultar las empresas que forman parte del Grupo Aire en: https://grupoaire.es. Usted puede ejercitar sus derechos de acceso, rectificación, supresión, oposición, limitación del tratamiento y, cuando legalmente proceda, portabilidad, mediante el envío a Stackscale de una solicitud a la dirección dp*@********le.com, indicando el derecho que ejercita y aportando una fotocopia por las dos caras de su DNI o documento legal de identificación de su identidad. Igualmente, podrá presentar una reclamación ante la Agencia Española de Protección de Datos, especialmente cuando no haya obtenido la satisfacción en el ejercicio de sus derechos, a través de la sede electrónica en www.aepd.es. --- ## Types of cloud computing: private, public, hybrid and multicloud URL: https://www.stackscale.com/blog/types-of-cloud/ There are 4 **main types of cloud computing**: private cloud, public cloud, hybrid cloud and multicloud. Each of these cloud deployment models offers different features and advantages. Therefore, the right model for each company will depend on their real needs and goals. Having a virtualized data center provides a lot of benefits to organizations, but not all solutions are made the same. In fact, two cloud solutions, even if they belong to the same type, are not the same either. Diverse aspects must be considered when choosing the right type of cloud for a project, including performance, costs, security and so on. ## Private cloud The **private cloud** is a cloud computing deployment model in which the environment and computing resources are exclusively dedicated to a single customer. As a single-tenant infrastructure, it is **comparable to owning a data center in a company**, but it allows scaling services on demand thanks to virtualization. ** The concept “cloud datacenter” is often used to refer to the private cloud as well. Private cloud solutions offer greater security and control** to companies, as they do not have to share their resources with other customers. As a result, cloud performance is not affected by the activities of noisy neighbors. Besides, by relying on a specialized private cloud provider, companies can completely forget about the management of physical servers. Originally, private cloud environments used to be hosted in on-premises data centers within the company’s facilities, but this is less and less common. Why? Because opting for a **hosted private cloud** in a specialized data center provides much more value and advantages to companies.  ### Types of Private Cloud There are different types of private cloud that offer different advantages to businesses: - **On-premise Private Cloud**. This type of Private Cloud consists of creating a private, virtualized environment within the organization’s on-premise data center. - **Hosted Private Cloud**. This type of Private Cloud offers dedicated resources to organizations, delivered by a third-party provider such as Stackscale. Servers continue to be exclusive to each organization and independent from the activities of other customers.   - **Virtual Private Cloud or VPC**. This type of Private Cloud uses an isolated environment within a Public Cloud. This allows organizations to run their workloads using private resources but the servers continue to be shared with other customers. ### Private cloud costs Unlike some companies might think, **a private cloud is not necessarily more expensive than a public cloud**. In fact, since most business workloads are predictable, it is often more cost-efficient to run them in a private cloud. Private cloud solutions allow businesses to remove big initial investments in equipment acquisition (CAPEX) as well as reduce management costs (OPEX). All that without giving up the advantages of having dedicated computing resources. Moreover, as providers are in charge of guaranteeing the technological evolution of the infrastructure, companies do not need to cover that cost overrun. At Stackscale we debunk the myth of expensive private clouds by offering **truly competitive private cloud solutions**. We design and develop high-performance private cloud environments so that companies do not need to invest a lot of money on hardware. ### Private cloud use cases **Private cloud environments are ideal for all kinds of organizations and projects**, including:  - corporate applications, - public administrations, - IT services providers, - high-traffic websites, etc. A private cloud solution is particularly suitable for use cases where high performance, regulatory compliance and cost optimization are essential. Furthermore, private cloud is the most common cloud deployment model to host **mission-critical data and applications**. ## Public cloud The **public cloud** is a cloud computing deployment model in which a cloud service provider **offers resources over the Internet with a pay-per-use model**. It is a multi-tenant model. Each customer has a virtual computing environment separated from other users within an infrastructure shared among multiple customers. This can negatively affect performance due to the activities of other neighboring users, when resources are oversubscribed by the cloud provider. The public cloud deployment model is known for being extremely flexible and scalable, which makes it a good choice for handling peak loads. However, despite what people might think, it isn’t always the most economical cloud solution.  ### Public cloud costs The public cloud’s pay-per-use model, which enables companies to only pay for the resources they use, **usually involves considerable savings during the initial phases of a project**. However, this economic advantage tends to disappear as the platform evolves. Oversubscription limits the control over the resources and, as a consequence, over cloud costs. Fast provisioning and lack of visibility and control can lead to contracting more resources than necessary. ** “Cost management must be approached differently when moving off-premises. Fast provisioning in the cloud must be properly managed to keep control of costs over time.” As projects grow, it is easy for public cloud costs to become hard to control and businesses can incur unnecessary expenses**. So, in projects hosted in public cloud environments, it is very important to carefully keep control of the contracted resources. Not only to optimize costs, but also to keep them under control. ### Public cloud use cases Public cloud **can be a good starting point for small projects and startups**, since it can be deployed very quickly. However, as we mentioned before, as the company and project grow, the expenses run the risk of going through the roof. That is why more and more companies opt for combining private cloud and public cloud environments to leverage the advantages of both models, as we explain below. ## Hybrid cloud The **hybrid cloud** is a cloud deployment model which combines **private computing resources and public computing resources**. An example of hybrid cloud infrastructure can be the combination of a private cloud for ensuring high performance, security and control for mission-critical applications and data, and a public cloud for maximum scalability to handle unusual traffic peaks. So, this hybrid model combines the advantages of both private and public cloud environments to provide additional flexibility to companies. **The key to a good hybrid cloud is guaranteeing a good interoperability between both environments**, so that its management is agile and efficient. These are some of the elements it is important to control because they can be critical in an hybrid cloud environment: - **Security**: the data transfer flow must be controlled with encryption solutions and VPNs. At Stackscale we offer solutions to interconnect the infrastructure and private cloud solutions of our clients with public cloud solutions such as Amazon Web Services (AWS), Microsoft Azure or Google Cloud. - **Hypervisor**: it is possible that the private cloud and the public cloud hypervisors are different. Therefore, it is necessary to use a solution to simplify the interoperability between both of them. - **Vision of the platform and service**: it is necessary to have a clear vision of how the infrastructure is deployed in one or several data centers. For doing so, companies can develop solutions, via API, to control it or use some third-party software that makes the management easier. ### Hybrid cloud costs Hybrid cloud environments can help companies optimize costs, since they allow to place different applications and workloads in the optimal cloud environment for each of them. Nevertheless, it is essential to **properly design, deploy and manage the environment in order to avoid unnecessary expenses**. Understanding and monitoring cloud costs at a global level is especially important when opting for a hybrid cloud infrastructure. To make cost management easier, **choosing a provider that offers transparent billing can be very helpful**. In this regard, at Stackscale we offer a simplified pricing and billing policy that allows customers to know their infrastructure costs beforehand. This enables them to control their cloud environment costs without the need for complex calculations or formulas and without surprises at the end of the month. ### Hybrid cloud use cases Hybrid cloud can be an useful option for companies that need an infrastructure based on the private cloud, for greater control over the infrastructure in terms of costs and resources, but that occasionally need to overflow services in a public cloud platform. ## Multicloud **Multicloud** is a cloud deployment model which combines multiple cloud services — both private and public — from several cloud service providers. This cloud computing deployment model allows to combine **the benefits of different types of cloud with the specific advantages of several service providers**. A multicloud infrastructure can be composed, for instance, of 2 private cloud environments and 1 public cloud environment. One of the cloud solutions can be used, for example, as an infrastructure reserved for Disaster Recovery. In addition, by combining different regional cloud providers, companies can operate closer to their customers. This can be helpful for reducing latency, complying with data protection and sovereignty regulations, etc. This type of cloud offers an additional level of flexibility and it is **likely to become more common over time**. It not only helps reduce dependance in a single provider but also reinforce digital transformation processes. However, as a complex cloud solution, **it demands a great level of management and security** which is not accessible to all companies.  ### Multicloud costs Just like hybrid cloud environments, multicloud environments can help companies optimize costs by choosing the most appropriate cloud solution for each workload and application. Nevertheless, it also requires **proper cost visibility and management** in order to avoid overspending. Understanding and monitoring cloud costs at a global level is especially important when opting for a multicloud infrastructure. ### Multicloud use cases Although suitable for a large variety of use cases, multicloud infrastructures are especially deployed in big and complex projects that also require complex solutions. But, as mentioned above, it is likely to become more commonly used over time. ## Brief comparison of types of cloud computing As we have seen, every cloud computing type offers different features and advantages, and the best option will depend on the needs of each particular company. **Cloud computing type****Main features and benefits****Private cloud** - Single tenancy. - Complete isolated access. - Predictable performance. - Controlled costs over time. - Higher level of security and privacy. - High visibility and control over the infrastructure. **Public cloud** - Multi tenancy. - Access over the Internet. - Pay-per-use model. - Fast provisioning and deployment. - High scalability to support load peaks. - Limited visibility and control over data. **Hybrid cloud** - The advantages of different solutions and providers. - Cost optimization. - Great flexibility. **Multicloud** - The advantages of different solutions and providers. - Cost optimization. - Great flexibility. - Minimization of the vendor lock-in risk. ### Looking for a cloud solution adapted to your business? Tell us about your project and we will help you find a solution that adapts to your needs. Solutions form EN Contact NameEmailPhoneTell us about your needs I give my consent to receiving customized commercial communications about Stackscale products and services (including the newsletter), by any channel, including electronic ones. I have read and accept the privacy policy. Submit The Stackscale Group processes the information you provide in order to respond to your request regarding the services we deliver and the products we provide. The data provided will be stored while we stay in contact and deleted when the request is closed, unless you consent to receiving sales communications, in which case your data will be stored until the previously given consent is revoked. As part of the Group to which Stackscale belongs, we inform you that your data will be communicated to the companies of Grupo Aire for corporate reasons. You can consult the companies integrating Grupo Aire at: https://grupoaire.es. You can exercise your rights of access, rectification, erasure, disagreement, limitation of the processing and, when legally appropriate, portability, by sending a request to Stackscale to the address dp*@********le.com, indicating the right you exercise and providing a double-sided photocopy of your identification. Additionally, you will be able to present a complaint to the Dutch Data Protection Authority, especially when you are not content with the exercise of your rights, via https://autoriteitpersoonsgegevens.nl/en. --- ## Cómo conseguir resiliencia cloud y por qué es importante URL: https://www.stackscale.com/blog/cloud-resilience/ **La resiliencia cloud o resiliencia en la nube está en el centro de la continuidad de negocio**. Es clave para garantizar que las empresas puedan recuperarse eficazmente de un fallo o desastre. Implica, por ejemplo, aprovechar soluciones de HA, disaster recovery y servicios en la nube adecuados para mantener las operaciones en funcionamiento incluso en los peores supuestos. ## ¿Qué es la resiliencia en la nube? La resiliencia en la nube hace referencia a la capacidad de un sistema o infraestructura cloud para recuperarse y seguir funcionando en caso de fallo o cualquier otro incidente inesperado. El **concepto de resiliencia en cloud computing** engloba aspectos como: - Alta Disponibilidad (HA). - Tolerancia a fallos. - Disaster Recovery (DR) o recuperación ante desastres. - Seguridad. - Monitorización y analítica. - Testeo y mejora constante. Su objetivo es minimizar el tiempo de inactividad y asegurar la continuidad empresarial en todo momento. Lo cual también mejora la fiabilidad y estabilidad de los sistemas y servicios cloud. ## Fiabilidad Cloud vs Resiliencia Cloud Aunque ambos conceptos están estrechamente relacionados y son importantes para garantizar la estabilidad, **la fiabilidad y la resiliencia se centran en aspectos diferentes**. Mientras que una alta fiabilidad se enfoca en la capacidad de los sistemas para ser menos propensos a fallar, al mismo tiempo que se consigue un cierto nivel de rendimiento y disponibilidad, una alta resiliencia también hace hincapié en la capacidad para recuperarse en caso de fallo o desastre. ## Aspectos importantes para conseguir una infraestructura en la nube resiliente Hay diversas estrategias y herramientas que se pueden utilizar para **hacer frente y recuperarse de fallos e interrupciones en los sistemas**. Desde la monitorización y la seguridad a la alta disponibilidad y la tolerancia a fallos, son muchos los aspectos que contribuyen a conseguir una alta resiliencia en la nube. De modo que cada organización debe desarrollar e implementar una estrategia que se adapte a sus objetivos y cumpla con sus requisitos. Veámos **algunos aspectos clave para conseguir una infraestructura en la nube resiliente**. ### Alta Disponibilidad Mediante la Alta Disponibilidad, las organizaciones pueden **eliminar los puntos únicos de fallo** en sus sistemas en la nube para minimizar el impacto de una interrupción o fallo. En caso de fallo del servidor principal, un servidor de respaldo dentro del clúster de HA lo detectará y reiniciará el servicio. De este modo se garantiza que los servicios y aplicaciones estén siempre disponibles y accesibles para los usuarios. #### Redundancia La redundancia, así como la detección automática de fallos, son características clave para lograr la Alta Disponibilidad. La HA puede lograrse dentro del mismo centro de datos, a nivel del nodo, y también contando con dos centros de datos geográficamente distantes. En Stackscale proporcionamos soluciones entre data centers distantes dentro de la misma región con latencias inferiores a 1 ms para que nuestros clientes puedan aumentar la resiliencia de su infraestructura cloud. ** Una infraestructura cloud georedundante mejora aún más la disponibilidad**, ya que en caso de que el centro de datos principal se caiga, los servicios seguirán funcionando en otro. ### Tolerancia a fallos Las empresas pueden ir más allá y optar por un diseño tolerante a fallos, de modo que el sistema en *standby* tome el relevo sin tiempo de inactividad cuando falle el sistema principal. La tolerancia a fallos se consigue mediante la replicación de sistemas y requiere una **redundancia completa del hardware**, entre otros elementos. ### Disaster Recovery Desarrollar una plan integral de Disaster Recovery también es esencial para la resiliencia cloud. La planificación de la recuperación ante desastres minimiza el impacto de fallos en el sistema, ciberataques u otras contingencias puesto **que facilita que las aplicaciones vuelvan a estar operativas en el mejor tiempo posible**. Esto permite que la organización pueda seguir operando, casi con total normalidad, hasta que el problema se haya resuelto por completo. Un plan de DR debe identificar los recursos críticos, establecer los objetivos de recuperación (RTO y RPO) y definir bien los roles y responsabilidades para ejecutar el plan, así como el protocolo de acción y las metodologías necesarias. #### Copias de seguridad y replicación de datos La planificación de disaster recovery también incluye elementos importantes como las copias de seguridad, la replicación de datos y la conmutación por error a ubicaciones secundarias. Las copias de seguridad son una forma sencilla de recuperación ante desastres para protegerse de contingencias como la corrupción de datos, actualizaciones defectuosas del sistema, etc. También es necesario probar periódicamente los procesos de copia de seguridad y restauración para garantizar que funcionan tal y como se espera. ### Seguridad La **adopción de medidas de seguridad adecuadas y sólidas** es básica, a la vez que indispensable, para proteger los sistemas y datos en la nube de las ciberamenazas. Desde la aplicación de buenas prácticas de seguridad hasta la ejecución periódica de auditorías de seguridad y evaluaciones de vulnerabilidades, existen muchas oportunidades para impulsar la resiliencia en la computación en nube. ### Monitorización y analítica En estrecha relación con la seguridad y el rendimiento, la monitorización y el análisis también desempeñan un papel importante a la hora de garantizar los niveles de servicio esperados, detectar a tiempo las amenazas y resolver problemas a fin de evitar la interrupción del servicio. Al implantar sistemas y herramientas de monitorización exhaustivos para la infraestructura en la nube, se garantiza una **mayor visibilidad y control** sobre los indicadores clave de rendimiento, utilización de recursos, posibles problemas, etc. ### Testeo y mejora constante Por último, pero no menos importante, sobra decir que las pruebas periódicas son esenciales en las estrategias de resiliencia de la nube. La realización de pruebas y simulaciones periódicas contribuye a crear un ciclo de mejora constante que pone de relieve la importancia de la resiliencia cloud y fomenta la colaboración, la innovación y la gestión proactiva de riesgos. Asimismo, una **estrategia de resiliencia cloud exitosa** también requiere de documentación clara y formación. Todos los miembros del equipo implicados en el mantenimiento y operación de la infraestructura cloud deben conocer las configuraciones, procedimientos y protocolos de acción para responder con eficacia a fallos e interrupciones en el servicio. Para terminar, cabe mencionar que en muchos casos, la resiliencia en la nube también podría conllevar una reevaluación de la estrategia de continuidad de negocio y servicios cloud de la organización. Esto incluye evaluar si la infraestructura se adapta a las necesidades reales de la empresa y garantizar una visibilidad total de los servicios y sistemas. Te podemos ayudar a mejorar la resiliencia cloud y la continuidad de negocio con soluciones cloud en alta disponibilidad y Disaster Recovery a medida para mantener las operaciones en funcionamiento incluso en los peores casos. --- ## How to achieve cloud resilience and why does it matter URL: https://www.stackscale.com/blog/cloud-resilience/ **Cloud resilience is at the core of business continuity**. It is key to ensure your business can effectively recover from a failure or disaster. It entails, for instance, leveraging suitable cloud services, HA and disaster recovery solutions to keep operations running even in the worst scenarios. ## What is cloud resilience? Cloud resilience refers to the ability of a cloud infrastructure or system to recover and keep running in case of a failure or any other unexpected event. The concept of **resilience in cloud computing** comprises aspects like: - High Availability (HA). - Fault Tolerance. - Disaster Recovery (DR). - Security. - Monitoring and analytics. - Testing and constant improvement. It aims to minimize downtime and ensure business continuity at all times. Thus enhancing the reliability and stability of cloud services and systems. ## Cloud Reliability vs Cloud Resilience Although closely related and important for ensuring overall stability, **reliability and resilience focus on different aspects**. While high reliability focuses on the ability of systems to be less likely to fail, while consistently achieving an expected level of performance and availability, high resilience also emphasizes the ability to recover in case of failure or disaster. ## Important aspects to achieve a resilient cloud infrastructure There are diverse strategies and tools that can be used to **withstand and recover from system failures and disruptions**. From monitoring and security to high availability and fault tolerance, there are many aspects that contribute to achieving high resilience in the cloud. Therefore, each organization must develop and implement a strategy that suits their goals and complies with their requirements. Let’s review **some key aspects to achieve a resilient cloud infrastructure**. ### High Availability Through High Availability, organizations can **eliminate single points of failure** in their cloud systems to minimize the impact of a disruption or failure. In case of failure of the primary server, a backup server within the HA cluster will detect it and restart the service. Thus ensuring services and applications are always available and accessible to users. #### Redundancy Redundancy, as well as automatic failure detection, are key features to achieve High Availability. HA can be achieved within the same datacenter, at node level, as well as relying on two geographically distant datacenters. At Stackscale we provide solutions between remote data centers within the same region with latencies below 1 ms to allow customers to increase the resilience of their cloud infrastructure. ** A geo-redundant cloud infrastructure further improves availability**, since in case the primary datacenter goes down, your services will keep running in another one. ### Fault Tolerance Businesses can go further and opt for a fault-tolerant design so that the standby system takes over without any downtime when the primary system fails. Fault Tolerance is achieved by mirroring systems and requires **complete redundancy in hardware**, among other elements. ### Disaster Recovery Developing a comprehensive Disaster Recovery plan is also essential for cloud resilience. DR planning helps minimize the impact of system failures, cyber attacks or any other contingencies by **getting applications back to operation in the shortest time possible**, allowing the organization to keep operating, virtually as usual, until the issue is completely solved. The DRP must identify critical resources, establish recovery goals (RTO and RPO) and define clear roles and responsibilities for executing the plan, as well as the action protocol and necessary methodologies. #### Backups and data replication DR planning also involves important elements such as backups, data replication and failover to secondary locations. Backups are a simple form of Disaster Recovery to be protected against contingencies like data corruption, system faulty updates, etc. Periodically testing backup and restoration processes is also necessary to ensure they work as expected. ### Security The **adoption of appropriate and robust security measures** is basic and yet indispensable to protect cloud systems and data from cyberthreats. From implementing security best practices to running regular security audits and vulnerability assessments, there are many opportunities to boost resilience in cloud computing. ### Monitoring and Analytics Closely related to security and performance, monitoring and analytics also play an important role in guaranteeing expected service levels, early detecting threats and solving issues in order to prevent service disruptions. By implementing comprehensive monitoring systems and tools for your cloud infrastructure, you ensure **greater visibility and control** over key performance indicators, resource utilization, potential issues, etc. ### Testing and constant improvement Last but not least, it should go without saying that regular testing is essential in cloud resilience strategies. Performing periodical tests and simulations contribute to creating a constant improvement cycle that highlights the importance of cloud resilience and promotes collaboration, innovation and proactive risk management. Moreover, a **successful cloud resilience strategy** requires clear documentation and training as well. All team members involved in maintaining and operating the cloud infrastructure must know the configurations, procedures and action protocols to effectively respond to service disruptions and failures. Finally, it is worth mentioning that in many cases, cloud resilience may also entail re-evaluating your organization’s cloud services and business continuity strategy. This includes assessing whether your infrastructure adapts to your real business needs and ensuring full visibility over all services and systems. We can help you improve cloud resilience and business continuity with custom Disaster Recovery and HA cloud solutions to keep operations running even in the worst scenarios. --- ## Adopción cloud en empresas de la UE en 2023 URL: https://www.stackscale.com/blog/cloud-adoption-eu-enterprises/ La **adopción del cloud computing en Europa** ha aumentado 4 puntos porcentuales (pp) de 2021 a 2023, según Eurostat. El 45 % de las empresas de la UE usaron la computación en la nube en 2023 —con una tasa de adopción significativamente más alta entre las grandes empresas—. Veamos algunas estadísticas de uso del cloud entre las empresas de la UE durante los últimos años. ## Estadísticas de adopción cloud en la UE por país de 2018 a 2023 El índice de adopción cloud varía considerablemente entre países. En lo que respecta a 2023, por un lado, Finlandia (78 %), Suecia (72 %), Noruega (71 %) y Dinamarca (70 %) lideran la adopción del cloud computing en empresas de la Unión Europea. Por otro lado, Bulgaria (18 %), Rumanía (18 %) y Grecia (24 %) son los países con el índice de adopción cloud más bajo. La siguiente tabla resume la evolución de la adopción cloud en empresas europeas de 2018 a 2023, según datos de Eurostat. **País****2018****2020****2021****2023**Media de la UE24 %36 %41 %45 %Alemania22 %33 %42 %47 %Austria23 %38 %40 %47 %Bélgica40 %53 %53 %52 %Bulgaria8 %11 %13 %18 %Chequia26 %29 %44 %47 %Chipre27 %35 %50 %53 %Croacia31 %39 %39 %45 %Dinamarca56 %67 %65 %70 %Eslovaquia21 %26 %36 %34 %Eslovenia26 %39 %43 %40 %España22 %26 %31 %30 %Estonia34 %56 %58 %59 %Finlandia65 %75 %75 %78 %Francia19 %27 %29 %27 %*Grecia13 %17 %22 %24 %Hungría18 %25 %26 %45 %Irlanda45 %51 %59 %63 %Islandiano disponibleno disponibleno disponibleno disponibleItalia23 %59 %60 %61 %Letonia15 %21 %29 %36 %Lituania23 %31 %34 %38 %Luxemburgo25 %29 %33 %37 %Malta37 %53 %57 %67 %Noruega51 %64 %64 %71 %Países Bajos48 %53 %65 %61 %Polonia11 %24 %29 %56 %Portugal25 %29 %35 %38 %Rumanía10 %16 %14 %18 %Suecia57 %70 %75 %72 % *Ruptura de la serie temporal ### Adopción cloud en Alemania La adopción del cloud computing en empresas en Alemania se ha más que duplicado durante los últimos seis años, pasando del 22 % en 2018 al 47 % en 2023. Sin embargo, a fecha de 2023, el porcentaje de empresas alemanas que usan cloud computing aún está lejos del índice de adopción cloud de otros países como Finlandia (78 %) o Suecia (72 %). ### Adopción cloud en Austria La adopción del cloud computing en empresas en Austria casi se ha duplicado durante los últimos seis años, pasando del 23 % en 2018 al 45 % en 2023. ### Adopción cloud en Bélgica La adopción del cloud computing en empresas en Bélgica ha aumentado 12 pp durante los últimos seis años, pasando del 40 % en 2018 al 52 % en 2023. El porcentaje de adopción cloud entre las empresas belgas ha disminuido ligeramente en 2023, respecto a 2021. ### Adopción cloud en Bulgaria La adopción del cloud computing en empresas en Bulgaria se ha más que duplicado durante los últimos seis años, pasando del 8 % en 2018 al 18 % en 2023. No obstante, Bulgaria, al igual que Rumanía y Grecia, sigue teniendo un índice de adopción por debajo del 25 %. ### Adopción cloud en Chequia La adopción del cloud computing en empresas en Chequia casi se ha duplicado durante los últimos seis años, pasando del 26 % en 2018 al 47 % en 2023. ### Adopción cloud en Chipre La adopción del cloud computing en empresas en Chipre cassie se ha duplicado durante los últimos seis años, pasando del 27 % en 2018 al 53 % en 2023. Es uno de los países que ha experimentado un mayor crecimiento en adopción cloud durante este período de tiempo, junto con Italia (+38 pp) y Malta (+30 pp). ### Adopción cloud en Croacia La adopción del cloud computing en empresas en Croacia ha aumentado 14 pp durante los últimos seis años, pasando del 31 % en 2018 al 45 % en 2023. ### Adopción cloud en Dinamarca La adopción del cloud computing en empresas en Dinamarca ha crecido 14 pp durante los últimos seis años, pasando del 56 % en 2018 al 70 % en 2023. Junto con Finlandia (78 %), Suecia (72 %) y Noruega (71 %), Dinamarca está entre los países que lideran la adopción del cloud computing en la UE. ### Adopción cloud en Eslovaquia La adopción del cloud computing en empresas en Eslovaquia ha aumentado 13 pp durante los últimos seis años, pasando del 21 % en 2018 al 34 % en 2023. Comparado con 2021, el porcentaje de adopción cloud entre las empresas eslovacas ha disminuido ligeramente en 2023. ### Adopción cloud en Eslovenia La adopción del cloud computing en empresas en Eslovenia ha aumentado 14 pp durante los últimos seis años, pasando del 26 % en 2018 al 40 % en 2023. Comparado con 2021, el porcentaje de adopción cloud entre las empresas eslovenas ha disminuido ligeramente en 2023. ### Adopción cloud en España La adopción del cloud computing en empresas en España ha aumentado 8 pp durante los últimos seis años, pasando del 22 % en 2018 al 30 % en 2023. El porcentaje de adopción cloud entre las empresas españolas ha disminuido ligeramente en 2023, respecto a 2021. ### Adopción cloud en Estonia La adopción del cloud computing en empresas en Estonia ha aumentado 25 pp durante los últimos seis años, pasando del 34 % en 2018 al 59 % en 2023. ### Adopción cloud en Finlandia La adopción del cloud computing en empresas en Finlandia ha aumentado 13 pp durante los últimos seis años, pasando del 65 % en 2018 al 78 % en 2023. Junto con Suecia (72 %), Noruega (71 %) y Dinamarca (70 %), Finlandia está entre los países que lideran la adopción del cloud computing en la UE. ### Adopción cloud en Francia La adopción del cloud computing en empresas en Francia ha crecido 8 pp durante los últimos seis años, pasando del 19 % en 2018 al 27 % en 2023. El porcentaje de adopción cloud entre las empresas francesas ha disminuido ligeramente en 2023, comparado con 2021. Aunque, teniendo en cuenta que hay una ruptura de la serie temporal, este decrecimiento no es del todo preciso. ### Adopción cloud en Grecia La adopción del cloud computing en empresas en Grecia ha aumentado 11 pp durante los últimos seis años, pasando del 13 % en 2018 al 24 % en 2023. No obstante, Grecia, al igual que Bulgaria y Rumanía, sigue teniendo un índice de adopción por debajo del 25 %. ### Adopción cloud en Hungría La adopción del cloud computing en empresas en Hungría se ha más que duplicado durante los últimos seis años, pasando del 18 % en 2018 al 45 % en 2023. Sin embargo, en 2023, el porcentaje de empresas húngaras que usan la computación en la nube aún está lejos del índice de adopción cloud de otros países como Finlandia (78 %), Suecia (72 %) y Noruega (71 %). ### Adopción cloud en Irlanda La adopción del cloud computing en empresas en Irlanda ha aumentado 18 pp durante los últimos seis años, pasando del 45 % en 2018 al 63 % en 2023. ### Adopción cloud en Italia La adopción del cloud computing en empresas en Italia casi se ha triplicado durante los últimos seis años, pasando del 23 % en 2018 al 61 % en 2023. Es uno de los países que ha experimentado un mayor crecimiento en adopción cloud durante este período de tiempo, junto con Malta (+30 pp) y Chipre (+26 pp). ### Adopción cloud en Letonia La adopción del cloud computing en empresas en Letonia se ha más que duplicado durante los últimos seis años, pasando del 15 % en 2018 al 36 % en 2023. Sin embargo, en 2023, el porcentaje de empresas letonas que usan la computación en la nube aún está lejos del índice de adopción cloud de otros países como Finlandia (78 %), Suecia (72 %) y Noruega (71 %). ### Adopción cloud en Lituania La adopción del cloud computing en empresas en Lituania ha aumentado 15 pp durante los últimos seis años, pasando del 23 % en 2018 al 38 % en 2023. ### Adopción cloud en Luxemburgo La adopción del cloud computing en empresas en Luxemburgo ha aumentado 12 pp durante los últimos seis años, pasando del 25 % en 2018 al 37 % en 2023. ### Adopción cloud en Malta La adopción del cloud computing en empresas en Malta casi se ha duplicado durante los últimos seis años, pasando del 37 % en 2018 al 67 % en 2023. Es uno de los países que ha experimentado un mayor crecimiento en adopción cloud durante este período de tiempo, junto con Italia (+38 pp) y Chipre (+26 pp). ### Adopción cloud en Noruega La adopción del cloud computing en empresas en Noruega ha aumentado 20 puntos porcentuales durante los últimos seis años, pasando del 51 % en 2018 al 71 % en 2023. Junto con Finlandia (78 %), Suecia (72 %) y Dinamarca (70 %), Noruega está entre los países que lideran la adopción del cloud computing en la UE. ### Adopción cloud en los Países Bajos La adopción del cloud computing en empresas en los Países Bajos ha aumentado 13 pp durante los últimos seis años, pasando del 48 % en 2018 al 61 % en 2023. Comparado con 2021, el porcentaje de adopción cloud entre las empresas holandesas ha disminuido ligeramente en 2023. ### Adopción cloud en Polonia La adopción del cloud computing en empresas en Polonia se ha multiplicado por cinco durante los últimos seis años, pasando del 11 % en 2018 al 56 % en 2023. Sin embargo, en 2023, el porcentaje de empresas polacas que usan la computación en la nube aún está lejos del índice de adopción cloud de otros países como Finlandia (78 %), Suecia (72 %) y Noruego (71 %). ### Adopción cloud en Portugal La adopción del cloud computing en empresas en Portugal ha aumentado 13 pp durante los últimos seis años, pasando del 25 % en 2018 al 38 % en 2023. ### Adopción cloud en Rumanía La adopción del cloud computing en empresas en Rumanía casi se ha duplicado durante los últimos seis años, pasando del 10 % en 2018 al 18 % en 2023. Sin embargo, Rumanía, al igual que Bulgaria y Grecia, sigue teniendo un índice de adopción por debajo del 25 %. ### Adopción cloud en Suecia La adopción del cloud computing en empresas en Suecia ha aumentado 15 pp durante los últimos seis años, pasando del 57 % en 2018 al 72 % en 2023. Junto con Finlandia (78 %), Noruega (71 %) y Dinamarca (70 %), Suecia está entre los países que lideran la adopción del cloud computing en la UE. Aunque, respecto a 2021, el porcentaje de adopción cloud entre empresas suecas ha disminuido ligeramente en 2023. ## Adopción cloud en la UE según el modelo de servicio * En lo que respecta al uso según el modelo de servicio cloud, el modelo de Software como Servicio es sin duda el más usado entre las empresas de todos los tamaños, con una tasa de adopción superior al 95 % en todos los casos. El modelo de Infraestructura como Servicio es el segundo más usado, especialmente entre las grandes empresas. El modelo de Plataforma como Servicio es el menos usado, especialmente entre las pequeñas empresas. ## Adopción cloud en la UE según el tamaño de la empresa Asimismo, el índice de adopción cloud también varía entre las empresas de diferentes tamaños. Como se muestra en el gráfico de abajo, el índice de adopción aumenta a medida que lo hace el tamaño de la empresa. En lo que se refiere a 2023, el uso del cloud computing sigue siendo mayor entre las grandes empresas, con un índice de adopción del 78 %; seguido de las medianas empresas, con un índice de adopción del 59 % y de las pequeñas empresas, con un índice de adopción del 42 %. Además, de 2021 a 2023, el aumento en el uso de la computación en la nube en grandes y medianas empresas también es algo mayor comparado con los negocios pequeños, +6 pp y +4 pp respectivamente. ## Adopción de la computación en la nube y soberanía de datos Cuando se habla de adopción cloud en la UE, también es pertinente mencionar que el mercado cloud está liderado por empresas extranjeras —a pesar de que existen **un gran número de proveedores de ****nube europea**** que ofrecen soluciones cloud realmente competitivas**—. Esto puede tener un impacto negativo a medio y largo plazo, desde el punto de vista de la soberanía de datos, la privacidad, problemas de dependencia del proveedor, etc. Por eso la Comisión Europea ha estado trabajando en desarrollar un sólido marco regulatorio para la protección y soberanía de datos en Europa. Además, proyectos como Gaia-X también contribuyen a impulsar la soberanía cloud europea construyendo una infraestructura de datos segura y federada. La soberanía digital es clave. Según el informe European Digital Sovereignty. Syncing values and value* publicado por la consultora Oliver Wyman, **para 2030, se estima que la economía digital añadirá 1,1 puntos porcentuales al crecimiento económico anual de la Unión Europea e impulsará el PIB más de un 14 %**. Así que es importante que las empresas europeas, así como los gobiernos, trabajen juntos para promover la innovación y la soberanía digital en la Unión Europea. ¿Tu empresa está planeando migrar su infraestructura a la nube? Stackscale puede ayudaros a **acelerar la adopción cloud** con consultoría personalizada y hasta 2 meses de migración cloud gratis. Fuentes: Eurostat, Eurostat (isoc_cicce_use) e informe de Oliver Wyman. --- ## Cloud adoption among EU enterprises in 2023 URL: https://www.stackscale.com/blog/cloud-adoption-eu-enterprises/ The **adoption of cloud computing in Europe** has increased about 4 percentage points (pp) from 2021 to 2023, according to Eurostat. 45% of EU enterprises used cloud computing in 2023 — with a significantly higher adoption rate among large enterprises. Let’s review some cloud usage statistics among EU enterprises during the last few years.  ## Cloud adoption statistics in the EU by country from 2018 to 2023 Cloud adoption rates vary considerably among countries. As of 2023, on the one hand, Finland (78%), Sweden (72%), Norway (71%) and Denmark (70%) lead the adoption of cloud computing among enterprises in the European Union. On the other hand, Bulgaria (18%), Romania (18%) and Greece (24%) are the countries with the lowest cloud adoption rate. The following table summarizes the evolution of cloud adoption among European enterprises from 2018 to 2023, according to Eurostat’s data. **Country****2018****2020****2021****2023**EU average24%36%41%45%Austria23%38%40%47%Belgium40%53%53%52%Bulgaria8%11%13%18%Croatia31%39%39%45%Cyprus27%35%50%53%Czechia26%29%44%47%Denmark56%67%65%70%Estonia34%56%58%59%Finland65%75%75%78%France19%27%29%27%*Germany22%33%42%47%Greece13%17%22%24%Hungary18%25%26%45%Icelandnot availablenot availablenot availablenot availableIreland45%51%59%63%Italy23%59%60%61%Latvia15%21%29%36%Lithuania23%31%34%38%Luxembourg25%29%33%37%Malta37%53%57%67%Netherlands48%53%65%61%Norway51%64%64%71%Poland11%24%29%56%Portugal25%29%35%38%Romania10%16%14%18%Slovakia21%26%36%34%Slovenia26%39%43%40%Spain22%26%31%30%Sweden57%70%75%72%* *Break in time series ### Cloud adoption in Austria Cloud computing adoption among enterprises in Austria has almost doubled over the past six years, from 23% in 2018 to 45% in 2023. ### Cloud adoption in Belgium Cloud computing adoption among enterprises in Belgium has increased 12 pp over the past six years, from 40% in 2018 to 52% in 2023. The percentage of cloud adoption among Belgian enterprises has slightly decreased in 2023, compared to 2021. ### Cloud adoption in Bulgaria Cloud computing adoption among enterprises in Bulgaria has more than doubled over the past six years, from 8% in 2018 to 18% in 2023. However, Bulgaria, along with Romania and Greece, still holds an adoption rate below 25%. ### Cloud adoption in Croatia Cloud computing adoption among enterprises in Croatia has increased 14 pp over the past six years, from 31% in 2018 to 45% in 2023. ### Cloud adoption in Cyprus Cloud computing adoption among enterprises in Cyprus has almost doubled over the past six years, from 27% in 2018 to 53% in 2023. It is one of the countries that has experienced a bigger growth in cloud adoption during this period of time, together with Italy (+38 pp) and Malta (+30 pp). ### Cloud adoption in Czechia Cloud computing adoption among enterprises in Czechia has almost doubled over the past six years, from 26% in 2018 to 47% in 2023. ### Cloud adoption in Denmark Cloud computing adoption among enterprises in Denmark has grown 14 pp over the past six years, from 56% in 2018 to 70% in 2023. Together with Finland (78%), Sweden (72%) and Norway (71 %), Denmark is among the countries leading cloud computing adoption in the EU. ### Cloud adoption in Estonia Cloud computing adoption among enterprises in Estonia has increased 25 pp over the past six years, from 34% in 2018 to 59% in 2023. ### Cloud adoption in Finland Cloud computing adoption among enterprises in Finland has increased 13 pp over the past six years, from 65% in 2018 to 78% in 2023. Together with Sweden (72%), Norway (71%) and Denmark (70%), Finland is among the countries leading cloud computing adoption in the EU. ### Cloud adoption in France Cloud computing adoption among enterprises in France has grown 8 pp over the past six years, from 19% in 2018 to about 27% in 2023. The percentage of cloud adoption among French enterprises has slightly decreased in 2023, compared to 2021. Although, considering there are data breaks in time, this decrease is not fully accurate. ### Cloud adoption in Germany Cloud computing adoption among enterprises in Germany has more than doubled over the past six years, from 22% in 2018 to 47% in 2023. However, as of 2023, the percentage of German enterprises using cloud computing is still far from the cloud adoption rate in other countries like Finland (78%) or Sweden (72%). ### Cloud adoption in Greece Cloud computing adoption among enterprises in Greece has increased 11 pp over the past six years, from 13% in 2018 to 24% in 2023. Nevertheless, Greece, as well as Bulgaria and Romania, still holds an adoption rate below 25%. ### Cloud adoption in Hungary Cloud computing adoption among enterprises in Hungary has more than doubled over the past six years, from 18% in 2018 to 45% in 2023. However, as of 2023, the percentage of Hungarian enterprises using cloud computing is still far from the cloud adoption rate in other countries like Finland (78%), Sweden (72%) and Norway (71%). ### Cloud adoption in Ireland Cloud computing adoption among enterprises in Ireland has increased 18 pp over the past six years, from 45% in 2018 to 63% in 2023. ### Cloud adoption in Italy Cloud computing adoption among enterprises in Italy has almost tripled over the past six years, from 23% in 2018 to 61% in 2023. It is one of the countries that has experienced a bigger growth in cloud adoption during this period of time, together with Malta (+30 pp) and Cyprus (+26 pp). ### Cloud adoption in Latvia Cloud computing adoption among enterprises in Latvia has more than doubled over the past six years, from 15% in 2018 to 36% in 2023. However, as of 2023, the percentage of Latvian enterprises using cloud computing is still far from the cloud adoption rate in other countries like Finland (78%), Sweden (72%) and Norway (71%). ### Cloud adoption in Lithuania Cloud computing adoption among enterprises in Lithuania has increased 15 pp over the past six years, from 23% in 2018 to 38% in 2023. ### Cloud adoption in Luxembourg Cloud computing adoption among enterprises in Luxembourg has increased 12 pp over the past six years, from 25% in 2018 to 37% in 2023. ### Cloud adoption in Malta Cloud computing adoption among enterprises in Malta has almost doubled over the past six years, from 37% in 2018 to 67% in 2023. It is one of the countries that has experienced a bigger growth in cloud adoption during this period of time, together with Italy (+38 pp) and Cyprus (+26 pp). ### Cloud adoption in the Netherlands Cloud computing adoption among enterprises in the Netherlands has increased 13 pp over the past six years, from 48% in 2018 to 61% in 2023. Compared to 2021, the percentage of cloud adoption among Dutch enterprises has slightly decreased in 2023. ### Cloud adoption in Norway Cloud computing adoption among enterprises in Norway has increased 20 pp over the past six years, from 51% in 2018 to 71% in 2023. Together with Finland (78%) Sweden (72%) and Denmark (70%), Norway is among the countries leading cloud computing adoption in the EU. ### Cloud adoption in Poland Cloud computing adoption among enterprises in Poland has increased fivefold over the past six years, from 11% in 2018 to 56% in 2023. However, as of 2023, the percentage of Polish enterprises using cloud computing is still far from the cloud adoption rate in other countries like Finland (78%), Sweden (72%) and Norway (71%). ### Cloud adoption in Portugal Cloud computing adoption among enterprises in Portugal has increased 13 pp over the past six years, from 25% in 2018 to 38% in 2023. ### Cloud adoption in Romania Cloud computing adoption among enterprises in Romania has almost doubled over the past six years, from 10% in 2018 to 18% in 2023. However, Romania, as well as Bulgaria and Greece, still holds an adoption rate below 25%. ### Cloud adoption in Slovakia Cloud computing adoption among enterprises in Slovakia has increased 13 pp over the past six years, from 21% in 2018 to 34% in 2023. Compared to 2021, the percentage of cloud adoption among Slovakian enterprises has slightly decreased in 2023. ### Cloud adoption in Slovenia Cloud computing adoption among enterprises in Slovenia has increased 14 pp over the past six years, from 26% in 2018 to 40% in 2023. Compared to 2021, the percentage of cloud adoption among Slovenian enterprises has slightly decreased in 2023. ### Cloud adoption in Spain Cloud computing adoption among enterprises in Spain has increased 8 pp over the past six years, from 22% in 2018 to 30% in 2023. The percentage of cloud adoption among Spanish enterprises has slightly decreased in 2023, compared to 2021. ### Cloud adoption in Sweden Cloud computing adoption among enterprises in Sweden has increased 15 pp over the past six years, from 57% in 2018 to 72% in 2023. Together with Finland (78%), Norway (71%) and Denmark (70%), Sweden is among the countries leading cloud computing adoption in the EU. However, compared to 2021, the percentage of cloud adoption among Swedish enterprises has slightly decreased in 2023. ## Cloud adoption in the EU by service model Regarding usage rates by cloud service model, the Software as a Service model is definitely the most widely used among enterprises of all sizes, with an adoption rate above 95% in all cases. The Infrastructure as a Service model is the second most used, especially among large enterprises. The Platform as a Service model is the least used model, especially among small organizations. ## Cloud computing adoption in the EU by enterprise size Furthermore, cloud adoption rates also vary among enterprises of different sizes. As shown in the graph below, the adoption rate increases along with the company’s size. As of 2023, the use of cloud computing continues to be higher among large enterprises, with an adoption rate of about 78%; followed by medium enterprises, with an adoption rate of 59% and small enterprises, with an adoption rate of about 42%. Besides, from 2021 to 2023, the increase in the use of cloud computing in large and medium companies is also slightly higher compared to small businesses, +6 pp and +4 pp respectively. ## Cloud computing adoption and data sovereignty When talking about cloud adoption in the EU, it is also worth mentioning that the cloud market is led by overseas companies — even though **there are numerous ****European cloud**** providers that offer truly competitive cloud solutions**. This can have a negative impact on the medium and long term, in terms of data sovereignty, privacy, vendor lock-in issues, etc. That is why the European Commission has been working on developing a strong regulatory framework for data protection and sovereignty in Europe. Besides, projects like Gaia-X are also contributing to boost European cloud sovereignty by building a federated and secure data infrastructure. Digital sovereignty is key. According to the report “European Digital Sovereignty. Syncing values and value” published by the consulting company Oliver Wyman, **by 2030, the digital economy is expected to add 1,1 pp to the European Union’s annual economic growth and to boost GDP by over 14%**. Therefore, it is important for European companies, as well as governments, to work together to promote innovation and digital sovereignty in the European Union. Is your company planning to migrate its infrastructure to the cloud? Stackscale can help you **accelerate your cloud adoption** with custom advice and up to 2-months free cloud migration. Sources: Eurostat, Eurostat (isoc_cicce_use) and Oliver Wyman report. --- ## Crecimiento y estadísticas del eCommerce (2024) URL: https://www.stackscale.com/blog/ecommerce-statistics-growth/ El comercio electrónico ha experimentado un crecimiento continuado durante la última década. En este artículo hemos recopilado algunas **estadísticas del eCommerce en 2024 y durante la última década**, que muestran cómo ha ido creciendo su adopción. ## Crecimiento del mercado global del eCommerce **Se estima que las ventas de comercio electrónico a nivel mundial superarán los 5,8 billones de euros (6,3 billones de dólares) en 2024** y los 6,3 billones de euros (6,8 billones de dólares) para 2025, según las predicciones y estadísticas del eCommerce de eMarketer. El pronóstico de crecimiento de las ventas eCommerce en retail es de alrededor del 9,4 % en 2024; una tasa de crecimiento que se espera que disminuya ligeramente durante el próximo trienio. Estas predicciones muestran una estabilización tras el aumento disparado del crecimiento del eCommerce a nivel mundial en 2020, a raíz de los confinamientos y las restricciones. A consecuencia del aumento de la actividad digital durante la pandemia, las ventas de eCommerce en retail crecieron más de un 25 % en 2020 y más de un 15 % en 2021. Estas estadísticas eCommerce no solo exigen que los negocios se mantengan al día de las nuevas tendencias y tecnologías, sino también que exploren mercados internacionales para aprovechar más oportunidades. Esto hace que las soluciones cloud especializadas y servicios complementarios como las CDN sean una prioridad para muchos comercios electrónicos en crecimiento. ## Ingresos en el mercado eCommerce a nivel mundial Los ingresos en el mercado eCommerce a nivel mundial superó los 2.800 mil millones de euros (3.100 mil millones de dólares) en 2023 y se espera que supere los 3.300 mil millones de euros (3.600 mil millones de dólares) en 2024, según datos del mercado del comercio electrónico de Statista. ### Ingresos por categoría de producto en 2023 Al analizar más en detalle los ingresos por categoría de producto, estos han sido los 10 sectores con las cifras de negocio más altas en 2023: - **Electrónica**: ~725 mil millones de euros (~781 mil millones de USD). - **Moda**: ~625 mil millones de euros (~673 mil millones de USD). - **Comida**: ~343 mil millones de euros (~370 mil millones de USD). - **Bebida**: ~194 mil millones de euros (~209 mil millones de USD). - **DIY y ferretería**: ~186 mil millones de euros (~201 mil millones de USD). - **Mobiliario**: ~174 mil millones de euros (~188 mil millones de USD). - **Medios**: ~169 mil millones de euros (~182 mil millones de USD). - **Belleza e higiene personal**: ~140 mil millones de euros (~151 mil millones de USD). - **Productos del tabaco**: ~96 mil millones de euros (~104 mil millones de USD). - **Juguetes y aficiones**: ~74 mil millones de euros (~80 mil millones de USD). ## Crecimiento del número de usuarios que compran online en la Unión Europa Según datos de las estadísticas del eCommerce para particulares en la Unión Europea de Eurostat, **la media de usuarios de Internet de la UE que realizan compras online fue de en torno al 70 % en 2023**. Mientras que la media de la zona Euro fue ligeramente superior, con en torno al 71 % de usuarios de Internet que compran en línea. ### Evolución del porcentaje de compradores online 2019-2023 El porcentaje de usuarios de Internet que compran en línea ha ido evolucionando durante los últimos cinco años. El ritmo de crecimiento varía según cada país, pero en términos generales todos han experimentado un **aumento considerable en el número de compradores online**. En la siguiente tabla están presentados el porcentaje de compradores online que realizaron alguna compra por internet en los 12 meses anteriores a la encuesta anual. **País****2019****2020****2021****2022****2023****Media de la UE**60 %65 %67 %68 %70 %**Eurozona**63 %67 %69 %69 %71 %**Alemania**79 %83 %76 %76 %77 %**Austria**62 %66 %63 %66 %72 %**Bélgica**66 %73 %75 %75 %75 %**Bulgaria**22 %31 %33 %41 %45 %**Chipre**39 %47 %54 %50 %57 %**Croacia**45 %55 %57 %56 %59 %**Dinamarca**84 %89 %91 %88 %89 %**Eslovaquia**60 %62 %75 %77 %77 %**Eslovenia**56 %63 %71 %63 %66 %**España**58 %63 %67 %68 %69 %**Estonia**68 %68 %70 %71 %73 %**Finlandia**73 %76 %79 %79 %79 %**Francia**70 %no disponible76 %76 %77 %**Grecia**39 %46 %54 %59 %58 %**Hungría**49 %60 %66 %70 %70 %**Irlanda**67 %74 %87 %85 %86 %**Islandia**80 %83 %85 %no disponibleno disponible**Italia**38 %44 %51 %49 %51 %**Letonia**47 %56 %62 %62 %62 %**Lituania**48 %54 %60 %60 %61 %**Luxemburgo**72 %79 %81 %81 %80 %**Malta**58 %63 %65 %68 %68 %**Noruega**82 %85 %92 %92 %91 %**Países Bajos**81 %87 %89 %88 %92 %**Polonia**54 %61 %61 %65 %64 %**Portugal**39 %45 %52 %54 %55 %**Reino Unido***87 %90 %no disponibleno disponibleno disponible**República Checa**64 %72 %75 %77 %78 %**Rumanía**23 %38 %38 %46 %50 %**Suecia**82 %84 %87 %86 %89 % *Hasta el Brexit. ### Comparación del porcentaje de compradores online 2013-2023 Al **comparar datos de la última década**, observamos un gran crecimiento en la adopción del eCommerce como opción de compra habitual dentro de la UE. Algunos países, como Bulgaria, Estonia y Rumanía, han triplicado e incluso cuadruplicado el porcentaje de compradores online entre 2013 y 2023. **País****2013****2023****Media de la UE**47 %70 %**Eurozona**47 %71 %**Alemania**69 %77 %**Austria**54 %72 %**Bélgica**48 %75 %**Bulgaria**12 %45 %**Chipre**25 %57 %**Croacia**26 %59 %**Dinamarca**77 %89 %**Eslovaquia**44 %77 %**Eslovenia**36 %66 %**España**32 %69 %**Estonia**23 %73 %**Finlandia**65 %79 %**Francia**59 %77 %**Grecia**25 %58 %**Hungría**29 %70 %**Irlanda**46 %86 %**Islandia**56 %no disponible**Italia**20 %51 %**Letonia**32 %62 %**Lituania**26 %61 %**Luxemburgo**70 %80 %**Malta**46 %68 %**Noruega**73 %91 %**Países Bajos**69 %92 %**Polonia**32 %64 %**Portugal**25 %55 %**Reino Unido***77 %no disponible**República Checa**36 %78 %**Rumanía**8 %50 %**Suecia**73 %89 % *Hasta el Brexit. ### Comparación del porcentaje de compradores online por grupos de edad 2013-2023 Al comparar los datos por grupos de edad de la última década, los datos en la UE y de la zona Euro son muy similares. El grupo de edad en el que más ha aumentado el número de compradores online ha sido el de los usuarios de Internet de entre 55 y 74 años —de en torno a un 27 % en 2013 a en torno a un 50 % en 2023—. **Grupo de edad****2013 (UE)****2023 (UE)****16-24 años**58 %81 %**25-54 años**55 %80 %**55-74 años**27 %50 % ### Productos y servicios más comprados online en la Unión Europea en 2022 Asimismo, según datos de Eurostat, estos fueron los productos y servicios más comprados en línea en la UE en 2023, durante los tres meses precedentes a la realización de la encuesta: - **Ropa, zapatos y accesorios** (40 %). - **Entradas a eventos **(21 %). - **Descargas y servicios de streaming de películas y series** (20 %). - **Comida a domicilio y servicios de catering** (17 %). - **Cosmética y productos de belleza y bienestar** (16 %). - **Descargas y servicios de streaming de música** (16 %). - **Muebles, accesorios del hogar y productos de jardinería** (15 %). - **Libros, revistas y periódicos en papel** (13 %).  - **Suplementos médicos y dietéticos** (13 %). - **Ordenadores, tabletas, teléfonos móviles y accesorios** (12 %). En resumen, según las estadísticas del eCommerce a nivel mundial, el mercado del comercio electrónico no ha parado de crecer durante la última década y se estima que siga creciendo. El número de usuarios que compran productos y servicios en línea sigue en aumento, al igual que el número de usuarios de Internet, y los negocios necesitan seguir el ritmo de la innovación para poder dar respuesta a las necesidades de los clientes y no quedarse atrás. Para ellos, las empresas aprovechan la flexibilidad, el rendimiento y la disponibilidad que ofrecen las soluciones cloud para eCommerce. Fuentes: eMarketer, Statista, Eurostat (isoc_ec_ibuy), Eurostat (isoc_ec_ib20) y Eurostat (isoc_ec_ibgs). --- ## eCommerce statistics and growth (2024) URL: https://www.stackscale.com/blog/ecommerce-statistics-growth/ eCommerce has experienced continued growth during the last decade. In this article we have collected some **eCommerce statistics in 2024 and over the last decade **showing how its adoption has increased over the years. ## Global eCommerce market growth **Global eCommerce sales are expected to surpass 5.8 trillion Euros (6.3 trillion USD) in 2024** and 6.3 trillion Euros (6.8 trillion USD) by 2025, according to eMarketer eCommerce statistics and forecasts. The forecast for retail eCommerce sales growth is about 9,4% in 2024; a growth rate that is expected to decrease slightly during the following triennium. These predictions continue to show a stabilization following the skyrocketing of eCommerce growth worldwide in 2020-2021, due to lockdowns and restrictions. As a result of the increase in digital activity during the pandemic, retail eCommerce sales grew above 25% in 2020 and above 15% in 2021. These eCommerce statistics not only demand for businesses to stay up to date to new trends and technologies, but also to explore international markets in order to leverage further opportunities. Thus making specialized cloud solutions and complementary services such as Content Delivery Networks a priority for many growing eCommerce sites. ## Revenue in the eCommerce market worldwide Revenue in the eCommerce Market worldwide surpassed 2,800 billion Euros (3,100 billion USD) in 2023 and it is expected to surpass 3,300 billion Euros (3,600 billion USD) by 2024, according to Statista’s eCommerce market insights. ### Revenue by product category in 2023 Looking closer to the revenue by product category, these were the 10 sectors with the highest revenue in 2023: - **Electronics**: ~725 billion Euros (~781 billion USD). - **Fashion**: ~625 billion Euros (~673 billion USD). - **Food**: ~343 billion Euros (~370 billion USD). - **Beverages**: ~194 billion Euros (~209 billion USD). - **DIY and Hardware Store**: ~186 billion Euros (~201 billion USD). - **Furniture**: ~174 billion Euros (~188 billion USD). - **Media**: ~169 billion Euros (~182 billion USD). - **Beauty and Personal Care**: ~140 billion Euros (~151 billion USD). - **Tobacco Products**: ~96 billion Euros (~104 billion USD). - **Toys and Hobbies**: ~74 billion Euros (~80 billion USD). ## Growth in the number of users buying online in the European Union According to data from eCommerce statistics for individuals in the European Union of Eurostat, **the average of Internet users purchasing online in the EU was about 70% in 2023**. While the average in the Euro area was slightly higher: about 71% of Internet users shop online. ### Evolution of the percentage of online shoppers 2019-2023 The percentage of Internet users purchasing online has evolved during the last five years. The growth rate varies depending on the country, but all of them have generally experienced a **significant increase in the number of online buyers**. The following table shows the percentage of online shoppers that purchased something on the Internet during the 12 months previous to the annual survey. **Country****2019****2020****2021****2022****2023****EU average**60%65%67%68%70%**Eurozone**63%67%69%69%71%**Austria**62%66%63%66%72%**Belgium**66%73%75%75%75%**Bulgaria**22%31%33%41%45%**Croatia**45%55%57%56%59%**Cyprus**39%47%54%50%57%**Czechia**64%72%75%77%78%**Denmark**84%89%91%88%89%**Estonia**68%68%70%71%73%**Finland**73%76%79%79%79%**France**70%not available76%76%77%**Germany**79%83%76%76%77%**Greece**39%46%54%59%58%**Hungary**49%60%66%70%70%**Iceland**80%83%85%not availablenot available**Ireland**67%74%87%85%86%**Italy**38%44%51%49%51%**Latvia**47%56%62%62%62%**Lithuania**48%54%60%60%61%**Luxembourg**72%79%81%81%80%**Malta**58%63%65%68%68%**Netherlands**81%87%89%88%92%**Norway**82%85%92%92%91%**Poland**54%61%61%65%64%**Portugal**39%45%52%54%55%**Romania**23%38%38%46%50%**Slovakia**60%62%75%77%77%**Slovenia**56%63%71%63%66%**Spain**58%63%67%68%69%**Sweden**82%84%87%86%89%**United Kingdom***87%90%not availablenot availablenot available *Until Brexit. ### Comparison of the percentage of online buyers 2013-2023 When **comparing data over the last decade**, we notice an important growth in online shopping adoption as a regular shopping option within the EU. Some countries, such as Bulgaria, Estonia and Romania, have tripled and even quadrupled the percentage of online buyers between 2013 and 2023. **Country****2013****2023****EU average**47%70%**Eurozone**47%71%**Austria**54%72%**Belgium**48%75%**Bulgaria**12%45%**Croatia**26%59%**Cyprus**25%57%**Czechia**36%78%**Denmark**77%89%**Estonia**23%73%**Finland**65%79%**France**59%77%**Germany**69%77%**Greece**25%58%**Hungary**29%70%**Iceland**56%not available**Ireland**46%86%**Italy**20%51%**Latvia**32%62%**Lithuania**26%61%**Luxembourg**70%80%**Malta**46%68%**Netherlands**69%92%**Norway**73%91%**Poland**32%64%**Portugal**25%55%**Romania**8%50%**Slovakia**44%77%**Slovenia**36%66%**Spain**32%69%**Sweden**73%89%**United Kingdom***77%not available *Until Brexit. ### Comparison of the percentage of online buyers by age group 2013-2023 When comparing data grouped by age over the last decade, data in the EU and the Euro area is very similar. The age group whose number of online buyers has increased the most is that of the Internet users between 55 and 74 years old — from about 27% in 2013 to about 50% in 2023. **Age group****2013 (EU)****2023 (EU)****16-24 years old**58%81%**25-54 years old**55%80%**55-74 years old**27%50% ### Most online purchased products and services in the European Union in 2023 Moreover, according to data from Eurostat, these were the most online purchased products and services in the EU in 2023, during the three months previous to running the survey: - **Clothes, shoes and accessories** (40%). - **Tickets to events** (21%). - **Films and series as a streaming service or downloads** (20%). - **Food delivery and catering services** (17%). - **Cosmetics and beauty and wellness products** (16%). - **Music as a streaming service or downloads** (16%). - **Furniture, home accessories and gardening products** (15%). - **Printed books, magazines and newspapers** (13%).  - **Medicine and dietary supplements** (13%). - **Computers, tablets, mobile phones and accessories** (12%). To sum up, according to eCommerce statistics worldwide, the eCommerce market has not stopped growing over the last years and it is expected to continue growing. The number of users that purchase products and services online keeps rising, along with the number of Internet users, and businesses need to keep up with innovation in order to meet customers demands and not fall behind. To do so, companies leverage the flexibility, performance and availability offered by eCommerce cloud solutions. Sources: eMarketer, Statista, Eurostat (isoc_ec_ibuy), Eurostat (isoc_ec_ib20) and Eurostat (isoc_ec_ibgs). --- ## Sala meet me room (MMR): características y ventajas URL: https://www.stackscale.com/blog/meet-me-room/ La sala meet me room (MMR, por sus siglas en inglés) es un espacio dentro de las instalaciones del centro de datos en el que las empresas de telecomunicaciones y los proveedores de servicios de red pueden conectar físicamente su infraestructura. Sirve como un **hub de interconexión** para operadores, ISPs, proveedores de servicios cloud, CDNs y otros proveedores de servicios dentro del centro de datos. ## ¿Qué es la meet me room? Una sala **meet me room o MMR** es el espacio (o espacios, cuando hay múltiples salas MMR) en el que se ordenan todos los cables de los clientes y proveedores del centro de datos. Esto permite a los proveedores establecer conexiones directas para intercambiar tráfico de datos, compartir recursos e interconectar sus redes. Asimismo, estos espacios de interconexión facilitan el diseño de soluciones de infraestructura cloud privadas, públicas e híbridas. Esta **disponibilidad de opciones de conectividad** ayuda a las empresas a elegir e implementar la solución que mejor se adapte a sus necesidades de forma más rápida y rentable. Sin necesidad de preocuparse de la interconexión en sí misma ni de su monitorización y mantenimiento, ya que el data center se encarga de ello. Los IXPs también pueden tener presencia en las meet me rooms para facilitar el intercambio de tráfico a empresas y proveedores. ## Ventajas de la sala meet me room Como ubicación neutra y centralizada que simplifica el proceso de establecer conexiones directas, las salas meet me room ofrecen diversos beneficios además de aumentar la eficiencia. Por ejemplo, contribuyen a: - **Reducir la latencia** evitando tener que enrutar el tráfico a través de redes externas. - **Ahorrar costes** al evitar recurrir a conexiones de terceros. Los proveedores pueden negociar acuerdos de peering más favorables, lo cual puede reducir potencialmente los gastos de conectividad. - **Potenciar el rendimiento de red** gracias a una ruta más directa y fiable para la transferencia de datos. - **Disfrutar de mayor escalabilidad y flexibilidad** para expandir las interconexiones a medida que el negocio crece. - Elegir entre la **amplia variedad de proveedores de conectividad** disponibles en el centro de datos y presentes en el MMR. Esto también impulsa la redundancia y la fiabilidad, ya que las organizaciones disponen de múltiples rutas para la transferencia de datos. - Beneficiarse de las **conexiones cruzadas** dentro del MMR para establecer enlaces directos e impulsar la colaboración y el intercambio de servicios con otros proveedores. En resumen, una MMR es un espacio de interconexión para operadores, ISPs, proveedores cloud, CDNs y otros proveedores de servicios dentro del centro de datos. No solo favorece la interconexión sino que también ofrece muchas ventajas como menor latencia, ahorro de costes, rendimiento mejorado de red y escalabilidad. Los centros de datos de  Stackscale cuentan con sala meet me room y proporcionan una conectividad ágil, segura y eficiente. Lo cual permite a los clientes disfrutar de mayor libertad para elegir los servicios y opciones de conectividad que mejor se adapten a sus necesidades y objetivos. --- ## Meet-me room (MMR): features and benefits URL: https://www.stackscale.com/blog/meet-me-room/ The meet-me room, also known as MMR, is a space within the data center facilities where telecommunications companies and network service providers can physically connect their infrastructure. It serves as **an interconnection hub** for carriers, ISPs, cloud service providers, CDNs and other service providers within the data center. ## What is a meet-me room? A **meet-me room or MMR** is the space (or spaces, when there are multiple MMRs) where all the cables of the data center’s customers and providers are arranged. This enables providers to establish direct connections to exchange data traffic, share resources and interconnect their networks. Moreover, these interconnection spaces facilitate the design of private, public and hybrid cloud infrastructure solutions. This **availability of connectivity options** make it easier for companies to find and implement the most suitable solution faster and more cost-efficiently. Without the hassle of taking care of the interconnection itself nor its monitoring and maintenance, as the data center is responsible for it. Besides, IXPs can also be present in meet-me rooms in order to make traffic exchange easier for organizations and providers. ## Meet-me room benefits As a neutral and centralized location that simplifies the process of establishing direct connections, meet-me rooms offer diverse benefits in addition to increasing efficiency. For instance, it contributes to: - **Reducing latency** by avoiding routing traffic through external networks. - **Saving costs** by avoiding the need for third-party connections. Providers can negotiate more favorable peering agreements, potentially reducing connectivity expenses. - **Enhancing network performance** by leveraging a more direct and reliable path for data transfer. - **Leveraging further scalability and flexibility** to expand interconnections as businesses grow. - Choosing among the **wide range of connectivity providers** available in the data center and present in the MMR. This also boosts redundancy and reliability, as organizations can have multiple paths available for data transfer. - Benefiting from **cross-connections** within the MMR to establish direct links and boost collaboration and services exchange with other providers. To sum up, a MMR is an interconnection space for carriers, ISPs, cloud providers, CDNs and other service providers within the data center. It not only favors interconnection but also offers numerous benefits such as lower latency, cost savings, improved network performance and scalability. Stackscale’s data centers have meet-me rooms and provide agile, secure and efficient connectivity. Thus providing customers with greater freedom to opt for the services and connectivity options that better meet their requirements and goals. --- ## Migrar de on-premise a cloud: añadir valor y optimizar costes URL: https://www.stackscale.com/blog/on-premises-cloud-costs/ Migrar de on-premises a cloud se suele considerar no solo como una manera de reducir costes sino también como una estrategia para añadir valor al negocio. Al migrar de un centro de datos on-premise a uno en la nube, las empresas pueden **disfrutar de muchos beneficios intangibles además de reducir costes**. De modo que, al calcular el retorno de la inversión o «ROI de la nube», deben tener en cuenta diversos factores. Ya que la optimización de costes es solo una de las motivaciones para cambiar a un modelo cloud. ## Beneficios de migrar de on-premise a cloud La lista de razones para migrar de una infraestructura on-premise a una basada en la nube va más allá del ahorro económico. Al contar con una solución cloud, las organizaciones también pueden: - Aumentar la escalabilidad, agilidad y competitividad. - Beneficiarse de la disponibilidad del servicio garantizada por SLA. - Mejorar las capacidades de recuperación ante desastres (DR) y continuidad de negocio. - Reforzar el control sobre los costes. Según el informe cloud de Couchbase de 2023, **más del 50 % de las empresas están cambiando de un modelo CAPEX a uno OPEX**, mientras que solo en torno al 20 % lo están haciendo a la inversa. De hecho, aunque la repatriación desde la nube pública a soluciones dedicadas está ganando popularidad entre los CIOs y CTOs, esta tendencia no está suponiendo la vuelta a centros de datos tradicionales. Ya que las soluciones cloud permiten a los negocios acceder a ciertos servicios y aplicaciones que no podrían permitirse implementar internamente. ### Escalabilidad y agilidad Las empresas pueden escalar su infraestructura siempre que lo necesiten para responder a la demanda. Pueden actualizar su infraestructura de TI más rápido para adaptarse a las necesidades cambiantes del negocio; así como **aprovechar nuevas oportunidades**. Las organizaciones también pueden beneficiarse de la agilidad que ofrece el cloud para adoptar nuevas tecnologías como la IA, con mayor facilidad y rentabilidad. ### Rentabilidad y competitividad La comparación CAPEX vs OPEX sigue destacando al plantear una migración de infraestructura. Comparado con las soluciones de TI tradicionales basadas en un modelo CAPEX, las soluciones cloud permiten que las empresas inviertan su capital disponible en soluciones que generen más beneficios como puede ser el desarrollo de productos, la I+D o la generación de leads. Lo cual también permite a las empresas **aumentar la competitividad y acceder a nuevos mercados**. Al externalizar la gestión y el mantenimiento de la infraestructura técnica, los equipos de TI pueden **dedicarse a tareas que aporten más valor al negocio y los clientes**. Aunque también necesitan asumir otras responsabilidades como la de educar y asesorar a otros departamentos para sacar el mayor partido de las tecnologías cloud, y así evitar tanto costes innecesarios como riesgos potenciales. Asimismo, al migrar de un centro de datos on-premise a uno en la nube, las empresas también pueden **acelerar el *****time to market***** y acortar los tiempos de aprovisionamiento**. ### Disponibilidad y *uptime* Los proveedores de servicios cloud establecen su nivel de disponibilidad como un porcentaje dentro de su Acuerdo de nivel de servicio o SLA. Por ejemplo, el SLA de Stackscale garantiza disponibilidad de red del 99,95 % y disponibilidad del hardware del 99,90 %. Además, los centros de datos en los que alojamos nuestra infraestructura garantizan un 99,99 % de disponibilidad SLA. ### Continuidad de negocio y Disaster Recovery La nube ha hecho que ciertas tecnologías y soluciones sean más accesibles para negocios de todos los tamaños. Esto incluye las soluciones de recuperación ante desastres y continuidad de negocio, que son una prioridad teniendo en cuenta que las ciberamenazas siguen en aumento año tras año. Los proveedores cloud como Stackscale ofrecen un **alto nivel de redundancia y seguridad**, de manera que las empresas puedan conseguir el nivel de continuidad de negocio que necesitan para sus sistemas de misión crítica, de forma más eficiente. Además, la mayoría de los proveedores de servicios proporcionan soluciones de disaster recovery adaptadas al plan de recuperación de cada negocio.  ## Mantener el control de los costes en el cloud La nube ayuda a **equilibrar el gasto en TI y optimizar costes**, pero también exige nuevos enfoques. Según el informe cloud de Couchbase de 2023, factores como el *vendor lock-in*, la falta de transparencia o las tarifas inflexibles suponen en torno a un 29% de exceso de gasto en servicios cloud. **La gestión de costes** se debe enfocar de forma diferente al migrar a una solución off-premises. El rápido aprovisionamiento en la nube se debe gestionar adecuadamente para mantener el control sobre los gastos en el tiempo. Por lo tanto, es especialmente importante confiar en soluciones que ofrezcan **precios transparentes y flexibilidad** para sacar el máximo partido al cloud sin incurrir en sobrecostes. Así como adoptar nuevas metodologías, como FinOps, para gestionar costes operativos de forma más eficiente. En este sentido, los entornos de Cloud Privado suelen proporcionar un rendimiento y costes más predecibles, dado que la mayoría de las cargas de trabajo de los negocios son predecibles. Las soluciones cloud dedicadas, junto con una estructura de facturación transparente, facilita a los negocios **mantener el presupuesto del cloud bajo control**. ** El modelo de nube privada a demanda ofrece la flexibilidad del cloud y la tranquilidad de contar con una infraestructura de uso exclusivo, sin inversiones de capital. Asimismo, para una buena relación entre costes y eficiencia, la colaboración estrecha entre los equipos tecnológicos y financieros también es clave para gestionar con éxito los costes y sacar el máximo partido a las inversiones. La relación entre el CTO y el CFO es importante para seleccionar las soluciones tecnológicas adecuadas para el negocio, tanto para optimizar costes como para mejorar el rendimiento. ¿Estás pensando en cambiar de un modelo on-premise a la nube? Nuestros expertos en cloud pueden ayudarte a encontrar la infraestructura adecuada para tu empresa**. Fuentes: Couchbase --- ## Migrating from on-premise to cloud: adding value & reducing costs URL: https://www.stackscale.com/blog/on-premises-cloud-costs/ Migrating from on-premise to cloud is often considered not only as a way of reducing costs but also as a strategy to add value to businesses. When migrating from an on-premise to a cloud datacenter, companies can **enjoy many intangible benefits in addition to cost savings**. Therefore, when calculating “cloud ROI”, companies should consider multiple factors. Since cost optimization is just one of the motivations for changing to a cloud model. ## Benefits of migrating from on-premise to cloud The list of reasons to migrate from an on-premise to a cloud-based infrastructure goes far beyond money saving. By relying on a cloud solution, organizations can also: - Increase scalability, agility and competitiveness. - Benefit from service availability guaranteed by SLA. - Boost business continuity and Disaster Recovery capabilities. - Reinforce control over costs. According to Couchbase’s cloud report of 2023, **more than 50% of companies are switching from a CAPEX to an OPEX model**, while only about 20% of companies are switching the other way around. In fact, although cloud repatriation from public cloud to dedicated solutions is gaining popularity among CIOs and CTOs, this trend is not leading to a return to on-premise data centers. As cloud solutions allow businesses to access certain services and applications that it might not be affordable to implement in-house. ### Scalability and agility Companies can scale their infrastructure up and down whenever necessary to meet demand. They can update their IT infrastructure faster in order to adapt to the evolving needs of the business; as well as **leverage new opportunities**. Organizations can also benefit from the agility cloud offers to adopt the newest technologies such as AI, more easily and cost-efficiently. ### Cost-efficiency and competitiveness The CAPEX vs OPEX comparison keeps standing out when considering an infrastructure migration. Compared to traditional IT solutions based on a CAPEX model, cloud solutions allow companies to invest their available capital in more revenue-generating solutions such as product development, R&D or lead generation. Thus also allowing companies to **increase competitiveness and enter new markets**. By outsourcing the management and maintenance of the technical infrastructure, IT teams can **focus on tasks adding more value to the business and customers**. Even though they also need to take other responsibilities such as educating and assessing other departments to make the most of cloud technologies, thus avoiding both unnecessary costs and potential risks.  Moreover, by migrating from an on-premise to a cloud data center, companies can also **accelerate their time to market and shorten provisioning times**. ### Availability and uptime Cloud service providers establish their level of availability as a percentage in their Service Level Agreement (SLA). For instance, Stackscale’s SLA guarantees 99,95% network availability and 99,90% hardware availability. Besides, the data centers where we host our infrastructure guarantee 99,99% SLA availability. ### Business continuity and Disaster Recovery The cloud has made certain technologies and solutions more affordable to businesses of all sizes. This includes business continuity and Disaster Recovery solutions, which are a priority as cyberthreats continue to rise year after year. Cloud providers like Stackscale offer a **high level of redundancy and security**, so companies can achieve the level of business continuity they need for their mission-critical systems, more efficiently. Besides, most service providers deliver disaster recovery solutions adapted to business DRP requirements. ## Keeping control of costs in the cloud The cloud helps **balance IT spending and optimize costs**, but it also demands for new approaches. According to Couchbase’s cloud report of 2023, factors such as vendor lock-in, lack of transparency or inflexible pricing entail about 29% overspend on cloud services. **Cost management** must be approached differently when migrating off-premises. Fast provisioning in the cloud must be properly managed to keep control of costs over time. Therefore, it is particularly important to rely on solutions that offer **transparent pricing and flexibility** to make the most of the cloud without incurring cost overruns. As well as adopting new methodologies, such as FinOps, to manage operational costs more efficiently. On this matter, Private Cloud environments usually provide more predictable costs and performance, as most of the workloads in businesses are predictable. Dedicated cloud solutions, along with a transparent billing structure, make it easier for businesses to **keep the cloud budget under control**. ** The on-demand private cloud model offers the flexibility of the cloud and the peace-of-mind of having an infrastructure of exclusive use, without capital investments. Furthermore, in terms of cost-efficiency, a close collaboration between technology and finance teams is also key to successfully manage costs and make the most of investments. The relationship between the CTO and the CFO is important to select the right technological solutions for the business, both for optimizing costs and boosting performance. Thinking about changing from an on-premises to a cloud model? Our cloud experts can help you find the right infrastructure for your company**. Sources: Couchbase --- ## Programar tareas con cron y crontab en Linux URL: https://www.stackscale.com/blog/cron-crontab-linux/ **Cron** es un administrador de tareas basado en tiempo que se usa para automatizar y programar tareas repetitivas, recopilación periódica de datos, avisos, etc. El **demonio cron o crond** permite a los usuarios administrar y ejecutar tareas automáticamente en intervalos de tiempo específicos. Es una de las herramientas clave para programar tareas en Linux y sistemas operativos basados en Unix. ## Cron **Cron** es una herramienta de línea de comandos ideada para programar tareas («**cron jobs**» en inglés), para ejecutarlas periódicamente y automáticamente, en la fecha y hora programada. Este administrador de tareas se puede usar para muchos fines, como: - Recolectar logs del sistema. - Crear copias de seguridad. - Descargar emails o archivos de Internet. - Programar el mantenimiento del sistema. - Sincronizar archivos. Las tareas se ejecutan en segundo plano, sin alterar las funcionalidades de Linux. Los usuarios pueden configurar una lista infinita de tareas cron para que se ejecuten según lo programado —cada x minuto, hora, día, mes o año—. La lista de tareas se almacena en un archivo llamado crontab. ## Crontab **Crontab**, abreviatura de «*cron table*», es tanto un comando como el archivo que contiene las tareas que el demonio cron tiene que ejecutar periódicamente. Cada usuario tiene su propio archivo de configuración y gestiona sus tareas programadas. Las tareas enumeradas en el archivo crontab contienen los comandos junto con su fecha y hora de ejecución. De modo que el administrador cron de Linux pueda ejecutar los scripts tal y como están programados al acceder y analizar el archivo. ## Cron jobs  Las tareas cron tienen la siguiente sintaxis: ``` min h d/m mes d/s ``` Se formatean con los siguientes campos: **Campo****Valores**min (minuto)0-59h (hora)0-23d/m (día del mes)1-31mes (mes)1-12d/s (día de la semana)0-6 (domingo-sábado)ComandoEl comando de Linux que se desea programar. Así como con diferentes caracteres especiales, como: **Carácter especial****Uso***Seleccionar todos los valores posibles en un campo.***El asterisco se puede usar para rellenar un campo sin ningún valor específico, puesto que es obligatorio rellenar todos los campos al crear una tarea cron./Especificar un intervalo de tiempo.,Seleccionar múltiples valores.-Especificar un rango de tiempo. ### Ejemplos de tareas cron programadas en crontab - Ejecutar el comando cada día a las doce y media de la noche: ``` 30 0 * * * ``` - Ejecutar el comando cada sábado a las dos de la noche: ``` 0 2 * * 6 ``` - Ejecutar el comando a medianoche el primer día del año: ``` 0 0 1 1 * ``` - Ejecutar el comando cada cinco minutos de lunes a viernes: ``` */5 * * * 1-5 ``` ## Atajos de crontab Asimismo, para simplificar las programaciones más habituales, existen algunos atajos o comandos especiales: Atajo****Programación**@rebootEjecutar la tarea cuando se reinicia el sistema.@yearly o @annuallyEjecutar la tarea una vez al año.@monthlyEjecutar la tarea el primer día de cada mes (0 0 1 * *).@weeklyEjecutar la tarea el primer día de cada semana (0 0 * * 0).@daily o @midnightEjecutar la tarea cada día a medianoche (0 0 * * *).@hourlyEjecutar la tarea cada hora (0 * * * *). ## Comando crontab Para gestionar tareas programadas, se pueden añadir las siguientes opciones al comando crontab: - -e para editar el archivo crontab actual. - -l para obtener una lista de las tareas del archivo crontab actual. - -r para eliminar de forma permanente el archivo crontab actual. - -u para ejecutar una opción en el archivo crontab de otro usuario. ## Programar una copia no es lo mismo que tenerla Escribir la tarea cron es la parte fácil. Lo que decide si una copia programada sirve de algo es dónde acaba y con qué rapidez se puede restaurar, y eso es cuestión de infraestructura y no de sintaxis. Sobre una solución gestionada de Disaster Recovery y backup el almacenamiento está georeplicado entre centros de datos europeos y cuenta con su propia política de snapshots, de modo que el punto de recuperación no depende de que una única tarea programada se ejecute como estaba previsto. ¿Necesitas ayuda con la administración de sistemas y servidores? Nuestros servicios gestionados incluyen acceso directo a soporte técnico especializado. Hablemos. --- ## Scheduling tasks with cron and crontab in Linux URL: https://www.stackscale.com/blog/cron-crontab-linux/ **Cron** is a time-based job scheduler used for automating and scheduling repetitive tasks, periodical collection of data, alerts, etc. The **cron daemon or crond** allows users to manage and run tasks automatically at specific time intervals. It is one of the key tools for scheduling tasks in Linux and Unix-like operating systems. ## Cron **Cron** is a command-line utility intended to schedule tasks or “**cron jobs**” to be run periodically and automatically, at a particular time and date. This task manager can be used for numerous purposes, such as: - Collecting system logs. - Creating backups. - Downloading email or files from the Internet. - Scheduling system maintenance. - Synchronizing files. Tasks run in the background, without altering any Linux functionality. Users can set up an endless list of cron jobs to be executed as scheduled — every n-th minute, hour, day, month or year. The list of tasks is stored in a file called crontab. ## Crontab **Crontab**, short for “cron table”, is both a command and the file that contains the cron jobs that the cron daemon must periodically run. Every user has its own configuration file and manages his own scheduled jobs. The tasks listed in the crontab file contain the commands along with their date and time of execution. So that the Linux cron utility can run the scripts as scheduled when accessing and analyzing the file. ## Cron jobs Cron jobs have the following syntax: ``` min h d/m mon d/w ``` They are formatted using the following fields: **Field****Values**min (minute)0-59h (hour)0-23d/m (day of the month)1-31mon (month)1-12d/w (day of the week)0-6 (Sunday to Saturday)CommandThe Linux command the user wishes to schedule. As well as diverse special characters, such as: **Special character****Purpose***Select every possible value in a field.***The asterisk can be used to fill a field without any specific value, as all fields must be filled when creating a cron job./Specify an interval of time.,Select multiple values.-Specify a range of time. ### Examples of cron jobs scheduled in crontab - Run the command every day at half past midnight: ``` 30 0 * * * ``` - Run the command every Saturday at 2:00AM: ``` 0 2 * * 6 ``` - Run the command at midnight the first day of January: ``` 0 0 1 1 * ``` - Run the command every five minutes from Monday to Friday: ``` */5 * * * 1-5 ``` ## Crontab shortcuts Moreover, in order to simplify commonly used schedules, there are some shortcuts or special commands available: Shortcut****Schedule**@rebootRun a task when the system restarts.@yearly or @annuallyRun a task once a year.@monthlyRun a task the first day of every month (0 0 1 * *).@weeklyRun a task the first day of every week (0 0 * * 0).@daily or @midnightRun a task every day at midnight (0 0 * * *).@hourlyRun a task once an hour (0 * * * *). ## Crontab command In order to manage scheduled jobs, the following options can be added to the crontab command: - -e to edit the current crontab file. - -l to get a list of all the tasks within the current crontab file. - -r to permanently delete the current crontab file. - -u