proyectos de centros de datos: planificación del sistema · proyectos de centros de datos:...

Proyectos de centros de datos:

planificación del sistema

Revisión 2

por Neil Rasmussen

Documento Técnico 142

Planning of a data center physical infrastructure project need not be a time consuming or frustrating task. La experiencia demuestra que, si las cuestiones correctas las resuelven las personas adecuadas en el orden apropiado, los requisitos imprecisos se pueden convertir rápidamente en un diseño detallado. En este documento se describen los pasos prácticos que se deben llevar a cabo para tratar de reducir costes mediante la simplificación y la reducción del proceso de planificación, todo ello mientras se mejora la calidad del plan.

Resumen ejecutivo

by Schneider Electric. Los Documentos técnicos ahora forman parte de la biblioteca de Schneider Electric producido por el centro de investigación científica para Centros de Datos de Schneider Electric [email protected]

Introducción 2

La secuencia de planificación de sistemas

3

Tarea n.º 1: Establecer los parámetros del proyecto

5

Tarea n.º 2: Desarrollar el concepto de sistemas

7

Tarea n.º 3: Incorporar preferencias y restricciones de los usuarios

8

Tarea n.º 4: Determinar los requisitos de implantación

10

Conclusión 12

Recursos 13

Haga clic en una sección para saltarla

Contenido >

Proyectos de centros de datos: planificación del sistema

Schneider Electric – Data Center Science Center Documento Técnico 142 Rev 2 2

La planificación de los proyectos para construir o actualizar centros de datos sigue siendo un reto importante para muchos departamentos de TI. Con frecuencia los planes se comunican en forma deficiente entre los distintos integrantes de la organización que participan de alguna manera en su actividad. Quienes toman decisiones pueden recibir propuestas con un nivel excesivo de detalle en cuanto a los aspectos técnicos pero que, a pesar de todo, parezcan carecer de la información necesaria para tomar decisiones de negocio correctas. Cambios iniciales de planes aparentemente pequeños pueden tener consecuencias importante en los costos más adelante, en la fase de construcción y montaje del centro de datos. El proceso de planificación y aprobación puede consumir una parte importante del tiempo de calendario de un proyecto y es frecuente que surjan sorpresas y los cambios imprevistos en fases tardías del proceso de planificación, los cuales provocan trabajos de replanificación que, a su vez, retrasan de forma importante la finalización del proyecto. Nuestra experiencia con muchos proyectos de centros de datos sugiere que muchos de estos problemas se pueden evitar si se proporciona la información adecuada en la secuencia correcta a quienes toman las decisiones. Este informe describe un método de planificación de proyectos de centros de datos para mejorar la calidad y la velocidad de los resultados. Este método de planificación estructurado describe una secuencia de pasos a seguir y las decisiones clave que se derivan de cada paso. Siguiendo este proceso y haciendo que el proceso sea visible para todas las partes interesadas, los administradores del proyecto pueden mejorar la transparencia del proyecto, hacer que las partes interesadas aprecien que su tiempo se utiliza de forma más eficiente y mejorar su aceptación del proyecto. En la Figura 1 se muestra cómo se realiza la planeación en el contexto del ciclo de vida de un centro de datos. La fase del "Plan" está dividida en las cuatro tareas principales de la secuencia de planificación de sistemas. La secuencia de planificación descrita en este informe establece los requisitos de diseño para el diseño de ingeniería detallado de la infraestructura física del centro de datos, el cual alimenta, refrigera, aloja y protege los sistemas informáticos. Esta secuencia de planificación está separada de la planificación informática y asume que hay otro proceso de planificación informática en paralelo o ya ha tenido lugar anteriormente.

Introducción



Assess

Plan Design

Build

Commission

Maintain, Operate, Monitor, Optimize

Tasks in the Plan phase

1 Establish key project parameters

2 Develop system concept

3 Incorporate user preferences and constraints

4 Determine implementation requirements

Las fases del ciclo de vida resaltadas en color gris en la Figura 1 representan el proyecto de centro de datos completo. La porción del PLAN del ciclo de vida establece los cimientos de todo lo que viene a continuación. La fase de planificación debería tomar el mínimo tiempo y dar lugar al mínimo gasto, pero tiene el máximo impacto sobre el rendimiento y el costo del centro de datos. La fase de planificación establece los detalles del sistema físico que se creará y del proceso del proyecto mediante el cual se creará el sistema. Para obtener más información sobre el proceso del proyecto, consulte el Informe técnico n.º 140, "Proyectos de centros de datos: proceso estandarizado". Para obtener más información sobre el ciclo de vida de un centro de datos, consulte el Informe técnico n.º 195, Gestión del ciclo de vida de un centro de datos. La secuencia de planificación de sistemas es el flujo lógico de pensamiento, actividades y datos que transforma la idea inicial de un proyecto en un conjunto compacto de requisitos y documentos que deberán controlar el rendimiento y el costo del centro de datos construido. En la implementación de Schneider Electric del proceso estandarizado del proyecto, la planificación de sistemas está secuenciada en cuatro tareas que tienen lugar durante la fase de Planificación del proyecto tal como se ilustra en la Figura 1. El flujo de procesos descrito en estas cuatro tareas contiene algunas ideas clave que hemos encontrado que son prácticas recomendadas eficientes para la planificación de centros de datos y conforman la base del método que se describe en este informe. Estas claves fundamentales son: Separación del concepto del sistema del diseño detallado: Resulta muy eficiente elegir un concepto de sistema antes de generar una especificación técnica detallada, trabajar en un diseño detallado o debatir largas listas de requisitos o preferencias de los usuarios. Las revelaciones en relación con el rendimiento o los costos que ocurren después de empezar el diseño detallado pueden cambiar el concepto fundamental del sistema y provocar grandes

La secuencia de planificación de sistemas

Figura 1 La fase del plan en el contexto del ciclo de vida del centro de datos, con las cuatro tareas principales de planificación

http://www.apc.com/wp?wp=140






cantidades de repetición del trabajo y retrasos. Las partes iniciales del proceso de diseño se deben centrar exclusivamente en asegurar una comprensión compartida de las capacidades más importantes del centro de dato y de su coste, y se debe evitar invertir en el diseño y la especificación detallada. Decidir sobre un concepto de diseño implica que quienes toman las decisiones a alto nivel determinen los objetivos a alto nivel y establezcan desde el principio el equilibrio entre rendimiento, coste, tamaño, ubicación y programación temporal del centro de datos implicado en el proyecto. Esta aproximación pretende el problema frecuente de que las partes interesadas no son conscientes de las características o los costos fundamentales de diseño hasta que se empiezan a ver diseños detallados en una fase posterior del proceso. Separación de los parámetros clave del proyecto de las preferencias y restricciones establecidas por los usuarios: Existe un pequeño conjunto de parámetros fundamentales de alto nivel del proyecto necesarios y suficientes para permitir la elección de un concepto de sistema. Algunos de estos parámetros fundamentales incluyen conceptos como la densidad y el plan de crecimiento, que no siempre han estado definidos claramente, y métodos de cuantificación sin ambigüedades. La planificación temprana debería centrarse en establecer un consenso sobre estos parámetros y posponer el abordaje de las preferencias de los usuarios y la mayoría de restricciones, con el fin de alcanzar una decisión temprana sobre el concepto del sistema. Esto garantiza que quienes toman las decisiones a alto nivel se centren en las decisiones más importantes pronto y no se dejen arrastrar por la discusión de los detalles. Las 4 tareas de planificación Cada una de las tareas esenciales de planificación de la Figura 1 utiliza información como entrada, la transforma o le añade detalles y la remite a la tarea siguiente. Se puede esperara que haya iteraciones dentro de cada paso, pero el objetivo es un proceso eficaz para tratar de minimizar las repeticiones y especialmente eliminar los errores que obliguen a retroceder dos o más pasos en el proceso. Este progreso se puede modelizar utilizando el flujo ilustrado en la Figura 2. Los datos que fluyen y se transforman son la descripción en desarrollo del sistema. En la Figura 2, los datos se muestran en forma de páginas en un portapapeles que viaja de una tarea a otra (los rectángulos verdes) con una nueva página que sirve como entrada adicional para cada paso subsiguiente en el camino. Cada tarea agrega más información y la suma del contenido se convierte en los requisitos de diseño para el proceso subsiguiente de ingeniería en detalle. Los requisitos de implementación (Tarea 4), combinados con los resultados establecidos en las tres tareas anteriores, juntos se convierten en los requisitos completos de diseño y sirven como "libro de normas" del diseño detallado de ingeniería que tiene lugar en la fase posterior de diseño (la cual no se analiza en este informe).



Esta tarea se inicia con la idea general de una necesidad de negocio que requiere un cambio en las capacidades informáticas de una organización. A partir de ahí, la tarea n.º 1 implica la determinación de los parámetros siguientes del proyecto: criticidad, capacidad, plan de crecimiento, eficiencia, densidad y presupuesto. Las partes interesadas clave que deberían estar implicadas en esta fase incluyen la gerencia de finanzas, el Director ejecutivo, un ejecutivo clave de IT, el gerente de operaciones de IT y otras personas que entiendan las necesidades y los objetivos empresariales fundamentales. Los seis parámetros del proyecto establecen los objetivos de alto nivel del proyecto de centro de datos, que más tarde se utilizan para desarrollar el concepto de sistemas de infraestructuras físicas para el centro de datos. Estos seis parámetros clave del proyecto se definen del modo siguiente:

1. Criticidad: Nivel de disponibilidad del sistema que se debe alcanzar en términos de normas estándar de la industria.

2. Capacidad: Máxima cargad e IT (en kW) que debe soportar la infraestructura física del centro de datos.

3. Plan de crecimiento: Descripción de la evolución hasta los requisitos de máxima potencia, incorporando la incertidumbre (consulte el Informe técnico n.º 143, Proyectos de centros de datos: Modelo de crecimiento)

Figura 2 Las cuatro tareas de la “secuencia de planificación de sistemas“

Tarea n.º 1: Establecer los parámetros del proyecto




4. Eficiencia: Objetivo de eficiencia energética de los sistemas de infraestructura del centro de datos.

5. Densidad: Potencia promedio y cresta que se espera que consuman los gabinetes de IT (kW/rack) y espacio necesario sobre el piso (consulte el Informe técnico n.º 155, Cálculo de las necesidades de espacio y de densidad de potencia totales para centros de datos) junto con información relativa a la incertidumbre en la densidad.

6. Presupuesto: Costos de capital planificados1 para el proyecto.

Muchos fallos de planificación, trabajo de diseño desperdiciado y retrasos en el calendario se pueden trazar hasta los problemas siguientes: • Las partes interesadas no han logrado entender y acordar de forma compartida estos

parámetros clave en una fase temprana del proceso.

• Las partes interesadas no eran del todo conscientes de los pros y contras entre estos parámetros.

• Las partes interesadas no estaban totalmente informadas de cómo iba a funcionar el diseño a partir de estos parámetros hasta que hay un diseño detallado en curso o incluso completado, cuando realizar correcciones puede ser demasiado caro.

Un objetivo importante de esta tarea es garantizar que se dedique poco tiempo de gerencia a tomar las decisiones más importantes. Una forma eficaz de lograrlo es dividir esta tarea en dos pasos: En primer lugar, es necesario celebrar reuniones en las que se impliquen la gerencia del proyecto y cada una de las partes interesadas individuales (p. ej. gerente de finanzas, gerente de informática, gerente de instalaciones) a fin de explicar el proceso, proporcionar un lenguaje común para los seis parámetros del proyecto, validar los miembros adecuados de sus equipos para participar en el proceso y prepararlos individualmente para una futura reunión conjunta en la cual se acordarán los seis parámetros clave del proyecto. Esto permite a cada miembro del equipo tener un conocimiento compartido del plan y pensar acerca de los problemas con antelación y validar sus necesidades y preocupaciones. En segundo lugar se debe organizar una jornada de trabajo para que las partes interesadas se centren en establecer los seis parámetros. Se espera que este proceso sea iterativo, ya que la elección de un parámetro (como la criticidad) puede hacer que otro parámetro (como el coste) sea inaceptable y esto, a su vez, puede impulsar un cambio en uno o más parámetros. Por ejemplo, elegir una sobre especificación de los requisitos de capacidad en kW para futuras ampliaciones de las estructuras informáticas puede llevar el proyecto a superar el presupuesto objetivo y exigir ahorros mediante la reducción de la criticidad. Las partes interesadas que participen en esa jornada de trabajo pueden considerar los pros y contras de los parámetros esenciales del proyecto en tiempo real, confiando en un experto conocedor y de confianza que participe en el debate o utilizando un modelo matemático como la Herramienta de planificación de centros de datos (ejemplo en la Figura 3). Esto permite a las partes interesadas considerar distintos escenarios posibles y entender las relaciones de compromiso entre el coste de capital, las dimensiones de la potencia, la eficiencia y la capacidad. Este tipo de herramientas de planificación se pueden utilizar en una jornada de trabajo para contribuir a que las partes interesadas desarrollen una comprensión conjunta de cómo sus áreas de interés particulares (como las finanzas, por ejemplo) afectan a las demás áreas del proyecto (como la capacidad del centro de datos).

1 El presupuesto para la planificación es el presupuesto del proyecto y no incluye el presupuesto de gastos

de explotación. Sin embargo, los costos de explotación son una consideración que se tiene en cuenta al establecer un equilibrio entre los distintos parámetros durante la selección del concepto del sistema.



http://www.apc.com/tool/?tt=8



El objetivo de estas sesiones de planificación es generar un conjunto de objetivos realistas de presupuesto, capacidad, plan de crecimiento, eficiencia, densidad y criticidad del centro de datos. Es posible que no se puedan establecer los seis parámetros en un una única jornada de trabajo ejecutiva, ya que algunos de los participantes pueden necesitar más tiempo para considerar o analizar las decisiones de equilibrio que se hayan identificado. No obstante, en muchos casos se pueden tomar decisiones de calidad en unos pocos días, y ese debería ser el objetivo de duración de este paso.

Esta tarea toma los parámetros fundamentales del proyecto determinados en la tarea anterior (criticidad, capacidad, crecimiento, plan, eficiencia, densidad y presupuesto), y los utiliza para seleccionar un concepto general de sistema de infraestructuras físicas. Las partes interesadas clave implicadas en esta fase deben incluir el grupo de operaciones de TI, gerencia de TI, gerencia de instalaciones, ingeniería de instalaciones y un consultor con experiencia en planificación de sistemas para proyectos de centros de datos. El elemento fundamental de esta tarea es seleccionar un diseño de referencia que contenga las características de criticidad, capacidad, eficiencia, densidad y presupuesto deseadas y que tenga la estabilidad necesaria para soportar el plan de desarrollo. Además, al finalizar este paso es importante haber decidido la ubicación específica (sala, edificio o lugar) para el centro de datos. En comparación con la forma de diseño de centros de datos tradicional “sobre un papel en blanco“, los diseños de referencias sirven como un buen punto de partida para avanzar en la fase de diseño. Un diseño de referencia es un modelo de diseño de ejemplo que contiene una combinación específica de atributos, incluidas funciones de criticidad, densidad de potencia, tecnologías de equipos, características de escalabilidad y nivel de instrumentación. Un diseño de referencia eficaz también incluye especificaciones de rendimiento a nivel de sistemas como el peso, el espacio ocupado, etc. e incluye una lista detallada de los materiales o componentes

Tarea n.º 2: Desarrollar el concepto de sistemas

Figura 3 Captura de pantalla de una herramienta de planificación de centros de datos

EstablishPROJECT PARAMETERS

DevelopSYSTEM CONCEPT

IncorporateUSER PREFERENCES AND CONSTRAINTS

DetermineIMPLEMENTATION REQUIREMENTS



que conforman el sistema. Un diseño de referencia determinado cuenta con una gama práctica de capacidades de alimentación para la cual es adecuado y proporciona una forma inmediata de evaluar con eficacia otros diseños sin realizar el laborioso proceso del diseño y la especificación propiamente dichos. Se pueden tomar las decisiones adecuadas de una forma rápida y eficaz. Para obtener más información sobre los diseños de referencia, consulte el Informe técnico n.º 147, Proyectos de centros de datos: Ventajas del uso de un diseño de referencia. Aunque existe un número prácticamente ilimitado de posibles diseños de referencia, los seis parámetros clave del proyecto descartarán rápidamente la mayoría de ellos y permitirán que el proceso de selección de un diseño de referencia se convierta en una elección sencilla entre unas cuantas opciones en lugar de un proceso largo de creación de un diseño que cumpla los parámetros a partir de una “hoja de papel en blanco”. Una vez que se hayan identificado varias opciones de diseños de referencia, las alternativas se pueden revisar en relación con otros aspectos tales como la logística, la reputación del proveedor, las referencias de los clientes, etc. En muchos casos, la ubicación propuesta para el centro de datos ya se conoce o está limitada a unas cuantas opciones. Seleccionar un diseño de referencia en una fase temprana proporciona la información necesaria para evaluar rápidamente si el concepto de diseño es compatible con una ubicación determinada. Si se observan incompatibilidades, se pueden examinar la elección de un diseño de referencia, las opciones de ubicación de emplazamiento y los parámetros del proyecto de forma conjunta e inmediata, y llegar a compromisos equilibrados para lograr una combinación satisfactoria. En un proceso de diseño tradicional, es posible que no se identifiquen las incompatibilidades hasta después de comenzar el diseño detallado, por lo que se pierde un tiempo valioso y se obliga a gerencia a volver atrás y a volver a plantearse decisiones que ya creían que estaban tomadas. Todo esto significa repetir trabajo y, en última instancia, se traduce en retrasos en el proyecto y costos adicionales. Esta capacidad de llegar a los compromisos más importantes de forma temprana y rápida se consigue mediante la condensación de las decisiones importantes en tres elementos: 1) los seis parámetros del proyecto, 2) una lista limitada de diseños de referencia y, 3) una lista de ubicaciones posibles. Si el administrador del proyecto se prepara bien para esta tarea, podría completarse en una única jornada de trabajo de gerencia. Para los proyectos más pequeños, las tareas 1 y 2 se pueden completar en una sola jornada de trabajo. Las preferencias de los usuarios y las limitaciones incluyen los requisitos de diseño técnicos que no están incluidos en los seis parámetros clave del proyecto y no aparecen explícitamente en el concepto del sistema o la elección de la ubicación. Teniendo en cuenta la elección del concepto del sistema de la tarea anterior, esta tarea recopila y evalúa las preferencias de los usuarios y las limitaciones para determinar si son válidas, o bien si se deben ajustar de alguna forma para reducir el costo o evitar problemas. La idea central en este caso es que las preferencias y restricciones impuestas por los usuarios se deben adaptar de tal modo que funcionen con el concepto de sistema elegido previamente. Nuestra experiencia dicta que es eficaz validar y adaptar las preferencias y las restricciones de los usuarios una vez elegido el concepto de diseño, en lugar de recopilarlas como requisitos previos e intentar utilizarlas para dirigir el diseño general. Son las preferencias de los usuarios y las limitaciones a menudo las que alejan de forma inadvertida los diseños de los centros de datos de los diseños estándar e incrementan el costo y el tiempo de desarrollo y disminuyen la calidad.

Tarea n.º 3: Incorporar preferencias y restricciones de los usuarios








Entre los colaboradores clave implicados en esta fase se deben incluir operaciones de TI, ingenieros de redes, ingenieros de instalaciones, otro personal relacionado con las actividades del día a día del centro de datos y un asesor con experiencia en la planificación de sistemas para los proyectos de centros de datos. Las preferencias y las restricciones de los usuarios se definen del modo siguiente: • Las preferencias son los deseos de los usuarios que están sujetos a la realización de

cambios o ajustes tras considerar (o volver a considerar) el coste y las consecuencias. A veces, las preferencias de los usuarios cambian cuando reciben información nueva.

• Las limitaciones son obstáculos que no se pueden superar o que solo se pueden cambiar si implican un gran gasto o consecuencias inaceptables. Las limitaciones son condiciones previas que resultan difíciles o imposibles de cambiar.

Las preferencias son características deseables por parte de los operadores o la organización en función de sus objetivos o experiencia, pero no son restricciones. Entre los ejemplos de preferencias de los usuarios se encuentran: • Preferimos la distribución en alto del cableado de alimentación.

• Necesitamos que los visitantes puedan ver el centro de datos en las visitas a las instalaciones.

• Queremos cámaras de seguridad vigilando cada milímetro del espacio del centro de datos.

• No queremos tener que hacer trabajos de cableado eléctrico o fontanería en la sala de TI una vez que esté en marcha.

• Preferimos usar racks de TI anchos para disponer de más espacio para cables.

• Queremos separar físicamente los armarios de TI por cliente.

• Queremos una pantalla en la pared que muestre el resumen del rendimiento energético del centro de datos.

Las restricciones dependen de las circunstancias y escapan al control del diseñador del centro de datos. Entre las restricciones se incluyen las limitaciones de las instalaciones o las normativas, o los requisitos empresariales inalterables. Los asesores deben evaluar si las decisiones que influyen en la planta física de las instalaciones cumplen los códigos nacionales y locales. Entre los ejemplos de restricciones se encuentran: • Una característica física de la instalación (por ejemplo, la altura del techo, la capacidad

de carga del piso, la geometría de la sala, las paredes o columnas existentes o los requisitos de montaje en el tejado para los dispositivos de exterior).

• Una ley o código que requiera su cumplimiento.

• Un estándar que se deba cumplir (como TIA 942).

• Las normas de trabajo (como las horas de acceso o las normas de los sindicatos).

• Una característica física de la ruta de entrega (como la capacidad de carga del montacargas que se utilizará para transportar los equipos a la sala).

Una vez validadas, las preferencias y las restricciones de los usuarios se revisan para comprobar su compatibilidad con el concepto de sistema seleccionado. Las que son compatibles pasan a formar parte de los requisitos del diseño. Si una preferencia o restricción validada no es compatible con el concepto de diseño, se intenta conciliar mediante ajustes en la preferencia o restricción, o bien mediante la inclusión de solicitudes de cambios menores en el concepto del sistema (por ejemplo, adaptaciones del concepto). Tal vez sea necesario repetir este proceso varias veces, ya que pueden existir equilibrios e interacciones entre las distintas preferencias y restricciones, tal como se muestra en la Figura 4. El objetivo aquí



es realizar adaptaciones en el concepto para evitar la necesidad de volver a considerar el concepto del sistema a menos que sea absolutamente necesario. Según nuestra experiencia, casi todas las preferencias y limitaciones se pueden incorporar satisfactoriamente de forma que funcionen con el concepto del sistema elegido.

OUTPUT Design ParametersReference DesignRoom Choice

INPUTS AssessTradeoffs

ProvideAlternatives

Identify Conflicts Concept

Adaptations

Validated Preferences

Validated Constraints

•

Validate Preferences & Constraints

ReconcileConflicts

User Preferences

Constraints

From task 2

Es importante asegurarse de que una limitación es realmente una limitación. A continuación, se muestran dos ejemplos de soluciones alternativas para una limitación:

Limitación: el centro de datos existente no permite su desconexión (para realizar la actualización). Posible solución: Coloque una pared temporal para separar el sistema en ejecución del área de trabajo para la nueva instalación e instale un suministro de alimentación independiente para ejecutar los dos sistemas a la vez durante el cambio. Limitación: No podemos utilizar unidades de expulsión de aire con conductos en el falso techo, ya que el techo no dispone de conducto de plénum contra incendios y el inspector de incendios no permitirá una conexión. Posible solución: Pulverice una preparación ignífuga en el conducto.

En la mayoría de los casos, es necesario realizar varias repeticiones para obtener un conjunto definitivo de preferencias de los usuarios y limitaciones. Esta tarea estará completa cuando las preferencias y las limitaciones se hayan conciliado con el concepto del sistema y se hayan descrito como adaptaciones del concepto y preferencias y limitaciones validadas. Esta tarea del proceso se puede agilizar si se recopilan las preferencias de los usuarios y las limitaciones junto con las tareas anteriores. Tenga en cuenta que muchas de las limitaciones no se pueden determinar hasta que se elija el emplazamiento. Esto puede requerir que la tarea anterior, “Desarrollar el concepto del sistema”, se lleve a cabo antes de que se puedan recopilar las limitaciones. Los requisitos de implantación actúan como un conjunto de reglas que se deben seguir a la hora de crear un diseño detallado del sistema, además de los resultados establecidos en las tres tareas anteriores. Los requisitos de implantación constan de los siguientes elementos:

1. Requisitos estándar que no varían de un proyecto a otro. Normalmente, los requisitos estándar aparecen como especificaciones estándar que incluyen la mayor

Tarea n.º 4: Determinar los requisitos de implantación

Figura 4 Detalles de la tarea para la incorporación de preferencias de los usuarios y limitaciones



parte de la especificación del centro de datos. Algunos ejemplos de requisitos estándar son los estándares de cumplimiento de normativas especiales, compatibilidad de subsistemas, seguridad o prácticas recomendadas que deben indicarse de forma explícita a ingenieros o instaladores2.

2. Requisitos del proyecto que definen los detalles específicos de los usuarios relacionados con la ejecución del proyecto. Aquí se incluyen fechas límite especiales, asignaciones o limitaciones de recursos de equipos o humanos, proveedores que se deben utilizar o adquisiciones especiales u otros procesos administrativos que el proyecto debe seguir.

La división de los requisitos de implantación en aquellos que son comunes para todos los sistemas (requisitos estándar) y aquellos que son específicos de este proyecto del usuario (requisitos del proyecto) simplifica el trabajo de creación y mantenimiento del diseño del sistema detallado, ya que la mayor parte de la revisión y de las decisiones se pueden centrar en el subconjunto de requisitos específicos del proyecto. Puede encontrar más información en System Specification and Project Manual Volume 1: Small and Medium Data Centers (Manual del proyecto y especificación del sistema volumen 1: Centros de datos pequeños y medianos). Los requisitos de implantación, junto con los resultados establecidos en las tres tareas anteriores dan como resultado la totalidad de requisitos de diseño y actúan como “reglas” para el diseño detallado en la fase de diseño posterior (no descrita en este documento). En la fase de diseño posterior, los requisitos de diseño establecidos mediante el proceso de planificación descrito en este documento definen la ingeniería del proyecto y el sistema. Es en este paso de diseño posterior donde se desarrollan las especificaciones de ingeniería, entre las que se incluyen:

1. Listas detalladas de componentes

2. Planta exacta de racks, lo que incluye el equipamiento de alimentación y refrigeración

3. Instrucciones de instalación detalladas

4. Programación detallada del proyecto

5. Características “finales” reales del diseño (eficacia, densidad y capacidad de ampliación)

El uso de un diseño de referencia como medio para establecer el concepto del diseño, tal y como se recomienda en este documento, simplifica en gran medida el diseño detallado del sistema que se ha creado en la fase de diseño, en caso de que se hayan proporcionado detalles suficientes en el diseño de referencia. Los diseños de referencia eficaces ya incluyen gran parte del contenido de la lista anterior, por lo que no es necesario volver a crearlos. Normalmente, los diseños de referencia incluyen diagramas lineales de los espacios eléctricos, mecánicos y de TI, proporcionan diseños en planta, una lista de materiales (BOM) y ofrecen las características de rendimiento del sistema esperadas. Todo ello se puede incorporar directamente en el diseño detallado con adaptaciones menores y procesos de análisis e ingeniería adicionales mínimos.

2 Se supone que ingenieros y arquitectos conocen y cumplen las normas obligatorias locales, y no es

necesario indicarlas de forma explícita. El objetivo de este paso es identificar las normas del sector, internas o voluntarias que se deben cumplir además de las normas obligatorias locales.





http://www.apcmedia.com/salestools/VAVR-64CHBJ_R1_EN.pdf






A pesar de su importancia crucial para que el proyecto se desarrolle con éxito, tradicionalmente, la planificación del sistema se ha considerado un proceso desestructurado y dificultoso que se ha llevado a cabo como un arte en lugar de una ciencia, con cabida para errores, supuestos incorrectos y malentendidos que pueden tener consecuencias negativas en las fases posteriores del proyecto. Esta fase suele emplear mucho más tiempo del que está previsto o es necesario. Muchas de las dificultades se pueden evitar considerando la planificación del sistema como un proceso estandarizado que consta de una secuencia ordenada de tareas que, de forma progresiva, desarrollan y pulen el concepto del sistema para garantizar que el sistema final satisfaga la necesidad empresarial original. En este documento, se describe un proceso de planificación del centro de datos compuesto por cuatro tareas, cada una de las cuales pule o transforma el concepto del sistema conforme progresa de la idea a los requisitos de diseño. El principio de este proceso es garantizar que las personas adecuadas toman las decisiones correctas en el orden apropiado con el fin de maximizar la eficacia. La secuencia empieza con: Una necesidad empresarial a partir de la que se establecen parámetros del proyecto, a partir de los cuales se desarrolla un concepto del sistema, complementado con

preferencias de los usuarios y limitaciones validadas que se suman a los requisitos de implantación.

La combinación de los resultados de estos pasos da lugar a un paquete de requisitos de diseño con el nivel de detalle adecuado para permitir que las partes interesadas lleguen a un entendimiento común y se impliquen, a la vez que se proporciona la orientación necesaria suficiente para garantizar que en las fases posteriores de ingeniería y construcción del proyecto se logren los resultados acordados. La estandarización del proceso de planificación, cuando se combina con el uso de un lenguaje común para la descripción de los requisitos, puede llevar la planificación de la mayoría de los centros de datos al ámbito de una ciencia predecible y repetitiva. Seguir un proceso organizado permite al director del proyecto evitar descuidos y la desinformación en la toma de decisiones durante la fase de planificación temprana de un proyecto de centro de datos, así como garantizar que las partes interesadas emplean su tiempo de forma eficaz.

Conclusión

Neil Rasmussen es Vicepresidente Senior de Innovación en Schneider Electric. Orienta el destino tecnológico del mayor presupuesto mundial de Investigación y Desarrollo dedicado al tema de la infraestructura de energía, refrigeración y racks para redes críticas. Neil tiene 25 patentes relacionadas con la infraestructura de refrigeración y el suministro eléctrico a centros de datos de alta eficiencia y densidad, y ha publicado más de 50 informes técnicos relacionados con los sistemas de alimentación y refrigeración, muchos de ellos publicados en más de 10 idiomas, los más recientes con un enfoque en la mejora de la eficiencia energética. Es reconocido internacionalmente por sus conferencias sobre el tema de los centros de datos de alta eficiencia. Actualmente se dedica a desarrollar la ciencia de las soluciones de infraestructura para centros de datos escalables, de alta densidad y alta eficiencia, y es el principal diseñador del sistema InfraStruXure de APC. Antes de fundar APC en el año 1981, Neil recibió los títulos de licenciado y máster en Ingeniería Eléctrica del MIT, donde realizó su tesis sobre el análisis de una fuente de alimentación de 200 MW para un reactor de fusión Tokamak. Desde 1979 hasta 1981 trabajó para MIT Lincoln Laboratories en sistemas de almacenamiento energético de volante y sistemas de energía eléctrica solar.

Sobre el autor



Instrucciones para la especificación de la criticidad/niveles de clasificación de centros de datos Documento Técnico 122

Proyectos de centros de datos: Proceso estandarizado Documento Técnico 140

Proyectos de centros de datos: Modelo de crecimiento Documento Técnico 143

Proyectos de centros de datos: Ventajas del uso de un diseño de referencia Documento Técnico 147

Cálculo de los requisitos de espacio y la densidad de potencia totales para los centros de datos Documento Técnico 155

Proyectos de centros de datos: Establecimiento de una superficie en planta Documento Técnico 144

Gestión del ciclo de vida del centro de datos Documento Técnico 195

Herramienta de planificación del centro de datos TradeOff Tool 8

tools.apc.com

Explore todas las herramientas TradeOff Tools™

Explore todos los informes técnicos whitepapers.apc.com

Para incluir comentarios sobre el contenido de este informe técnico: Centro de investigación científica para Centros de Datos [email protected] Si tu eres un cliente y tiene preguntas específicas sobre su proyecto de centro de datos: Póngase en contacto con su representante de Schneider Electric www.apc.com/support/contact/index.cfm

Contáctenos

Recursos Haga clic sobre el icono para conectarse a el recurso




http://www.apc.com/tool/?tt=8





http://www.apc.com/support/contact/index.cfm

http://www.apc.com/support/contact/index.cfm

http://whitepapers.apc.com/

http://tools.apc.com/

proyectos de centros de datos: planificación del sistema · proyectos de centros de datos:...

Documents