СПОСОБ ОЦЕНКИ ПОТРЕБЛЕНИЯ МОЩНОСТИ
METHOD OF ESTIMATING POWER CONSUMPTION

Область техники
Настоящее раскрытие относится, в целом, к анализу потребления мощности и, в частности, к способам анализа потребления мощности информационными центрами (дата-центрами).
Уровень техники
Дата-центры быстро становятся одними из крупнейших потребителей энергии, особенно в США. В то время как потребность в энергии растет волнующими темпами, потребление энергии дата-центром является чрезвычайно неэффективным. В настоящее время нет ни одного целесообразного целостного подхода, обеспечивающего эффективность потребления энергии всем дата-центром и в то же время учитывающего потребности бизнеса.
Из вышесказанного можно понять, что могут иметься значительные проблемы и недостатки, относящиеся к современным способам анализа потребления мощности дата-центрами.
Раскрытие изобретения
Предложены способы анализа потребления мощности для дата-центров. В одном примере осуществления изобретение предлагает способ анализа потребления мощности множеством компонентов вычислительной платформы, содержащий прием информации, относящейся к компоненту, извлечение с использованием процессора компьютера сохраненных в электронном виде данных, относящихся к компоненту, оценку потребления мощности компонентом на основании, по меньшей мере, сохраненных данных и выдачу показания потребления мощности.
Согласно другим аспектам этого примера осуществления, компонент может представлять собой по меньшей мере одно из следующего: процессор компьютера, электронное запоминающее устройство и сетевой компонент.
Согласно другим аспектам этого примера осуществления, способ можно повторять для множества компонентов устройства. Способ включает в себя обобщение оценок потребления мощности компонентами устройства для получения оцененного потребления мощности устройством.
Согласно дополнительным аспектам этого примера осуществления, устройство может представлять собой по меньшей мере одно из следующего: сервер, сетевое устройство, хост и запоминающее устройство.
Согласно дополнительным аспектам этого примера осуществления, способ можно повторять для множества устройств в некоторой зоне.
Согласно дополнительным аспектам этого примера осуществления, способ может дополнительно содержать прием результатов одного или более измерений, относящихся к компоненту, и оценку потребления мощности компонентом на основании, по меньшей мере, результатов одного или более принятых измерений.
Согласно дополнительным аспектам этого примера осуществления, одно или более измерений может представлять собой по меньшей мере одно из следующего: показания от датчика температуры, микросхемы процессора, радиатора, контроллера дисков, источника питания и сетевого компонента.
Согласно дополнительным аспектам этого примера осуществления, одно или более измерений может представлять собой по меньшей мере одно из следующего: загруженность процессора, интенсивность транзакций, интенсивность обмена данными, информация о конфигурации, перечень активных процессов и количество виртуальных машин.
Согласно дополнительным аспектам этого примера осуществления, способ может дополнительно содержать оценку температурного профиля компонента на основании по меньшей мере одного или более из оцененных потреблений мощности компонентом и одного или более принятого измерения.
Согласно дополнительным аспектам этого примера осуществления, способ может дополнительно содержать оценку потребления мощности на основании температурного профиля.
Согласно дополнительным аспектам этого примера осуществления, оценка потребления мощности на основании температурного профиля может содержать использование температурного профиля для оценки издержек на охлаждение.
Согласно дополнительным аспектам этого примера осуществления, способ может дополнительно содержать прием результатов одного или более измерений от по меньшей мере одного из следующего: блок распределения мощности и кондиционер воздуха помещения для ЭВМ.
Согласно дополнительным аспектам этого примера осуществления, способ может дополнительно содержать использование принятых результатов одного или более измерений для оценки по меньшей мере одного из следующего: потребление мощности и температурный профиль.
Согласно дополнительным аспектам этого примера осуществления, прием информации, относящейся к компоненту, может содержать выявление компонента посредством сетевого интерфейса.
Согласно дополнительным аспектам этого примера осуществления, выявление компонента посредством сетевого интерфейса может содержать использование по меньшей мере одного из следующего: простой протокол управления сетями (SNMP), инициатива по менеджменту запоминающих устройств - технические условия (SMI-S), интеллектуальный интерфейс управления платформой (IPMI), инструментарий управления Windows (WMI), Secure Shell («безопасная оболочка», SSH), BACNet и Modbus.
Согласно дополнительным аспектам этого примера осуществления, выявление компонента посредством сетевого интерфейса может содержать выявление, осуществляемое в дата-центре из удаленного места.
Согласно дополнительным аспектам этого примера осуществления, способ может дополнительно содержать прием входных данных для неопознанного компонента в случае, если сохраненные в электронном виде данные, относящиеся к компоненту, не извлечены.
Согласно дополнительным аспектам этого примера осуществления, способ может дополнительно содержать выявление одного или более логического элемента, относящегося к компоненту, и оценку потребления мощности на основании по меньшей мере одного или более выявленного логического элемента.
Согласно дополнительным аспектам этого примера осуществления, один или более логический элемент может представлять собой по меньшей мере одно из следующего: компонент операционной системы, относящийся к компоненту; процесс, относящийся к компоненту; виртуальная машина, относящаяся к компоненту; и приложение, относящееся к компоненту.
Согласно дополнительным аспектам этого примера осуществления, сохраненные в электронном виде данные, относящиеся к компоненту, могут представлять собой базу данных по меньшей мере одного из следующего: профили компонентов, массивы серверов, кондиционеры воздуха помещения для ЭВМ, блоки распределения мощности и физическая инфраструктура дата-центра.
Согласно дополнительным аспектам этого примера осуществления, способ может дополнительно содержать предоставление одной или более рекомендации на основании по меньшей мере одного из следующего; оцененное потребление мощности компонентом, оцененное потребление мощности устройством, оцененное потребление мощности зоной, оцененное потребление мощности дата-центром, температурный профиль зоны.
Согласно дополнительным аспектам этого примера осуществления, одна или более рекомендаций может содержать по меньшей мере одно из следующего: устранение неиспользуемых компонентов, объединение недостаточно используемых компонентов, модернизация неэффективных компонентов, замена неэффективных компонентов, изменение географического местоположения компонентов для улучшения температурного профиля и перераспределение рабочей нагрузки между компонентами внутри географического местоположения для улучшения температурного профиля.
Согласно дополнительным аспектам этого примера осуществления, температурный профиль может оцениваться с использованием вычислительной гидродинамики.
В другом аспекте изобретения способ может быть реализован с использованием по меньшей мере одного машиночитаемого носителя данных с записанной на нем программой, содержащей инструкции, считывание которых по меньшей мере одним процессором обеспечивает выполнение этим процессором указанного способа.
В еще одном аспекте изобретения предлагается изделие для оценки потребления мощности множеством компонентов вычислительной платформы, содержащее по меньшей мере один машиночитаемый носитель данных с сохраненными на нем инструкциями, считывание которых с указанного носителя по меньшей мере одним процессором обеспечивает выполнение этим процессором следующих операций: прием информации, относящейся к компоненту, извлечение сохраненных в электронном виде данных, относящихся к компоненту, оценку потребления мощности компонентом на основании, по меньшей мере, сохраненных данных и выдачу показаний потребления мощности.
В дальнейшем аспекте изобретения предлагается система для оценки потребления мощности множеством компонентов вычислительной платформы, содержащая один или более процессоров, соединенных с возможностью обмена данными с сетью и выполненных с возможностью приема информации, относящейся к компоненту, извлечения сохраненных в электронном виде данных, относящихся к компоненту, оценки потребления мощности компонентом на основании, по меньшей мере, сохраненных данных и выдачи показания потребления мощности.
Настоящее изобретение далее будет описано более подробно со ссылками на примеры его осуществления, изображенные на прилагаемых чертежах. Несмотря на то что настоящее изобретение описано ниже со ссылкой на примеры осуществления, необходимо понимать, что оно не ограничено ими. Специалист, обладающий средним уровнем знаний в данной области, после уяснения принципов, раскрытых в настоящем документе, должен представлять себе другие воплощения, модификации и варианты осуществления, которые входят в объем настоящего изобретения, а также другие области применения, в которых настоящее изобретение может найти широкое применение.
Краткое описание чертежей
Для того чтобы помочь более полному уяснению настоящего изобретения, даются ссылки на прилагаемые чертежи, на которых одинаковые элементы обозначены одинаковыми позициями. Эти чертежи следует истолковывать не в качестве ограничения настоящего изобретения, а лишь в качестве примера.
Фиг. 1 показывает схему, изображающую архитектуру сети, содержащую платформу для анализа потребления мощности согласно варианту осуществления настоящего изобретения,
Фиг. 2 показывает схему, изображающую архитектуру сети, содержащую платформу для анализа потребления мощности согласно варианту осуществления настоящего изобретения,
Фиг. 3 изображает схему вычислительной системы согласно варианту осуществления настоящего изобретения,
Фиг. 4 показывает модуль анализа потребления мощности согласно варианту осуществления настоящего изобретения,
Фиг. 5 изображает способ анализа потребления мощности согласно варианту осуществления настоящего изобретения,
Фиг. 6 изображает способ анализа потребления мощности согласно варианту осуществления настоящего изобретения,
Фиг. 7 изображает объекты и данные системы анализа потребления мощности согласно варианту осуществления настоящего изобретения,
Фиг. 8 изображает конвейерный принцип исполнения команд в системе анализа потребления мощности согласно варианту осущесвления настоящего изобретения,
Фиг. 9 - схема потока данных, показывающая идентификацию зомби-серверов (т.е. неиспользуемых серверов) в дата-центре согласно варианту осуществления настоящего изобретения,
Фиг. 10 изображает систему для анализа потребления мощности в дата-центре согласно варианту осуществления настоящего изобретения,
Фиг. 11 изображает архитектуру программного обеспечения для анализа потребления мощности в дата-центре согласно варианту осуществления настоящего изобретения,
Фиг. 12 изображает схему системы для оптимизации экономии энергии дата-центром согласно варианту осуществления настоящего изобретения,
Фиг. 13 изображает схему теплового потока дата-центра согласно варианту осуществления настоящего изобретения,
Фиг. 14 изображает пользовательский интерфейс для мониторинга показателей потребления мощности дата-центром согласно варианту осуществления настоящего изобретения,
Фиг. 15 изображает пользовательский интерфейс для мониторинга ресурсов дата-центра согласно варианту осуществления настоящего изобретения,
Фиг. 16 изображает пользовательский интерфейс для идентификации местоположения устройства в дата-центре согласно варианту осуществления настоящего изобретения,
Фиг. 17 изображает пользовательский интерфейс для идентификации зомби-устройств в дата-центре согласно варианту осуществления настоящего изобретения,
Фиг. 18 изображает тепловую карту дата-центра согласно варианту осуществления настоящего изобретения,
Фиг. 19 изображает передачу одного или более ресурсов зонам в дата-центре согласно варианту осуществления настоящего изобретения,
Фиг. 20 изображает передачу одного или более ресурсов зонам в дата-центре согласно варианту осуществления настоящего изобретения,
Фиг. 21 изображает зависимость между количеством отказов оборудования и сроком его использования в дата-центре согласно варианту осуществления настоящего изобретения,
Фиг. 22 изображает зависимость между количеством отказов оборудования и его температурой согласно варианту осуществления настоящего изобретения,
Фиг. 23 изображает использование коэффициентов для идентификации температурных проблем в дата-центре согласно варианту осуществления настоящего изобретения,
Фиг. 24 изображает использование коэффициентов для идентификации температурных проблем в дата-центре согласно варианту осуществления настоящего изобретения,
Фиг. 25 изображает использование коэффициентов для идентификации температурных проблем в дата-центре согласно варианту осуществления настоящего изобретения,
Фиг. 26 изображает пример пользовательского интерфейса для анализа потребления мощности дата-центром согласно варианту осуществления настоящего изобретения,
Фиг. 27 изображает пример пользовательского интерфейса для оценки потребления мощности дата-центром согласно варианту осуществления настоящего изобретения,
Фиг. 28 изображает пример пользовательского интерфейса для оценки потребления мощности дата-центром согласно варианту осуществления настоящего изобретения,
Фиг. 29 изображает пример пользовательского интерфейса для оценки потребления мощности дата-центром согласно варианту осуществления настоящего изобретения,
Фиг. 30 изображает представление высокого уровня способов для оптимизации дата-центра согласно варианту осуществления настоящего изобретения.
Осуществление изобретения
Фиг. 1 показывает схему, изображающую архитектуру 100 сети для анализа потребления мощности согласно варианту осуществления настоящего изобретения. Фиг. 1 - это упрощенный вид архитектуры 100 сети, которая может включать дополнительные элементы, которые не показаны. Архитектура 100 сети может содержать дата-центры 110(1)-110(М). Хотя обычно они представляют собой более крупные ресурсы, в целях настоящего раскрытия под дата-центрами могут подразумеваться крупные структуры, предназначенные для поддержания множества вычислительных платформ, помещения для серверов или даже монтажный шкаф, поддерживающий одну вычислительную платформу. Дата-центр 110(1) может содержать множество блоков 110 и блоков 130. Блоки 110 и 130 могут содержать один или более компонентов 120. Дата-центр 110(1) может также содержать источник 150 питания и охлаждающие средства 160. Другие компоненты и устройства могут содержаться в дата-центре (например, запоминающие блоки, библиотеки лент, оптические дисководы с автоматической сменой дисков и мейнфреймы). Блоки 110 и 130 могут быть коммуникативно соединены друг с другом и/или другими компонентами. Блоки 110 и 130 могут также быть коммуникативно соединены с сетью 190.
Согласно некоторым вариантам осуществления, блоки 110 и 130 могут представлять собой стеллажи для удержания одного или более вычислительного устройства и/или компонента (например, компонентов 120). Блоки 110 могут быть расположены в первом проходе в дата-центре, а блоки 130 могут быть расположены во втором проходе в дата-центре. Блоки 110 и 130 и компоненты 120 могут питаться от одного или более источников 150 питания. Блоки 110 и 130 и компоненты 120 могут выделять тепло внутрь дата-центра и могут охлаждаться охлаждающими средствами 160.
Источник 150 питания может представлять собой один или более блоков распределения мощности (БРМ), источник бесперебойного питания (ИБП), распределительные блоки электрической сети и/или генератор. Источник 150 питания может содержать интерфейс с доступом через сеть для удаленного управления и/или мониторинга (например, интерфейс RS-232 и/или интефейс Ethernet). Источник 150 питания может предоставлять данные одному или более устройству в дата-центре 110 и принимать данные от одного или более устройства в дата-центре 110. Источник 150 питания может также предоставлять данные платформе 170 и принимать данные от платформы 170 через сеть 190.
Охлаждающие средства 160 могут представлять собой один или более кондиционеров воздуха помещения для ЭВМ или другое оборудование для мониторинга температуры, оборудование для контроля температуры и оборудование для контроля влажности. Охлаждающие средства 160 могут предоставлять данные одному или более устройству в дата-центре 110 и принимать данные от одного или более устройства в дата-центре 110. Охлаждающие средства 160 могут также предоставлять данные платформе 170 и принимать данные от платформы 170 через сеть 190.
Сеть 190 может представлять собой локальную сеть (LAN), крупномасштабную сеть (WAN), Интернет, сотовую сеть, спутниковую сеть или иную сеть, которая обеспечивает возможность коммуникации между устройствами, коммуникативно соединенными с сетью 190. Сеть 190 может также включать одну сеть из названных выше в качестве примера, работающую как самостоятельная сеть, или любое количество сетей из названных выше в качестве примера, работающих во взаимодействии друг с другом. Сеть 190 может использовать один или более протокол одного или более клиента или сервера, которые коммуникативно соединены с нею. Сеть 190 может переходить с протоколов одних сетевых устройств на протоколы других сетевых устройств. Хотя сеть 190 изображена как одна сеть, необходимо понимать, что, согласно одному или более варианту осуществления, сеть 190 может содержать множество связанных сетей.
Согласно некоторым вариантам осуществления, компоненты 120 могут представлять собой вычислительные платформы (например, ЭВМ-серверы, блэйд-серверы, сетевые компоненты, сетевые запоминающие устройства или иные устройства). Согласно некоторым вариантам осуществления, компоненты 120 могут представлять собой компоненты более крупного устройства (например, карты для сетевого устройства или сервера). Компоненты 120 и/или блоки 110 и 130 могут использоваться для одной или более цели (например, в качестве архивных платформ, вспомогательных серверов, сетевых запоминающих устройств, мультимедиа-серверов, серверов электронной почты, платформы менеджмента документов, поисковых серверов организаций и серверов приложений).
Описание, приведенное ниже, описывает сетевые элементы, ЭВМ и/или компоненты системы и способа для анализа потребления мощности, которые могут включать один или более модулей. В настоящем документе термин «модуль» можно понимать как относящийся к вычислительному программному обеспечению, аппаратно реализованному программному обеспечению, аппаратному обеспечению и/или различным их сочетаниям. Модули, однако, не следует истолковывать как программное обеспечение, которое не воплощено на аппаратном обеспечении, аппаратно реализованном программном обеспечении или не записано на перезаписываемом запоминающем устройстве (т.е. модули не являются программным обеспечением в чистом виде). Необходимо отметить, что модули приводятся в качестве примера. Модули могут комбинироваться, интегрироваться, отделяться и/или дублироваться для поддержания различных приложений. Кроме того, функция, описываемая в настоящем документе как выполняемая на конкретном модуле, может выполняться на одном или более другом модуле и/или одним или более другим устройством вместо выполнения этой функции на указанном конкретном модуле или в дополнение к выполнению этой функции на указанном конкретном модуле. Далее, модули могут быть воплощены на нескольких устройствах и/или других компонентах в одном месте или на удалении друг от друга. Кроме того, модули можно перемещать от одного устройства и добавлять к другому устройству и/или включать в оба устройства.
Платформа 170 может быть коммуникативно соединена с сетью 190. Согласно некоторым вариантам осуществления, платформа 170 может представлять собой один или более хост или одну или более вычислительную платформу, который или которая поддерживает модуль 172 анализа потребления мощности. Модуль 172 анализа потребления мощности может анализировать потребление мощности одного или более из дата-центров 110, блоков 110, блоков 130, компонентов 120, источника 150 питания, охлаждающих средств 160 и подкомпонентов одного или более элемента. Модуль 172 анализа потребления мощности может также анализировать температурные профили (например, температуру, выделение тепла и т.д.) одного или более из дата-центров 110, блоков 110, блоков 130, компонентов 120, источника 150 питания, охлаждающих средств 160 и подкомпонентов одного или более элемента. Согласно некоторым вариантам осуществления, модуль 172 анализа потребления мощноовти может быть расположен удаленно от дата-центров 110 (например, в обслуживающем центре). Согласно некоторым вариантам осуществления, один или более компонентов или модулей модуля 172 анализа потребления мощности может содержаться в дата-центре 110 или быть расположен рядом с дата-центром 110.
Запоминающее устройство 192 для данных может представлять собой запоминающее устройство с доступом через сеть и может быть локальным, удаленным или одновременно и первым, и вторым по отношению к платформе 170. Запоминающее устройство 192 для данных может использовать избыточный массив независимых жестких дисков (RAID), пленку, диск, сеть хранения данных (SAN), основанную на протоколе iSCSI (Интернет интерфейс малых вычислительных систем) SAN, основанную на волоконном канале SAN, общую межсетевую файловую систему (CIFS), подключаемое к сети запоминающее устройство (NAS), сетевую файловую систему (NFS) или иное запоминающее устройство с доступом через ЭВМ. В одном или более варианте осуществления запоминающее устройство 192 для данных может представлять собой базу данных, такую как Oracle database, Microsoft SQL Server Database, DB2 database, MySQL database, Sybase database, объектно-ориентированная база данных, иерархическая база данных или другая база данных. В некоторых вариантах осуществления запоминающее устройство 192 для данных может использовать одноуровневую архитектуру файла или XML (расширяемый язык разметки) для хранения данных.
Запоминающее устройство 192 для данных может хранить данные о надежности производителя и паспортном потреблении мощности по широкому разнообразию ресурсов дата-центров. Эти данные могут использоваться для оценки потребления мощности ресурсами и надежности ресурсов. Данные могут включать данные о ресурсе, профильные данные, геопространственные данные и данные о взаимозависимости ресурсов в одном или более дата-центре. Эти типы данных могут быть выявленными, импортированными или введенными вручную. Статистические данные, данные анализа и данные о надежности могут представлять собой результаты расчетов, собранные данные опросов либо их сочетание. Запоминающее устройство 192 для данных может вести данные путем пополнения и/или исправления данных в базе данных на основании информации, принимаемой от дата-центров.
Модуль 172 анализа потребления мощности может содержать аналитический модуль 174, выявляющий модуль 176, собирающий данные модуль 178 и оптимизирующий модуль 180.
Выявляющий модуль 176 может использовать один или более способов для идентификации и каталогизации ресурсов дата-центра. Например, выявляющий модуль 176 может использовать одно или более из следующего: SNMP, SMI-S, IPMI, WMI, SSH, BACNet, Modbus и/или индивидуально созданные протоколы для идентификации ресурсов дата-центра. Согласно некоторым вариантам осуществления, выявляющий модуль 176 может предоставлять пользовательский интерфейс, обеспечивающий возможность ручного ввода ресурсов, и/или интерфейс программирования приложений (API), обеспечивающий возможность подачи информации о ресурсе (например, подачи с форматированием в XML). Согласно одному или более вариантам осуществления, инструмент фиксации мгновенного состояния, инструмент экспорта или иной инструмент может иметься для выявления и экспорта данных в портативное электронное запоминающее устройство из дата-центра, который может быть выполнен без возможности удаленного доступа (например, находиться в учреждении с режимом изоляции).
Выявляющий модуль 176 может предоставлять данные собирающему данные модулю 178 и/или запоминающему устройству 192 для данных.
Собирающий данные модуль 178 может осуществлять мониторинг выявленных ресурсов дата-центра для сбора и сохранения показателей одного или более ресурсов для анализа. Показатели ресурса могут включать, например, данные о рабочих характеристиках процессора, загруженность памяти, загруженность и рабочие характеристики запоминающего устройства, показания датчиков температуры, показания таблицы процессов, потребление мощности БРМ, информацию о статусе ИБП, информацию о статусе кондиционера воздуха помещения для ЭВМ, информацию о статусе оборудования для поддержания требуемого качества электроэнергии, информацию о конфигурации и статусе переключателей и информацию о статусе охлаждающих средств. Показатели ресурса могут собираться с использованием одного или более протокола и/или API (например, SNMP). Показатели и другие данные могут сохраняться в электронном запоминающем устройстве (например, запоминающем устройстве 192 для данных) или извлекаться из электронного запоминающего устройства (например, запоминающего устройства 192 для данных).
Аналитический модуль 174 может использовать сохраненные показатели (например, показатели из запоминающего устройства 192 для данных) для оценки или расчета потребления мощности. Аналитический модуль 174 может также суммировать потребление мощности одним или более компонентами (например, определять суммарное потребление мощности для сервера, зоны или дата-центра). Аналитический модуль 174 может определять или оценивать температурный профиль одного или более компонентов. Аналитический модуль 174 может оценивать температурный профиль на основании принимаемых данных о температуре, оцененных данных о температуре (например, основанных на потреблении мощности), других данных (например, данных о загруженности или данных об активности) или их сочетания. Аналитический модуль 174 может оценивать потребность в мощности для охлаждающего блока на основании одного или более температурного профиля или обобщенных температурных профилей (например, обобщенных температурных профилей для компонентов сервера, для устройств в стеллаже, для устройств в зоне, для стеллажей в зоне, для прохода в дата-центре, для всего дата-центра и т.д.). Аналитический модуль 174 может использовать вычислительную гидродинамику для генерации температурных профилей. Согласно некоторым вариантам осуществления, аналитический модуль 174 может использовать данные, относящиеся к логической конфигурации одного или более устройств, о чем говорится более подробно со ссылкой на Фиг. 2 ниже.
Оптимизирующий модуль 180 может использовать данные анализа от аналитического модуля 174 для идентификации одной или более проблем. Оптимизирующий модуль 180 может генерировать и предоставлять одно или более предложение и/или решение для идентифицированных проблем. Оптимизирующий модуль 180 может выполнять моделирование для идентификации и иллюстрации действия предлагаемых изменений. Согласно некоторым вариантам осуществления, одна или более стратегия может быть использована для предложения улучшений. Например, могут идентифицироваться неиспользуемые компоненты (например, неиспользуемые серверы). Если возможно, неиспользуемые компоненты могут устраняться (например, отключаться от питания и/или удаляться из дата-центра). Недостаточно используемые компоненты могут комбинироваться, и один или более компонент может удаляться (например, нагрузка может быть перенесена с первого сервера на второй сервер, и освободившийся от нагрузки сервер может быть отключен от питания и/или удален). Неэффективные компоненты могут модернизироваться или заменяться (например, может выполняться сравнение с другим, альтернативным, оборудованием по такому параметру, как соотношение между количеством транзакций в секунду или количеством передаваемых пакетов данных в секунду, с одной стороны, и потреблением мощности и выделением тепла, с другой стороны). Могут идентифицироваться горячие точки. Вычислительная гидродинамика может использоваться для генерации моделей распределения температур внутри дата-центра. Размещение оборудования (либо перестановка существующего оборудования, либо размещение нового оборудования) может быть рекомендовано на основании тепловых карт зоны, множества зон или дата-центра. Температуры могут суммироваться по зонам. Пользователи или администраторы могут формировать зоны по своему усмотрению так, чтобы они включали компоненты, отдельные устройства, множество устройств, стеллаж, множество стеллажей, проход через дата-центр или другие области либо части дата-центра. Зоны могут объединять компоненты и/или устройства вертикально (например, верх и низ в каждом стеллаже), горизонтально (например, все нижние ячейки или установочные места во множестве стеллажей или две верхние ячейки или два верхних установочных места во множестве стеллажей) или в иных направлениях (например, через горячие или холодные проходы либо вдоль одного прохода). Согласно некоторым вариантам осуществления, охлаждающие вентиляционные отверстия, перфорированная напольная плитка или другие охлаждающие структуры могут сменять друг друга для обеспечения более эффективной доставки охлаждения к более горячим областям дата-центра или для внедрения тепловых барьеров с целью создания разделения между горячими проходами и холодными проходами. Это может быть осуществлено в дополнение к одной или более другой стратегии или вместо одной или более другой стратегии. Согласно некоторым вариантам осуществления, оптимизирующий модуль 180 может использовать данные, относящиеся к логической конфигурации одного или более устройств, как описано более подробно со ссылкой на Фиг. 2 ниже.
Платформа 170 может находиться в коммуникации с несколькими дата-центрами 110 для предоставления дата-центрам данных об оценке потребления мощности, а в некоторых вариантах осуществления - принятой информации, относящейся к конфигурации дата-центров, данных о загруженности вычислительных машин на физическом и/или логическом уровне и/или данных о потреблении мощности, и/или данных о выделении тепла.
В некоторых примерах информация, предоставляемая дата-центру модулем 172 анализа потребления мощности, может позволять администраторам и/или программным контрольным процессам в дата-центре определять или оценивать потребление мощности и/или выделение тепла оборудованием в дата-центре. В некоторых примерах она (информация) предоставляет потребление мощности отдельными вычислительными машинами или суммарное потребление мощности более крупными блоками, такими как группы машин (например, все стеллажи). В некоторых примерах может определяться потребление мощности для более мелких составляющих, например конкретных физических компонентов машин, либо может определяться доля потребления мощности разных процессов или приложений, выполняемых на вычислительной машине.
Рассмотрим Фиг. 2. Физическое представление блока 210 может представлять собой физическое представление вычислительной машины (например, ЭВМ-сервера). Физическое представление блока 210 может включать некоторое количество отдельных физических компонентов 220, например микросхем процессора, контроллеров дисков и полупроводниковых запоминающих устройств. Кроме того, физическое представление блока 210 может также включать некоторое количество устройств 230 мониторинга, которые могут осуществлять мониторинг физических атрибутов компонентов, таких как потребление мощности (например, в ваттах), выделение тепла (например, температура радиатора) и рабочие характеристики (например, тактовая частота процессора, скорость вращения диска, скорость передачи данных). Устройства мониторинга могут быть выполнены с возможностью доступа через программное обеспечение.
Продолжим рассмотрение Фиг. 2. Логическое представление блока 210 может представлять собой логическое представление той же самой физической машины или платформы, что показано на физическом представлении блока 210. Логическое представление блока 210 может включать некоторое количество логических/программных компонентов 240-266. Например, логическое представление блока 210 может включать компонент 240-операционную систему/ядро и процессы 250. В одном или более вариантах осуществления логическое представление блока 210 может включать средство мониторинга и/или среду 260 виртуализации (например, «гипервизор») для виртуальных компонентов 262 машины, которые могут сами включать процессы 264, 266, и другие программные компоненты. Логическое представление блока 210 может также включать одно или более программное средство 268 мониторинга, которое может предоставлять атрибуты логических/программных компонентов, такие как загруженность процессора, интенсивность транзакций (например, количество запросов к базе данных в секунду) и интенсивность обмена данными (например, количество сообщений или пакетов пересылаемых данных в секунду на различных уровнях протокола), а также информацию о конфигурации, такую как наименования активных процессов, виртуальных машин и т.д.
Информация от устройств 230 мониторинга и средств 268 мониторинга может передаваться в платформу 170, которая может включать модуль 172 анализа потребления мощности. Согласно некоторым вариантам осуществления, этот модуль может оценивать потребление мощности физическими и/или логическими компонентами и/или вычислительными машинами/программными средами. Модуль 172 анализа потребления мощности может использовать запоминающее устройство 192 для данных, которое может включать оцененные статистические параметры, для обеспечения составления карт, начиная картами на основе данных о загруженности и заканчивая картами на основе оцененного потребления мощности, для различных элементов, представленных в запоминающем устройстве 192 для данных. Оцененные потребления мощности могут передаваться оптимизирующему модулю 180, который может обеспечивать табличное или графическое представление оцененного потребления мощности.
Согласно некоторым вариантам осуществления, платформа 170 может также включать аналитический модуль 274, который может быть использован для обновления запоминающего устройства 192 для данных. Например, данные для нового элемента (например, не видимого раньше компонента, который найден в дата-центре) могут оцениваться на основании данных, принимаемых от дата-центра, или статистические параметры для существующих компонентов могут уточняться на основании дополнительных данных мониторинга, принимаемых от дата-центров. Иными словами, запоминающее устройство 192 для данных может изначально иметь относительно неточные или чрезмерно заниженные оценки для компонента, для которого имеется мало данных, и аналитический модуль может быть использован для предоставления информации мониторинга дата-центра с целью повышения точности оценок.
В качестве примера, данные мониторинга машины от устройств 230 мониторинга могут быть отнесены к конкретной вычислительной машине (например, блоку 210). Эти отнесенные данные могут предоставляться аналитическому модулю 174, определяющему потребление мощности. Данные мониторинга машины могут включать данные для физических компонентов и/или данные для логических компонентов (например, собранные от устройств 230 и средств 268 мониторинга соответственно). Аналитический модуль 174, определяющий потребление мощности, может использовать профиль потребления мощности из запоминающего устройства 192 для данных, который может включать данные, относящиеся к каждому типу компонентов (например, привязанные к идентификатору типа компонентов). Это может позволять составлять карты, начиная картами на основе данных мониторинга и заканчивая картами на основе оценки потребления мощности, для каждого компонента (например, на основании параметрической функции, такой как полиноминальная кривая). Выходные данные аналитического модуля 174, определяющего потребление мощности, могут представлять собой суммарное потребление мощности, а также распределение потребления мощности между различными физическими и логическими компонентами.
Согласно некоторым вариантам осуществления, оценки потребления мощности, относящиеся к множеству вычислительных машин, могут сочетаться с данными о местоположении этих машин для определения пространственного профиля потребления мощности для дата-центра. В некоторых примерах этот пространственный профиль может также принимать во внимание местоположение охлаждающих устройств для определения оцененного выделения тепла или температурного профиля.
Необходимо понимать, что в то время, как в некоторых вариантах осуществления функции анализа и предсказания потребления мощности могут быть централизованными, а дата-центры предоставляют данные мониторинга централизованным средствам, где данные о профилях потребления мощности могут комбинироваться для определения оцененного потребления мощности, в других вариантах осуществления данные о профилях потребления мощности могут распределяться на оценивающие потребление мощности компоненты, которые могут быть локальными по отношению к дата-центру или даже локальными по отношению к отдельным вычислительным машинам. В некоторых подобных вариантах осуществления данные мониторинга либо суммированные или обработанные формы этих данных могут предоставляться централизованной вычислительной платформе, где профильные данные о потреблении мощности могут пополняться и/или уточняться.
Фиг. 3 показывает схему вычислительной системы 300 согласно варианту осуществления. Вычислительная система 300 может быть подходящей для воплощения способов согласно одному или более вариантам осуществления. Вычислительная система 300 может представлять собой клиент, сервер, узел сети, шлюз или другую способную работать в сети процессинговую платформу. Вычислительная система 300 может включать шину 302, которая может быть коммуникативно соединена с одним или более компонентом системы 300, таким как, например, процессор 304 ЭВМ; память 306 (например, RAM (оперативная память), ROM (постоянная память), flash-RAM и т.д.); контроллер 308 ввода-вывода; сетевой интерфейс 310; интерфейс 312 запоминающего устройства, обеспечивающий возможность соединения с накопителем 314 на фиксированном диске; дисковод 316 для магнитных дисков, предназначенный для приема извлекаемого магнитного диска 318; дисплей 322, присоединенный посредством дисплейного адаптера 320; порты 324 и 328 последовательного ввода-вывода; клавиатура 334, присоединенная посредством контроллера 332 клавиатуры; SCSI-адаптер 336, предназначенный для присоединения к SCSI-устройству 338 (например, запоминающему устройству, сканеру и т.д.), дисковод 340 для оптических дисков, предназначенный для приема оптического диска 342; и мультимедиа-устройство 346 (например, динамик, камера, микрофон и т.д.), присоединенное посредством мультимедиа-интерфейса 344. Могут также иметься другие устройства, такие как указывающее устройство 330 (например, мышь, трекбол, джойстик и т.д., присоединенные через порт 328 последовательного ввода-вывода), модем 326 (присоединенный к шине 302 через порт 324 последовательного ввода-вывода), устройство 348 менеджмента потребления мощности и батарея 350.
Шина 302 может обеспечивать обмен данными между процессором 304 ЭВМ и памятью 306 и одним или более другим компонентом. Согласно некоторым вариантам осуществления, память 306 может представлять собой основную память, в которую могут быть загружены операционная система и одна или более программа-приложение. Приложения или другое программное обеспечение могут храниться на читаемом ЭВМ носителе и быть доступными с этого читаемого ЭВМ носителя, такого как дисковод для жестких дисков (например, накопитель 314 на фиксированном диске), дисковод для оптических дисков (например, дисковод 340 для оптических дисков), дисковод 316 для магнитных дисков или иное запоминающее устройство (например, запоминающее устройство с доступом через сеть, доступ к которому может быть осуществлен через сетевой интерфейс 310). Например, присваивающий расширение модуль 114 может находиться в памяти 306.
Интерфейс 312 запоминающего устройства может быть соединен со стандартным читаемым ЭВМ запоминающим устройством для хранения и извлечения информации, таким как накопитель 314 на фиксированном диске. Накопитель 314 на фиксированном диске может быть частью вычислительной системы 300 или может быть отдельным с доступом к нему через другие интерфейсные системы. Модем 326 может обеспечивать прямое соединение с удаленным сервером через линию телефонной связи или с Интернетом через поставщика услуг Интернет. Сетевой интерфейс 310 может обеспечивать прямое соединение с удаленным сервером через прямую линию связи или с Интернетом через РоР (точку присутствия).
Устройство 348 менеджмента потребления мощности может осуществлять мониторинг уровня потребления мощности батареи 350. Согласно некоторым вариантам осуществления, батарея 350 может представлять собой источник бесперебойного питания (ИБП), расположенный либо локально, либо удаленно по отношению к вычислительной системе 300. В этих вариантах осуществления устройство 348 менеджмента потребления мощности может предоставлять информацию об уровне потребления мощности ИБП.
Другие устройства или компоненты могут быть присоединены таким же образом (например, цифровые камеры, ИБП и т.д.). Компоненты, показанные на фиг. 3, не являются обязательными, и один или более из изображенных компонентов может отсутствовать в других вариантах осуществления. В некоторых вариантах осуществления могут иметься несколько компонентов одного и того же типа (например, несколько процессоров 304 ЭВМ, несколько интерфейсов 312 запоминающего устройства и т.д.). Устройства и подсистемы могут быть соединены способами, отличными от тех, что показаны на фиг. 3. Правила для воплощения одного или более вариантов осуществления могут храниться в читаемом ЭВМ запоминающем устройстве, таком как одно или более из следующего: память 306, накопитель 314 на фиксированном диске, оптический диск 342 или извлекаемый магнитный диск 318. Правила для воплощения одного или более вариантов осуществления могут также быть приняты через один или более интерфейс и сохранены в памяти. Операционная система, имеющаяся в вычислительной системе 300, может представлять собой MS-WINDOWS, UNIX, Linux, Mac OS, Mac OS X или другую операционную систему.
Рассмотрим Фиг. 4, на которой показан модуль 410 анализа потребления мощности согласно варианту осуществления настоящего изобретения. Как показано, модуль 410 анализа потребления мощности может содержать один или более компонентов, включая модуль 412 детекции компонента, модуль 414 профиля компонента, модуль 416 мониторинга компонента, модуль 418 логического анализа, модуль 420 анализа компонента, модуль 422 анализа зоны и центра, модуль 424 стратегии оптимизации и модуль 426 записи ошибок и отчетов.
Модуль 412 детекции компонента может использовать один или более способов для идентификации и каталогизации ресурсов дата-центра. Например, модуль 412 детекции компонента может использовать одно или более из следующего: SNMP, SMI-S, IPMI, WMI, SSH, BACNet и Modbus и/или индивидуально созданные протоколы для идентификации ресурсов дата-центра. Согласно некоторым вариантам осуществления, модуль 412 детекции компонента может предоставлять пользовательский интерфейс, обеспечивающий возможность ручного ввода ресурсов, и/или API, обеспечивающий возможность подачи информации о ресурсе (например, подачу с форматированием в XML). Согласно одному или более вариантам осуществления, инструмент фиксации мгновенного состояния, инструмент экспорта или иной инструмент может иметься для выявления и экспорта данных в портативное электронное запоминающее устройство из дата-центра, который может быть выполнен без возможности удаленного доступа (например, находиться в учреждении с режимом изоляции).
Модуль 414 профиля компонента может получать и сохранять данные о надежности поставщика и профильные данные о паспортном потреблении мощности по широкому разнообразию ресурсов дата-центра. Эти данные могут быть использованы для оценки потребления мощности и надежности ресурсов. Данные могут включать данные о ресурсе, профильные данные, геопространственные данные и данные о взаимозависимости ресурсов в одном или более дата-центре. Эти типы данных могут быть выявленными, импортированными или введенными вручную. Статистические данные, данные анализа и данные о надежности могут представлять собой результаты вычислений, собранные данные опросов ресурсов либо их сочетание. Модуль 414 профиля компонента может вести данные путем пополнения и/или исправления данных в базе данных на основании информации, принимаемой от дата-центров.
Модуль 416 мониторинга компонента может осуществлять мониторинг выявленных ресурсов дата-центра для сбора и сохранения показателей одного или более ресурсов для анализа. Показатели ресурса могут включать, например, данные о рабочих характеристиках процессора, загруженность памяти, загруженность и рабочие характеристики запоминающего устройства, показания датчиков температуры, показания таблицы процессов, потребление мощности БРМ, информацию о статусе ИБП, информацию о статусе кондиционера воздуха помещения для ЭВМ, информацию о статусе оборудования для поддержания требуемого качества электроэнергии, информацию о конфигурации и статусе переключателей и информацию о статусе охлаждающих средств. Показатели ресурса могут собираться с использованием одного или более протокола и/или API (например, SNMP). Показатели и другие данные могут сохраняться в электронном запоминающем устройстве (например, запоминающем устройстве 192 для данных) или извлекаться из электронного запоминающего устройства (например, запоминающего устройства 192 для данных).
Модуль 418 логического анализа может использовать сохраненные показатели (например, показатели из запоминающего устройства 192 для данных) для оценки или расчета потребления мощности. Модуль 418 логического анализа может использовать данные, относящиеся к логической конфигурации одного или более устройств (например, загруженность процессора, интенсивность транзакций (например, количество запросов к базе данных в секунду) и интенсивность обмена данными (например, количество сообщений или пакетов пересылаемых данных в секунду на различных уровнях протокола), а также такую информацию о конфигурации, как наименования активных процессов, виртуальных машин и т.д.). Наименования активных процессов могут быть использованы для оценки потребления мощности на основании статистических данных, профильных данных или иных данных (например, процесс отчета базы данных может быть известен как процесс интенсивного потребления мощности, характеризующийся значительной загруженностью ЭВМ и интенсивным обращением к дискам). Карта загруженности логических ресурсов может быть составлена для одного или более физического компонента или устройства для оценки потребления мощности, выделения тепла и других факторов, влияющих на издержки и рабочие характеристики дата-центра.
Модуль 420 анализа компонента может использовать сохраненные показатели (например, показатели из запоминающего устройства 192 для данных) для оценки или расчета потребления мощности для одного или более компонентов. Модуль 420 анализа компонента может использовать принимаемые текущие измерения, статистические данные и профильные данные (например, спецификации производителя или другие сведения, относящиеся к компоненту или устройству) для расчета и/или оценки потребления мощности и температурных свойств для компонентов или устройств. Потребление мощности устройством или компонентом может быть использовано для оценки выделения тепла и соответствующих издержек на охлаждение.
Модуль 422 анализа зоны и центра может суммировать потребление мощности одного или более компонента, устройства либо одной или более части дата-центра (например, определять суммарное потребление мощности для сервера, зоны или дата-центра). Модуль 422 анализа зоны и центра может определять или оценивать температурный профиль одного или более компонентов. Модуль 422 анализа зоны и центра может оценивать температурный профиль на основании принимаемых данных о температуре, оцененных данных о температуре (например, основанных на потреблении мощности) или их сочетания. Модуль 422 анализа зоны и центра может оценивать требуемую мощность для охлаждающего блока на основании одного или более температурного профиля или суммарного температурного профиля (например, суммированных температурных профилей для компонентов сервера, для устройств в стеллаже, для устройств в зоне, для стеллажей в зоне, для прохода в дата-центре, для всего дата-центра и т.д.). Модуль 422 анализа зоны и центра может использовать вычислительную гидродинамику для генерации температурных профилей.
Модуль 424 стратегии оптимизации может использовать данные анализа для идентификации одной или более проблем. Модуль 424 стратегии оптимизации может генерировать и предоставлять одно или более предложение и/или решение для идентифицированных проблем. Модуль 424 стратегии оптимизации может выполнять моделирование для идентификации и иллюстрации действия предлагаемых изменений. Согласно некоторым вариантам осуществления, одна или более стратегия может быть использована для предложения улучшений. Например, могут идентифицироваться неиспользуемые компоненты (например, неиспользуемые серверы (т.е. зомби-серверы)). Если возможно, неиспользуемые компоненты могут устраняться (например, отключаться от питания и/или удаляться из дата-центра). Недостаточно используемые компоненты могут комбинироваться, и один или более компонентов может удаляться (например, нагрузка может быть перенесена с первого сервера на второй сервер, и освободившийся от нагрузки сервер может быть отключен от питания и/или удален). Неэффективные компоненты могут модернизироваться или заменяться (например, может выполняться сравнение с другим, альтернативным, оборудованием по такому параметру, как соотношение между количеством транзакций в секунду или количеством передаваемых пакетов данных в секунду, с одной стороны, и потреблением мощности и выделением тепла, с другой стороны). Могут идентифицироваться горячие точки. Вычислительная гидродинамика может использоваться для генерации моделей распределения температур внутри дата-центра. Пользователи или администраторы могут формировать зоны по своему усмотрению так, чтобы они включали компоненты, отдельные устройства, множество устройств, стеллаж, множество стеллажей, проход через дата-центр или другие области либо части дата-центра. Зоны могут объединять компоненты и/или устройства вертикально (например, верх и низ в каждом стеллаже), горизонтально (например, все нижние ячейки или установочные места во множестве стеллажей или две верхние ячейки или два верхних установочных места во множестве стеллажей) или в иных направлениях (например, через горячие или холодные проходы либо вдоль одного прохода). Согласно некоторым вариантам осуществления, модуль 424 стратегии оптимизации может использовать данные, относящиеся к логической конфигурации. Выходные данные модуля 424 стратегии оптимизации могут представлять собой предназначенные для пользователя изображения (например, веб-страницы), отчеты, уведомления (например, посредством SMS-сообщений, электронной почты и т.д.) и другие электронные сообщения.
Модуль 426 записи ошибок и отчетов может производить записи, отчеты или другую информацию, относящуюся к анализу потребления мощности компонентами вычислительной платформы.
Рассмотрим Фиг. 5, на которой показан способ 500 для анализа потребления мощности компонентами вычислительной платформы согласно варианту осуществления настоящего изобретения. Блоком 502 способ 500 может начаться.
На блоке 504 может быть принята информация, относящаяся к компоненту. Информация может быть выявлена или может быть принята с выхода дата-центра или посредством ввода пользователем. При выявлении может быть использован один или более способов для идентификации и каталогизации ресурсов дата-центра. Например, при выявлении может быть использовано одно или более из следующего: SNMP, (SMI-S), IPMI, WMI, SSH, BACNet и Modbus и/или индивидуально созданные протоколы для идентификации ресурсов дата-центра. Согласно некоторым вариантам осуществления, процессы выявления могут предоставлять пользовательский интерфейс, обеспечивающий возможность ручного ввода ресурсов, и/или API, обеспечивающий возможность подачи информации о ресурсах (например, подачи с форматированием в XML). Согласно одному или более вариантам осуществления, инструмент фиксации мгновенного состояния, инструмент экспорта или иной инструмент может иметься для выявления и экспорта данных в портативное электронное запоминающее устройство из дата-центра, который может быть выполнен без возможности удаленного доступа (например, находиться в учреждении с режимом изоляции).
На блоке 506 способ может определять, опознан ли выявленный компонент. Способ 500 может осуществлять доступ к электронному репозиторию для попытки найти соответствие выявленному компоненту, используя один или более выявленный атрибут. Если компонент опознан, способ 500 может перейти к блоку 512. Если компонент не опознан, способ может перейти к блоку 508.
На блоке 508 могут быть запрошены данные, относящиеся к выявленному, но не опознанному компоненту. Способ 500 может отправлять электронное сообщение пользователю или администратору (например, посредством SMS-сообщения или электронной почты), может перечислить неопознанные компоненты в пользовательском интерфейсе или в отчете либо может иным образом запросить у пользователя или администратора профильные данные, относящиеся к неопознанному компоненту.
На блоке 510 через пользовательские средства ввода или иной интерфейс могут быть приняты данные (например, обновление известных профильных данных согласно новой спецификации производителя). После того как профильные данные приняты, способ может обновить репозиторий с профильными данными или иным образом обработать принятые профильные данные. Способ может затем перейти к блоку 514.
На блоке 512 профильные данные компонента могут быть извлечены из электронного репозитория. Профильные данные могут включать статистическое и/или оцененное потребление мощности, температурные свойства (например, количество генерируемого тепла), относящиеся к этому компоненту логические процессы (например, драйверы) и другие данные.
На блоке 514 может быть составлена карта логической инфраструктуры или логических компонентов для физического компонента. Например, компоненты ядра и/или операционной системы, процессы, потоки, приложения, виртуальные машины и/или процессы, потоки и приложения виртуальных машин могут быть отнесены к физическому компоненту. Например, процессы отчета могут быть отнесены к нагрузке на массив дисков или на иное электронное запоминающее устройство для содействия оценке потребления мощности и количества генерируемого тепла.
На блоке 516 может осуществляться мониторинг физических и/или логических компонентов. Мониторинг может собирать данные на одном или более уровнях детализации (например, процессор, контроллер дисков, блэйд-сервер, стеллаж, зона, проход дата-центра, дата-центр, части дата-центров, относящиеся к организационной единице/клиенту/отделу учета затрат предприятия и т.д.).
На блоке 518 потребление мощности и температурные свойства могут быть профилированы на основании сохраненных данных. Потребление мощности может также быть рассчитано на основании мониторинга логических и физических компонентов. Измеренное потребление мощности и/или оцененное потребление мощности могут усредняться, суммироваться или иным образом обрабатываться для определения потребления мощности на одном или более уровнях детализации. Типы и количества вычислений и оценок могут зависеть:
- от наличия измеренных показателей,
- от вероятности вмешательства в работу оборудования и влияния на работу оборудования либо создания нагрузки на оборудование при получении этих показателей,
- от наличия профилированных или статистических данных
и других факторов. В той степени, в какой это возможно, нагрузка на оборудование для получения данных может быть сведена к минимуму в дата-центре (например, данные могут собираться во время более низкого потребления мощности и оцениваться при более высоких нагрузках либо собираться, но передаваться во время более низкого потребления мощности).
На блоке 520 тепло, генерируемое и выделяемое одним или более компонентами, может оцениваться на основании измерений потребления мощности, оценок потребления мощности, данных о тепловом профиле и других факторов. Могут быть использованы расчеты вычислительной гидродинамики.
На блоке 522 способ 500 может определять, остались ли другие компоненты, которые требуется выявить и/или проанализировать. Если остались другие компоненты, которые требуется выявить и/или проанализировать, способ может вернуться к блоку 504. Если других компонентов не осталось, способ может перейти на блок 524.
На блоке 524 способ 500 может предоставить выходные данные, относящиеся к потреблению мощности. Выходные данные могут представлять собой предназначенные для пользователя изображения (например, веб-страницы), отчеты, уведомления (например, посредством SMS-сообщений, электронной почты и т.д.) и другие электронные сообщения.
Блоком 526 способ 500 может заканчиваться.
Рассмотрим Фиг. 6, где показан способ 600 анализа потребления мощности компонентами вычислительной платформы согласно варианту осуществления настоящего изобретения. Блоком 602 способ 600 может начаться.
На блоке 604 способ может анализировать потребление мощности и выходные данные о температуре для идентификации одной или более проблемы, одной или более горячей точки и/или одной или более стратегии оптимизации. Моделирование может выполняться для идентификации и иллюстрации действия предлагаемых изменений. Согласно некоторым вариантам осуществления, одна или более стратегия может быть использована для предложения улучшений. Один или более показатель может использоваться для определения загруженности, эффективности и параметров компонентов. Например, загруженность процессора, загруженность диска и схемы обращений, скорость передачи данных и другие факторы могут измеряться и сравниваться с потреблением мощности и/или выделением тепла.
На блоке 606 способ может определять, могут ли быть идентифицированы неиспользуемые компоненты (например, неиспользуемые серверы). Если неиспользуемые компоненты идентифицированы, способ может перейти на блок 608. Если неиспользуемые компоненты не идентифицированы, способ может перейти на блок 610.
На блоке 608 неиспользуемые компоненты могут быть устранены (например, отключены от питания и/или удалены из дата-центра).
На блоке 610 способ может определять, имеются ли недостаточно используемые компоненты. Если недостаточно используемые компоненты имеются, способ может перейти на блок 612. Если недостаточно используемых компонентов нет, способ может перейти на блок 614.
На блоке 612 нагрузка с одних недостаточно используемых компонентов может быть перенесена на другие недостаточно используемые компоненты и освободившиеся компоненты могут быть удалены (например, нагрузка может быть перенесена с первого сервера на второй сервер и освободившийся сервер может быть отключен от питания и/или удален).
На блоке 614 способ может определять, обнаружены ли неэффективные компоненты. Если неэффективные компоненты обнаружены, способ может перейти на блок 616. Если один или более неэффективный компонент не обнаружен, способ может перейти на блок 618.
На блоке 616 неэффективные компоненты могут быть модернизированы или заменены (например, имеющееся оборудование может быть сравнено с альтернативным оборудованием по такому параметру, как соотношение между количеством транзакций в секунду или количеством пакетов пересылаемых данных в секунду, с одной стороны, и потреблением мощности и выделением тепла, с другой стороны).
На блоке 618 компоненты и/или устройства могут быть категоризированы и/или организованы в зоны. Результаты анализа могут быть сгруппированы или суммированы по этим зонам. Горячие точки могут быть идентифицированы. Вычислительная гидродинамика может быть использована для генерации моделей распределения температур внутри дата-центра.
На блоке 620 может быть определено, имеются ли горячие точки. Если горячие точки идентифицированы, способ 600 может перейти на блок 622. Если горячие точки не идентифицированы, способ может закончиться блоком 624.
На блоке 622 размещение оборудования (либо изменение местоположения имеющегося оборудования, либо размещение нового оборудования) может быть рекомендовано на основании тепловых карт зоны, множества зон или дата-центра. Согласно некоторым вариантам осуществления, охлаждающие вентиляционные отверстия, перфорированная напольная плитка или другие охлаждающие структуры могут сменять друг друга для обеспечения более эффективной доставки охлаждения к более горячим областям дата-центра или для внедрения тепловых барьеров с целью создания разделения между горячими проходами и холодными проходами. Это может быть осуществлено в дополнение к одной или более другой стратегии или вместо одной или более другой стратегии.
Блоком 624 способ 600 может закончиться.
Согласно некоторым вариантам осуществления, программное обеспечение дата-центра, анализирующее потребление мощности, может выявлять ресурсы в дата-центре и периодически собирать данные о загруженности и о рабочей среде с целью задействования механизмов аналитики, оптимизации и контроля. Эти механизмы могут работать совместно для оптимизации потребления мощности, охлаждения, занимаемого пространства и надежности, с тем чтобы доводить до максимума эффективность дата-центра. Кроме того, одна или более часть данных о рабочей среде может накладываться в виде карты на карту используемых приложений. Это может обеспечивать альтернативное представление (коммерческого уровня) эффективности и загруженности дата-центра.
Согласно некоторым вариантам осуществления, программное обеспечение может выявлять, собирать, анализировать, а затем оптимизировать компоненты дата-центра. Согласно некоторым вариантам осуществления, для выполнения этих действий архитектура программного обеспечения может быть организована как совокупность трех основных логических процессинговых доменов. Эти процессинговые домены могут представлять собой выявляющий компонент, собирающий данные компонент и аналитический компонент. Логическое представление процессинговых доменов может представлять собой естественные границы, посредством которых наборы функций могут быть увязаны с контекстом, и работа тем самым может быть разделена. Кроме того, с функциональной точки зрения, каждый из этих доменов может быть независимым от других с возможностью его легкого извлечения или замены с минимальными последствиями для остальной системы.
Согласно некоторым вариантам осуществления, указанная архитектура может быть способна поддерживать продукт, который может быть предназначен для оперирования миллионами элементов дата-центра. Это может включать данные опросов, аналитику, оптимизацию, контроль, выявление и/или отчеты. Это, в свою очередь, может требовать от элементов архитектуры работать в распределенной среде, так чтобы работа могла быть разделена. Каждый компонент должен разрабатываться с учетом этих факторов.
Согласно одному или более варианту осуществления, архитектура может быть достаточно гибкой для того, чтобы обеспечивать возможность замены основных функциональных элементов без последствий для остальной системы. Для этого могут использоваться четко определенные интерфейсы и слои абстрагирования между основными компонентами системы. Кроме того, может быть вполне вероятным, что набор аналитических функций может изменяться очень часто. Поэтому может иметься оболочка для обеспечения возможности быстрого ввода в эксплуатацию и, возможно, географически распределенного создания новых аналитических функций. И, наконец, некоторые аналитические функции в системе могут представлять собой частично находящиеся на хосте сервисы, в то время как некоторые могут быть лишь локальными. Аналитическая оболочка может быть способна оперировать обеими этими моделями.
Многие из функций продукта, такие как анализ с использованием вычислительной гидродинамики и определенные отчеты, могут требовать для их выполнения порядка нескольких часов, согласно некоторым вариантам осуществления. Другие функции могут требовать несколько секунд. Что касается архитектуры в целом, задание и практическое воплощение рабочих характеристик могут выполняться в процессе разработки каждого отдельного компонента, поскольку к разным компонентам могут предъявляться разные требования по рабочим характеристикам. Каждая функция или каждый компонент системы может работать таким образом, чтобы не препятствовать выполнению важных задач, таких как опросы и интерактивные задачи, которые могут требовать быстрого ответа. Кроме того, программное обеспечение может иметь минимальное влияние на изделия, мониторинг которых оно осуществляет.
Согласно некоторым вариантам осуществления, логические представления основных компонентов в архитектуре могут быть категоризированы на несколько отдельных областей функциональности и ответственности. Фиг. 7 показывает основные компоненты согласно одному или более вариантам осуществления. Каждый компонент из фигуры 7 подробно описан ниже.
Выявляющий компонент может представлять собой единицу, ответственную за выявление объектов в дата-центре и их сохранение в базе данных ресурсов системы. Эти объекты могут включать как физические, так и логические ресурсы. Выявляющий компонент может быть способен поддерживать несколько протоколов и способов для осуществления этого, включая, без ограничения, SNMP, SMI-S, IPMI, WMI, SSH, BACNet, ModBus и/или индивидуально созданные протоколы.
Собирающий данные компонент может периодически собирать данные о загруженности и о рабочей среде, относящиеся к объектам в базе данных ресурсов. Как и выявляющий компонент, собирающий данные компонент может быть способен поддерживать широкое и изменяющееся разнообразие протоколов и способов.
Аналитический компонент может предоставлять комплексную оболочку и набор вспомогательных средств для анализа, оптимизации и контроля функций. Оболочка может иметь архитектуру «pipeline and filter» («конвейер и фильтры» - такое расположение компонентов, при котором выход одного компонента является входом следующего компонента), которая доводит до максимума повторное использование кода и обеспечивает возможность быстрого и независимого создания функций.
Объектная модель может представлять собой представление ресурсов, отнесенных данных и связей между ресурсами, хранящихся в электронном запоминающем устройстве (например, базе данных). Этот слой может проходить через все три процессинговых домена. Это может обеспечивать общий способ абстракции и доступа ко всем трем процессинговым доменам.
Объекты менеджмент-слоя и конфигурации, показанные на фигуре 7, могут представлять собой менеджмент-представление объектной модели. Они могут содержать объекты для передачи информации о статусе, конфигурации, синхронизации и контроле между пользовательскими интерфейсами и одной или более другой частью системы. Одной из их главных функций может быть обеспечение возможности менеджмент-представления объектной модели, которое отличается от ее представления в процессинговых доменах. На этом уровне могут быть включены слой перехода от объектной модели к менеджмент-модели.
Объекты слоя долговременного хранения, показанные на фиг. 7, могут представлять собой представление объектной модели в слое долговременного хранения. Это может быть слой, ответственный за переход между объектной моделью и объектами ее представления в слое долговременного хранения. Он может также содержать логику для менеджмента таблиц, запросов и администрирования базы данных.
Согласно некоторым вариантам осуществления, GxDB может представлять собой находящийся на хосте сервис, который может снабжать систему данными о надежности поставщика и паспортном потреблении мощности по широкому разнообразию ресурсов дата-центра. Эти данные могут использоваться совместно с выявляющим и аналитическим компонентами для оценки потребления мощности и надежности без периодического сбора текущих данных о загруженности ресурса. Аналитический компонент может содержать средства для обмена данными с определенными типами ресурсов в GxDB и логику для запроса информации об определенных типах ресурсов в GxDB.
Согласно по меньшей мере одному варианту осуществления, может иметься два основных типа данных, хранящихся в системе: данные, хранящиеся в GxDB и описывающие ресурсы и их характеристики, и данные, периодически собираемые или рассчитываемые. Данные о ресурсе, профильные данные, геопространственные данные и данные о взаимозависимости могут описывать ресурсы в дата-центре. Эти типы данных могут выявляться, импортироваться или вводиться вручную. Статистические данные, данные анализа и данные о надежности могут либо представлять собой результаты расчетов, записанные аналитическим компонентом, либо собранные данные опросов ресурсов, выявленных в дата-центре.
Согласно некоторым вариантам осуществления, данные в системе могут быть организованы в трех основных логических моделях. Эти модели могут представлять собой объектную модель, модель долговременного хранения и модель менеджмент-слоя. Эти модели могут обеспечивать возможность как абстракции, так и независимой организации данных на разных уровнях программного обеспечения. Это может также позволять каждому слою изменяться независимо от других с влиянием лишь на тонкие переходные слои.
Модель данных может масштабироваться горизонтально для представления широкого разнообразия устройств и данных, относящихся к этим устройствам. Она может также быть способна принимать широкий диапазон собранных и рассчитанных данных. Количество данных, собранных и сохраненных с течением времени, может исчисляться десятками терабайт. Данные могут быть организованы и разделены таким образом, чтобы обеспечивалась возможность быстрого доступа при незначительном одновременном использовании каналов связи.
По меньшей мере в одном варианте осуществления модель данных может быть достаточно гибкой для того, чтобы приспосабливаться к изменениям различных слоев модели без последствий для остальных слоев модели. Например, изменение в слое долговременного хранения может не влиять на модель менеджмент-слоя или любого другого получателя кода благодаря тонкому переходному слою, который копирует данные между моделями.
Под рабочей деятельностью в этом контексте могут пониматься переход объектов с одного слоя на другой, а также доступ к данным. В целом, копирование атрибутов устройства между слоями может представлять собой небольшой объем данных. При этом копирование собираемых данных между слоями может не выполняться ввиду их большого объема. Кроме того, доступ к данным может осуществляться посредством по меньшей мере нескольких сотен транзакций одновременно.
Слой объектной модели может представлять собой представление, совместно и непосредственно используемое собирающим данные компонентом, выявляющим компонентом и аналитическим компонентом. Он может содержать семь различных основных категорий данных: данные о ресурсах, статистические данные, данные анализа, геопространственные данные, профильные данные о надежности/потреблении мощности, расчетные данные о надежности и данные о взаимозависимости. Каждая из этих категорий описана более подробно ниже.
Данные о ресурсах могут описывать программные и аппаратные ресурсы в дата-центре и то, как они связаны друг с другом. Они (данные о ресурсах) могут включать атрибуты, такие как адрес устройства, способ доступа к устройству и тип устройства. Они могут представлять собой метаданные, которые отвечают на вопрос «что это и как обратиться к этому?»
Статистические данные могут представлять собой данные о текущей загруженности, собираемые от ресурсов. Например, для дисковода они могут представлять собой количество передаваемых блоков данных, а для процессора они могут представлять собой процент нерабочего времени. Эти данные могут собираться периодически через определенные интервалы времени и могут использоваться для выведения других данных, таких как текущее потребление мощности.
Под данными анализа могут пониматься, в целом, данные, которые были рассчитаны с использованием других типов данных. Например, данные анализа с использованием вычислительной гидродинамики могут быть рассчитаны с использованием сочетания данных о ресурсах, геопространственных данных и либо статистических данных, либо профильных данных.
Геопространственные данные могут представлять собой метаданные, которые описывают физические размеры и местоположение ресурса или даже не ресурса, а, например, двери или окна. Например, эти данные могут быть использованы для расчета аспектов рабочей среды, таких как воздушные потоки и температура в ограниченном пространстве.
Профильные данные могут представлять собой метаданные, которые описывают для ресурса потребление мощности/температуру, площадь корпуса и надежность устройства. Эти данные могут быть использованы, например, в GxDB таким образом, что потребление мощности может быть оценено без необходимости сбора статистических данных о загруженности.
Согласно некоторым вариантам осуществления, расчетные данные о надежности могут просто представлять собой текущую надежность системы, рассчитанную на основании рабочей среды. Они могут выдаваться независимо от более обобщенных данных анализа для подчеркивания их отличия от профильных данных о надежности.
Данные о взаимозависимости могут представлять собой метаданные, которые могут описывать то, какие взаимозависимости имеются между ресурсами. Например, процесс зависит от сервера, массива запоминающих устройств и набора физических приводов, содержащихся внутри массива запоминающих устройств. Эти данные могут быть использованы, например, для анализа надежности сквозной передачи данных сервиса.
Модель долговременного хранения может отличаться от остальной системы тем, каким образом в ней хранятся данные. Она может содержать тонкий слой, который является переходным между объектной моделью и моделью долговременного хранения как для модификаций, так и для запросов. Этот слой может также содержать логику для ведения и администрирования базы данных, используемой в продукте для анализа потребления мощности дата-центром.
Схема слоя долговременного хранения может представлять собой нормализованное представление объектной модели. Схема, кроме того, может быть разработана таким образом, чтобы доводить до максимума эффективность извлечения и хранения данных.
Слой доступа к данным может представлять собой набор объектов, который абстрагирует друг от друга запросы к базе данных, транзакции и манипуляции с таблицами.
Менеджер администрирования базы данных может представлять собой подсистему, которая осуществляет менеджмент базы данных. Он может осуществлять менеджмент создания базы данных с воплощением ее схемы; уничтожения базы данных; резервного копирования/восстановления базы данных; модернизации схемы базы данных; ведения таблицы и менеджмент свободных мест.
Модель менеджмент-слоя может абстрагировать представление объектной модели менеджмент-уровня от остальной системы. Она может состоять из тонкого слоя, который обеспечивает трансляцию в представление объектной модели и из представления объектной модели.
Аналитический компонент может представлять собой домен, который оперирует функциями отчета, анализа, оптимизации и контроля в программном обеспечении, осуществляющем анализ потребления мощности дата-центром. Он может быть структурирован таким образом, чтобы доводить до максимума повторное использование кода во множестве функций, обеспечивать естественные абстракции для независимой доработки и обеспечивать максимальную гибкость для набора функций, так чтобы их можно было заменять (даже динамически), когда необходимо. Он может представлять собой многозадачную машину, которая может масштабироваться для оперирования множеством задач одновременно, независимо от того, предназначены эти задачи для одной и той же функции или для разных функций.
Аналитический компонент может масштабироваться для оперирования сотнями задач одновременно с очень большим количеством данных. Эти задачи могут варьироваться от инициируемых пользователем задач, требующих данные о состоянии и ответные данные, получаемых в реальном времени, до внутренних задач системы, не требующих ответных данных и основанного на записи статуса.
Набор функций из системного подхода может быть неподходящим, с точки зрения результирующих данных и способа, которым они представляются, однако многие из этих данных могут быть использованы для расчета и производства промежуточных результатов. При этом то, как эти расчеты выполняются, может сильно варьироваться. Аналитический компонент может поддерживать функции, которые варьируются от распределенных сервисов с частичным хостингом до интенсивных локальных сервисов ввода-вывода. Он также может оперировать функциями, которые могут требовать много времени для выполнения, и функциями, которые требуют немедленных результатов.
Аналитический компонент выполняет задачи, которые полностью абстрагированы друг от друга. Поэтому может существовать набор приемов для ограничения загрузки ресурсов этими независимыми задачами. Пулы ресурсов используются для осуществления этого, когда возможно (например, пул потока, пул памяти). Функции, встроенные в аналитический компонент, могут также принимать во внимание загруженность ресурсов в системах, мониторинг которых они осуществляют.
Объектно-ориентированная оболочка для аналитического компонента может быть построена по архитектуре «конвейер и фильтры», в которой могут иметься организованные в конвейер небольшие активные независимые модули функциональности, известные как фильтры-объекты (также называемые ступенями конвейера). Команды могут проходить через конвейер в одном направлении, предоставляя каждому объекту-ступени возможность собирать или обрабатывать данные, проходящие по конвейеру. Когда достигнут конец конвейера, команда может проходить через конвейер в противоположном направлении, предоставляя каждому объекту-ступени возможность снова собирать или обрабатывать данные. Фиг. 8 показывает архитектуру «конвейер и фильтры», которая описана ниже.
Могут иметься объекты, управляющие объектами-функциями, ответственные за создание и уничтожение конвейеров. Они могут на основании анализа событий принимать решение о создании конвейера и определять параметры конвейера, такие как ресурсные ограничения, и параметры ступеней. В большинстве случаев эти конвейеры могут быть подготовлены за некоторое определенное время и могут быть статичными (не меняющимися в процессе эксплуатации), однако они могут быть и динамическими, т.е. выполненными с возможностью внесения изменений при необходимости.
Объекты-ступени могут представлять собой логические блоки, которые могут определять, как работает функция. Они могут представлять собой простые сфокусированные независимые модули функциональности, которые вместе могут создавать комплексные функции. Каждый объект-ступень может принимать команды и либо выполнять расчеты с данными, прикрепленными к командам, либо извлекать дополнительные данные, необходимые для дальнейшей обработки. Объекты-ступени могут также принимать решения о том, чтобы не обрабатывать определенные типы команд, и в этом случае команда проходит через них без изменений. Объекты-ступени могут не реагировать на некоторые команды. Объекты-ступени могут просто выполнять команды, которые несут информацию через конвейер, но могут также (на основании информации, содержащейся в командах) отслеживать состояние конвейера или частей системы.
Объекты-команды могут проходить через конвейер и при этом проходят через все объекты-ступени. Объекты-команды могут содержать параметры команды, расчетные данные и/или извлеченные данные, текущее состояние команды и ее желаемое результирующее состояние.
Процессор команд может представлять собой одиночный объект, который может создавать, уничтожать и направлять команды через конвейер посредством хорошо известного интерфейса, поддерживаемого всеми объектами-ступенями. Он может также представлять собой единицу, которая содержит контекст потока, в котором команды проходят через конвейер. Может иметься один поток для одной команды, который несет команду через конвейер. Процессор команд может принимать запросы от интерфейса менеджмент-слоя и конвертировать эти запросы в команды конвейера. После выполнения команды данные о команде и состояние команды могут передаваться обратно в менеджмент-слой.
Помимо отдельного конвейера для каждой функции, имеется два других конвейера. Первый, называемый глобальным конвейером, может иметься в единственном экземпляре во всей системе. Ступени, содержащиеся в глобальном конвейере, применяются ко всему набору функций. Например, он может содержать ступень, которая в каждом случае назначает память для данных, подлежащих возвращению, либо лицензирующую ступень, которая принимает решение об ограничениях лицензии и о том, что ограничение лицензии превышено, и следует запретить команде переходить в другие конвейеры. Согласно некоторым вариантам осуществления, все команды могут проходить через глобальный конвейер перед поступлением в другие конвейеры.
Другой конвейер может быть назван предварительным конвейером. Может иметься один конвейер такого типа на один обычный (функциональный) конвейер, однако он может содержать общие ступени, которые могут применяться лишь к отдельным рассматриваемым конвейерам. Например, ступень, отвечающая за правильность работы, может иметься на этом конвейере, которая может не позволять командам перемещаться вниз по функциональному конвейеру при возникновении ошибки. Все команды проходят через подходящий предварительный конвейер после прохождения через глобальный конвейер, но перед прохождением через соответствующий функциональный конвейер.
Может иметься несколько главных функциональных схем, которые могут поддерживаться аналитическим компонентом. Могут иметься функции внутреннего ведения системы, такие как сжатие данных и ведение таблицы базы данных. Могут иметься находящиеся на хосте сервисы, такие как GxDB и сервис анализа с использованием вычислительной гидродинамики, коммуникация с которыми может осуществляться через аналитический компонент. Могут иметься отчетные сервисы, такие как обнаружитель зомби-серверов и сервис отчетов о потреблении мощности. Могут также иметься контрольные функции, такие как управление выключением и ограничение мощности. Все сервисы всех этих типов могут быть встроены в оболочку, речь о которой шла выше.
Ошибками можно оперировать несколькими способами в аналитическом компоненте. Команды могут нести состояние ошибки с ними, и каждая ступень может определять, что ей следует делать, на основании ошибки. Когда возникают критические ошибки и определяется, что команда не может перейти на следующую ступень, устройство может вернуть информацию о статусе, повернув команду в обратном направлении, как если бы был достигнут конец конвейера. В этом случае процессор команд может просто симулировать условие конца конвейера.
Могут иметься функции, которые требуют значительной обработки, а следовательно, значительного времени для выполнения команды. Подсистема статусов может иметься вне оболочки аналитического компонента, однако эта подсистема может запрашивать статус внутри оболочки посредством запроса к процессору команд. Процессор команд знает, где в конвейере команда может находиться в любой заданный момент времени, и может рассчитывать процент выполнения по количеству пройденных ступеней. В отношении самой команды может быть запрошено, в какой степени в данный момент выполнена ее обработка внутри отдельной ступени.
Использование лицензий может быть обеспечено посредством самих конвейеров. Может иметься лицензирующая ступень как на глобальном конвейере, так и на каждом предварительном конвейере. Эти ступени поворачивают команды в обратном направлении с присвоением состояния ошибки, когда было достигнуто ограничение лицензии.
Поскольку оболочки и архитектура по своей природе могут представлять собой нечто абстрактное, пример воплощения функции может быть изображен так, как на Фиг. 9. Функция может представлять собой обнаружитель зомби-серверов, который возвращает идентификационные данные и геопространственное местоположение зомби-серверов, которые относятся к определенной группе. Другие функции могут тоже быть воплощены с использованием оболочек.
На Фиг. 9 может иметься три ступени. Первая может представлять собой ступень «группа-элемент», которая просто выясняет, зная название группы, какие серверы относятся к ней. Если мы разыскиваем лишь зомби-серверы в группе, то этот объект-ступень может присоединить к команде перечень лишь тех серверов, о которых из базы данных ресурсов извлечена информация, что они относятся к этой группе. Следующая ступень может представлять собой ступень «идентификация зомби-серверов». Эта ступень просто отыскивает зомби-серверы на основании данных о загруженности серверов, перечисленных в команде. Последняя ступень может представлять собой ступень «определение местоположения серверов». Эта ступень просто отправляет запрос базе геопространственных данных, с тем чтобы последняя предоставила информацию о местоположении для ресурсов, перечисленных в получаемой ею команде.
Все эти три ступени могут быть самодостаточными и отдельными, так что одна не знает, что предыдущая делала до нее и что следующая будет делать после нее. Каждая из этих ступеней может быть достаточно универсальной для того, чтобы с легкостью быть использованной в других функциях. Например, ступень «определение местоположения серверов» может быть использована в функции размещения сервера.
Выявляющий компонент может быть ответственным за каталогизацию ресурсов дата-центра и соответствующих атрибутов в запоминающем устройстве долговременного хранения.
Ресурсы дата-центра включают не только типовые ИТ-ресурсы, такие как серверы, диски, массивы дисков, память, материнские платы, карты расширения и переключатели, но также обслуживающие ресурсы, такие как кондиционеры воздуха помещения для ЭВМ, блоки распределения мощности, генераторы, электрические схемы, программные ресурсы, которые представляют приложения, выполняемые на серверах, и, наконец, ресурсы-сооружения, такие как здания, стены, полы, стеллажи и т.д.
Могут иметься некоторые общие для всех ресурсов атрибуты, например геопространственная информация, которая описывает, где ресурс в данный момент находится или может находиться. Эти общие атрибуты могут собираться, записываться в запоминающее устройство долговременного хранения и ставиться в соответствие с ресурсом.
Кроме того, индивидуальные атрибуты ресурса могут требовать их сбора, записи в запоминающее устройство долговременного хранения и постановки в соответствие с ресурсом. Например:
- Среди атрибутов ИТ-ресурсов это могут быть тип/модель, серийный номер, объем памяти или емкость запоминающего устройства и т.д.;
- Среди атрибутов ресурсов-сооружений это могут быть тип поверхности, плотность и т.д.;
- Среди атрибутов обслуживающих ресурсов это могут быть тип/модель и охлаждающая способность и т.д.;
- Среди программных ресурсов это могут быть информация о поставщике и версии и т.д.
Несколько одновременных операций выявления может поддерживаться для обслуживания больших сетей. Это может означать, что один оператор выполняет несколько операций выявления либо несколько операторов выполняют по одной операции выявления.
Выявляющий компонент может масштабироваться от монтажного шкафа с одним сервером до самых крупных дата-центров, которые могут содержать миллион ресурсов. Процесс выявления и объем базы данных, обусловленный каталогизацией ресурсов и атрибутов, могут масштабироваться соответствующим образом.
За исключением слоев пользовательского интерфейса и запоминающего устройства долговременного хранения выявляющий компонент может не знать о других частях системы. Для сведения знаний о других компонентах к минимуму могут использоваться средства-посредники.
Текущие ресурсы и атрибуты ресурсов могут быть неизвестны и поэтому эти данные могут постоянно пополняться.
Способ и порядок выявления ресурсов и атрибутов могут быть гибкими. В некоторых случаях выявление одной или более частей ресурса дата-центра может проходить непосредственно из динамической таблицы. В других случаях детекция частей может осуществляться посредством автоматического выявления ресурса и посредством введения с помощью ЭВМ некоторого количества данных. В других случаях геопространственная информация может поступать из динамической таблицы посредством автоматизированного ручного ввода, ручного ввода либо может не собираться вовсе. Выявление может осуществляться с минимальным влиянием на дата-центр.
Согласно некоторым вариантам осуществления, процесс выявления может инициироваться редко. Как таковой, процесс выявления может не быть происходящим в реальном времени, но может быть настолько эффективным, насколько это возможно.
Пользователь может быть способен выявлять ресурсы и атрибуты дата-центра (включая геопространственные атрибуты, такие как местоположение ресурсов), по меньшей мере на уровне группы оборудования, в течение нескольких минут-часа использования инструмента, а не в течение недель, как в настоящее время в стандартных способах.
Выявляющий компонент может быть использован оператором дата-центра для выявления ресурсов изначально или, возможно, периодически по некоторому графику. Процесс выявления может быть направлен на один сервер, на уровень подсети или IP либо на весь дата-центр.
Выявляющий компонент может использовать имеющуюся технологию для осуществления автоматического выявления ресурсов и атрибутов. При этом могут использоваться или не использоваться SNMP, WMI, IPMI, SSH, BACNet, ModBus или даже индивидуально созданные протоколы. Одно выявление может требовать нескольких протоколов для выполнения процесса. Кроме того, в некоторых случаях ресурс может сначала выявляться на высоком уровне с последующим сбором более подробной информации об этом ресурсе. Несколько выявляющих проходов может быть сделано для полного сбора данных о ресурсе.
Ресурсы и атрибуты могут выявляться и записываться в запоминающее устройство долговременного хранения без непосредственных знаний о протоколах, используемых для получения данных. Кроме того, выявляющий компонент может не иметь непосредственных подробных знаний о слое запоминающего устройства долговременного хранения.
Выявляющий компонент может не полагаться непосредственно на какие-либо протоколы. В данном контексте, ручной ввод данных или импорт данных из файлов может служить другим «протоколом». Вместо этого абстракции, которые расположены выше протоколов, могут быть использованы. Этим способом могут быть добавлены дополнительные протоколы или даже индивидуальные способы сбора и записи данных.
Не все протоколы обладают одинаковыми возможностями. По существу, каждый протокол может определять, какие возможности он поддерживает.
При разработке может быть учтено, что несколько протоколов и несколько проходов может быть использовано для выполнения одного выявления.
Данные, возвращающиеся от протоколов, могут подходить или не подходить к внутреннему представлению объектной модели. Поэтому собранные данные могут транслироваться. Эта трансляция может быть воплощена таким образом, что новые устройства могут поддерживаться без необходимости рекомпиляции основного кода.
Находящиеся в памяти объекты объектной модели могут быть записаны в запоминающее устройство долговременного хранения/считаны из запоминающего устройства долговременного хранения. Составляющие этого процесса могут быть абстрагированы. Текущее вспомогательное запоминающее устройство может представлять собой локальную/находящуюся на хосте базу данных из сервисного центра или локальную/находящуюся на хосте базу данных из дата-центра, одноуровневый файл, журнал отладки и т.д. Слой абстракции долговременного хранения данных может быть ответственным за трансляцию находящихся в памяти объектов в объекты долговременного хранения данных, которые выписываются во вспомогательное запоминающее устройство, и за трансляцию объектов вспомогательного запоминающего устройства в представление для занесения в память во время операции чтения.
Запросы к слою запоминающего устройства долговременного хранения могут быть совмещены для сведения к минимуму количества обращений к вспомогательному запоминающему устройству. Если это считается необходимым, запись в обход кэша или кэширование с отложенной записью объектов, расположенных в памяти и использованных самыми последними, могут уменьшать необходимость в многократном обращении.
Запрос на импорт к базе данных менеджмента конфигурации (CMDB) может просто представлять собой запуск выявления, при этом воплощение ниже протокольной абстракции может представлять собой индивидуальный тип протокола «импорт из CMDB».
База данных для ресурсов и соответствующих атрибутов может представлять собой сервисный ресурс или ресурс дата-центра. По существу, конфигурация не должна препятствовать удаленной работе выявляющего компонента из месторасположения вспомогательного запоминающего устройства. Кроме того, является возможным, чтобы процесс выявления весь или частично был удаленным от дата-центра, в котором выполняется выявление. Тем не менее, данные могут анализироваться централизованно.
Имеется два аспекта оперирования ошибками: обнаружение и устранение. Если конкретная операция выявления «повторно выявляет» ресурс и обнаруживает конфликт, она может выполнить сверку с тем, что уже каталогизировано. Например, она может обнаружить, что сервер на заданном IP-адресе был заменен другим сервером или что он был модернизирован путем добавления памяти или карты расширения.
Если процесс выявления обнаруживает ресурс, но не укладывается во временной лимит во время подробного или глубокого выявления, выявляющий компонент может сделать пометку и перейти к следующей операции.
Если ошибки возникают во время интервью или выполняемого с помощью ЭВМ взаимодействия с оператором дата-центра, выявляющий компонент может предлагать способы устранения. Ошибки могут записываться и предоставляться в конце выявления для уменьшения препятствий протеканию процесса выявления. Например, маловероятно, что оператор может стоять перед консолью во время продолжительного импорта или автоматического выявления.
Во время выявления выявляющий компонент может предоставлять информацию о прогрессе (например, видимый прирастающий счетчик количества и типов выявленных ресурсов, счетчик потерянных соединений и т.д.). Если имеется несколько фаз выявления, выявляющий компонент может выдавать отчеты о том, какая фаза может быть в данный момент активна. Если имеется несколько операций выявления, каждая операция может выдавать отчеты независимо, а также может предоставляться суммарное представление по всем операциям.
Когда выявление закончено, выдается статус, который может показывать завершение и предоставлять предложения о том, как оперировать ошибками.
Выявляющий компонент может отправлять информацию о статусе через слой пользовательского интерфейса от команды «опросить статусы», отправленной через пользовательский интерфейс.
Собирающий данные компонент может представлять собой средство мониторинга ресурсов. Работой собирающего данные компонента может быть сбор наиболее важной информации о ресурсах и архивирование этой информации в запоминающем устройстве долговременного хранения. Тип собираемой информации может варьироваться в зависимости от типа ресурса и может задаваться требованиями аналитического компонента. Ранее выявленные ресурсы дата-центра (ИТ, обслуживающие и программные) могут опрашиваться, а собираемые данные вместе с меткой (метками) времени могут записываться в статистическое запоминающее устройство долговременного хранения.
Примеры данных, которые требуется собрать
Предположительный/возможный источник
Данные о рабочих характеристиках процессора
SNMP
Загруженность памяти
SNMP
Загруженность и рабочие характеристики запоминающего устройства
SNMP, SMI-S, API
Показания датчиков температуры
SNMP, API
Рабочие характеристики таблицы процессов
SNMP, SSH
Потребление мощности БРМ
SNMP, API
Информация о состоянии ИБП
SNMP, API
Информация о состоянии кондиционера воздуха помещения для ЭВМ
SNMP, API
Информация о состоянии оборудования для поддержания требуемого качества электроэнергии
SNMP, API
Информация о конфигурации и состоянии переключателя
SNMP, SMI-S, API
Информация о состоянии охлаждающих средств
SNMP, API
Частота опросов может задаваться пользователем в разумных пределах. Может поддерживаться несколько одновременных операций сбора данных для обслуживания крупных сетей. Это может означать, что один оператор выполняет несколько операций либо несколько операторов выполняют операции по сбору данных.
Согласно некоторым вариантам осуществления, система может быть способна опрашивать миллион ресурсов за 5 минут без отрицательного влияния на рабочие характеристики сервисов дата-центра.
Статистические данные могут записываться непрерывно в запоминающее устройство долговременного хранения. По существу, увеличение объема статистических данных может составлять до миллиона опрошенных ресурсов за 5 минут и может происходить в течение некоторого заданного периода времени. Может иметься график для «сжимающего» анализа, который может обобщать статистические данные путем их усреднения во избежание переполнения данными. При этом объем сохраняемых данных между сжатиями может соответствующим образом увеличиваться.
Неизвестно, какова будет текущая величина собираемых данных, поэтому может быть предусмотрена возможность расширения места для их записи.
Способ и порядок сбора данных может быть гибким. В некоторых случаях данные могут поступать непосредственно из динамической таблицы. В других случаях данные могут собираться путем автоматического опроса и путем введения с помощью ЭВМ некоторого количества данных. Сбор может быть разработан таким образом, чтобы свести к минимуму влияние на дата-центр.
Сбор данных может представлять собой непрерывный процесс опроса и потому может быть очень эффективным. Система может быть способна опрашивать миллион ресурсов за 5 минут без отрицательного влияния на сервисы дата-центра (серверы, сеть и т.д.).
Собирающий данные компонент может использовать ранее выявленные ресурсы для выяснения того, о чем следует опрашивать, собирает наиболее важную информацию от этих ресурсов и записывает эту относящуюся к ресурсам наиболее важную информацию в статистическое запоминающее устройство долговременного хранения с меткой (метками) времени.
Если средство мониторинга не может найти сервер, который ранее был выявлен, пользователь может быть уведомлен об этом. Конфликты могут записываться и разрешаться в конце процесса сбора данных.
«Сжимающий» анализ с независимым графиком может обобщать статистику путем усреднения данных во избежание переполнения данными. При этом средство мониторинга может отвечать лишь за запись наиболее важной информации, но не за обобщение данных.
Наиболее важная информация о ресурсе может собираться и архивироваться в запоминающем устройстве долговременного хранения без непосредственного знания протоколов, использованных для получения данных. Кроме того, собирающий данные компонент может не иметь непосредственных подробных знаний о слое запоминающего устройства долговременного хранения.
Собирающий данные компонент может не полагаться на какие-либо протоколы непосредственно. В этом контексте ручной ввод статистических данных или импорт данных из файлов может служить другим «протоколом». Вместо этого абстракции, которые расположены выше протоколов, могут быть использованы. Этим способом могут быть добавлены дополнительные протоколы или даже индивидуальные способы сбора и записи данных.
Не все протоколы обладают одинаковыми возможностями. По существу, каждый протокол может определять, какие возможности он поддерживает.
Данные, возвращающиеся от протоколов, могут подходить или не подходить к внутреннему представлению объектной модели. Поэтому собранные данные могут транслироваться. Эта трансляция может быть воплощена таким образом, что новые устройства могут поддерживаться без необходимости рекомпиляции основного кода.
Находящиеся в памяти объекты объектной модели могут быть записаны в запоминающее устройство долговременного хранения/считаны из запоминающего устройства долговременного хранения. Составляющие этого процесса могут быть абстрагированы. Текущее вспомогательное запоминающее устройство может представлять собой локальную/находящуюся на хосте базу данных из сервисного центра или локальную/находящуюся на хосте базу данных из дата-центра, одноуровневый файл, журнал отладки и т.д. Слой абстракции долговременного хранения данных может быть ответственным за трансляцию находящихся в памяти объектов в объекты долговременного хранения данных, которые выписываются во вспомогательное запоминающее устройство, и за трансляцию объектов вспомогательного запоминающего устройства в представление для занесения в память во время операции чтения.
Запросы к слою запоминающего устройства долговременного хранения могут быть совмещены, когда это возможно, для сведения к минимуму количества обращений к вспомогательному запоминающему устройству. Если это считается необходимым, запись в обход кэша или кэширование с отложенной записью объектов, расположенных в памяти и использованных самыми последними, могут уменьшать необходимость в многократном обращении.
Сборка данных для некоторых ресурсов может импортироваться вручную из динамических таблиц или может иметь некоторый индивидуальный формат. Например, является возможным, что некоторый инструмент-посредник может собирать определенные данные с некоторой частотой на определенных ресурсах и может генерировать статистический отчет в некотором определенном формате. Собирающий данные компонент может быть достаточно абстрагированным для поддержания этого индивидуального источника статистических данных.
Собирающий данные компонент может работать удаленно из месторасположения вспомогательного запоминающего устройства. Процесс сбора сам по себе может весь или частично проходить удаленно от дата-центра, мониторинг которого осуществляется. При этом данные могут анализироваться централизованно.
Имеется два аспекта оперирования ошибками: обнаружение и устранение. Если ошибки возникают во время интервью или выполняемого с помощью ЭВМ взаимодействия с оператором дата-центра, собирающий данные компонент может предлагать способы устранения. Ошибки могут записываться и предоставляться в конце, с тем чтобы позволить сбору данных завершиться. Например, маловероятно, что оператор стоит перед консолью во время продолжительного импорта или сбора.
Может иметься изящный способ предотвращения переполнения данными. В собирающем данные компоненте может отсутствовать предположение, что пользователь сконфигурировал и обеспечил сжатие правильно.
Во время сбора данных собирающий данные компонент может предоставлять информацию о прогрессе (например, видимый прирастающий счетчик количества и типов опрошенных ресурсов, счетчик потерянных соединений и т.д.). Если имеется несколько фаз сбора данных, компонент может выдавать отчеты о том, какая фаза в данный момент активна. Если имеется несколько операций сбора данных, каждая операция может выдавать отчеты независимо, а также может предоставляться суммарное представление по всем операциям.
Когда сбор данных закончен, выдается статус, который может показывать завершение и предоставлять предложения о том, как оперировать ошибками.
Собирающий данные компонент может отправлять через слой пользовательского интерфейса информацию о статусе (например, полученную в результате выполнения команды об опросе статусов, отправленной тоже через пользовательский интерфейс).
Геномная карта дата-центра (GxDB) может представлять собой находящуюся на WEB-хосте базу данных, которая может содержать подробные характеристики обычного оборудования дата-центра, к которому относятся, без ограничения, сервер, массивы, кондиционеры воздуха помещений для ЭВМ, системы менеджмента потребления мощности и физическая инфраструктура. Общим подходом может быть описание систем (таких, как серверы или массивы запоминающих устройств) как совокупности составляющих их компонентов: процессоров, памяти, дисков и т.д. Для каждого компонента могут собираться и вестись данные о потреблении мощности, надежности, функциональности, рабочих характеристиках и интерфейсах, а также о размере и массе, когда это уместно. Информация в этой базе данных может использоваться для осуществления основанных на программном обеспечении определения потребления мощности, анализа надежности и логических/физических симуляций.
На Фиг. 10 показаны основные компоненты, которые составляют хостинг-сервисы для базы данных конфигураций или профилей (например, GxDB), а также несколько клиентов сервиса согласно одному или более вариантам осуществления.
GxDB может быть способна вести подробные характеристики оборудования и компонентов, найденных в клиентских дата-центрах. Со временем этот набор может вырасти настолько, что будет включать информацию обо всем общедоступном ИТ-оборудовании. База данных может содержать описания порядка десятков тысяч компонентов.
Содержание и форма базы данных могут эволюционировать со временем. Схема может быть достаточно универсальной и расширяемой для того, чтобы обеспечивать легкость добавления новой информации о различных типах компонентов, когда они выявляются во время тестирования.
База данных компонентов или профилей (например, GxDB) может иметь очень низкую скорость прироста информации; лишь относительно небольшое количество записей может добавляться за день (наиболее вероятно - порядка десятков или сотен). База данных может быть способна обслуживать порядка десятков комплексных запросов в секунду. Согласно некоторым вариантам осуществления, GxDB может в целом представлять собой репозиторий с однократной записью и многократным считыванием, и множество точных копий системы может быть создано с легкостью.
Согласно некоторым вариантам осуществления, GxDB может быть воплощена с использованием стандартных имеющихся в открытых источниках баз данных и инструментов WEB-хостинга. В других вариантах осуществления может быть использована индивидуальная система базы данных или более крупная коммерческая система для лежащего в основе SQL-компонента или WEB-промежуточного программного обеспечения.
Схема GxDB может быть выведена из объектной модели дата-центра, описанной выше. Таблицы могут быть организованы по типам компонентов дата-центра (например, таблица процессоров, таблица дисков, таблица материнских плат и т.д). Компоненты дата-центра внутри таблиц могут иметь уникальные шифры, которые могут использоваться для идентификации определенных компонентов, которые составляют более крупные системы, такие как серверы и массивы запоминающих устройств.
Для данного компонента дата-центра схема дифференцирует источник и качество информации об этом компоненте: согласно некоторым вариантам осуществления, может иметься три уровня информации:
i. Информация, полученная из листа (листов) спецификации, - данные из спецификаций производителя;
ii. Информация, внесенная пользователем, - данные, внесенные сообществом пользователей; и
iii. Информация, подтвержденная поставщиком услуги, - данные о потреблении мощности и надежности, собранные имеющимися инструментами.
Согласно некоторым вариантам осуществления, GxDB может находиться на WEB-хосте. Хостинг-сервис может использовать серверную платформу Linux, запоминающее устройство, операции ведения и резервного копирования/восстановления, требуемые для любого приложения, находящегося на WEB-хосте. GxDB может использовать специализированный сервер (физический или виртуальный) с доступом через SSH и возможностью инсталляции произвольных пакетов программ. Пропускная способность может не быть самым важным параметром.
Может иметься два типа интерфейсов для GxDB:
- Асинхронный WEB-GUI-интерфейс (GUI - графический пользовательский интерфейс) для доступа конечного пользователя;
- API для программного доступа с других компонентов. Один из этих интерфейсов или они оба могут поддерживать: утилиты для просмотра/запросов, введения новых данных, доступа к записям, ведения, табличной области, резервного копирования, восстановления и генома.
Для того чтобы способствовать заполнению GxDB, может иметься набор инструментов, помогающих вносить характеристики ИТ-оборудования в соответствующие поля. Эти инструменты включают, без ограничения, датчик нагрузки процессора, датчик нагрузки ввода/вывода (для запоминающих устройств и сетей передачи данных), выявляющие инструменты для считывания информации о конфигурации, инструменты автоматического считывания показаний о потреблении мощности с БРМ или USB-ваттметров, утилиты для введения собранных данных в центральную GxDB.
Согласно некоторым вариантам осуществления, частная информация клиента может не передаваться или не сохраняться в GxDB. Могут быть воплощены передовые способы защиты находящихся на хосте данных. Как API, так и пользовательские интерфейсы могут требовать проверки подлинности пользователя. Источник любой предоставляемой пользователем информации может отслеживаться.
Информация в GxDB может быть центральной по отношению к работе программных компонентов, вводимых в эксплуатацию в клиентских дата-центрах. Для того чтобы избежать постоянного обмена данными через сеть и обеспечить безопасность, подгруппы GxDB могут кэшироваться или точно копироваться на программном обеспечении, вводимом в эксплуатацию в месте нахождения клиента.
Будучи центральным находящимся на хосте сервисом, который может использоваться непрерывно одним или более клиентами, GxDB может выявлять и автоматически исправлять широкое разнообразие системных сбоев. База данных сама по себе может вводиться в эксплуатацию избыточным образом, и она может также осуществлять мониторинг для выявления проблем функциональности и рабочих характеристик и может сообщать и/или сигнализировать, когда обнаружены потенциальные сбои.
Пользовательские интерфейсы для продукта могут поддерживать широкое разнообразие функций - от базового конфигурирования программных компонентов до современного 3D-моделирования и симуляции больших комплексных дата-центров. Может иметься несколько отдельных интерфейсов для поддержания истории конкретного пользователя.
Архитектура пользовательского интерфейса может предоставлять механизм кэширования для эффективного ведения текущих рабочих наборов информации. Отображающие компоненты могут иметь способность страничного отображения подгрупп ИТ-компонентов и наборов результатов. Несколько пользователей могут взаимодействовать с системой анализа потребления мощности одновременно.
Архитектура GUI может поддерживать простые утилиты сбора данных, мастера конфигурации системы, инструменты разбивки наподобие САПР и передовые средства визуализации данных. Общий вид высокого уровня GUI показан на фигуре 11.
Фиг. 11 показывает множество приводимых в качестве примера представлений.
Слой модели данных может обеспечивать трансляцию из представления ОМ для базового компонента в модель, которая может быть организована для эффективных операций GUI. Во многих случаях это может быть тривиальное прохождение, однако архитектура может обеспечивать чистое отделение представлений от процессинговых элементов в системе. Этот слой может также воплощать бизнес-логику, которая может быть общей во всех представлениях, но не воплощена надлежащим образом в аналитических, выявляющих системах или мониторинговых системах.
Пользовательские интерфейсы могут быть многопоточными на двух уровнях. Система управления окнами GUI может быть управляемой событиями и многопоточной для обеспечения способных к реакции неблокирующих виджетов, а удаленный API может быть построен вокруг асинхронного механизма «команда/ответ», который может оперировать несколькими ожидающими выполнения запросами.
Слой удаленного API может содействовать коммуникации между GUI, GxDB и базовым программным обеспечением. Этот слой может воплощать асинхронный механизм «команда/ответ» и ту или иную форму кэширования результата.
Основанная на роли безопасность может быть использована для контроля доступа к функциям сбора данных и системного контроля. Программное обеспечение может также поддерживать шифрование трафика для дата-центров, которые подвергаются удаленному мониторингу и менеджменту через сети общего пользования.
Продукты для анализа потребления мощности дата-центром могут включать находящийся на хосте GxDB-WEB-сервер, инсталлированные клиентом программные средства и WEB-ресурсный(ые)-сервер(ы), откуда пользователи и/или клиенты могут загружать патчи (дополнения) к их программному(ым) средству(ам).
Менеджер свойств может быть одиночным, так что может быть общеиспользуемым среди одного или более компонента в системе.
Эта подсистема может позволять каждому продукту иметь набор величин по умолчанию, который может быть модифицирован даже во время работы во избежание необходимости перестраивать, перегруппировывать, а в некоторых случаях перезапускать сервисы продукта для изменения режима работы.
Пользовательский интерфейс для просмотра и модификации текущих величин свойств может быть доступен через интерфейс с командной строкой для его использования лишь внутренним или выездным обслуживающим персоналом.
Некоторые примеры свойств могут включать:
- Логика глобального или компонентного уровня для активации/деактивации отладки;
- Границы;
- Настройки лимитов времени;
- Запись.
Менеджер записей может быть одиночным, так что может быть общеиспользуемым среди одного или более компонентов в системе. Он может представлять собой пример подсистемы, которая может использовать менеджер свойств для активации/деактивации различных настроек записи.
Каждый компонент может иметь отдельный файл записей, который обеспечивает ясную и точную передачу сообщений об ошибках, о предупреждениях и информационных сообщений. Такая передача сообщений предоставляет достаточную информацию для мониторинга статуса наших продуктов во время их работы. Файлы записей могут создаваться, когда наши сервисы запускаются, и пополняться до тех пор, пока действие сервиса не будет прекращено. Предыдущие файлы записей могут подвергаться ротации (например, после внесения каждых 10 записей) для статистического обзора.
Согласно некоторым вариантам осуществления, менеджер записей может использоваться одним или более компонентом и одной или более подсистемой для обеспечения единообразия стиля выходной информации среди различных компонентов, т.е. чтобы формат даты/времени был единообразным и сообщения об ошибке и предупреждении были единообразными: «Ошибка:» и «Предупреждение:» соответственно.
Количество уровней записей может быть увеличено для содействия отладке путем усовершенствования, обеспечения качества и выездного обслуживания. Такие уровни записей называются выходными данными уровня отладки и обеспечиваются свойствами, менеджмент которых осуществляет менеджер свойств.
Может иметься опция глобальной отладки, обеспечивающая выдачу сообщений по всем отладкам, и опция локальной отладки для выдачи сообщений по отладке определенных компонентов и подсистем. Запись по отладке может иметь собственную метку для упрощения ее поиска в файлах записей, например для поиска отладки выявления.
Примеры типов категорий отладки включают: отладка выявления, отладка сбора данных, отладка аналитики, отладка безопасности, отладка графика работы, отладка долговременного хранения/доступа к базе данных, отладка конфигурации, отладка графика работы, отладка пользовательского интерфейса и т.д. по необходимости.
Менеджер проверок может быть одиночным, так что может быть общеиспользуемым среди одного или более компонентов в системе анализа потребления мощности дата-центром, и предназначен для менеджмента одной или более части информации, относящейся к проверке безопасности.
Проверочная запись по каждой системе виртуальной памяти (VSS) содержит относящуюся к безопасности информацию, которая идентифицирует дату/время, пользователя и запрос, инициируемый в нашей системе, а также любые относящиеся к безопасности уведомления или ошибки. Для доступа к WEB-серверу также записывается IP-адрес запрашивающего клиента.
Все VSS-компоненты могут предоставлять средства трассировки, которые могут быть деактивированы по умолчанию, но могут быть динамически активированы, когда это необходимо, посредством менеджера свойств. Информация об уровне трассировки может включать дату-время, название класса, название способа, индикаторы входа/выхода и параметры способа.
Отладочный интерфейс с командной строкой может представлять собой отладочную утилиту, которая может осуществлять доступ к работающей системе. Он позволяет пользователю отображать и модифицировать информацию об объектах, в том числе величины атрибутов объекта, и информацию о стеках данных.
Хотя программные средства могут представлять собой белый ящик с инсталлированной операционной системой Linux, в которую затем инсталлируется продукт для анализа потребления мощности дата-центром, пользователь может рассматривать их как черный ящик (т.е. пользователь может не иметь представления о внутренней структуре продуктов и/или сервисов), который предоставляет соответствующие системные ресурсы. Обновления отправляются на описательный web-сервер и доступны.
Менеджер графиков работы может быть одиночным, так что может быть общеиспользуемым среди одного или более компонентов в системе анализа потребления мощности дата-центром. Он поддерживает составление графика и выполнение задач в определенное время либо пользователем, либо компонентом в нашей системе.
Основные внутренние компоненты программных средств или пользователи могут полагаться на менеджер графиков работы в занимающих много времени задачах, которые нельзя остановить, например в сессиях выявления компонентов и составления карты большого дата-центра или в долговременной аналитической операции. Далее, клиенты могут полагаться на менеджер графиков работы для очистки базы данных от устаревших данных через предварительно заданные интервалы времени или для менеджмента резервного копирования конфигурации в целях восстановления после аварии.
Менеджер графиков работы может принимать входные данные для ответа на следующие вопросы:
- Какая работа должна быть выполнена?
- Кто создал график работы?
- Когда был создан график работы?
- Когда согласно графику работа должна быть выполнена?
- Является ли работа повторяющейся и если да, то с какими интервалами?
Менеджер статусов может быть одиночным, так что может быть общеиспользуемым среди одного или более компонентов в платформе анализа дата-центра. Он может предоставлять информацию о статусе, позволяющую пользователям понимать текущее рабочее состояние, в том числе информацию о статусе работ, находящихся в процессе выполнения, и работ, назначенных для исполнения в будущем.
Эта подсистема может обеспечивать понимание того, что происходит и как это прогрессирует. Поскольку создание графика работы, в конечном счете, требует видимости статуса работы, выходные данные менеджера графиков работы могут быть неотъемлемой частью выходных данных менеджера статусов, отображающего текущее состояние задачи (например, «внесена в график», «выполняется», «выполнена») и процент выполнения, если задача выполняется. Также может показываться статус для любой задачи, выполнение которой завершено (например, «успешно», «неуспешно», «время выполнения превышено» и т.д.).
Менеджер статусов может отслеживать работы с атрибутами, к числу которых могут относиться следующие:
- Какая работа была внесена в график?
- Кто запросил эту работу?
- Когда запрос на исполнение работы был инициирован?
- Когда согласно графику работа подлежит/подлежала выполнению?
- Состояние работы (например, «внесена в график», «выполняется», «выполнена»).
- Статус работы (например, % выполнения).
- Код завершения работы (например, «успешно», «неуспешно», «время выполнения превышено» и т.д.).
Пользовательский интерфейс (UI) может предоставлять приборный интерфейс (например, такой, как показан на Фиг. 26), обеспечивающий видимость текущего состояния основных компонентов, таких как, например, внесенные в график задачи, выполняемые задачи и выполненные задачи. Информация о задаче может сохраняться в течение некоторого назначаемого периода времени, после чего история может удаляться.
Набор библиотек для общеиспользуемых функций может обеспечивать единообразие между воплощениями компонента, доведение до максимума повторного использования кода и простоту ведения.
Библиотеки могут включать, без ограничения, пул потока и инструменты менеджмента памяти, закрепление соответствующих функций за семафорами и мьютексами, а также функции удобства для работы со строками и т.п.
Источники для библиотек класса разработки могут храниться в общем пакете контроля источников и могут не быть отнесены к какому-либо одному конкретному компоненту.
Далее, долговременно хранящиеся данные, а также данные о конфигурации и базе данных могут храниться в формате UTF-8.
База данных или электронное запоминающее устройство, содержащая или содержащее ресурсы дата-центра и собираемые данные, может помогать в понимании проблем клиента. Могут иметься средства импорта/экспорта, с тем чтобы облегчить извлечение конкретных конфигураций и их импорт в другие системы. Эти средства могут использоваться локально для помощи в автоматизации проверки обеспечения качества, а также для того, чтобы позволить обслуживающему персоналу выявлять проблемы, связанные с конфигурацией, на рабочем месте клиента.
Для клиентских рабочих мест, которые имеют соединение через внешнюю сеть с находящимися на хосте серверами, имеются средства удаленного доступа для информирования пользователей о наличии обновлений для их инсталлированного в данный момент программного обеспечения.
Безопасность может иметь высокий приоритет в дата-центрах. Например, может отсутствовать доступ к клиентским системам, предназначенный для помощи в решении проблем, связанных с использованием продукта или отладкой продукта. Имеется инструмент для фиксации мгновенного состояния сервисной системы, собирающий различные файлы записей продукта и системы, включая информацию о конфигурации и свойствах. Клиенты могут загружать сжатую собранную информацию на наш обслуживающий сайт. Состояния, описанного собранной информацией, может быть достаточно для удаленного устранения проблемы клиента.
Обеспечение эффективности дата-центра может требовать отличного от существующих, но технически совершенного способа, который автоматически идентифицирует неэффективность и применяет определенные стратегии, которые, как было доказано, доводят до максимума экономию энергии.
Согласно некоторым вариантам осуществления, подход может быть кратко представлен в виде следующих этапов:
i. Уяснение существующей физической инфраструктуры: сбор данных о физической структуре дата-центра;
ii. Мониторинг операций (непрерывное использование приборов и измерений для идентификации эффективности текущих операций всех потребляющих энергию систем и идентификации загруженности ИТ-оборудования);
iii. Уяснение связи между логической и физической инфраструктурой: составление карты физического ИТ-оборудования и наложение ее на карту логического использования IT-оборудования.
На основании идентифицированной неэффективности потребления мощности могут быть предложены стратегии планирования для ее (неэффективности) устранения.
Логический, операционный этапы и этап планирования могут работать во взаимодействии для создания автоматического процесса для оптимизации потребления энергии в дата-центре.
Имеется пять элементов в процессе автоматизации, как показано в примере осуществления на Фиг. 12:
1) Логический симулятор (потребление мощности ИТ-ресурсами);
2) Симулятор физического оборудования (оценка температурного профиля физического оборудования);
3) Энергетическая модель оборудования (модель оценки потребления мощности на охлаждение дата-центра);
4) Селектор стратегии (для экономии энергии);
5) Оптимизатор потребления энергии (для всего дата-центра).
Логический симулятор может работать на логическом уровне для оценки мощности, требуемой ИТ-системами, и генерирует в качестве выходной информации список рентабельных стратегий экономии энергии и расположений или нахождений кандидатов, который предоставляется симулятору физического оборудования.
Входная информация логического симулятора может включать:
i) План физической сети и соединений всего ИТ-оборудования;
ii) Базу данных ИТ-ресурсов, которая ведет все вводимое в эксплуатацию ИТ-оборудование;
iii) Статистическую базу данных загруженности, эффективности, потребления мощности и т.д. для ИТ-оборудования;
iv) Измерения: данные от всех датчиков о температуре, о расходе воздуха либо родственные данные, получаемые с помощью других внутренних измерительных устройств от любого ИТ-оборудования;
v) Ввод в эксплуатацию ИТ-оборудования (или любые измнения в ИТ-оборудовании): ввод в эксплуатацию, повторный ввод в эксплуатацию, изъятие из эксплуатации или, возможно, изменение местоположения и т.д. ИТ-оборудования.
Логический симулятор может использовать основанную на ограничениях оптимизацию для генерации его рекомендаций.
Симулятор физического оборудования может быть использован для приема выходных данных логического симулятора и транслирования потребления мощности ИТ-оборудованием в температурный профиль физического оборудования, такой как, например, тепловая карта. Тепловая карта для различных зон дата-центра (как показано на Фиг. 13) может быть получена с использованием моделирования на основе вычислительной гидродинамики.
Когда тепловая карта получена, мы можем оценить нагрузку на охлаждающие средства (например, в британских тепловых единицах). Это может быть осуществлено, согласно некоторым вариантам осуществления, с использованием таблиц перевода мер, таких как таблицы компании ASHME, для определения суммарной энергии, потребляемой охлаждающими средствами для поддержания желаемой заданной рабочей температуры дата-центра.
Энергетическая модель оборудования может содержать нелинейную модель, которая оценивает нагрузку на охлаждающие средства, требуемую для оборудования, когда некоторый источник тепла (т.е. ИТ-оборудование) введен в эксплуатацию в дата-центре. Поскольку модель может быть зависимой от конкретной физической конфигурации и размещения ИТ-оборудования и охлаждающих систем в дата-центре, она может быть построена посредством адаптации (обратной связи) и на основании любых предварительных знаний о термодинамических свойствах оборудования.
На основании желаемой стратегии загрузки охлаждающих средств и вариантов их размещения, которые предоставлены симулятором физического оборудования и логическим симулятором, этот модуль (селектор стратегии) может определять (используя методики теории игр, измерения из дата-центра и показатели, которые мы называем V-коэффициентами (определены ниже)) наилучшие варианты размещения оборудования, которые сводят к минимуму суммарную нагрузку на охлаждающие средства и суммарное потребление мощности в дата-центре.
Оптимизатор может оценивать и анализировать варианты размещения, рекомендуемые селектором энергетической стратегии, на основании предполагаемых суммарных издержек на электроэнергию (потребление мощности ИТ-оборудованием, определенное логическим симулятором, и нагрузка на охлаждающие средства, определенная симулятором физического оборудования). Он может определять оптимальную стратегию и оптимальный вариант размещения.
Когда оптимальная стратегия и оптимальный вариант размещения выполнены, оптимизатор может сравнить текущую нагрузку на охлаждающие средства и текущее суммарное потребление энергии с предполагаемыми величинами и на основании отклонений доработать энергетическую модель оборудования.
Используя управление с обратной связью, модель физического оборудования дата-центра может непрерывно обновляться для точности. Это, в свою очередь, может повышать предсказуемость суммарной экономии энергии для данного дата-центра.
Как показано в примере графического пользовательского интерфейса на Фиг. 14, операции дата-центра могут подвергаться мониторингу для понимания того, сколько мощности каждый ИТ-компонент потребляет в то или иное время.
В случае с серверами может быть использована база данных или может быть использовано электронное запоминающее устройство, которая или которое оценивает потребление мощности для ИТ-оборудования (например, серверов, запоминающих устройств и т.д.) различных поставщиков на основании информации о конфигурации, такой как количество процессоров, устройств памяти и т.д. Эта база данных может быть снабжена автоматизирующим программным обеспечением для предсказания потребления мощности на уровне оборудования, когда физический план и логическая ИТ-инфраструктура дата-центра известны.
Важной функцией этой базы данных и ее программного обеспечения по отношению к введенному в эксплуатацию оборудованию может являться предсказание текущего потребления мощности любым оборудованием в любое время.
Согласно некоторым вариантам осуществления, понимание текущего состояния потребления энергии и мощности может быть обеспечено путем непрерывного мониторинга потребления мощности ИТ-оборудованием и расхода энергии на охлаждающие средства. Для этого может иметься несколько причин.
Во-первых, паспортные потребление мощности и расход энергии на охлаждающие средства, указанные поставщиками оборудования, могут представлять собой величины наихудшего случая. Поэтому использование значений из паспортной таблицы поставщика может привести к значительному завышению предсказываемых величин, что, в свою очередь, может привести к использованию более дорогих систем питания, а следовательно, большей неэффективности и большим издержкам на доставку питания.
Во-вторых, уровни потребления мощности ИТ-оборудованием могут варьироваться значительно в зависимости от уровня загруженности. Колебание потребления мощности в 50% может быть обычным явлением, когда сервер переходит из режима незначительной загрузки в режим полной загрузки. Когда эта вариация потребления мощности распространяется на большое количество серверов в дата-центре, вариации суммарного потребления мощности могут быть очень большими.
В-третьих, могут иметься значительные вариации в потреблении мощности при относительно небольших изменениях физической конфигурации серверов.
В-четвертых, точные измерения потребления мощности могут требовать измерительного оборудования, влияющего на работу ИТ-оборудования, особенно когда несколько устройств, таких как серверы, потребляют мощность из одной схемы и определение потребления мощности каждым сервером в отдельности может быть невозможным.
В-пятых, в то время как оценка потребления мощности является сложной, предсказание нагрузки на охлаждающие средства в различных областях дата-центра, когда различное ИТ-оборудование помещено в этих областях, является еще более сложным. В настоящее время нет хорошего доступного или осуществимого способа измерения в реальном времени нагрузки или издержек на охлаждающие средства, которые относятся к каждой физической области внутри дата-центра.
При проведении инвентаризации физических ИТ- и питающих ресурсов в дата-центре могут использоваться как ручная инспекция дата-центра, так и инспекция дата-центра с помощью измерительного оборудования. Детальная инвентаризация может использоваться для определения того, какое потребляющее мощность физическое ИТ-оборудование было введено в эксплуатацию на участке. Детальная информация может включать информацию о местоположении, т.е. местоположение внутри серверного стеллажа, местоположение стеллажа в дата-центре по отношению к проходам и т.д., поскольку количество энергии, необходимой для охлаждения, может зависеть от конкретного расположения, которое может широко варьировать термодинамические профили.
Результаты физической инвентаризации могут затем извлекаться и изучаться, как показано на Фиг. 15, где для каждого сервера, который был идентифицирован по местоположению, может иметься измерение, которое показывает потребление мощности с удовлетворительной точностью. Поскольку ожидаемые уровни экономии энергии могут находиться в диапазоне 20%-40%, любой способ измерения, который имеет погрешность более нескольких процентов, может являться неподходящим для точного охарактеризовывания рабочего потребления мощности и возможности экономии энергии. Поскольку (при инвентаризации) потребление мощности измеряется не способом постоянного мониторинга оборудования, а на приблизительном уровне в дата-центре, может иметься недостаток точных подробных измерений.
Потребление мощности может быть оценено на уровне отдельного ИТ-оборудования (или отдельной схемы). Этот новый способ может использовать внутреннюю информацию устройства для предсказания потребления мощности без нужды в каком-либо специальном измерительном оборудовании или электропроводе. Это может решить две проблемы:
- Во-первых, может быть невозможно установить измерительное оборудование физически на отдельные устройства, такие как серверы внутри стеллажа.
- Во-вторых, даже если установка измерительного оборудования возможна, некоторые владельцы дата-центров могут не позволять устанавливать измерительное оборудование, влияющее на работу.
Принимая во внимание эти два ограничения и учитывая, что не существует задокументированного подхода для решения этой проблемы, этот новый логически выведенный подход может оценивать потребление мощности на уровне отдельного устройства независимо от схемы, в котором оно находится, путем считывания других данных непосредственно с устройства. Это может предоставлять информацию о потреблении мощности этим устройством независимо от конфигурации устройства.
Когда физическая инвентаризация всего ИТ-оборудования была выполнена, использование базы данных может обеспечить идентификацию того, как логическая карта бизнес-приложений накладывается на карту физического оборудования, например какие серверы используются для сервисов электронной почты.
С помощью этой логической привязки может быть определено, какое ИТ-оборудование используется для каких важных (или, наоборот, неважных) бизнес-приложений и тратится ли на это приемлемая доля бюджета мощности.
Симулятор физического оборудования может предоставлять тепловую карту физического оборудования. Однако для оценки нагрузки на охлаждающие средства селектор стратегии может использовать не только выходные данные симулятора физического оборудования, но и энергетическую модель оборудования дата-центра.
Эта оценка может помогать в количественной оценке того, каким образом любая новая или измененная ИТ-нагрузка влияет на суммарное потребление энергии, и может содействовать в обеспечении возможности предсказания в рамках выбранной стратегии экономии энергии. Насколько нам известно, в то время как существующие подходы к уменьшению потребления энергии в дата-центре используют ручной и выбираемый для конкретного случая подходы, предлагаемый подход может обеспечивать автоматизированный и масштабируемый подход к уменьшению потребления энергии дата-центром.
Существующие способы измерения эффективности потребления энергии в дата-центре являются очень грубыми и не помогают в определении конкретных областей, где энергия может быть сэкономлена. Они включают измерение эффективности потребления мощности (PUE), которое показывает лишь то, какая доля всей расходуемой мощности полезно потребляется дата-центром и ИТ-оборудованием. Это может иметь несколько ограничений.
Например, существующие способы измерения эффективности потребления мощности не предоставляют информацию о том, как горячая точка (зона или область в дата-центре, которая при работе гораздо горячее, чем другие области) или неэффективность охлаждения в зоне повышают издержки на охлаждение, в то время как эта горячая точка повышает температуру в соседней зоне, которая (соседняя зона) при нормальных условиях была бы холоднее. Эта неэффективность может вносить 20%-ное или даже большее увеличение издержек на охлаждение.
Если способ измерения эффективности потребления мощности не может выделить локализованные зоны, которые вызывают значительную неэффективность, он не показывает, какие области дата-центра могут обеспечивать наибольшую экономию энергии, и не показывает природу неэффективности.
Из-за ограниченности информации, предоставляемой существующими способами измерения эффективности, идентификация источников неэффективности дата-центра представляла собой ручной процесс.
Новые количественные долевые показатели эффективности, так называемый «описательный коэффициент» или «V-коэффициент», могут характеризовать дата-центр на уровне узлов, меньших, чем стеллаж, и находящихся внутри стеллажа. Он (коэффициент) может быть выведен или вычислен из параметров, которые можно измерить внутри дата-центра. Он может количественно показывать улучшения в эффективности потребления энергии после того, как была применена стратегия экономии энергии.
Несколько разных V-коэффициентов были разработаны, включая коэффициенты по наилучшему размещению ИТ-оборудования внутри дата-центра, по эффективности потребления энергии ИТ-оборудованием и по эффективности охлаждения любой зоны в дата-центре.
В качестве простой иллюстрации того, как может быть использован V-коэффициент, рассмотрим помещение нового ИТ-оборудования, сервера, внутрь дата-центра.
Фиг. 13 показывает температурный профиль дата-центра (он был генерирован с помощью процесса, требующего большого объема вычислений, называемого вычислительной гидродинамикой или CFD). Две зоны - горячая и холодная - отмечены в дата-центре. Простым подходом было бы помещение нового сервера в холодную зону. Однако процесс размещения оборудования является более сложным, поскольку он должен принимать во внимание издержки на охлаждение (эффективность охлаждения) в зоне, суммарное количество (в ваттах) доступной мощности в стеллаже и имеющееся свободное пространство.
Используя V-коэффициент заполненности, мы можем автоматически определить наилучшую зону в дата-центре, которая сводит к минимуму издержки на охлаждение и при этом обеспечивает выполнение требований по количеству доступной мощности, объему свободного пространства и т.д.
Фиг. 16 показывает визуальный результат использования V-коэффициента для оптимального размещения сервера в дата-центре. Зеленые области показывают идеальное местоположение для сервера.
В качестве части этапа планирования может быть предоставлен список целесообразных стратегий с градацией по приоритетности, которые (стратегии) могут быть реализованы в дата-центре. Этот список используется селектором стратегии.
Фиг. 17 показывает визуализацию стратегии устранения зомби-серверов. Красные зоны показывают местоположение зомби-серверов, которые могут быть устранены (например, неиспользуемых серверов или других неиспользуемых ресурсов).
Примеры осуществимых стратегий включают:
- Устранение горячих точек
Идентификация горячих точек может включать идентификацию областей в дата-центре, которые гораздо горячее, чем другие области. С помощью перемещения оборудования или модификации нагрузки мы можем уменьшить потребляемую мощность (генерируемое тепло) или улучшить охлаждение (например, поток воздуха). Эта стратегия может обеспечить меньшую нагрузку на охлаждающие средства и меньшие издержки.
- Размещение оборудования
Размещение оборудования может включать благоразумное помещение нового оборудования в более холодных точках, а не в более горячих точках для уменьшения суммарной температуры дата-центра.
- Эксплуатация дата-центра при более высоких температурах Эксплуатация дата-центра при более высоких температурах может уменьшать суммарную нагрузку на охлаждающие средства и тем самым увеличивать эффективность потребления мощности дата-центром.
- Устранение зомби-серверов
Путем идентификации и выведения из эксплуатации зомби-серверов (т.е. серверов, которые не используются для каких-либо приложений в дата-центре) потребление мощности и нагрузка на охлаждающие средства могут быть снижены.
- Объединение ИТ-ресурсов
Объединение ИТ-ресурсов таким образом, что вычислительные и запоминающие ресурсы имеют большие возможности, может снижать суммарное потребление мощности (т.е. может быть уменьшено потребление мощности блоком оборудования).
- Замена оборудования, имеющего более низкую эффективность потребления энергии
Замена оборудования, имеющего более низкую эффективность потребления энергии, оборудованием, имеющим более высокую эффективность потребления энергии, может снизить суммарное потребление мощности.
Большая часть этих стратегий (как размещение нового оборудования, так и технологическое обновление) не являются простыми решениями. Они требуют учета следующего:
i. Наложение карты загруженности логического ИТ-оборудования на его текущее физическое расположение;
ii. Ограничения пространства и доступной мощности.
Внесение изменений (как размещение нового оборудования, так и перестановка имеющегося оборудования) изменяет потребление мощности и соответствующую нагрузку на охлаждающие средства в данном месте и в соседних зонах.
Обычно решение подобной проблемы, осуществляемое в оптимизаторе потребления энергии, требует решения задачи оптимизации с множеством ограничений.
Согласно одному варианту осуществления, один подход представляет собой «мониторинг-понимание-контроль» эффективности потребления энергии во всем дата-центре.
Согласно некоторым вариантам осуществления, один или более расчетов может включать коэффициенты, учитывающие другие издержки, в том числе издержки на охлаждение. Например, может иметься описательный коэффициент, который может учитывать реальную стоимость ватта мощности. Стоимость мощности может быть равна следующему: стоимости мощности, потребляемой ИТ-оборудованием, + стоимость мощности, потребляемой охлаждающими средствами, + стоимость потерь мощности. Другие расчеты могут включать:
- Стоимость мощности ~ Эффективность потребления мощности * стоимость ватта;
- Стоимость пространства = Амортизационная стоимость здания для дата-центра/мощность;
- Стоимость дополнительно предоставляемой мощности + стоимость охлаждающего аппаратного обеспечения/мощность ⇒ дополнительные БРМ охлаждающие средства, ИБП, батареи ИБП и другое/мощность.
Кроме того, введение в эксплуатацию ИТ-оборудования в дата-центре может влиять на следующие параметры: мощность, охлаждение, пространство и доступность (надежность). Стандартные расчеты эффективности потребления мощности могут быть недостаточными. Например, Фиг. 18 может представлять собой тепловую карту, представляющую два разных места для размещения оборудования в дата-центре. Опция 1 может представлять собой горячее место, а опция 2 может представлять собой холодное место. Эти места могут, согласно некоторым вариантам осуществления, быть определены с использованием вычислительной гидродинамики. Стандартные расчеты эффективности потребления мощности могут быть не достаточными для их определения.
Объем расчетов может применяться местно: вычисления могут вестись на уровне стеллажа для нахождения «зоны» внутри стеллажа, где может быть размещено оборудование. Это может быть полезно для оптимального размещения оборудования. При этом могут использоваться индикаторы эффективности потребления мощности, доставляемой в зону (для работы, выполняемой ИТ-оборудованием). Дата-центр может быть разделен или организован на зоны. Размер зоны может быть меньше стеллажа (например, 1 скоба или 2 скобы в двух стеллажах) или больше либо равен стеллажу (например, несколько стеллажей). Ячейки, установочные места или скобы могут быть объединены в зоны. Например, Фиг. 19 может представлять собой один стеллаж до разделения на зоны. Фиг. 20 может представлять собой пример разделения стеллажа на зоны согласно некоторым вариантам осуществления. Зоны могут также охватывать и/или вмещать один или более стеллажей.
Примеры коэффициентов включают:
t
- V - коэффициент относительной температуры в зоне.
Этот коэффициент, который может показывать, как следует распределять издержки на охлаждение в дата-центре, который может охлаждаться неравномерно (например, имеет горячие точки).
w
- V - коэффициент доли мощности
Этот коэффициент показывает отношение мощности, используемой в определенной зоне, к суммарной потенциально предоставляемой мощности.
s
- V - коэффициент нормализованного пространства, доступного в зоне.
Этот коэффициент показывает количество доступных установочных мест (скоб) и идущих подряд установочных мест (скоб).
u
- V - коэффициент загруженности ИТ-оборудования в зоне.
Для вычисления этого коэффициента сначала необходимо нормализовать произведение «количество ядер × тактовая частота × загруженность».
p
- V - коэффициент заполненности (стоимости) зоны (вектора) или дата-центра.
p
t
w
s
p
V=VVV V - это функция коэффициента относительной температуры в зоне, коэффициента доли мощности и коэффициента нормализованного пространства, доступного в зоне.
p
Зоны с высоким коэффициентом V могут быть менее желательными местами для установки оборудования.
e
- V - коэффициент нормализованной эффективности ИТ-оборудования.
e
u
V=f(V(V) (нелинейная функция!).
e
u
t
V - это функция коэффициента загруженности ИТ-оборудования и коэффициента относительной температуры. Зоны, где этот коэффициент ниже, являются менее эффективными. Этот коэффициент может быть более высоким, когда коэффициент V загруженности ИТ-оборудования является более высоким. Этот коэффициент может быть более низким, если коэффициент V относительной температуры является более высоким.
Он может быть оценен с использованием температуры процессора, GxDB-профилей сервера и т.д.
r
t
- V - коэффициент надежности ИТ-оборудования в зоне. Как изображено на Фиг. 21, надежность может зависеть от возраста оборудования в зоне. Как изображено на фигуре 22, она может зависеть от температуры в зоне, т.е. от коэффициента V.
Имеется несколько видов коэффициентов относительной температуры с точки зрения размеров зоны:
t
- Глобальный (масштаба дата-центра) V
Он может измерять дисбаланс температурных профилей в дата-центре (ДЦ).
Он может предоставлять одно числовое значение, которое показывает состояние дисбаланса (в частности, неэффективность охлаждения). Он может быть вычислен как взвешенная разность температур зон.
i
j
Z, Z - средние температуры зон i и j;
ij
d - расстояние между зонами i и j;
N - суммарное количество зон.
t
- Локальный V
Он может измерять дисбаланс температурных профилей для одной зоны. Он может показывать издержки на размещение любого ИТ-оборудования в зоне. Он может представлять собой относительную меру издержек.
Он может находиться в некотором соотношении с температурным профилем дата-центра.
Горячие точки могут быть найдены с помощью вычислительной гидродинамики.
t
Фиг. 23 представляет собой пример использования глобального коэффициента V для сравнения конфигураций двух дата-центров. Может иметься шестнадцать единообразных (уровня стеллажа) зон с разными температурами.
t
Фиг. 24 представляет собой второй пример использования глобального коэффициента V. Две конфигурации дата-центра могут иметь одинаковый набор температур зон, но разное их распределение.
t
t
Фиг. 25 представляет собой пример использования локального (для зоны) коэффициента V. Локальный (для зоны) коэффициент V может представлять собой «арендные» издержки, т.е. издержки, возникающие при помещении оборудования в данном месте. Он может быть более высоким в той зоне, где разность температур выше: это может отражать более высокие издержки на смешивание горячего и холодного воздуха.
Таким образом, возможно большое количество различных стратегий экономии энергии, которые работают с разными параметрами и производят разные V-коэффициенты.
Стратегии экономии энергии
Стратегия
Необходимые параметры/информация
Соответствующий коэффициент
Размещение
Устранение горячих точек
- Замеры температур внутри стеллажа
V<sub>p</sub>(V<sub>T</sub>)
- Оценка температуры стеллажа/полки
- Нагрузка на охлаждающие средства серверов
Размещение
Размещение оборудования
- Тепловая карта уровня зоны
V<sub>p</sub>(V<sub>T</sub>)
- Нагрузка на охлаждающие средства ИТ-оборудования (серверов)
Размещение
Сбалансированная доставка мощности
Снижение мощности
Эксплуатация дата-центра в горячем режиме
- Среднее количество отказов / Среднее время между отказами сервера
V<sub>r</sub>, V<sub>w</sub>
- Уменьшение среднего времени между отказами сервера при изменении температуры
- Изменение нагрузки на охлаждающие средства при изменении температуры
Снижение мощности
Устранение зомби-серверов
- Ключевые приложения, выполняемые в дата-центре
V<sub>u</sub>, V<sub>w</sub>
- Наложение карты выполняемых приложений на карту серверов - общий уровень
Снижение мощности
Использование передовых способов питания и охлаждния
V<sub>w</sub>, V<sub>t</sub>
Снижение мощности
Объединение
- Спецификации нового оборудования
V<sub>u</sub>, V<sub>w</sub> и V<sub>s</sub>
- Требуемые рабочие характеристики для работы приложения
Более хорошее оборудование
Технологическое обновление
- Политика ДЦ в отношении технологических обновлений/замен
V<sub>u</sub>, V<sub>w</sub>
- Спецификации нового оборудования
Более хорошее оборудование
Технологическое обновление, размещение оборудования
Сочетание №6 и №7
V<sub>p</sub>, V<sub>u</sub>, V<sub>w</sub>, V<sub>s</sub>
Более хорошее оборудование
Ярусное размещение
Путем балансирования потребления мощности, охлаждения и загруженности быстродействие дата-центра может быть повышено. Это может высвободить ресурсы, повысить уровень и быстроту сервисов, а также увеличить срок службы дата-центра.
Согласно некоторым вариантам осуществления, лишь программное обеспечение может быть использовано в дата-центре. Дополнительные датчики или исполнительные устройства могут не требоваться. Использование стандартных протоколов и API может обеспечить возможность использования оборудования нескольких поставщиков. Может быть обеспечено объединение данных от большого количества источников данных.
Это может повысить эффективность использования мощности на уровнях дата-центра, электрической схемы и стеллажа. Это может обеспечить интегрированное понимание физических и логических слоев дата-центра. Это может обеспечить возможность усовершенствования учета мощности (возврата переплаты) на уровнях сервера, приложения и бизнеса. Это может обеспечить возможность при исполнении договоров об уровне обслуживания лучше анализировать риск и эксплуатационную готовность, улучшить тактическую оптимизацию и стратегическое планирование, а также использовать менеджмент эффективности дата-центра.
Описанные способы анализа потребления мощности и анализа температуры могут предоставлять информацию о потребности в мощности/охлаждении физического компонента, менеджмент потребления мощности в реальном времени, менеджмент охлаждения в реальном времени, анализ для выявления тенденций и для предсказаний, возможность возврата переплат, тактическое размещение оборудования, менеджмент риска и эксплуатационной готовности, а также систему и симуляцию для оптимизации эффективности.
Согласно некоторым вариантам осуществления, описанный один или более способ анализа потребления мощности и анализа температуры может быть обеспечен в основе программного обеспечения в качестве сервисной модели. Могут иметься различные модели расчета цены. Могут обеспечиваться регулярные обновления моделей потребления мощности и температурных моделей. Согласно некоторым вариантам осуществления, способы могут учитывать льготные цены (на энергию) для некоторых компонентов дата-центра, менеджмент которых осуществляется. Может иметься функция сведения издержек к некоторому уровню.
Фиг. 26-29 показывают примеры экранов мониторинга, отчетов и менеджмента. Фиг. 30 показывает представление высокого уровня одного или более вариантов осуществления способов, описываемых в настоящем документе.
Здесь необходимо отметить, что способы анализа потребления мощности дата-центрами согласно настоящему изобретению, описанные выше, обычно включают, в известной степени, обработку входных данных и генерацию выходных данных. Эта обработка входных данных и генерация выходных данных могут осуществляться в аппаратном обеспечении или программном обеспечении. Например, в модуле анализа потребления мощности дата-центром могут использоваться определенные электронные компоненты либо подобные или родственные схемы для воплощения функций, относящихся к анализу потребления мощности дата-центром согласно настоящему изобретению, как описано выше. Альтернативно, один или более процессор, работающий согласно инструкциям, может воплощать функции, относящиеся к анализу потребления мощности дата-центром согласно настоящему изобретению, как описано выше. В этом случае в объем настоящего изобретения входит то, что указанные инструкции могут храниться на одном или более читаемом процессором запоминающем устройстве (например, на магнитном диске или ином запоминающем устройстве) или передаваться одному или более процессору посредством одного или более сигнала, воплощенного на одной или более несущей волне.
Настоящее изобретение не ограничено объемом конкретных вариантов осуществления, описанных в настоящем документе. Безусловно, другие различные варианты осуществления и модификации настоящего изобретения, помимо тех, что описаны в настоящем документе, должны быть очевидны для специалистов, обладающих средним уровнем знаний в данной области, из вышеприведенного описания и прилагаемых чертежей. Таким образом подразумевается, что эти другие варианты осуществления и модификации входят в объем настоящего изобретения. Далее, хотя настоящее изобретение было описано в настоящем документе в контексте конкретного воплощения в конкретной рабочей среде для конкретной задачи, специалисты, обладающие средним уровнем знаний в данной области, должны понимать, что его применимость не ограничена ими и что настоящее изобретение может быть с выгодой воплощено в любом количестве рабочих сред для любого количества целей. Соответственно, полные объем и сущность настоящего изобретения определены нижеприведенной формулой изобретения.