• Ventas: 1-800-961-2888
  • Servicio: 1-800-961-4454

Conceptos y prerrequisitos de instalación de la Rackspace Private Cloud


Este capítulo enumera los prerrequisitos para instalar un clúster con las herramientas de Rackspace Private Cloud. Rackspace le recomienda que revise este capítulo en detalle antes de comenzar con la instalación.

Contenidos

Requisitos de hardware
Requisitos del servidor Chef
Requisitos de los nodos del clúster
Requisitos de software
Requisitos de Internet
Requisitos de red
Redes en los cookbooks de Rackspace Private Cloud
Prepararse para la instalación
Consideraciones de acceso de instancias en nova-network
Consideraciones de proxy
Ajustar las configuraciones del ambiente de proxy en los nodos
Evaluar las configuraciones de proxy
Disponibilidad alta
Zonas de disponibilidad

Requisitos de hardware

Rackspace ha evaluado la implementación de Rackspace Private Cloud con un dispositivo físico para cada uno de los siguientes nodos:

  • Un servidor Chef
  • Un nodo de controlador de OpenStack Nova
  • Máquinas físicas adicionales con nodos de cómputo de OpenStack Nova, según sea necesario

Si tiene requisitos diferentes para su ambiente, comuníquese con Rackspace.

Requisitos del servidor Chef

Rackspace recomienda que el hardware del servidor Chef cumpla con los siguientes requisitos:

  • RAM de 4 GB
  • Espacio de disco de 50 GB
  • CPU de doble socket con núcleo doble

Requisitos de los nodos del clúster

Cada nodo en el clúster tendrá instalado chef-client. Los requisitos de hardware varían según el fin del nodo. Cada dispositivo debe admitir VT-x. Consulte el siguiente cuadro con los requisitos detallados.

Tipo de nodo Requisitos
Controlador de Nova
  • RAM de 16 GB
  • Espacio de disco de 144 GB
  • CPU de doble socket con núcleo doble o de socket único con núcleo cuádruple
Cómputo de Nova
  • RAM de 32 GB
  • Espacio de disco de 144 GB
  • CPU de doble socket con núcleo doble o de socket único con núcleo cuádruple

La sobreasignación de CPU está fijada en 16:1 VCPU a núcleos, y la sobreasignación de memoria está establecida en 1.5:1. Cada núcleo físico puede admitir hasta 16 núcleos virtuales; por ejemplo, un procesador con núcleo doble puede admitir hasta 32 núcleos virtuales. Si necesita más núcleos virtuales, agregue nodos físicos adicionales a su configuración.

Para ver una lista de dispositivos certificados para Private Cloud, consulte Dispositivos certificados para Private Cloud - Cómputo.

Requisitos de software

El siguiente cuadro enumera los sistemas operativos en los que Rackspace Private Cloud se ha probado.

Sistema operativo Versión de Rackspace Private Cloud probada
Ubuntu 12.04 Todas las versiones
Ubuntu 12.10 y posteriores Ninguna
CentOS 6.3 v4.0.0 y anteriores
CentOS 6.4 v4.1.2 y posteriores
CentOS 6.5 v4.2.2 y posteriores
Red Hat Enterprise Linux 6.0 Ninguna

Es posible instalar Rackspace Private Cloud en sistemas operativos que no han sido probados, pero esto puede causar problemas inesperados.

Si necesita OpenStack Networking, Rackspace le recomienda que use Rackspace Private Cloud v4.2.2 con CentOS 6.4 o Ubuntu 12.04 para los nodos de controlador y de redes.

Se han probado los siguientes kernels:

  • linux-image-3.8.0-38-generic
  • linux-image-3.2.0-58-generic 
  • kernel-2.6.32-358.123.2.openstack.el6.x86_64

Requisitos de Internet

Se requiere acceso a Internet para completar la instalación, así que asegúrese de que los dispositivos que usa tengan acceso a Internet para descargar los archivos de instalación.

Requisitos de red

Una red implementada con los cookbooks de Rackspace Private Cloud usa nova-network por defecto, pero OpenStack Networking (Neutron, anteriormente llamado Quantum) se puede habilitar de manera manual. Con fines de prueba de concepto y demostración, nova-network será adecuada, pero si tiene pensado construir un clúster de producción y requiere redes definidas por software por cualquier razón, debe usar OpenStack Networking, que está diseñado como un reemplazo de nova-network.

Si desea usar OpenStack Networking para su nube privada, tendrá que especificarlo en su ambiente Chef y configurar los nodos de manera apropiada. Vea Configurar OpenStack Networking para obtener información detallada acerca de los conceptos de OpenStack Networking e instrucciones para configurar OpenStack Networking en su ambiente.

Redes en los cookbooks de Rackspace Private Cloud

Los cookbooks están construidos en base a los siguientes supuestos:

  • Las direcciones de IP de la infraestructura son fijas.
  • Las terminales de enlace para los servicios se describen mejor por las redes a las que están conectadas.

Los cookbooks contienen definiciones para tres redes generales y qué servicios se enlazan a ellas. Estas redes están definidas por el rango CIDR, y se supone que cualquier interfaz de red con una dirección dentro del rango CIDR nombrado se incluya en esa red. Puede especificar el mismo CIDR para múltiples redes; por ejemplo, las redes nova y management pueden compartir un CIDR.

El siguiente cuadro enumera las redes y los servicios que se enlazan a la dirección de IP dentro de cada una de estas redes generales.

Red Servicios
nova
  • keystone-admin-api
  • nova-xvpvnc-proxy
  • nova-novnc-proxy
  • nova-novnc-server
public
  • graphite-api
  • keystone-service-api
  • glance-api
  • glance-registry
  • nova-api
  • nova-ec2-admin
  • nova-ec2-public
  • nova-volume
  • neutron-api
  • cinder-api
  • ceilometer-api
  • horizon-dash
  • horizon-dash_ssl
management
  • graphite-statsd
  • graphite-carbon-line-receiver
  • graphite-carbon-pickle-receiver
  • graphite-carbon-cache-query
  • memcached
  • collectd
  • mysql
  • keystone-internal-api
  • glance-admin-api
  • glance-internal-api
  • nova-internal-api
  • nova-admin-api
  • cinder-internal-api
  • cinder-admin-api
  • cinder-volume
  • ceilometer-internal-api
  • ceilometer-admin-api
  • ceilometer-central

La configuración le permite tener múltiples interfaces o subinterfaces separadas por VLAN. Puede crear interfaces con etiquetado VLAN en la configuración de nova-network (con puentes Linux) o en Neutron (con OVS). También es posible la implementación de una NIC única. Las configuraciones de NIC múltiples y de NIC única se describen en Configurar OpenStack Networking.

Prepararse para la instalación

Necesita la siguiente información para la instalación:

  • La dirección de red nova en formato CIDR
  • El puente de red nova, como br100 o eth0. Esto se usará como el puente de VM en los nodos de cómputo. Por lo general, el valor predeterminado es aceptable. Este puente será creado por Nova según sea necesario y no necesita ser configurado de forma manual.
  • La dirección de red pública en formato CIDR. Aquí es donde se ejecutarán los servicios de API públicos, como la terminal Keystone pública y el panel. Una dirección de IP de esta red debe configurarse en todos los hosts del clúster de Nova.
  • La interfaz de red pública, como eth0 o eth1. Esta es la interfaz de red que se conecta a la red pública (Internet/WAN) en los nodos de cómputo. En una configuración de nova-network, los nodos de cómputo con NAT de tráfico de instancias fuera de esta interfaz a menos que una dirección de IP flotante específica haya sido asignada a esa instancia.
  • La dirección de red de administración en formato CIDR. Esta red se usa para la comunicación entre servicios como monitoreo y syslog. Esta puede ser la misma que su red pública Nova si no desea separar el tráfico de servicio.
  • El rango CIDR de la red de VM. Este el rango desde el que las direcciones de IP serán asignadas automáticamente a VM. Se podrá visualizar una dirección para esta red desde dentro de su instancia en eth0. Esta red debe estar destinada a OpenStack y no se debe compartir con otros servicios.
  • La interfaz de red de la red de VM para los nodos de cómputo (como eth1).
  • El nombre del clúster de Nova. Este debe ser único e incluir caracteres alfanuméricos, guiones (-) o guiones bajos (_).
  • El nombre de la zona de disponibilidad predeterminada. Rackspace recomienda usar nova como la predeterminada.
  • Para las configuraciones de nova-network, un rango o rangos CIDR con excepción NAT opcionales para redes configuradas con una DMZ. Una lista de los rangos de red CIDR separados por coma que se excluirán de las reglas de NAT. Esto posibilita la comunicación directa desde y hacia instancias de otros rangos de red sin el uso de IP flotantes.

Consideraciones de acceso de instancias en nova-network

En una configuración nova-network, por defecto, las instancias que crea en el clúster de OpenStack se pueden acceder públicamente vía NAT solo al asignarles direcciones de IP flotantes. Antes de asignar una dirección de IP flotante a una instancia, debe contar con un conjunto de direcciones para elegir. Su equipo de seguridad de red debe proporcionar un rango de direcciones y asignarlo a su ambiente. Estas direcciones deben tener un acceso público. Las direcciones de IP flotantes no se especifican durante el proceso de instalación. Podrá agregarlas con el comando nova-manage floating create --ip_range una vez que el nodo de controlador esté en funcionamiento. Consulte "Administrar direcciones de IP flotantes".

También puede hacer que las instancias sean accesibles para otros hosts en la red predeterminada al configurar la nube con una DMZ de red. El rango de DMZ de red no puede ser el mismo que el rango de red nova. Al especificar una DMZ, se habilita el tráfico de red sin NAT entre las instancias de máquinas virtuales y los recursos fuera de la red nova fija. Por ejemplo, si la red nova fija es 10.1.0.0/16 y especifica una DMZ de 172.16.0.1/12, cualquier dispositivo o host en ese rango se podrá comunicar con las instancias de la red nova fija.

Para usar la DMZ, debe tener al menos dos NIC en los servidores de implementación. Una NIC debe estar destinada a las instancias de VM.


Consideraciones de proxy

En general, las instrucciones de instalación de Rackspace Private Cloud suponen que ninguno de sus nodos están detrás de un proxy. Si están detrás de un proxy, revise esta sección antes de proceder con la instalación. Rackspace todavía no ha probado un ambiente híbrido en donde algunos nodos estén detrás del proxy y otros no lo estén.

Ajustar las configuraciones del ambiente de proxy en los nodos

Debe hacer que sus configuraciones de proxy estén disponibles para todo el sistema operativo en cada nodo mediante la configuración de /etc/environment de la siguiente manera:

$ /etc/environment
http_proxy=http://<yourProxyURL>:<port>
        https_proxy=http://<yourProxyURL>:<port>
        ftp_proxy=http://<yourProxyURL>:<port>
no_proxy=<localhost>,<node1>,<node2>                    
                    

Reemplace node1 y node2 con los nombres de hosts de sus nodos.

En todos los casos, se requiere no_proxy y debe contener una entrada localhost. Si localhost falta, la instalación de Omnibus Chef Server fallará. Ubuntu requiere http_proxy y no_proxy como mínimo. CentOS requiere http_proxy, https_proxy y no_proxy para paquetes yum y actualizaciones clave. Sin embargo, como los métodos de instalación pueden cambiar con el tiempo, Rackspace recomienda que configure tantas variables como pueda.

Los nodos también deben tener sudo configurado para guardar las siguientes variables del ambiente:

Defaults env_keep += "http_proxy https_proxy ftp_proxy no_proxy"  
                    

En Ubuntu, esto puede colocarse en un archivo en /etc/sudoers.d. En CentOS, asegúrese de que su versión cargue los archivos en /etc/sudoers.d antes de agregar esta variable.

Evaluar las configuraciones de proxy

Puede ingresar y ejecutar env y sudo env para verificar que las configuraciones de proxy sean correctas. Tiene que ver a http_proxy, https_proxy, ftp_proxy y no_proxy configurados en el resultado, como en el siguiente ejemplo.

$ env
TERM=screen-256color
SHELL=/bin/bash
SSH_CLIENT=<ssh-url>
SSH_TTY=/dev/pts/0
LC_ALL=en_US
http_proxy=<yourProxyURL>:<port>
ftp_proxy=<yourProxyURL>:<port>
USER=admin
PATH=/usr/local/sbin
PWD=/home/admin
LANG=en_US.UTF-8
https_proxy=<yourProxyURL>:<port>
SHLVL=1
HOME=/home/admin
no_proxy=localhost,chef-server,client1
LOGNAME=admin
SSH_CONNECTION=<sshConnectionInformation>
LC_CTYPE=en_US.UTF-8
LESSOPEN=| /usr/bin/lesspipe %s
LESSCLOSE=/usr/bin/lesspipe %s %s
_=/usr/bin/env
                
$ sudo env
TERM=screen-256color
LC_ALL=en_US
http_proxy=<yourProxyURL>:<port>
ftp_proxy=<yourProxyURL>:<port>
PATH=/usr/local/sbin
LANG=en_US.UTF-8
https_proxy=<yourProxyURL>:<port>
HOME=/home/admin
no_proxy=localhost,chef-server,client1
LC_CTYPE=en_US.UTF-8
SHELL=/bin/bash
LOGNAME=root
USER=root
USERNAME=root
MAIL=/var/mail/root
SUDO_COMMAND=/usr/bin/env
SUDO_USER=admin
SUDO_UID=1000
SUDO_GID=1000
               

Disponibilidad alta

Rackspace Private Cloud tiene la capacidad de admitir alta disponibilidad (AD) para todos los componentes y API de servicio de Nova, Cinder, Keystone y Glance, así como también para el programador, RabbitMQ y MySQL. La funcionalidad de AD está impulsada por Keepalived y HAProxy.

Rackspace Private Cloud usa los siguientes métodos para implementar la AD en su clúster.

  • Replicación maestro/maestro y falla activa/pasiva en MySQL: MySQL se instala en ambos nodos de controlador y la replicación maestro/maestro se configura entre los nodos. Keepalived administra las conexiones a los dos nodos para que solo ese único nodo reciba las solicitudes de lectura/escritura en cualquier momento dado.
  • Falla activa/pasiva en RabbitMQ: RabbitMQ se instala en ambos nodos de controlador. Keepalived administra las conexiones a los dos nodos para que solo ese único nodo esté activo en cualquier momento dado.
  • Balanceo de carga de API: todos los servicios sin estado y con carga balanceada (esencialmente todas las API y unos pocos servicios) se instalan en ambos nodos de controlador. Luego, HAProxy se instala en ambos nodos, y Keepalived administra las conexiones a HAProxy, que proporciona AD a HAProxy. Las terminales Keystone y todo el acceso a la API pasa por Keepalived.

Zonas de disponibilidad

Las zonas de disponibilidad le permiten administrar y aislar diferentes nodos dentro del ambiente. Por ejemplo, es posible que quiera aislar diferentes conjuntos de nodos de cómputo para proporcionar diferentes recursos a los clientes. Si una zona de disponibilidad experimenta tiempo de inactividad, las otras zonas en el clúster no se verán afectadas.

Cuando crea un clúster de Nova, se crea con una zona de disponibilidad predeterminada, y todos los nodos de cómputo son asignados a esa zona. Puede crear zonas de disponibilidad adicionales dentro del clúster cuando sea necesario.







© 2011-2013 Rackspace US, Inc.

Excepto cuando se indique lo contrario, el contenido de este sitio está bajo una licencia Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License


Ver especificaciones de licencia y DESCARGO DE RESPONSABILIDAD