Base de conocimientos

Esta guía explica cómo trasladar un sitio web existente dentro de un Alojamiento Web de Infomaniak a otro alojamiento web de Infomaniak.

Introducción

• No existen muchas soluciones listas para usar para migrar un sitio web:
  • En general, pocos proveedores de alojamiento ofrecen la exportación o importación de un sitio completo con sus bases de datos.
  • Esto se debe, en parte, a que existen multitud de formas de construir un sitio y tantos lenguajes, que son en gran medida incompatibles entre sí.
• Si el sitio que se va a transferir está construido con WordPress, consulte esta otra guía que ilustra una solución simplificada.
• También es posible trasladar un alojamiento web completo (ver más abajo).

Solución manual: ejemplo de transferencia de sitio

Para hacerlo manualmente, es necesario:

• recuperar los datos web, así como las bases de datos asociadas,
• volver a publicar esto en un sitio creado en el servicio de alojamiento web de destino,
• y si el nombre de dominio asociado es el mismo, será necesario eliminar o cambiar el nombre del primer sitio.

Para lo demás, aquí tiene un ejemplo de los pasos a seguir:

1. Contrate el otro servicio de alojamiento web / servidor en la nube si aún no lo ha hecho.
2. Cree un «sitio web de prueba» en este nuevo alojamiento (por ejemplo, dev.dominio.xyz; consulte más abajo).
3. Copie manualmente sus datos mediante FTP y MySQL (exportar / importar).
4. Adapte su sitio si es necesario (dirección de la base de datos, etc.).
5. Una vez que esté satisfecho con el «nuevo sitio», elimine el antiguo.
6. Cambie el nombre del nuevo sitio para darle su nombre real.

Una alternativa consiste, en el punto 2 anterior, en trabajar con el alias www. que puede separar previamente de su sitio actual. De hecho, el alias www(.domain.xyz) suele estar instalado como alias de su sitio, y basta con separarlo, lo que permite la creación de un sitio en el otro alojamiento con el nombre www.domain.xyz (no olvide, en el punto 6, añadir su alias de tipo "domain.xyz" sin los www a este nuevo sitio).

Migración de alojamientos web completos

Existe una forma automatizada de migrar un alojamiento web de Infomaniak a:

• un Servidor Cloud de Infomaniak (si el alojamiento está actualmente compartido o si el alojamiento ya está en un Servidor Cloud)
• otra Organización de Infomaniak

Un alojamiento Starter no se puede trasladar, pero se puede convertir.

Esta guía le explica cómo desactivar (o reactivar) la herramienta de detección de vulnerabilidades, una protección gratuita y complementaria al antivirus que protege automáticamente los Alojamientos Web contra el malware y las vulnerabilidades de seguridad.

Desactivar o reactivar la detección de vulnerabilidades

Para acceder al alojamiento web y desactivar (o reactivar) el servicio:

1. Haga clic aquí para acceder a la gestión de alojamientos y sitios web en su Panel de control de Infomaniak (❓: ayuda).
2. Haga clic en el nombre del alojamiento correspondiente.
3. Haga clic en Seguridad en el menú lateral izquierdo.
4. Haga clic en Análisis de vulnerabilidades en el menú lateral izquierdo.
5. Haga clic en el interruptor para desactivar o activar el análisis:
   

Consulte esta otra guía si necesita información sobre cómo deshacer una corrección de seguridad.

Esta guía le explica cómo aplicar o anular un parche, una cuarentena o un bloqueo realizado por la herramienta de detección de vulnerabilidades, la protección gratuita y complementaria al antivirus que protege automáticamente los Alojamientos Web contra el malware y las vulnerabilidades de seguridad.

Introducción

• Si no realiza ninguna acción, la herramienta corregirá automáticamente las vulnerabilidades detectadas en un plazo de 7 días.
• Se recomienda encarecidamente no deshacer una actualización o ponerla en cuarentena a menos que esté seguro de lo que está haciendo.

Aplicar o cancelar una corrección

Para ello:

1. Haga clic aquí para acceder a la gestión de alojamientos y sitios web en su Panel de control de Infomaniak (❓: ayuda).
2. Haga clic en el nombre del alojamiento correspondiente.
3. Haga clic en Seguridad ‍ en el menú lateral izquierdo.
4. Haga clic en Análisis de vulnerabilidades en el menú lateral izquierdo:
   
5. Si no se muestra nada en particular, haga clic primero en el botón para Ver el historial.
6. Si existe un historial de eventos, haga clic en el menú de acción ⋮ a la derecha de la vulnerabilidad correspondiente en la tabla que se muestra.
7. Haga clic en Cancelar la corrección.
8. En algunos casos, son posibles otras acciones:
   1. Aplicar el parche: corrige inmediatamente la vulnerabilidad.
   2. Cancelar el parche: deshace la corrección y restaura el archivo original vulnerable (no recomendado).
   3. Eliminar el archivo: borra definitivamente el malware de su alojamiento (puede afectar al funcionamiento de su sitio).
   4. Poner en cuarentena: aísla el archivo vulnerable y le permite restaurarlo si es necesario (puede afectar al funcionamiento de su sitio).
   5. Cancelar la cuarentena: restaura el archivo aislado a su ubicación original (no recomendado).
   6. Añadir una excepción: permite indicar a la herramienta que el archivo vulnerable es seguro; este último ya no se analizará.
   7. Eliminar una excepción: elimina el estado Autorizado del archivo; este último se volverá a analizar.

Detalle de los diferentes estados

1. VULNERABLE: se ha detectado una vulnerabilidad en un archivo; la columna ruta de acceso indica la ubicación del archivo.
2. RESUELTO: la vulnerabilidad ha sido corregida por la herramienta.
3. AUTORIZADO: el archivo vulnerable ha sido autorizado manualmente; este último ya no será analizado por la herramienta.
4. RESUELTO: se realizó una corrección manual externa a la herramienta en el archivo (actualización del CMS, modificación del código fuente, eliminación manual del archivo, etc.).
5. CORRECCIÓN ANULADA: la corrección de la herramienta se anuló manualmente; es posible volver a aplicar el parche.

Esta guía explica cómo migrar de un VPS Lite a un VPS Cloud conservando todos sus datos y sin tener que reconfigurar nada de su instalación.

Introducción

• Se conserva la dirección IP del servidor, así como todos los datos del disco.
• No es posible deshacer este cambio ni volver a la configuración anterior.
• No es posible cambiar de un VPS Cloud a un VPS Lite.

Realizar una migración de VPS Lite a VPS Cloud

Para iniciar el proceso, acceda al VPS Lite:

1. Haga clic aquí para acceder a la gestión de su VPS en el Manager de Infomaniak (¿necesita ayuda?).
2. Haga clic directamente en el nombre asignado al VPS correspondiente:
   
3. Haga clic en Mejorar mi oferta:
   
4. Haga clic en el botón Actualizar en la ventana emergente que aparece.
5. Complete el pedido para mejorar su VPS Lite.
6. Espere durante la migración, se producirá una interrupción del servicio durante el proceso.

Esta guía explica cómo especificar un archivo que se cargará antes de que se cargue la página deseada o al principio de cada script PHP que se ejecute en su servidor, incluido como si se hubiera llamado con la función require(), pero de forma más general utilizando la directiva auto_prepend_file de PHP.

Introducción

• Por ejemplo, para declarar las cabeceras de un sitio web, es posible crear un archivo headers.php que contenga funciones PHP header() y que se añada al principio de cada archivo PHP…
  • … mediante un archivo .user.ini (específico de una carpeta),
  • … o mediante la configuración del sitio en el Panel de control (global), como se explica a continuación.

Incluir un archivo de forma global desde el Panel de control

Para acceder a la gestión del sitio web:

1. Haga clic aquí para acceder a la gestión de alojamientos y sitios en su Panel de control de Infomaniak (❓: ayuda).
2. Haga clic en el nombre del sitio web correspondiente.
3. Haga clic en Gestionar la configuración avanzada:
   
4. Haga clic en la pestaña PHP / Apache:
   
5. Complete la línea correspondiente introduciendo la ruta del archivo que desea incluir.
6. Haga clic en el botón Guardar en la parte inferior de la página:
   

Después de definir esta directiva, todas las páginas PHP de su servidor incluirán automáticamente el archivo especificado antes de ejecutar su propio código.

Las cabeceras definidas en un archivo .htaccess solo son válidas para el contenido que no es PHP (es decir, contenido estático).

Infomaniak utiliza php-fpm, que recibe las diferentes cabeceras a través de apache fast_cgi. En la RFC de cgi_www, la cabecera Strict-Transport-Security no forma parte de las cabeceras que se transmiten a través de CGI, y la documentación de Apache lo confirma. Consulte esta otra RFC.

Esta guía explica cómo personalizar el horario o los horarios durante los cuales Infomaniak puede realizar tareas de mantenimiento para mejorar sus servicios (nuevas funciones, correcciones, etc.).

Introducción

• Esta función solo está disponible para:
  • Servidores Cloud
  • VPS Cloud / VPS Lite
  • Jelastic Cloud
• Si no indica lo contrario, Infomaniak suele realizar las tareas de mantenimiento programadas entre las 22:00 y las 6:00 de la mañana.

Modificar el período de mantenimiento programado

Para ello:

1. Haga clic aquí para acceder al servicio para el que desea programar los mantenimientos en el Administrador de Infomaniak (¿necesita ayuda?).
2. Haga clic directamente en el nombre asignado al producto correspondiente.
3. Haga clic en Mantenimientos programados en el menú lateral izquierdo o en la página central, según el servicio correspondiente (a continuación, Jelastic):
   
   • El mismo principio se aplica a un VPS:
     
4. Haga clic en los botones para definir, en azul, un intervalo de tiempo preferido para la intervención.
5. Valide haciendo clic en el botón que se encuentra en la parte inferior:
   

Esta guía detalla la creación de un repositorio GIT tanto en su Alojamiento Web como en su Servidor Cloud de Infomaniak.

Introducción

• GIT y GitHub están disponibles de forma predeterminada en las dos plataformas mencionadas.

Creación del repositorio GIT

Configuración en el servidor:

• el repositorio GIT se encuentra en /git_depot
• el sitio se encuentra en la carpeta /web/[proyecto] (en su servidor FTP)

Líneas de comando que debe indicar:

cd
mkdir git_depot
cd git_depot/
git init --bare [projet].git
cd [projet].git
git update-server-info

Envío del repositorio local al servidor

Tareas a realizar en el equipo local:

git init
git remote add origin ssh://user@[xxxxx].ftp.infomaniak.com:/home/clients/[123456789]/git_depot/[projet].git
git status
git add .
git commit -a -m "init"
git push --set-upstream origin master
git push

Clonar el sitio en el directorio del servidor

Tareas a realizar en el servidor:

cd
cd web
rm -r [projet]/
git clone /home/clients/[123465789]/git_depot/[projet].git [projet]/

Esta guía explica cómo aumentar el volumen de almacenamiento de su VPS Cloud una vez que se haya realizado el cambio de plan.

Introducción

• De forma predeterminada, el VPS en la nube se proporciona con dos volúmenes:
  • 1 volumen para el sistema operativo de su elección (/dev/vda).
  • 1 volumen para el almacenamiento de sus datos (/dev/vdb); este es el volumen que se ampliará.
• Atención: según el sistema operativo instalado, el volumen del sistema puede llamarse /dev/sda, /dev/sda1 o /dev/vda; lo mismo ocurre con el volumen de datos /dev/sdb, /dev/sdb2 o /dev/vdb. Por lo tanto, es necesario reemplazar estas indicaciones con las que correspondan a su situación.

Comandos SSH para aumentar el volumen de almacenamiento

Si elige XFS, por ejemplo, es necesario instalar las herramientas adecuadas (si aún no están instaladas):

sudo apt install xfsprogs

A continuación, aumente el volumen con los siguientes comandos SSH:

sudo xfs_grow /dev/vdb

Y si elige EXT4:

sudo resize2fs /dev/vdb

Ampliar el volumen después de aumentar el espacio de almacenamiento

Pueden presentarse dos casos una vez que haya ampliado el volumen de almacenamiento de su servidor Linux. Tenga en cuenta que ningún dato se elimina al aumentar el espacio mediante el cambio de plan de su VPS.

Primer caso

Si se utiliza todo el volumen sin particiones, no es necesario realizar un resizepart, ya que no hay ninguna partición.

sudo umount /dev/vdb
sudo fsck.ext4 -f /dev/vdb
sudo resize2fs /dev/vdb

Segundo caso

En el caso de un volumen que contiene una partición (/dev/vdb1), primero hay que detener los procesos que utilizan este volumen y luego desmontar la partición.

sudo umount /dev/vdb1

A continuación, deberá aumentar el tamaño de la partición con parted, que dispone del comando resizepart, algo que no ofrece fdisk.

sudo parted /dev/vdb
GNU Parted 3.2
Using /dev/vdb
Welcome to GNU Parted! Type ‘help' to view a list of commands.
(parted) resizepart 1 100%
(parted) quit
sudo fsck.ext4 -f /dev/vdb1
sudo resize2fs /dev/vdb1

¿Y el volumen del sistema?

No es posible aumentar el tamaño del volumen del sistema.

Para Linux, Infomaniak ofrece 20 GB, lo cual es suficiente para cualquier distribución de Linux.

Para Windows, Infomaniak ofrece 100 GB en el disco C, lo cual es suficiente para Windows. Las aplicaciones deben instalarse en la unidad D. Si dispone de 50 GB, puede solicitar 100 GB (póngase en contacto con el soporte de Infomaniak e indique un horario para la operación, ya que habrá unos minutos de interrupción).

Esta guía explica cómo instalar y configurar systemd en un Servidor Cloud y presenta los comandos principales que se pueden utilizar.

Requisitos previos

• Siga la guía de instalación de systemd para Servidor Cloud.
• Consulte la documentación oficial para conocer todas las posibilidades que ofrece systemd.
• Los archivos «unit» deben colocarse en: ~/.config/systemd/user/ ( /home/clients/absolute-path-id/.config/systemd/user ) (reemplace absolute-path-id, que puede ver en su panel de control) y los permisos deben configurarse en 0644.
• El parámetro --user debe indicarse en cada comando.

Comandos principales

A continuación, se muestra una lista no exhaustiva de comandos que se pueden utilizar con systemd.

Obligar a systemd a volver a leer los archivos de unidad y a tener en cuenta las modificaciones:

systemctl --user daemon-reload

Activación de un servicio:

systemctl --user enable --now SERVICENAME.service

Comprobación del estado de un servicio:

systemctl --user status SERVICENAME.service

Configuración de Node como servicio con systemd

Será necesario crear un archivo "Unit" con la extensión ".service", que deberá guardarse en el directorio:

~/.config/systemd/user/

Es posible reutilizar el ejemplo siguiente sustituyendo los valores que comienzan por {}:

[Unit]
Description={Le nom du service} # Spécifier ici un nom du service. Celui-ci est obligatoire mais n'a pas d'impact sur le fonctionnement
[Service]
Restart=always
Environment=NODE_VERSION={la version souhaitée} # Spécifier ici la version de Node à utiliser. S'assurer qu'elle soit installée au préalable avec "nvm install {la version souhaitée}"
WorkingDirectory=%h/{repertoire du projet Node} # %h correspond à la racine de l'hébergement
ExecStart=/bin/bash -c "exec $HOME/.nvm/nvm-exec {commande de lancement du script node}" # Cette commande dépend du projet. Par exemple, "npm run start", "npm run serve" ou encore "node server.js" sont courants
[Install]
WantedBy=default.target

Otras acciones con un archivo Unit

systemctl --user daemon-reload

Iniciar el servicio (si ya está activo, no ocurrirá nada):

systemctl --user start [Nom du Unit]

Detener el servicio (si no está activo, no ocurre nada):

systemctl --user stop [Nom du Unit]

Reiniciar el servicio (si no está en ejecución, se inicia):

systemctl --user restart [Nom du Unit]

Obtener información sobre el servicio; en concreto:

• "Activo", que indica si el servicio está en funcionamiento y desde cuándo.
• "CGroup" muestra el grupo de procesos que gestiona el servicio, lo que permite ver los procesos activos, junto con sus argumentos y su ID.

Debajo de "CGroup" se encuentran los posibles registros (la salida estándar y de error del proceso):

systemctl --user status [Nom du Unit]

Activar el inicio automático del servicio al arrancar el servidor; NB: esto no inicia el servicio:

systemctl --user enable [Nom du Unit]

Desactivar el inicio automático del servicio al arrancar el servidor; NB: esto no detiene el servicio:

systemctl --user disable [Nom du Unit]

Configuración con las entradas de usuario:

[Unit]
Description="nom service"
[Service]
Restart=always
Environment=NODE_VERSION=16.17
WorkingDirectory=%h/sites/"nom-repertoire-site"/
ExecStart=/bin/bash -c "exec $HOME/.nvm/nvm-exec npm run start"
[Install]
WantedBy=default.target

Esta guía explica cómo modificar las variables de la extensión PHP-CLI, que está disponible de forma predeterminada en el Servidor Cloud de Infomaniak.

Modificar las variables PHP_CLI

Para acceder a las extensiones PHP del Servidor Cloud:

1. Haga clic aquí para acceder a la gestión de su Servidor Cloud en el Manager de Infomaniak (¿necesita ayuda?).
2. Haga clic directamente en el nombre asignado al Servidor Cloud correspondiente.
3. Haga clic en Extensiones PHP en el menú lateral izquierdo.
4. Haga clic en el menú de acción ⋮ a la derecha de PHP-CLI en la tabla que se muestra.
5. Haga clic en Configurar:
   
6. Modifique las siguientes variables: allow_url_fopen, allow_url_include, memory_limit, max_execution_time, short_open_tag, allow_local_infile
7. Haga clic en el botón azul Guardar.

Esta guía explica cómo conectarse a Elasticsearch después de haberlo instalado en Magento desde un Servidor Cloud de Infomaniak.

Requisitos previos

• Tener un Servidor Cloud de Infomaniak.
• Instalar Magento.
• Contacte con el servicio de asistencia de Infomaniak para la instalación de Elasticsearch.

Información de inicio de sesión

Una vez que haya iniciado sesión en su espacio de Magento, deberá indicar la siguiente información para iniciar Elasticsearch:

• Nombre de host: localhost o 127.0.0.1
• Puerto: 9200
• Prefijo: magento2

Esta guía presenta varios ejemplos de uso de Varnish en Servidor Cloud de Infomaniak.

Introducción

• Consulte estos recursos adicionales sobre el lenguaje de configuración de Varnish (VCL) para dominar el procesamiento de solicitudes, el enrutamiento y el almacenamiento en caché:
  • Tutorial de VCL
  • Guía del usuario de VCL
  • Referencia de VCL

Configuración de Varnish

Una vez instalado, la configuración de Varnish se basa en reglas precisas de almacenamiento en caché y de limpieza de la caché. Asegúrese de restringir el acceso para evitar que entidades no autorizadas puedan vaciar su caché.

Aquí tiene un ejemplo de archivo de configuración que incluye los casos de uso más frecuentes:

vcl 4.0;

# Default backend configuration
backend default {
    .host = "127.0.0.80";  # Backend IP address
    .port = "80";           # Backend port
}

# Access Control List (ACL) for purge authorization
acl purge {
    "localhost";            # Local access
    "1.2.3.4";              # Trusted home IP
    "42.42.42.0"/24;        # Trusted company range
    ! "42.42.42.7";         # Specific IP exclusion (e.g., problematic user)
}

# Handle incoming requests
sub vcl_recv {
    # Handle PURGE requests
    if (req.method == "PURGE") {
        # Check if client IP is authorized
        if (!client.ip ~ purge) {
            return (synth(405, "IP not authorized for PURGE requests."));
        }
        return (purge);
    }

    # Custom PURGEALL for image directory
    if (req.method == "PURGEALL" && req.url == "/images") {
        if (!client.ip ~ purge) {
            return (synth(405, "IP not authorized for PURGEALL requests."));
        }
        # Invalidate all image-related objects in cache
        ban("req.url ~ \.(jpg|png|gif|svg)$");
        return (synth(200, "Images purged."));
    }

    # Bypass cache for authorized requests (e.g., admin panels)
    if (req.http.Authorization) {
        return (pass);
    }
}

# Handle backend responses before caching
sub vcl_backend_response {
    # Set TTL for images to 1 day
    if (beresp.http.content-type ~ "image") {
        set beresp.ttl = 1d;
    }

    # Respect backend's "uncacheable" instruction
    if (beresp.http.uncacheable) {
        set beresp.uncacheable = true;
    }
}

Purgado a través de la interfaz de línea de comandos

Una vez que sus reglas estén activas, puede probar el purgado de su sitio (por ejemplo, "domain.xyz") utilizando la herramienta curl:

# Purge the homepage
$ curl -X PURGE {{URL_5}}

# Expected Varnish response
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged</title>
</head>
<body>
    <h1>Success 200: Purge completed</h1>
    <p>The page has been successfully purged.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 2</p>
    <hr>
    <p>Varnish Cache Server</p>
</body>
</html>

Para eliminar una URL específica, simplemente modifique la ruta de la solicitud:

# Purge a specific file
$ curl -X PURGE {{URL_6}}

# Expected Varnish response
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged</title>
</head>
<body>
    <h1>Success 200: Purge completed</h1>
    <p>The file has been successfully purged.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 4</p>
    <hr>
    <p>Varnish Cache Server</p>
</body>
</html>

O para iniciar la eliminación masiva de las imágenes definidas en el VCL:

# Execute PURGEALL for images
$ curl -X PURGEALL {{URL_7}}

# Expected Varnish response
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged images</title>
</head>
<body>
    <h1>Success 200: Images purged</h1>
    <p>All images have been successfully purged.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 32770</p>
    <hr>
    <p>Varnish Cache Server</p>
</body>
</html>

Purgado desde un CMS (PHP)

La gestión de la caché también se puede realizar de forma dinámica a través de su panel de administración. En la configuración anterior, se añadió un control sobre la cabecera Uncacheable. Su CMS puede enviar esta cabecera para obligar a Varnish a no almacenar una respuesta.

A continuación, se muestra cómo enviar una solicitud de purga programática en PHP:

<?php
// Initialize cURL for a specific URL
if ($curl = curl_init("{{URL_8}}")) {
    curl_setopt_array($curl, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CUSTOMREQUEST => "PURGE",
        CURLOPT_HTTPHEADER => [
            "Host: {$_SERVER['HTTP_HOST']}" // Match the target host
        ]
    ]);

    curl_exec($curl);
    
    // Check if the purge was successful (HTTP 200)
    if (curl_getinfo($curl, CURLINFO_HTTP_CODE) == 200) {
        echo "Cache purged!";
    }
    curl_close($curl);
}
?>

Esta guía explica cómo realizar una copia de seguridad de los datos de WordPress en un espacio de copia de seguridad Swiss Backup, la solución de copia de seguridad en una nube suiza independiente.

Introducción

• Si las copias de seguridad ofrecidas por Infomaniak no se ajustan o ya no se ajustan a sus necesidades en términos de disponibilidad o seguridad, o si su sitio web está alojado en otro lugar, sus datos podrán guardarse mediante una conexión S3 Compatible en los servidores de Infomaniak; así tendrá la seguridad de no perder nada.

Instalar y configurar la extensión UpdraftPlus

Requisitos previos

• Tener un espacio de Swiss Backup de Infomaniak con una cuota de dispositivo disponible (mínimo 1) para una copia de seguridad de iCloud.
• Añadir 1 dispositivo de tipo Cloud para obtener los parámetros compatibles con S3.

A continuación:

1. Añada la extensión de WordPress UpdraftPlus, que ofrece la posibilidad de realizar copias de seguridad de los datos de WordPress en una ubicación compatible con S3.
2. Haga clic en Configuración y, a continuación, en Copias de seguridad de UpdraftPlus:
   
3. Haga clic en Configuración y, a continuación, en Compatible con S3 (Genérico):
   
4. Más abajo, complete los campos según la información específica de su dispositivo.
   
5. A continuación, se muestra el tipo de información que debe tener a mano y que debe especificar en los diferentes campos para crear la conexión:
   

A continuación, podrá programar sus copias de seguridad a intervalos regulares.

Descargar la copia de seguridad manualmente

Las copias de seguridad realizadas a través de UpdraftPlus - S3 se pueden recuperar mediante un cliente S3 compatible, como por ejemplo Cyberduck.

Restaurar una copia de seguridad de UpdraftPlus

Consulte esta guía oficial en inglés.

Esta guía trata sobre la creación de redes privadas entre diferentes ofertas de alojamiento de Infomaniak, como VPS Cloud / VPS Lite, Public Cloud, NAS Synology, etc.

Crear una VLAN entre VPS

Se recomienda migrar a la oferta Public Cloud para crear este tipo de redes privadas entre máquinas virtuales.

Esta guía se refiere al intercambio en Servidor Cloud.

Intercambio y memoria RAM

Puede haber uso de la memoria virtual (swap) incluso cuando el consumo de RAM es bajo. De hecho, el sistema puede utilizar la memoria virtual en cualquier momento si lo considera necesario.

La memoria virtual no es un espacio de memoria dedicado a ser utilizado solo cuando no hay RAM disponible, aunque este sea su uso principal.

Si desea obtener más información, existe un parámetro llamado "swappiness" que permite definir la forma en que el sistema utilizará el espacio de intercambio. El valor predeterminado es 60 y no se puede modificar.

La infraestructura de Infomaniak no transmite instrucciones de virtualización a los VPS Cloud / VPS Lite; por lo tanto, no es posible realizar virtualización anidada(virtualización que se ejecutaría dentro de un entorno ya virtualizado), ya que esto plantea problemas, especialmente durante las migraciones en vivo.

No obstante, puede…

• … crear una instantánea del servidor (copia de seguridad no automatizada)
• … realizar una copia de seguridad del servidor en Swiss Backup (copia de seguridad automatizada)

Esta guía explica cómo aprovechar las nuevas versiones de PHP, MySQL y muchos otros paquetes migrando un Servidor Cloud a una nueva infraestructura de Infomaniak.

Introducción

• La migración es gratuita y se realiza en 3 etapas:
  1. Infomaniak pone a su disposición un Servidor Cloud de última generación con las mismas características que el actual, al mismo precio y con la misma duración de contrato.
  2. Dispone de un mes para trasladar sus alojamientos al nuevo Servidor Cloud puesto a su disposición (véase más abajo).
  3. Cuando sus alojamientos se hayan trasladado al nuevo servidor, cancele el antiguo Servidor Cloud.
• Los accesos FTP y las bases de datos no cambian.
• En lo que respecta al alojamiento, solo cambian las versiones compatibles de PHP y MariaDB, así como las direcciones IPv4 e IPv6 del servidor.
• Los nombres de host no cambian y se actualizan automáticamente para que apunten a las nuevas direcciones IP.
• Durante esta operación, las estadísticas se restablecen.

Procedimiento de migración

Al migrar sus datos a la nueva infraestructura en la nube, aumentará el rendimiento y la fiabilidad de sus sitios web, que tendrán acceso a las últimas tecnologías:

1. Haga clic aquí para acceder a la gestión de su producto en el Panel de control de Infomaniak (¿necesita ayuda?).
2. Haga clic directamente en el nombre asignado al producto correspondiente.
3. Haga clic en el botón azul que se encuentra en el cuadro titulado "Mejore su Servidor Cloud" (o en Gestionar):
   

Infomaniak no proporciona acceso root a Servidor Cloud.

En cambio, el acceso root es posible en:

• VPS Cloud / VPS Lite
• Jelastic Cloud
• Nube pública

Esta guía explica cómo modificar la configuración de almacenamiento de un VPS Cloud / VPS Lite de Infomaniak.

Introducción

• Es necesarioampliar el volumen después de aumentar el espacio de almacenamiento.
• Las modificaciones de configuración (CPU/RAM) o de almacenamiento hacen que el servicio no esté disponible durante unos 20 minutos.

Modificar el tamaño del almacenamiento en VPS Cloud / VPS Lite

Para acceder al VPS Cloud / VPS Lite:

1. Haga clic aquí para acceder a la gestión de su producto en el Panel de control de Infomaniak (¿necesita ayuda?).
2. Haga clic en el menú de acciones ⋮ a la derecha del elemento correspondiente en la tabla que se muestra.
3. Haga clic en Modificar la oferta:
   
4. Realice los ajustes deseados entre las opciones disponibles y finalice el proceso en la parte inferior: