Debido a la voracidad de los sistemas Windows, los VPS dominan distribuciones ligeras de Linux: Mint, Colibri OS, Debian o Ubuntu, que carecen del entorno de escritorio pesado y innecesario para nuestras tareas. ¡Como se dice, solo consola, solo hardcore! Y de hecho, esto no es una exageración: el mismo Debian arranca con 256 MB de memoria y un núcleo a 1 GHz, es decir, casi en cualquier "madera podrida". Para trabajar cómodamente se necesitan al menos 512 MB y un procesador un poco más ágil. Pero, ¿qué pasaría si te dijéramos que se puede hacer algo similar en un VPS con Windows? Que no es necesario instalar un pesado Windows Server, que requiere de tres a cuatro gigabytes de RAM y al menos un par de núcleos a 1.4 GHz. Simplemente usa Windows Server Core: deshazte de la GUI y de algunas de las funciones. De eso hablaremos en este artículo.
¿Quién es este Windows Server Core?
No hay información clara sobre qué es Windows (server) Core, ni siquiera en el sitio oficial de Microsoft; de hecho, está tan confuso que no se entiende de inmediato, pero las primeras menciones datan de la época de Windows Server 2008. En esencia, Windows Core es un núcleo operativo de Windows Server (¡sorpresa!), "adelgazado" al tamaño de su propia GUI y aproximadamente la mitad de sus servicios secundarios.
La característica principal de Windows Core es que no es exigente con el hardware y tiene un manejo completamente por consola a través de PowerShell.
Si visitas el sitio de Microsoft y revisas los requisitos técnicos, necesitarás al menos 2 GB de RAM y un núcleo a 1.4 GHz para iniciar Windows Server 2016/2019. Pero todos entendemos que con esa configuración solo podemos esperar iniciar el sistema, pero definitivamente no tener un funcionamiento cómodo de nuestro sistema operativo. Por esta razón, para trabajar con Windows Server generalmente se asigna más memoria y al menos 2 núcleos/4 hilos del procesador, a menos que se les proporcione una máquina física costosa en algún Xeon, en lugar de una económica virtual.
Sin embargo, el núcleo del sistema servidor solo requiere 512 MB de memoria, y los recursos del procesador que consumía la GUI para simplemente mostrarse en pantalla y mantener en funcionamiento sus numerosos servicios pueden ser utilizados para algo más útil.
Aquí hay una comparación de los servicios soportados de forma nativa en Windows Core y un Windows Server completo desde el sitio oficial de Microsoft:
application
server core
server withdesktop experience
Command prompt
available
available
Windows PowerShell/ Microsoft .NET
available
available
Perfmon.exe
not available
available
Windbg (GUI)
compatible
available
Resmon.exe
not available
available
Regedit
available
available
Fsutil.exe
available
available
Disksnapshot.exe
not available
available
Diskpart.exe
available
available
Diskmgmt.msc
not available
available
Devmgmt.msc
not available
available
Server Manager
not available
available
Mmc.exe
not available
available
Eventvwr
not available
available
Wevtutil (Consultas de eventos)
available
available
Services.msc
not available
available
Panel de control
not available
available
Windows Update (GUI)
not available
available
Explorador de Windows
not available
available
Taskbar
not available
available
Notificaciones de la barra de tareas
not available
available
Taskmgr
available
available
Internet Explorer o Edge
not available
available
Sistema de ayuda integrado
not available
available
Shell de Windows 10
not available
available
Windows Media Player
not available
available
PowerShell
available
available
PowerShell ISE
not available
available
PowerShell IME
available
available
Mstsc.exe
not available
available
Servicios de escritorio remoto
available
available
Hyper-V Manager
not available
available
Como se puede ver, se han eliminado muchas cosas de Windows Core. Se han desechado servicios y procesos relacionados con la GUI del sistema, así como cualquier "basura" que seguramente no se necesitará en nuestra máquina virtual de consola, por ejemplo, Windows Media Player.
Casi como Linux, pero no es él
Es muy tentador comparar Windows Server Core con distribuciones de Linux, pero en realidad no es del todo correcto. Sí, estos sistemas son similares en cuanto a la reducción del consumo de recursos al prescindir de GUI y muchos servicios secundarios, pero en términos de explotación y algunos enfoques de construcción, sigue siendo Windows, no un sistema unix.
El ejemplo más sencillo es que, mediante la construcción manual del núcleo de Linux y la posterior instalación de paquetes y servicios, incluso la distribución de Linux más ligera puede convertirse en un peso pesado parecido a un cuchillo suizo (aquí realmente se me antoja hacer una broma sobre Python e insertar una imagen de la serie "Si los lenguajes de programación fueran armas", pero no lo haremos). En Windows Core, esa libertad es mucho menor, ya que, seguimos lidiando con un producto de Microsoft.
Windows Server Core se entrega como una compilación lista para usar, cuya configuración predeterminada se puede evaluar en la tabla anterior. Si necesita algo de la lista no compatible, tendrá que agregar los elementos faltantes en línea a través de la consola. Sin embargo, no hay que olvidar la función 'Feature on demand' y la posibilidad de descargar componentes como archivos CAB, que luego se pueden agregar a la compilación antes de la instalación. Pero este escenario no funciona si ya durante el funcionamiento descubre que le falta algún servicio eliminado.
Pero lo que diferencia claramente la versión Core de la completa es la capacidad de actualizar el sistema y agregar servicios sin detener el funcionamiento. Windows Core admite la instalación de paquetes "en caliente", sin reiniciar. Como resultado de observaciones prácticas: una máquina que ejecuta Windows Core necesita reiniciarse aproximadamente 6 veces menos que una que ejecuta Windows Server, es decir, una vez cada seis meses, en lugar de una vez al mes.
Un agradable bono para los administradores es que si se utiliza el sistema como se pensó, es decir, a través de la consola, sin RDP, y no se convierte en un segundo Windows Server, se vuelve extremadamente seguro en comparación con la versión completa. La mayoría de las vulnerabilidades de Windows Server provienen precisamente de RDP y de las acciones del usuario que, a través de este mismo RDP, hace lo que no debería. Es algo parecido a la historia de Henry Ford y su relación con el color del automóvil: «Cualquier cliente puede tener su automóvil pintado de cualquier color que desee, siempre que sea negro». Así es con el sistema: el usuario puede comunicarse con el sistema de cualquier manera, siempre que lo haga a través de consola.
Instalación y gestión de Windows Server 2019 Core
Anteriormente mencionamos que Windows Core es, de hecho, Windows Server sin la envoltura de GUI. Es decir, puedes usar casi cualquier versión de Windows Server como versión core, es decir, prescindir de la GUI. Para los productos de la familia Windows Server 2019, hay 3 de 4 compilaciones de servidor: el modo core está disponible para Windows Server 2019 Standard Edition, Windows Server 2019 Datacenter y Hyper-V Server 2019; en esta lista, solo se excluye Windows Server 2019 Essentials.
El paquete de instalación de Windows Server Core no necesita ser buscado en particular. En el instalador estándar de Microsoft, la versión core se ofrece literalmente por defecto, mientras que la versión con GUI debe seleccionarse manualmente:
Las opciones para gestionar el sistema, en realidad, son más que la única mencionada PowerShell, que se ofrece por defecto. Se puede gestionar una máquina virtual en Windows Server Core de al menos cinco maneras diferentes:
- PowerShell Remoto;
- Herramientas de Administración Remota del Servidor (RSAT);
- Centro de Administración de Windows;
- Sconfig;
- Administrador del Servidor.
Los primeros tres elementos son los más interesantes: PowerShell estándar, RSAT y Centro de Administración de Windows. Sin embargo, es importante entender que al obtener las ventajas de una de las herramientas, también se imponen limitaciones.
No vamos a detallar las capacidades de la consola, PowerShell es PowerShell, con sus evidentes ventajas y desventajas. Con RSAT y WAC, la situación es un poco más complicada.
WAC proporciona acceso a elementos de control del sistema importantes, como la edición del registro y la gestión de discos y dispositivos. RSAT, en el primer caso, solo funciona en modo de vista y no permitirá realizar cambios, y para gestionar discos y dispositivos físicos, las Herramientas de Administración de Servidores Remotos necesitan una GUI, lo cual no es nuestro caso. En general, RSAT no puede trabajar con archivos y, por lo tanto, no puede realizar actualizaciones, ni instalar o desinstalar programas en la edición del registro.
▍Gestión del sistema
WAC
RSAT
Gestión de componentes
Sí
Sí
Editor del registro
Sí
No
Gestión de red
Sí
Sí
Visor de eventos
Sí
Sí
Carpetas compartidas
Sí
Sí
Gestión de discos
Sí
Solo para servidores con GUI
Programador de tareas
Sí
Sí
Gestión de dispositivos
Sí
Solo para servidores con GUI
Gestión de archivos
Sí
No
Gestión de usuarios
Sí
Sí
Gestión de grupos
Sí
Sí
Gestión de certificados
Sí
Sí
Actualizaciones
Sí
No
Desinstalación de programas
Sí
No
Monitor del sistema
Sí
Sí
Por otro lado, RSAT nos brinda control total sobre los roles en la máquina, mientras que Windows Admin Center no puede hacer literalmente nada en este aspecto. Aquí hay una comparación de las capacidades de RSAT y WAC en este aspecto, para mayor claridad:
▍Gestión de roles
WAC
RSAT
Advanced Thread Protection
PREVIO
No
Windows Defender
PREVIO
Sí
Contenedores
PREVIO
Sí
Centro Administrativo de AD
PREVIO
Sí
Dominios y confianzas de AD
No
Sí
Sitios y servicios de AD
No
Sí
DHCP
PREVIO
Sí
DNS
PREVIO
Sí
Administrador DFS
No
Sí
Administrador de GPO
No
Sí
Administrador de IIS
No
Sí
Es decir, ya es evidente que al renunciar a la GUI y PowerShell en favor de otros elementos de control, no se puede escapar utilizando una herramienta única: para una administración completa en todos los frentes necesitaremos al menos una combinación de RSAT y WAC.
Además, hay que tener en cuenta que utilizar WAC implica un coste de 150-180 megabytes de memoria RAM. Windows Admin Center crea 3-4 sesiones en el lado del servidor al conectarse, que no se cierran incluso al desconectar la herramienta de la máquina virtual. También, WAC no funciona con versiones antiguas de PowerShell, por lo que necesitas al menos PowerShell 5.0. Todo esto va en contra de nuestra paridad de ahorro de recursos, pero hay que pagar por la comodidad. En nuestro caso, con memoria RAM.
Otra opción para gestionar Server Core es instalar una GUI mediante medios de terceros, para no cargar con esas toneladas de basura que vienen en una compilación completa junto con la interfaz.
En este caso, tenemos dos opciones: implementar el Explorer original en el sistema o utilizar Explorer++. Como alternativa al último, cualquier gestor de archivos servirá: Total Commander, FAR Manager, Double Commander, etc. La última opción es preferible si la economía de memoria RAM es crítica para usted. Puede añadir Explorer++ o cualquier otro gestor de archivos creando una carpeta de red y lanzándolo a través de la consola o del programador.
Instalar un Explorer completo nos dará más posibilidades en términos de trabajar con software dotado de interfaz de usuario. Para ello, a la característica de compatibilidad de aplicaciones del Server Core llamada Feature on Demand (FOD), que devolverá al sistema MMC, Eventvwr, PerfMon, Resmon, Explorer.exe e incluso Powershell ISE. Sin embargo, esto tendrá un costo, como en el caso del WAC: perderemos sin remedio alrededor de 150-200 megabytes de memoria RAM, que el explorer.exe y otros servicios consumirán sin piedad. Incluso si no hay un usuario activo en la máquina.
Así es como se ve el consumo de memoria del sistema en máquinas con el paquete Explorer nativo y sin él.
Surge la pregunta inevitable: ¿para qué todas estas acrobacias con PowerShell, FOD y gestores de archivos, si cualquier paso en cualquier dirección conduce a un aumento en el consumo de memoria RAM? ¿Por qué engrosarse con un montón de herramientas y andar de un lado a otro para asegurarse un trabajo cómodo en Windows Server Core, cuando se puede simplemente instalar Windows Server 2016/2019 y vivir como un ser humano?
Hay varias razones para utilizar Server Core. La primera: su consumo de memoria es casi la mitad. Si recuerdas, esta condición fue la base de nuestro artículo desde el principio. Aquí tienes una comparación del consumo de memoria en Windows Server 2019, compáralo con las capturas de pantalla un poco más arriba:
Y aquí, 1146 MB de memoria consumida en lugar de 655 MB en Core.
Si asumimos que no necesitarás WAC y estarás utilizando Explorer++ en lugar del Explorer original, entonces seguirás ganando casi medio hectárea en cada máquina virtual que ejecute Windows Server. Si solo hay una máquina virtual, la ganancia es insignificante, pero ¿y si hay cinco? Aquí ya la presencia de GUI tiene importancia, especialmente si no la necesitas.
En segundo lugar, cualquier intento de modificar Windows Server Core no resolverá el problema principal de la gestión de Windows Server: RDP y su seguridad (es decir, su total ausencia). Windows Core, incluso con complementos como FOD, RSAT y WAC, sigue siendo un servidor sin RDP, lo que significa que no está expuesto al 95% de los ataques existentes.
En el saldo
En general, Windows Core es solo un poco más "pesado" que cualquier distribución de Linux estándar, pero es mucho más funcional. Si necesita liberar recursos y está dispuesto a trabajar con la consola, WAC y RSAT, utilizando administradores de archivos en lugar de un GUI completo, vale la pena considerar Core. Aún más, ya que le permitirá no pagar por una versión completa de Windows, y el dinero ahorrado puede usarse para aumentar su , agregando, por ejemplo, más RAM. Para su conveniencia, hemos añadido Windows Server Core a nuestro .
Fuente: habr.com
