Elegido por sitio
Cada línea de alojamiento ofrece su propio conjunto de centros de datos. Usted elige uno cuando crea un sitio, y el formulario de pedido solo ofrece una ciudad donde esa línea tenga disponibilidad hoy.
Regiones y residencia de datos
La región no es un ticket de soporte en esta plataforma: es una propiedad del sitio, respetada por el motor de ubicación cada vez que se implementa algo. Usted elige el centro de datos al crear un sitio, de entre las ciudades que ofrece hoy su línea de hosting, y cada implementación se sitúa en la capacidad de la flota en esa ubicación, con un edge global al frente. Cada página de hosting enumera esas ciudades, leídas en tiempo real.
Detrás de cada ubicación hay dos elementos: la flota de procesos que ejecuta sus sitios y el plano de control que los administra. Ambos reconocen la región. La ubicación que elija queda a su entera elección; la capacidad subyacente es disposición nuestra, y operamos deliberadamente con más de un proveedor para que ninguno constituya por sí solo la plataforma.
Cada línea de alojamiento ofrece su propio conjunto de centros de datos. Usted elige uno cuando crea un sitio, y el formulario de pedido solo ofrece una ciudad donde esa línea tenga disponibilidad hoy.
Las ciudades que aparecen en cada página de alojamiento y en el formulario de pedido se leen desde el motor de asignación, de modo que una nueva ubicación se muestra el día en que dispone de capacidad y una que esté completa no se ofrece.
La región se aplica en el código en el momento en que se crea un sitio, no mediante un operador que recuerde qué caja utilizar.
Cada host de la flota se registra con una clave de región, una lista de afinidad de línea de productos, un tipo de servidor web y una cifra de capacidad, y luego obtiene trabajo. El servicio de asignación filtra los candidatos primero por región, luego por línea de productos, después por capacidad libre y selecciona el host apto con menor carga.
Si fijó una región, solo los trabajadores de esa región son elegibles. Si no lo hizo, el sitio hereda la región del trabajador en el que aterriza y ese valor se almacena en el sitio; por lo tanto, el registro de dónde residen sus datos es un campo que puede leer, no una suposición.
La asignación reserva capacidad mediante una actualización condicional que solo tiene éxito mientras el worker sigue activo, continúa aceptando despliegues y permanece por debajo de su capacidad. Dos despliegues que compitan por el último espacio disponible no pueden ganar a la vez, por lo que una región nunca se sobresuscribe de forma inadvertida.
Si nada elegible en su región tiene espacio, el despliegue genera un error de ubicación y se detiene. No recurre a otro continente para que la solicitud tenga éxito. Un error visible y una ampliación de capacidad superan a un sitio que cambia de país silenciosamente.
Cada worker incluye un conmutador accepts-deploys. Cambiarlo a drain detiene la llegada de nuevos sitios mientras los sitios existentes continúan ejecutándose intactos, que es la forma en que realizamos el mantenimiento, las actualizaciones de hardware y el desmantelamiento dentro de una región sin trasladar sus cargas de trabajo.
La residencia de datos es una de las pocas decisiones de alojamiento que resulta verdaderamente difícil de revertir, por lo que la plataforma la trata como una dimensión de primer nivel y no como un mero detalle de despliegue. La elección de residencia del cliente es una entrada para la asignación, la región se registra en el sitio y la flota se etiqueta para que coincida. Esto es lo que hace que una respuesta sobre la residencia sea auditable en lugar de anecdótica.
El modelo de tenencia funciona en paralelo. Cada registro en el motor incluye un alcance de organización con seguridad a nivel de fila de PostgreSQL aplicada en la base de datos, y la tenencia es jerárquica: una organización de revendedor por encima de organizaciones de clientes por encima de sitios. La región determina dónde residen los datos; la seguridad a nivel de fila determina quién puede acceder a ellos. Ambos aspectos son importantes para un revisor de cumplimiento y ninguno es opcional.
La exportación y la eliminación de datos conforme al GDPR forman parte del mismo diseño en lugar de ser un proceso añadido posteriormente, y las acciones privilegiadas y administrativas se registran en auditorías. Si el cuestionario de su comprador pregunta dónde residen los datos, quién puede consultarlos y qué sucede cuando un interesado solicita su devolución, aquí encontrará respuesta a esas preguntas.
Elegir una región cercana ayuda, pero la mayor parte de la latencia que experimentan sus visitantes se determina antes de que una solicitud llegue a su servidor de origen.
La multirregión sirve de muy poco si todo sigue compartiendo el mismo destino. La arquitectura separa las piezas que no deben fallar juntas.
El motor, la base de datos, la capa de flujo de trabajo y los paneles de control se ejecutan en su propio plano de control de Kubernetes, totalmente separados de la flota de nodos de trabajo que da servicio a los sitios de los clientes. Una incidencia en el plano de control no debe hacer caer los sitios de los clientes, y una incidencia en la flota no debe hacer caer la plataforma.
El panel de control del cliente, la consola de administración y este sitio web de marketing están implementados en Cloudflare de forma independiente del clúster del plano de control, por lo que una incidencia en la plataforma no elimina también el lugar al que usted acudiría para informarse al respecto.
La página de estado está alojada deliberadamente con un proveedor diferente en una región distinta. Una página de estado que se ejecuta en la misma infraestructura que supervisa resulta inútil precisamente en el momento en que usted la necesita.
Las copias de seguridad por sitio son inmutables y externas, se escriben en almacenamiento de objetos y las restauraciones se prueban en lugar de darse por sentadas. Las restauraciones se realizan con un solo clic desde el panel, junto al administrador de archivos, los dominios, el DNS, el SSL y los registros.
No garantizamos un acuerdo de nivel de servicio, un tiempo de respuesta ni una cifra de latencia en esta página; los términos del SLA se acuerdan por contrato. La cifra del 99.99% asociada a los planes Footprint-Free es una garantía de tiempo de actividad, un objetivo para el que diseñamos la infraestructura, no un registro histórico medido de disponibilidad.
En la práctica, la decisión se reduce a cuatro preguntas, y la mayoría de los clientes las responden en menos de un minuto.
Sí. La región es una entrada para el motor de asignación, no una solicitud procesada fuera de banda. Fije una región y solo los fleet workers etiquetados para esa región serán aptos para recibir el sitio; la región elegida se guarda luego en el registro del sitio para que siempre pueda consultar dónde se ejecuta. Si la deja sin configurar, el sitio hereda la región del worker en el que se ubique.
Depende de la línea de alojamiento, ya que cada línea funciona con la capacidad creada para ella. El formulario de pedido y cada página de alojamiento enumeran las ciudades que puede elegir hoy, leídas en tiempo real desde el motor de asignación, por lo que esta respuesta nunca queda desactualizada. Para una residencia estricta en la EU, elija un centro de datos dentro de la Unión Europea; cuando las adquisiciones requieran una plataforma subyacente certificada, podemos asignar capacidad que cumpla con esos requisitos. Los proveedores detrás de cada ubicación son nuestro propio acuerdo comercial: usted elige la ubicación, no el proveedor.
No: Zinn Digital® no cuenta hoy con certificaciones de cumplimiento normativo propias, y no insinuaremos lo contrario. Lo que podemos hacer es ubicar su carga de trabajo en una plataforma subyacente que sí disponga de ellas, en caso de que las adquisiciones de un comprador exijan estrictamente una plataforma certificada bajo sus sitios. Por otra parte, los controles propios de la plataforma son reales e inspeccionables: aislamiento por sitio, seguridad a nivel de fila en cada tabla delimitada por inquilino, secretos almacenados en Vault, TLS en todo momento y registro de auditoría de acciones privilegiadas.
La implementación falla visiblemente con un error de ubicación en lugar de alojar silenciosamente su sitio en otro lugar. Esto es deliberado: un sitio que ha cambiado silenciosamente de jurisdicción es un resultado mucho peor que una implementación que se detuvo y le explicó el motivo. La capacidad se amplía incorporando más hosts en línea en esa región, donde se registran a sí mismos y comienzan a aceptar trabajo de inmediato.
No publicamos análisis comparativos de latencia y no prometeremos una cifra específica. Lo que sí podemos describir es la arquitectura: Cloudflare se sitúa al frente de cada sitio para que las respuestas almacenables en caché se sirvan desde una ubicación perimetral cercana al visitante, LSCache sirve páginas completas desde el worker sin tocar PHP ni la base de datos, y una caché de objetos Redis por sitio absorbe las consultas repetidas. Para la mayoría de los sitios de contenido, esta combinación significa que la región de origen importa mucho menos que la configuración de la caché. Si su audiencia se concentra en un continente, ubique el origen allí de todos modos.
La región se define al ubicar un sitio y se almacena en el registro del mismo, por lo que un cambio de región implica una migración y no una simple alternancia. Comuníquese con nosotros antes de comenzar la creación si ya sabe que habrá un traslado; resulta mucho más económico ubicar el sitio correctamente la primera vez que trasladar una cartera activa.
Las copias de seguridad por sitio son inmutables, externas y aisladas de la flota en ejecución, se escriben en almacenamiento de objetos con restauraciones probadas en lugar de supuestas, y se pueden restaurar con un solo clic desde el panel. Si sus requisitos de cumplimiento normativo exigen que el almacenamiento de copias de seguridad se ubique en una jurisdicción específica, consúltelo directamente con nosotros; se trata de un detalle contractual que acordamos por cliente y no de una afirmación genérica en una página web.
Sí. El periodo de prueba es de 14 días y no requiere tarjeta. Cubre Footprint-Free Hosting con hasta cinco sitios, lo cual es suficiente para ver cómo se comportan los despliegues, la ubicación y las capas de caché antes de que decida dónde debe alojarse su cartera de producción.
Inicie una prueba de 14 días sin tarjeta, o indíquenos primero sus requisitos de residencia y le ubicaremos correctamente desde el primer despliegue.
Empiece gratis