Собственный цод: Шесть причин использовать собственный ЦОД

Шесть причин использовать собственный ЦОД

Почему между использованием облаков и созданием собственного центра обработки данных компании до сих пор выбирают второе?

Когда дело доходит до хранения огромных объемов данных, облачные дата-центры представляют собой экономичную альтернативу настройке и эксплуатации собственных ЦОДов.

По сути, облачный дата-центр — это удаленная версия ЦОДа, расположенная где-то вдали от физических помещений вашей компании, которая позволяет получать доступ к вашим данным через Интернет. Облачный провайдер выполняет текущее обслуживание, часто владея разными центрами обработки данных в нескольких географических точках, чтобы защитить ваши данные во время простоев и других сбоев, считает Говард Вэн (Howard Wen).

Но никакие аргументы сторонников облаков не заставят компании отказаться от своих внутренних центров обработки данных. Почему же собственные ЦОДы обладают такой устойчивостью?

Хотя ожидается, что размер мирового рынка облачных вычислений вырастет с $371,4 млрд в 2020 году до $ 832,1 млрд к 2025 году, при среднегодовом темпе роста 17,5%, локальные серверы по-прежнему работают в 98% предприятий.

Промышленность «началась с мэйнфреймов, затем мы перешли на автономные серверы, а затем настала эра облачных технологий», — говорит Питер Цай (Peter Tsai), старший аналитик по технологиям в Spiceworks, известном форуме ИТ-сообщества, — Теперь кажется, что мы возвращаем вычислительные ресурсы обратно, ближе к тому месту, где они нужны».

Внутренние центры обработки данных никуда не денутся несмотря на то, что предприятия переводят все больше ИТ в облака. Результатом становится активное принятие гибридных вычислений, когда одни ИТ-активы передаются на внешнее облако, а другие обслуживаются внутри корпоративных стен.

Каковы движущие силы поддержки внутренних центров обработки данных и управления ИТ? Свою версию предлагает Мэри Э. Шаклетт (Mary E. Shacklett), известный обозреватель в области технологий и президент Transworld Data, компании, предоставляющей маркетинговые и технологические услуги.

1. Инвестиции в существующие системы

С одной стороны предприятия борются со старением ИТ-персонала, с другой — им необходимо поддерживать критически важные приложения, которые были написаны еще 60 лет назад на COBOL.

Многие из этих программ прекрасно и бесперебойно проработали все эти годы. Их критически важная обработка включает в себя вызов подпрограмм «черного ящика», которые работают безупречно, но не задокументированы и неизвестно, что они на самом деле делают. Поэтому, сейчас востребованы знания языка COBOL.

Существует также множество устаревших систем, таких как ERP, которые обеспечивают «проверенную временем» ценность для бизнеса.

Почти каждый поставщик ERP теперь предлагает облачные версии своих систем, поэтому перед предприятиями встает выбор: переходить ли на облачную версию ERP или поддерживать свою систему 30–40-летней давности с собственным кодом, если это дает компании явное конкурентное преимущество? Многие выбирают последнее, и продолжают работу своих внутренних центров обработки данных.

2. Управление жизненным циклом

В обзоре Spiceworks было отмечено, что «on-premise технологии остаются в дорожных картах покупателей бизнес-технологий, но события, связанные с окончанием срока эксплуатации, могут скорректировать инвестиции».

В том же исследовании был сделан вывод о том, что «треть организаций покупает новые серверы в связи с окончанием срока поддержки операционной системы». Например, Microsoft отказалась от расширенной поддержки Windows Server 2008 в январе 2020 года, а затем в июле 2020 года отказалась от поддержки SQL Server 2008.

Хотя такие события действительно побуждают компании реинвестировать, многие не всегда делают это быстро. Вместо этого они ищут сторонние варианты поддержки или выполняют внутреннюю поддержку, чтобы эти системы могли работать локально.

В других случаях компании предпочитают попробовать что-то новое, например, перейти в облако.

Несколько лет назад автор консультировал компанию, предоставляющую финансовые услуги, которая решила перенести свои серверы Microsoft в облако. В то же время эта компания решила купить новые локальные серверы и лицензии, чтобы у них была, по крайней мере, возможность аварийного переключения в случае отказа в облаке.

Результатом стало гибридное сочетание облачных и локальных систем, которое гарантировало руководству, что они экономят немного денег за счет перехода в облако, но также имеют контроль аварийного переключения своих систем.

3. Безопасность и интеллектуальная собственность

Если у вас есть проприетарный код в ваших системах, который дает вашей компании конкурентное преимущество, есть системы, содержащие интеллектуальную собственность, в отношении которой вы не хотите рисковать утечкой данных, а также требования безопасности, которые не подпадают под ваш прямой контроль и управление, размещение этих активов во внутреннем центре обработки данных имеет наибольший смысл.

4. Быстрота и гибкость

Ценность гибридного подхода в том, что он дает организациям быстроту и гибкость. У вас есть возможность использовать внутренние и внешние системы, в зависимости от потребностей бизнеса.

Приняв гибридную стратегию, компании также могут воспользоваться лучшими стратегическими, операционными и экономическими вариантами.

В некоторых случаях «лучшим выбором» может быть передача в облако. В других случаях предпочтительнее использовать собственный дата-центр.

Вот пример: крупная компания с хорошо настроенной системой ERP от известного поставщика приобретает небольшую компанию. С эксплуатационной точки зрения идея состоит в том, чтобы переместить недавно приобретенную меньшую компанию во внутреннюю корпоративную ERP-систему, но существует так много настраиваемых программ и интерфейсов, что вместо этого покупатель решает перевести новую компанию на облачную версию системы.

В дальнейшем материнская компания может либо перенести новую компанию в корпоративную систему ERP и иметь возможность выполнить эту миграцию без спешки, либо принять решение присоединиться к недавно приобретенной компании путем переноса корпоративной ERP в облако.

5. Тестирование и отказоустойчивость

Многие компании предпочитают сохранять внутреннее присутствие для своих критически важных систем в то же время, когда они реплицируют эти системы в облако.

Одна из причин для репликации систем в облако — предоставить легкодоступную «песочницу», которую разработчики приложений могут самостоятельно использовать для тестирования. Гибкость аварийного переключения — еще одна причина, по которой компании используют как облачные, так и локальные версии своих критически важных систем. Используя эти системы в тандеме, предприятия могут переключаться на локальные системы в случае сбоя облака или переключаться на облако в случае сбоя локальных систем.

6. Конкурентные преимущества ИТ

У компаний, оказывающих финансовые услуги, занимающихся биологическими исследованиями, страхованием, гостиничным бизнесом, производством, технологиями и здравоохранением есть веские причины держать свою интеллектуальную собственность, код алгоритмов и данные под непосредственным управлением в своих центрах обработки данных. Несмотря на то, что многие облачные сервисы имеют надежную защиту, ИТ-отделы не всегда доверяют им.

И хотя есть случаи взлома как корпоративных систем, так и облаков, ИТ-директора и генеральные директора чувствуют себя лучше, если они напрямую контролируют проприетарное программное обеспечение и данные, дающие их компаниям уникальные конкурентные преимущества на рынке.

Гибкость и оплата использования облачных вычислений «pay-per-use» пошли на пользу компаниям, поскольку устраняют необходимость в дорогостоящих капитальных затратах в центрах обработки данных и во многих случаях (в частности, для малых и средних предприятий) за счет уменьшения потребности в ИТ-персонале для управления корпоративными системами.

Тем не менее, несмотря на переход в облако, важность оставления некоторых из наиболее важных систем и инфраструктуры в собственных ЦОДах сохраняется.

Какой ЦОД лучше всего подойдет Вашей модели бизнеса?

Какой ЦОД лучше всего подойдет Вашей модели бизнеса?

Нет никаких сомнений: дата-центрам необходимы перемены также, как и бизнесу. Компания может самостоятельно управлять своими ресурсами, оставшись в пределах собственного здания или мигрируя все приложения в облако, другие могут выбрать аренду площади в коммерческом ЦОДе. Также существует решение, которое удовлетворит всех и предоставит уникальный вариант развития компании. Итак, как же руководство компании выбирает, когда и как развивать собственный дата-центр? Приведем плюсы и минусы каждого из решений.

Собственный дата-центр

В этом случае компания самостоятельно управляет своими данными в пределах своей же территории. Собственный ЦОД может улучшить эффективность в зависимости от тех или иных потребностей бизнеса. Однако, естественно, он требует определенного технического обслуживания. Без четкого понимания или прогнозов, что произойдет в ближайшем будущем, становится сложнее масштабировать эти инвестиции в ту или иную сторону: стоит не угадать, и стоимость этого выбора может оказаться выше, чем любого другого решения.

Вся эта активность вокруг хранения данных в облаке заставляет думать, будто использование собственных серверов – это прошлый век, но есть ряд причин, почему компании все же останавливаются на этом выборе. Например, у некоторых компаний есть требования к статической прочности, обусловленные необходимостью постоянно обрабатывать значительные объемы данных и требующие постоянных инвестиций в инфраструктуру ЦОДа. С течением времени понадобится модернизировать этот дата-центр, однако для осуществления подобного на арендованных площадях или в облаке потребуются немалые затраты, которые будут потрачены только в самом необходимом случае.

Страховые компании и банки, например, используют одни и те же приложения в течение всего периода своей эксплуатации — они являются частью ключевой компетенции организации и ее стратегическим преимуществом. Компании нефтегазового сектора работают с большими объемами данных и перемещение такого массива информации в другие локации, например, в облако может значительно увеличить расходы.

Помимо этого, многие рабочие нагрузки не были разработаны или предназначены для облака или не могут быть виртуализированы, например приложения, написанные на языке COBOL для мейнфреймов. Изменение таких приложений и тиражирование программного обеспечения в другие среды – мероприятие дорогостоящее. В некотором смысле, конечно, подобные устаревшие приложения в конечном итоге будут переписаны под виртуализированные или облачные среды, когда потребность в этом оправдает расходы и риски.

Облачные вычисления

С точки зрения корпоративного развития, конечно, намечается тенденция использования исключительно облачных вычислений через какое-то время. Когда та или иная организация переносит свою рабочую нагрузку в облако, это в значительной степени отличается от переноса данных на обычные виртуальные машины (VMs). Корпоративные дата-центры поддерживают большое количество приложений, которые могут быть перемещены в сотни и тысячи виртуальных машин. Трудно управлять такой виртуальной средой и одновременно обеспечивать высокий уровень безопасности и доступности. Внедрение автоматизации и инструментов управления значительно повышает эффективность работы и может буквально «превратить» несколько виртуальных машин в частное облачное хранилище. На сегодняшний момент ресурсы стали более гибкими и доступными для любого типа нагрузок, какие только могут понадобиться компании.

Частные и публичные облачные среды отличаются друг друга. Приобретая частное облако, компания вместе с тем получает полный контроль за всей системой. Внутренние операционные затраты могут быть меньше, чем ежемесячная оплата услуг публичного облака в зависимости от набора используемых услуг. Развитие в частном облаке намного проще с точки зрения безопасности и управления, чем перенос данных в публичное облако. По большей части, это обычная практика для многих предприятий.

Публичное облако – это арендуемая среда, которая предлагает практически те же услуги, что и приватное. Помимо этого, эта среда отходит от управления инфраструктурой и может предоставить более высокий уровень безопасности.

Проблемой перехода в публичную облачную среду могут стать собственные регламенты компании. Для некоторых из них может существовать ряд нормативно-правовых препятствий для миграции данных. По этой причине большинство банков, к примеру, зачастую размещают частные облачные хранилища в собственных объектах.

Другим недостатком публичных облаков является отсутствие стандартизации общедоступных облачных платформ. Каждый поставщик облачных услуг делает это по-своему и перейти от одного провайдера к другому может оказаться не таким простым делом. Размещение программного обеспечения в другой облачной среде может быть не только дорого, но и попросту хлопотно, особенно если компания размещает в облаке большие массивы данных.

Облако также заставляет руководителей отказаться от определенной дозы контроля, например, SLA. Если в облаке что-то пойдет не так, руководство должно быть в курсе планов по резервному копированию данных и их восстановлению. Как только компания подписывается под использованием публичного облака, необходимо иметь в виду, что пути назад уже может и не быть. Хватит ли у вас ресурсов на самостоятельное управление вычислительной средой? Если даже и удалось восстановить данные, на каком оборудовании будут работать ваши резервные приложения?

И все же, если Ваша компания не использует какие-либо дифференцированные платформы, есть шанс, что облачные приложения будут для Вас лучшим выходом, хотя бы с точки зрения доступа клиентов. Однако немногие крупные компании, которые потратили миллионы на разработку собственных закрытых приложений, обратятся к облачным вычислениям.

Коммерческий ЦОД

Эти дата-центры предлагают возможность платить за инфраструктуру как утилиту (infrastructure as a utility) вместо использования ее на собственном объекте. Даже комплексное планирование ресурсов предприятия (enterprise resource planning, ERP) с вложенными миллионами долларов могут не оправдать необходимость строительства и владения собственным дата-центром. В этом случае будет иметь смысл перенести серверы на другой объект и выкупить у коммерческого ЦОДа площадь, электричество, охлаждение и подключение к сети. И, поскольку многие облачные и контент провайдеры размещаются в тех же коммерческих дата-центрах, у компании будет возможность иметь с ними связь напрямую. Это может значительно уменьшить задержки и механизм взаимодействия с пользователем, а также упростить их планирование при наличии публичных и частных облачных сред, а также подключения к хост-провайдеру под одной крышей.

Выбор модели

В конечном счете большинство компаний используют не одну и даже не две модели дата-центров. Например, компания может использовать частное облако для обеспечения самостоятельного доступа к вычислительным ресурсам и в то же время использовать собственные бизнес-критические приложения на мощностях своего или коммерческого дата-центра.

В итоге у разных компаний разные потребности, и они используют разные модели ЦОД, чтобы удовлетворить их. На сегодняшний день мы имеем несколько альтернатив, которые позволяют выстроить свою инвестиционную стратегию и план миграции приложений для реализаций различных сочетаний программно-аппаратных подходов. Облако становится все популярным, коммерческие ЦОДы становятся более мощными, а общество проявляет все больше доверия к аутсорсингу. Хитрость заключается в том, чтобы выбранная модель наилучшим образом соответствовала поставленной задаче.

Превратите свой дом в дата-центр. В настоящее время стало довольно распространенным явлением… | by Beyondtech

8 минут чтения

·

30 января 2017 г.

В настоящее время стало довольно распространенным использовать определенные части домов в небольших центрах обработки данных.

Комнаты, гаражи и подвалы перестраиваются для использования в качестве мини-центров обработки данных, чтобы они находились рядом с их оборудованием и продолжали работать, как в обычных офисах и центрах обработки данных.

Увлеченные ИТ и энтузиасты технологий используют свои навыки и знания, чтобы использовать это оборудование и строить центры обработки данных в домах.

Наличие центра обработки данных у вас дома похоже на расширение центрального.

В начале только крупные компании или отрасли имели центры обработки данных, но времена изменились, и количество малых предприятий и домов, создающих небольшие центры обработки данных, значительно увеличилось.

Центр обработки данных — это мозг компании, и из-за важности этой области каждый аспект процесса строительства важен для получения успешного результата.

Иметь собственный центр обработки данных может быть отличной идеей, если вы относитесь к тому типу людей, которые не хотят тратить время на пробки или каждый день ездить на работу и домой туда и обратно.

Хотя выполнение этого проекта может быть непростым, вы действительно можете стать трудоголиком.

Для этого ваш дом должен соответствовать некоторым требованиям.

Повышение мощности: Вам понадобится надежный и чистый источник электроэнергии. Кроме того, вам нужны батареи, они должны будут поддерживать всю инфраструктуру в течение как минимум 150% времени, необходимого для подключения вашего генератора к сети, чтобы, если возникнут какие-либо проблемы с генераторами, у вас было время для их решения.

Лучшая сеть: Вам нужна более высокая пропускная способность, по крайней мере, более 9 МБ и более качественные сетевые кабели. Вам потребуется настроить IDS и IPS для обнаружения и предотвращения атак, когда это возможно, а также для смягчения последствий DDoS.

Серверы, оборудование, стойки: Основное назначение центра обработки данных — размещение серверов, необходимых для поддержки услуг поставщиков, а также клиентских веб-сайтов и приложений. Серверы размещаются в стойках, которые могут быть размещены в определенной конфигурации внутри центра обработки данных в целях изоляции или для оптимизации охлаждения.

Охлаждение: Вы должны иметь возможность поддерживать температуру в центре обработки данных на уровне 70 градусов по Фаренгейту, независимо от того, 30 градусов на улице или 107. Если вы используете стандартный портативный блок переменного тока, это нормально, но если вы используете построенный в коммерческом стиле, что даже лучше.

Независимо от того, что вы делаете, вам нужно убедиться, что ваше охлаждение связано с вашими батареями и генератором. Вам также необходимо убедиться, что у вас есть вторичное решение для охлаждения на случай, если оно выйдет из строя. Кроме того, вам нужно будет следить за температурой, и рекомендуется иметь не менее 3 датчиков температуры в каждой стойке.

Кроме того, вам нужно будет следить за температурой, и рекомендуется иметь по крайней мере 3 датчика температуры в каждой стойке.

Безопасность: Убедитесь, что никто, кроме уполномоченных лиц, не имеет доступа к вашему центру обработки данных. Брелоки — дешевый вариант для этой установки. Следует вести журнал времени доступа (как входящего, так и исходящего).

Вам понадобится средство пожаротушения: Ваша страховка может не покрывать все несчастные случаи, происходящие в вашем центре обработки данных. Мы рекомендуем вам быть осторожными и держать свое пожарное оборудование под рукой.

Резервная копия: Вам понадобятся резервные копии всех ваших конфигураций и всех ваших вещей, и, конечно же, вам нужно время от времени проверять эти резервные копии.

Все эти компоненты и требования — физические, виртуальные и концептуальные — работают вместе, чтобы поддерживать и достигать всех услуг и функций центра обработки данных.

Таким образом,

серверы и связанное с ними вычислительное оборудование обеспечиваются питанием и связью, обеспечивается охлаждение для предотвращения перегрева, что является очень важным делом, а резервные утилиты используются для обеспечения практически постоянной безотказной работы.

Кроме того, для защиты и надзора предусмотрены меры контроля и безопасности, а действия сотрудников регулируются специальными политиками и процедурами, гарантирующими надежность и эффективность.

Когда все эти части работают должным образом, центр обработки данных может эффективно поддерживать ряд действий и услуг и обеспечивать место для хранения важных данных.

Это, в свою очередь, позволяет центрам обработки данных обеспечивать необходимую надежность и время безотказной работы, что позволяет пользователям использовать приложения и устройства, на которые они привыкли полагаться.

Вот несколько примеров и идей для реализации этого проекта в домах:

Вы когда-нибудь задумывались об использовании элегантного и красивого стола Ikea для размещения вашего оборудования вместо стандартной стойки в центре обработки данных?

В одном из самых известных домашних центров обработки данных они адаптировали приставной стол LACK шведской мебельной сети для размещения серверов и коммутаторов, создав LACKRack.

В конце они обнаруживают, что расстояние между ножками стола составляет 19 дюймов, что равно ширине стандартного слота в стойке центра обработки данных.

Пространство для сервера создано с помощью шурупов для крепления стоек к ножкам стола. Столы являются штабелируемыми и модульными, поэтому их можно собирать в различных конфигурациях.

В 2010 году, когда Lack Rack впервые был показан, это поощрило новые разработки и инновации.

Фрэнк Денин, технологический евангелист PernixData, вдохновленный Lack Rack, адаптировал первоначальную спецификацию дизайна и создал портативную 19-дюймовую стойку.

«Мой домашний офис предназначен для использования в качестве офиса, а не центра обработки данных, — пишет Деннеман. «Итак, куда вы поместите 19стоечные серверы, не нарушая эстетику вашего домашнего офиса в минималистичном дизайне?

Ну, вы создаете 19-дюймовую стойку на колесах, чтобы вы могли катить ее с глаз долой и размещать там, где хотите». Говорит Фрэнк о своем изобретении.

(Исходный текст: datacenterknowledge.com)

Канадский ИТ-специалист по имени Ален Будро имеет в своем домашнем центре обработки данных высококачественное корпоративное оборудование таких компаний, как HP, Dell, Sun, IBM и Jupiter. который находится в подвале.

Его веб-сайт может показать подробный обзор его сети, включая схему всех компонентов. Это включает в себя облако Open Stack MAAS (Metal as a Service) и несколько систем хранения (iSCSI и Fibre Channel).

«Мой первый шаг состоял в том, чтобы установить электрическую коробку, чтобы обеспечить мощность 240 вольт при 40 ампер, которая при необходимости будет обеспечивать максимум 9,6 кВт/ч, — пишет Будро, который преподает разработку приложений и использует оборудование для тестирования.

«Сервера редко бывают открыты все сразу, поэтому среднее потребление 1-2 кВт/час.» По его словам, электричество в Квебеке стоит около 7 центов за кВт/час.

Тем не менее, Будро пишет, что этот тип домашнего центра обработки данных «не для слабонервных».

(Исходный текст: datacenterknowledge.com)

Youtube — мощный канал, на нем вы можете найти множество людей, которые объясняют и показывают, как они строили свои собственные центры обработки данных в домах. Некоторые из самых популярных видео набрали более 50 000 просмотров на YouTube. Это видео датируется самым ранним 2012 годом.

Этот проект стал известен, и большинство из этих видеороликов являются основным источником вдохновения для других, чтобы построить свои собственные бизнес-центры обработки данных. Эти видеоролики могут подробно показать вам, что вам нужно или какие компоненты необходимы для функционирования вашего центра обработки данных.

Вот пример удачного видео на Youtube, показывающего, как дата-центры были построены в доме.

Стеллажи с ИТ-оборудованием в вашем доме иногда привлекают внимание. В 2012 году ИТ-специалист, известный в Интернете как Хоук Рончи, опубликовал на YouTube видео своей домашней стойки, которое было просмотрено более 220 000 раз.

Установка «на самом деле не центр обработки данных, но не во многих домах есть полноразмерная стойка с объемом более 150 ТБ», — написал он. «Стойка прикручена к деревянному полу к цементному фундаменту, на котором стоит дом». Полностью укомплектованная стойка потребляет всего около 1 кВт мощности, но пропускная способность — это другое дело.

В 2013 году Хоук Рончи сказал Ars Technica, что с ним связалась компания Verizon, которая была удивлена, увидев, что учетная запись резидента использует более 50 терабайт трафика в месяц. Выяснилось, что размещение медиасервера большого объема нарушило условия обслуживания жилой линии FiOS, и ему пришлось перейти на бизнес-план.

Будущее за облаками. Наличие файлов в Интернете дает массу преимуществ, это означает, что вы можете получить доступ к своим документам с любого ПК, смартфона или планшета.

То, о чем вы должны действительно беспокоиться в облаке, — это безопасность, вы должны убедиться, что никто, кроме уполномоченных лиц, не имеет доступа к вашей информации и документам.

Вот небольшое руководство по созданию собственного серверного облака для центров обработки данных.

1. Войдите в облачную панель управления и щелкните Серверы > Облачные серверы на верхней панели навигации.
2. Щелкните Создать сервер.
3. В разделе «Сведения» введите имя вашего сервера в поле «Имя сервера».
4. В списке Регион выберите регион, в котором вы хотите создать сервер.
5. Дополнительные сведения о регионах и их эффективном использовании см. в разделе О регионах.
6. В разделе Образ выберите, какую операционную систему вы хотите использовать.
7. Полный список доступных образов см. в разделе «Изображения» на странице продукта «Облачные серверы».
8. В разделе Flavor выберите подходящую конфигурацию для сервера.
9. Дополнительные сведения о вариантах см. в Руководстве пользователя Cloud Core Infrastructure.
10. (необязательно) Назначьте серверу открытый ключ, выбрав существующий ключ в разделе «Дополнительные параметры».
11. Чтобы добавить новый открытый ключ, нажмите «Управление ключами SSH» и выполните следующие действия:

• На странице «Ключи SSH» нажмите «Добавить открытый ключ».
• Если вы добавляете открытый ключ, дайте ему имя. .
• В поле Регион подтвердите или выберите регион, в котором будет использоваться ваш ключ.
• Вставьте свой открытый ключ в поле Открытый ключ.

Первое, что вам нужно сделать для реализации этого проекта, это организоваться. Вы можете начать с составления списка вещей, которые вам понадобятся, принимая во внимание потребности вашей компании или бизнеса.

Создание центра обработки данных может занять некоторое время и усилия, но оно того стоит.

5 шагов к созданию собственного центра обработки данных

08 мая 2023 г.

Если последние два года о чем-то и свидетельствуют, так это о том, что данные никогда не спят. Прямо с 2020 года мы наблюдаем всплеск возможностей подключения, распределения пользователей и более пристальное внимание к системам, которые продолжают работать круглосуточно: центрам обработки данных.

Единственная четкая статистика, которую вы можете извлечь из всего этого, заключается в том, что объем рынка колокационных центров обработки данных в Индии, как ожидается, вырастет в среднем на 21% с 375 МВт во втором полугодии 2020 г. до 1078 МВт к 2025 г.

Также важно понимать, что Облако никуда не денется. Теперь единственной переменной в экосистеме данных является то, как предприятия подходят к облачным вычислениям в масштабе. В соответствии с этим наблюдается огромная экономия при переходе на модели OPEX на основе подписки по сравнению с авансовыми инвестициями CAPEX.

Начнем с того, что переход от периферии к облаку, от автоматизации к механизации, от целостности данных к безопасности — руководителям центров обработки данных есть над чем подумать. Собрав все в одну корзину, в этой статье рассказывается, как развивающиеся организации могут начать с создания собственных центров обработки данных.

Фаза первая: оценка

Самый первый вопрос, на который необходимо ответить до того, как начнется весь процесс, — будет ли ЦОД построен в соответствии с требованиями или по спецификации. Видите ли, в отличие от центра обработки данных Colocation, где можно управлять динамическими требованиями, построенный в частном порядке центр обработки данных необходимо привести в соответствие с долгосрочными бизнес-планами компании. Только после того, как разработчик окончательно определился с целевым клиентом и целями проекта, можно начинать такие действия, как выбор площадки. Кроме того, во многих случаях застройщики центров обработки данных склонны следовать стандартному проекту, который может оказаться невыгодным в долгосрочной перспективе. Следовательно, при выборе места для центра обработки данных необходимо учитывать следующие факторы:

  • Доступная земля и соответствующее зонирование
  • Анализ почвы
  • Существующие здания на территории и вокруг нее
  • Топография
  • Электроснабжение
  • Водоснабжение
  • Оптоволоконная связь
  • Персонал и доступность 901 79   • Профиль стихийного бедствия

Этап Два: Планирование

Фаза планирования может выполняться одновременно с процессами проектирования и выбора площадки. В некоторых сценариях он даже заменяет первый шаг, чтобы обеспечить своевременное развертывание и реализацию стратегии. Поскольку центр обработки данных создается с нуля, разработчик выделяет несколько параметров, касающихся эффективности использования энергии (PUE), резервирования N или N+1, предполагаемых вариантов использования, возобновляемых источников энергии, безопасности, укомплектования персоналом и разрешений, которые необходимо учитывать комплексно. В течение этого времени также устраняются такие узкие места, как одновременное распределение фаз.

Ниже приведены некоторые распространенные ошибки, допущенные на этапе планирования центра обработки данных:

  • Акцент только на капитальных затратах, а не на общей стоимости владения (TCO)
  • Плохая оценка затрат на строительство надежность
  • Непонимание влияния выбора конструкции на затраты и время

Третий этап: проектирование

На этом этапе необходимо ответить на вопросы, касающиеся жизнеспособности центра обработки данных, такие как сертификация устойчивости, целевая плотность стоек, количество этажей и т. д. . Как обсуждалось ранее, некоторые элементы дизайна будут в значительной степени заимствованы из последних двух этапов. Следовательно, важно установить широкие и стандартные критерии для оптимизации процесса проектирования.

В зависимости от того, выбираете ли вы «проектирование-сборка» или комплексное обслуживание, работа должна выполняться либо внутри компании, либо поручить ее специализированным поставщикам услуг. В любом случае, сложности по сравнению с колокейшн-центрами данных будут расти как на дрожжах. Чтобы собрать все это воедино, электрические, механические и архитектурные команды должны слаженно сотрудничать, продвигаясь к следующему этапу.

Этап четвертый: строительство и ввод в эксплуатацию

Здесь вы начинаете строительство Центра обработки данных. Партнеры и подрядчики работают в синергии для выполнения завершенных проектов, что обеспечивает оправданные сроки капитальных вложений.

Загвоздка здесь в том, что в то время как простая конструкция Power-Shell может занять от 3 до 4 месяцев, гораздо более сложный гипермасштабируемый ЦОД может строиться до 2 лет. Учитывая немедленный спрос на облачные вычисления и услуги On-Ramp, это становится стресс-тестом для поддержания целостности организационных данных без зависимости от объекта Colocation.

Этап пятый: Эксплуатация

На самом деле только этап разработки завершается строительством и вводом в эксплуатацию. Операции начинаются только после того, как вы займете пространство и развернете свои ресурсы через облако. На данный момент разработчик центра обработки данных работает над сбором данных в режиме реального времени об использовании и производительности серверов. Результаты дают представление о том, хорошо ли системы работают друг с другом или нет. Если есть какие-либо несоответствия, то их необходимо преобразовать в действенные программы, которые чаще всего означают повторение определенных этапов и добавление к общему времени и инвестициям.

Лучшая альтернатива созданию собственного центра обработки данных?

То, что было сказано выше, — это всего лишь схема того, как должна выглядеть конструкция вашего дата-центра. То, как вы выполняете плейбук в соответствии с вашими требованиями, полностью зависит от ваших организационных целей и перехода от этапа к этапу.

С точки зрения долговечности основными причинами, по которым многие предприятия выбирают собственный центр обработки данных, являются безопасность и контроль. Хотя оба эти аспекта оказывают огромное влияние на функциональность услуги, их также можно легко достичь, передав вашу загрузку данных на аутсорсинг установленному центру обработки данных Colocation. Это существенно экономит тысячи часов работы и более высокие капитальные затраты, связанные с прохождением пяти этапов, и обеспечивает масштабируемость по требованию, которую может предложить только поставщик колокационных центров обработки данных.

Являясь ведущим поставщиком колокационных центров обработки данных уровня III в Индии, Web Werks предлагает целостную экосистему взаимосвязи местных, национальных и глобальных интернет-провайдеров с услугами Cloud On-Ramp, сетями доставки контента (CDN) и интернет-биржами (IE). Мы также расширяем возможности подключения к некоторым из крупнейших в стране пиринговых бирж, таких как DE-CIX, Extreme IX и NIXI, которые помогают запускать ресурсоемкие приложения без каких-либо узких мест.

Кроме того, основные поставщики гипермасштабируемых облачных услуг (CSP), такие как Azure, AWS и Google, входят в сферу действия наших облачных услуг для частного, общедоступного, сертифицированного SAP и гибридного развертывания в нескольких облаках. Это в сочетании с 3 современными центрами обработки данных TIER III, расположенными в Мумбаи, Пуне и Дели-NCR, 902:24, и в Бангалоре, Хайдарабаде и Ченнаи появятся новые. Кроме того, организации получают беспрепятственную локализацию в разных странах благодаря неограниченному доступу к более чем 15 передовым центрам обработки данных, расположенным в США, Европе и Азиатско-Тихоокеанском регионе, в партнерстве с нашим партнером по совместному предприятию Iron Mountain Data Centers.

Чтобы узнать, как Web Werks может помочь вам добиться превосходной эффективности центра обработки данных за небольшую часть стоимости строительства собственного центра обработки данных, посетите https://www.