SQL Server FAQ: ¿Qué arquitectura de procesador (CPU) elegir para SQL Server? ¿32-bit o 64-bit? ¿x86, x64 ó IA64 Intel Itanium?
|
¿Qué arquitectura de procesador (CPU) elegir para SQL Server? ¿32-bit o 64-bit? ¿x86, x64 ó IA64 Intel Itanium? SQL Server está disponible en distintas arquitecturas de procesador (CPU). Sin embargo, la elección de una arquitectura de procesador para SQL Server implica también su elección para el hardware y para el sistema operativo, con el correpondienten impacto en costes. Además, la elección de una arquitectura de procesador, puede implicar ciertas limitaciones de utilización del producto (direccionamiento de memoria, disponibilidad de drivers de Sistema Operativo, Conectividades - ODBC, OLEDB, .Net Providers, etc. -, disponibilidad de iFilters, disponibilidad de software, etc.). Entonces ¿Qué arquitectura de procesador me interesa para mi SQL Server? |
Antes de instalar SQL Server, podemos elegir la arquitectura sobre la que construir nuestra infraestructura de base de datos. En el caso de SQL Server 2000 podemos elegir entre x86 e Itanium (IA64 - 64 bits), ya que no es posible montarlo sobre arquitectura de 64-bit de x64. En el caso de SQL Server 2005, podemos elegir entre arquitecturas de procesador CPU x86 (32 bits), x64 (64 bits) e IA64 (64 bits).
Lo primero que debemos elegir es el Sistema Operativo. La mejor manera de sacar el mejor provecho a SQL Server es elegir una arquitectura de Sistema Operativo congruente con nuestra elección de motor de base de datos (ej: Windows Server 2003 x64 y SQL Server 2005 x64) y arquitectura de procesador CPU (es decir, el "hierro"... en éste ejemplo, x64 de Intel o de AMD ;-).
Es posible montar sobre una arquitectura de procesador CPU x64 (64 bit), una edición de Windows x86 (32 bit), algo de hecho muy habitual, por costes (la pela es la pela.... jeje ;-). La arquitectura x64 es la única excepción (al tratarse de la evolución de x86, ya que Itanium IA64 es una arquitectura totalmente distinta), pues habitualmente, cada arquitectura de procesador requiere de una compilación acorde (en Itanium IA64 sólo podremos montar software para Itanium, y en x86 sólo podremos montar software para x86). Esto es un caso especial, pues en una máquina (es decir, el "hierro") x64 podemos montar Windows x86 (32 bit) y software x86 de 32 bits, o bien podemos montar Windows x64 (64 bits) y software x64 o software x86 (este último se ejecutará emulando 32 bits, en lo que se llama WoW - Windows on Windows). Un detalle... en x64 tenemos dos administradores de ODBC... el de 64 bits y el de 32 bits !!
Realizada esta pequeña introducción, ahora queda lo más importate ¿qué factores determinan la elección de una arquitectura de procesador (CPU) u otra? Alla vamos...
- Direccionamiento de memoria. En arquitecturas x86 de 32 bit, la memoria que un proceso de Windows puede direccionar está limitada a 2GB. Para poder direccionar más memoria en SQL Server, es necesario utilizar AWE, un API que permite realizar una "paginación" entre zonas de memoria visibles por el proceso de SQL Server (los 2GB que háblabamos) y zonas de memoria no visibles (por encima de los 2GB de memoria). Esto en su día estaba muy bien, pero a fecha de hoy, poco sentido tiene, además de que dicha paginación aunque rápida (es en memoria) existe, y evitarla con un direccionamiento de memoria lineal siempre será una mejora. Por ello, si deseamos o necesitamos direccionar grandes cantidades de memoria, es interesante utilizar versiones de Windows y de SQL Server de 64 bits (x64 ó Itanium IA64).
- Drivers del Sistema Operativo. Si elegimos un hardware y Sistema Operativo de 64 bits (ej: x64 o Itanium IA64) es importante que dispongamos de todos los drivers para dicha arquitectura para sacar el mayor provecho (drivers de VGA, de tarjetas de fiber channel para el Almacenamiento SAN, de red, etc.).
- Disponibilidad de conectividades (ODBC, OLEDB, .Net Providers, etc.). Si desde una edición de SQL Server (ej: x64) deseamos utilizar conectividades con otros motores, será necesario disponer de los correspondientes drivers para dicha arquitectura. Si esto es requisito, por existencia de alguna aplicación de nuestra empresa, es interesante considerarlo a priori (mejor que a posteriori, verdá !! ;-)
- Disponibilidad de iFilters. No hay duda de que la Búsqueda de Texto Completo (Full Text Search) es una funcionalidad muy interesante de SQL Server (bien aprovechada por Sharepoint, por cierto). Sin embargo, cuando deseamos poder indexar documentos fuera de lo habitual, necesitamos de los correspondientes iFilters (para PDF, para AutoCad, etc.). Bien, pues también es interesante de que nos preocupemos de que tenemos disponibilidad de los iFilters que necesitamos para la arquitectura que deseamos utilizar (y a priori... que a posteriori lo hace cualquiera ;-)
- Disponibilidad de software adicional. En toda empresa que se precie (incluso en las que no), se suele utilizar una serie de aplicaciones corportivas que puede ser requisito que montemos (antivirus corporativo, software de monitorización, cliente de backup, etc.). Es importante comprobar que tenemos disponibilidad de dicho software para el sistema que deseamos instalar, para lo cual, es importante verificar las versiones (quizás sea necesario subir la versión del software de Backup, y ésto a su vez implique un trabajo considerable en función del parking de máquinas de la empresa.... en fin... nuestro día a día... jeje ;-) Como siempre, vamos a comprobarlo a priori... que a posteriori lo hace cualquiera !!
Otro tema, es la edición particular de SQL Server y de Windows, en función de la necesidad de determinadas funcionalidades (ej: clustering MSCS requiere Windows Server 2003 Enterprise) y aprovechamiento de hardware (límites de procesadores y memoria, principalmente).
Para entornos de desarrollo, por favor, comprobar el precio de SQL Server 2000 Developer y/o SQL Server 2005 Developer, en vuestro proveedor de software adicional o en Amazon o dónde sea !! La edición Developer es igual en funcionalidad que la Enterprise, pero cuesta sólo 40 euros y se puede conseguir incluso en Amazon. Si no tuviera mi suscripción MSDN, ya me la habría comprado para casa !!! Si comparáis el precio de SQL Server Developer con un Enterprise... en fin... la idea al final es facilitar a la creación de entornos de desarrollo (ej: empresas fabricantes de software), puesto que el objetivo de todo software que se desarrolla es que se pase a producción (y es en ese punto dónde Microsoft si exige el coste de licencia... ). Más que razonable, ¿o no?.
En cualquier caso, el precio junto con el contrato particular que se tenga establecido con Microsoft, puede ser un factor relevante. También se paga el hecho de "ser el primero".... es decir, resulta más fácil sentirse confortable con una edición x86 o x64 que con Itanium, puesto que existen muchas más instalaciones en el mundo x86 ó x64 que Itanium, y esto repercute en un producto mucho más probado (tanto Windows como SQL Server). Por contra, los servidores más grandes son arquitecturas Itanium, máquinas en las que podemos encontrar ediciones Windows DataCenter, certificadas por Microsoft y pre-instaladas por el fabricante de hardware (HP, Unisys, etc.). |
|
|
|