Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 2904 сообщений
Cообщения с меткой

инфраструктура - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[Из песочницы] Действия при приходе на работу — прием дел, актуализация, документирование, аудит

Суббота, 22 Июля 2017 г. 15:06 (ссылка)

С интересом прочел Аудит ИТ-инфраструктуры — как быть новичку, но мне показалось, что список дел при аудите и приеме на работу (особенно, если оттуда уже давно уволились все, кто что-то помнил) гораздо шире.



Если у вас в организации процессы не построены — то этот текст для вас бесполезен. Если построены — то тоже бесполезен. Почти Rifleman's Creed — Without me, my rifle is useless. Without my rifle, I am useless.



Каких-то стандартных пакетов управления всей архитектурой и техникой я не видел — что не удивительно, учитывая постоянное расхождение отчетности по бухгалтерии и техники по факту и общую сложность систем. Хорошо если ведется схема сети, учет паролей и прочее необходимое, есть какой-то учет что когда (сертификаты, оплата домена) истекает, но порой этого нет. Просто одни забыли спросить, другие не волновались насчет этого. У третьих оно было, но они уже уволились, а четвертые забили, вот и имеем что имеем.

Управление жизненным циклом, SCOM/SCSM — это немного другое, а ITIL

Service Asset and Configuration Management — это благие пожелания, не содержащие некий функционал.



Соответственно, первым делом при приходе на работу нужен аудит «для себя»



— Какие устройства где стоят, за что отвечают, есть ли к ним доступ (к web панели управления/ssh/ilo), если нет — то как его восстановить. Живы ли эти устройства, или стоят для учета.



— Кто ответственный за СКУД, общую безопасность, электричество, кондиционирование (обслуживание), водопроводы, пожарную сигнализацию. Когда последний раз проводилось обслуживание тех же кондиционеров. Какова надежность (запас мощности) кондиционеров (N+0, N+1).



— ИБП и батареи. Сколько держат (в часах), когда менялись батареи, когда была калибровка, есть ли извещение о срабатывании и прочем блекауте. Какова надежность (запас мощности) ИБП — (N+0, N+1).



— Как выстроено взаимодействие с соседними отделами и бизнесом как заказчиком сервисов.



— Как работает сервис деск.



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



— Как работает извещение о сбоях, особенно крупных — например, общий блекаут/отключение электричества, протечка водопровода / отопления.



Архивация и восстановление

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

От имени какой УЗ идет архивация (особенно в случае агентов/сервиса бекапа в машинах), не многовато ли у нее прав (в каких группах состоит), есть ли у нее (и от нее) пароль и не стоит ли его сменить. Где она (в системе резервного копирования) прописана.

Есть ли регламент, в котором прописано и утверждено все вышеперечисленное.



Контроль прав, контроль служебных УЗ (учетных записей)

Кроме простой проверки «кто в группе доменных администраторов и почему», необходим контроль служебных УЗ. В том числе контроль какой сервис от какого имени стартует (если не стартует от системы), что со встроенными УЗ, что в какую группу включено и зачем, какие им (группам) делегированы права и куда.



AD

Роли AD — где (на каких серверах) лежат, что в журналах. Кто за какие сетевые сервисы (DHCP, DNS) отвечает. Аудит — есть ли, как устроен. Пересылка логов — каких, куда, и что там с ними происходит.



Готовьтесь изучать новый для вас предмет — инженерная археология / Конструкторско-технологическая археология (1)



Типовые дыры и костыли кривокурих админов локалхоста. Начиная от правленных host

ВНЕЗАПНО для меня выяснилось, что админы локалхоста не только правят файлы etc/host (ну ладно, кто не правил в детстве?), но еще этим и гордятся, и пишут об этом статьи.



Впрочем, с настройками DNS на DC бывает тот же стыд.

Не, ну как можно не прочитать технет?? (2)



ЗАПОМНИТЕ, ГРАЖДАНЕ!

Писать в \host\etc в продакшене надо тогда и только тогда, когда ты уже прочитал инструкцию, для Оракла и Veritas netbackup, дожав инструкциями по Veeam.



Вторая очередь проверки

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



— Задачи в Tash scheduler и автозагрузке по серверам

— файлы HOST в частности и настройки DHCP и DNS в целом

— кому, как, куда и какие даны права в AD и Exchange.



Если с первым пунктом понятно, скачиваем Sysinternals Autoruns for Windows и поехали, то с вторым и третьим пунктом все сложней.



Внезапно для многих, в Microsoft Windows server нет кнопки «сделать хорошо». Даже скрипта makegood.ps1 нет — MS WS и AD как сервис не имеет каких-то встроенных готовых графических решений для отображения кому и куда делегированы права в AD, а использование powershell огорчает инфобезопасника и любителя GUI.

С другой стороны, необходимый инструментарий для этого есть —



Для просмотра делегирования прав по organizational unit (OU) — Active Directory OU Permissions Report:

This script generates a report of all Active Directory OU permissions in the domain. I would advise all Active Directory shops to review this report on a quarterly basis to make sure there are no surprise administrators lurking in your domain.

Лежит традиционно на технете.



Для просмотра раздачи прав Exchanhe вот — на том же технете

RBAC Role Group Membership Reporting

This PowerShell script will generate a report of the Role Based Access Control (RBAC) role groups in an Exchange Server organization.



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



Ссылки:

(1)

Индустриальная археология «Мценского уезда». Часть 1.

Индустриальная археология «Мценского уезда». Часть 2.



Корпоративная память и обратная контрабанда.

Копия этой же статьи со ссылками.

Оригинал в web.archive

Конструкторско-технологическая археология



(2)

Ссылка 1

Ссылка 2

или

Ссылка 3



и наконец собственно:



DNS: DNS servers on should include the loopback address, but not as the first entry

Impact

If the loopback IP address is the first entry in the list of DNS servers, Active Directory might be unable to find its replication partners. См. по ссылке



Вообще с доступностью первого DNS для CSV есть много интересного, но о этом может быть будет позже.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333910/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Обзор-рейтинг провайдеров виртуальных серверов Windows: 2017

Пятница, 21 Июля 2017 г. 14:12 (ссылка)





В марте 2017 года возникла необходимость в обновлении серверного оборудования под MS SQL Server и терминальный сервер, необходимых для работы приложения по учёту продаж. Стоимость нового сервера и системы хранения превышало 700 т.р., что не укладывалось в наши бюджеты, поэтому решили рассмотреть виртуальные серверы для размещения наших приложений.



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

Можем выделить следующие преимущества:




  1. Реализация отказоустойчивости на уровне гипервизора;


  2. Преимущественно отказоустойчивое хранение данных;


  3. Низкая стоимость резервного копирования и простая реализация для нас;


  4. Расширение ресурсов в соответствии с нашими потребностями (Pay as you grow);


  5. Наличие SLA.




Программа и методика испытаний



Программа и методика испытаний, которая была заранее определена для тестирования провайдеров.

Объекты тестирования:




  1. Вычислительная подсистема;


  2. Дисковая подсистема;


  3. Подключение к сети Интернет.




Для тестирования подсистем использовалось следующее ПО:




  • Вычислительная подсистема: Linpack


  • Дисковая подсистема: CrystalDiskMark, HD Tune Pro


  • Пропускная способность: beta.speedtest.net




Настройки ПО:















































































Вычислительная подсистема: Linpack

Объём задачи

10000

Объём памяти

772 МБ

Время испытания

5 часов

Режим

64-bit

Число потоков

Равняется количеству ядер

Данные

4 КБ

Дисковая подсистема: CrystalDiskMark

Размер файла

1 ГБ

Количество проверок

5

Дисковая подсистема

HD Tune Pro
Benchmark

Чтение

File Benchmark

Размер файла 500 МБ

Шаблон: заполнение нулями

Пропускная способность доступа в сеть Интернет

Москва

Билайн

Краснодар

РТ (Ростелеком)

Екатеринбург

РТ

Иркутск

РТ

Владивосток

РТ

Франкфурт

Leaseweb



Перечень городов обусловлен наличием в них наших филиалов. Для проведения испытаний использовалось подключение к сети Инернет в конкретном филиале. Измерение скорости проводилось с использованием beta.speedtest.net. Франкфурт взяли для понимания скорости загрузки в ownCloud, который размещается в Leaseweb.



Критерии оценивания



Использовали следующие критерии для оценивания провайдеров.

























































































































































































Наименование

Баллы

Описание

Дата-центр

0.6



Информация о ДЦ

0.2

Информация о том, где размещается оборудование

Информация об инженерных подсистемах

0.2

Данные об уровне инженерных подсистемах ДЦ

Сертификация TIER

0.2

Есть ли подтверждение о сертификации TIER по uptime institute / IBM и подобных организаций

Информация об оборудовании

0.3



Серверное оборудование

0.1

Какое оборудование используется и какие вычислители задействованы в кластере

Система хранения данных

0.1

Используются ли СХД или SDS решения

Сетевое оборудование

0.1

Используемое сетевое оборудование

Информация о юр.лице

0.3



Контактные данные

0.1

Контактные данные технической поддержки и наличие номера телефона для обращений в поддержку

Адрес юр.лица

0.1

Контактные данные и адрес юридического лица, которое предоставляет хостинг услуги

Реквизиты компании

0.1

Реквизиты юридического лица

Информация о платформе виртуализации

0.1



Договор оферты

0.2



Договор оферты

0.1

Доступ к договору оферты без прохождения регистрации

SLA

0.3

Доступ к SLA без прохождения регистрации

Тестирование сервиса

Вычислительная подсистема

0.4



Соответствие заявленной частоты и выделенной частоты процессора

0.2

Соответствие выделенной частоты и процессора согласно описанию тарифа

Стабильность вычислительной подсистемы

0.2

Стабильность вычислительной подсистемы без заметных провисов в производительности

Недокументированное ограничение вычислительной подсистемы

-0.3

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

Дисковая подсистема

0.8



Стабильность дисковой подсистемы

0.2

Стабильность дисковой подсистемы с низкой задержкой и без заметных провисов в производительности

Высокоскоростная дисковая подсистема

0.2

Высокая скорость дисковой подсистемы на уровне SSD (Seq.R 400 / Seq.W 300), HDD (Seq.R 100 / Seq.W 100)

Высокая доступность данных

0.2

В случае падения сервера данные будут доступны

Отказоустойчивость дискового хранения

0.2

Сетевое соединение

0.5



Стабильность сетевого соединения

0.2

Стабильное сетевое подключение без обрывов и зависаний

Низкие задержки по России

0.1

Субъективный параметр основываясь на текущих наших средних показателях PRTG

Высокая скорость доступа по России (более 20 мбит/с)

0.2



Дополнительные услуги

1



Базовая техническая поддержка

0.2

Наличие бесплатной базовой технической поддержки (не включая конфигурирование сервисов)

Расширенная техническая поддержка

0.2

Наличие расширенной технической поддержки (включая конфигурирование сервисов)

Бесплатная лицензия Windows Server

0.2

Бесплатное предоставление Windows Server по программе SPLA

Лицензия ПО 0.1 Возможен заказ дополнительных лицензий
Гибкое расширение ресурсов 0.3 Создание произвольной конфигурации виртуального сервера с возможностью расширения ресурсов


Список провайдеров



Был определён список провайдеров, согласно следующим критериям:




  • размещение в России;


  • лицензия Windows Server включена в стоимость;


  • бесплатное тестирование сервиса перед покупкой;


  • возможность увеличения ресурсов виртуального сервера;


  • гипервизор Hyper-V или VMware.




Согласно нашим критериям были определены следующие провайдеры:




  • ultravds.com / ruvds.com / bigd.host

  • incloud.ru

  • cloudlite.ru

  • parking.ru

  • 1cloud.ru

  • neoserver.ru

  • adman.com

  • infobox.ru

  • eserver.ru

  • mclouds.ru

  • ihc.ru

  • cloud-pro.ru

  • rackstore.ru

  • docker.ru



Провайдеры, которые были отклонены из-за отсутствия бесплатного тестирования:




  • ultravds.com / ruvds.com / bigd.host

  • adman.com

  • parking.ru

  • docker.ru

  • cloud-pro.ru — ответа не получили



Особые условия тестирования:




  • eserver.ru — активация после предоставления скана документа, подтверждающего личность

  • neoserver.ru — активация через менеджера и по будням

  • rackstore.ru — активация через менеджера



Для экономии вашего времени можете воспользоваться следующими ссылками:



Перейти к сводной таблице с критериями оценки.

Перейти к сводной таблице с результатами тестирования.



Тестирование провайдеров



incloud.ru



Хостинг провайдер incloud.ru предоставляет виртуальные машины на платформе виртуализации VMware vSphere.



Провайдер: incloud.ru

Дата-центр: Россия, г. Москва, ДЦ MSTN

Платформа виртуализации: VMware

Триальный период: предоставляется по запросу на 3 дня

Время активации сервера: после создания запроса данные для доступа предоставили через 15 минут



Заявленное оборудование:

Серверное оборудование — HP, Dell, Supermicro

Сетевое оборудование — Cisco, Juniper

Система хранения данных — Dell



Характеристики тестируемого сервера:

vCPU: 2 x 2.4 (Intel Xeon E5645)

RAM: 2GB

Хранение: 50GB SSD



Результаты тестирования incloud.ru



CPU

Согласно показателям LINPACK частота в сторону виртуальных машин ограничивается, информация о частоте при оформлении не указывается.



Частота CPU: 1.597 GHz

Количество CPU: 2

Количество ядер: 2

Число потоков: 2

Среднее значение производительности 18.86 GFlops.

Отклонение от среднего значения: до 6%



График производительности в GFlops








Дисковая подсистема

В качестве системы хранения используются СХД Dell, тестирование производилось на SSD.



Тестирование с помощью CrystalDiskMark



Тестирование производительности с помощью HD Tune Pro
Скорость чтения подскакивает после сохранения данных в кеше, это косвенно подтверждает то, что используется СХД.



Кеш виден издалека.



Работа с данными проходит гладко, сразу видно промышленную СХД, но утилизация ресурсов ограничена на чтение и запись на уровне 100 MB/s. Однако, этого вполне достаточно для комфортной работы.







Пропускная способность доступа в сеть Интернет














































Местоположение

Download (Mbps)

Upload (Mbps)

Ping (ms)

Москва (Beeline)

96.46

90.55

19

Краснодар (Rostelecom)

96.25

78.56

29

Екатеринбург (Rostelecom)

96.36

69.19

47

Иркутск (Rostelecom)

95.55

48.08

82

Владивосток (Rostelecom)

88.31

26.26

133

Франкфурт (Leaseweb)

96.23

75.11

42



Дополнительные возможности:




  • Резервное копирование


  • Лицензии ПО (Microsoft)


  • Защита от DDoS-атак




Доступные образы: Windows Server 2008 R2, 2012 R2 и Linux-based. Доступна установка из своего образа

Стоимость: 1620 рублей в месяц за конфигурацию: 2 vCPU / 2 GB RAM / 40 GB SSD / Windows Server 2012 R2

Стоимость дополнительных ресурсов:




  • 1 vCPU — 200 рублей

  • 1 GB RAM — 200 рублей

  • 10 GB SATA — 50 рублей

  • 10 GB SAS — 100 рублей

  • 10 GB SSD — 150 рублей



Ограничения согласно правилам:

Исполнитель оставляет за собой право ограничить скорость канала до 10-30 Мбит/с или заблокировать сервер в случае генерации большого объёма сетевого трафика на протяжении длительного периода времени, который будет создавать нагрузку на сетевое оборудование более 90%.



Плюсы:




  • стабильная вычислительная и дисковая подсистема;


  • произвольная конфигурация.




Минусы:




  • ограниченные ресурсы вычислительной, дисковой подсистемы и доступа в сеть Интернет;


  • отсутствие онлайн чата для уточнения состава услуг;


  • на сайте представлено мало информации о компании.




ihc.ru



Хостинг-провайдер ihc.ru предоставляет широкий спектр услуг хостинга, начиная от размещения сайтов на shared хостинге до размещения виртуальных машин и аренды выделенных серверов в нескольких московских центрах обработки данных.

Провайдер: ihc.ru

Дата-центр: Россия, г. Москва, ДЦ DataPro и ДЦ IXcellerate

Платформа виртуализации: Microsoft Hyper-V

Триальный период: предоставляется на 3 дня при условии пополнения баланса на сумму от 100 р. (средства остаются на балансе и могут быть использованы в дальнейшем при оплате услуг)

Время активации сервера: 5 минут



Заявленное оборудование:

Серверное оборудование — нет информации

Сетевое оборудование — нет информации

Система хранения данных — локальный RAID5



Характеристики тестируемого сервера:

vCPU: 2 x 2.0 (E5645)

RAM: 4GB

Хранение: 50GB SAS HDD



Результаты тестирования ihc.ru



CPU

Согласно показателям LINPACK частота ЦП в сторону виртуальных машин ограничивается, информация о частоте при оформлении указана на уровне 2 GHz.

Частота CPU: 1.286 GHz

Количество CPU: 1

Количество ядер: 2

Число потоков: 2

Среднее значение производительности 4.79 GFlops.

Отклонение от среднего значения: до 2%



График производительности в GFlops


Низкая производительность вычислительной подсистемы.



Стабильное, но не «быстрое» вычисление без заметных провалов.



Дисковая подсистема

Интересное выделение дискового пространства для виртуальной машины — под ОС выделяется 30GB и дополнительно 50GB согласно тарифному плану.





Как указано в описании тарифа RAID5 SAS HDD.



Тестирование производительности с помощью HD Tune Pro








Пропускная способность доступа в сеть Интернет












































Местоположение

Download (Mbps)

Upload (Mbps)

Ping (ms)

Москва (Beeline)

204.83

269.13

2

Краснодар (Rostelecom)

191.81

232.82

107

Екатеринбург (Rostelecom)

122.68

177.04

181

Иркутск (Rostelecom)

120.90

106.89

74

Владивосток (Rostelecom)

104.41

34.33

161

Франкфурт (Leaseweb)

143.03

181.90

65



Дополнительные возможности:




  • Резервное копирование


  • Возможность приобретения дополнительных IP-адресов


  • Лицензии на ПО (ISPmanager, Microsoft, 1С-Битрикс)




Доступные образы: Windows Server 2008 R2, 2012 R2

Стоимость: 3000 рублей в месяц за конфигурацию: 2 x 2 GHz (2 GHz гарантировано) / 4 GB RAM / 50 GB RAID5 SAS HDD / Windows Server 2012 R2

Ограничения согласно правилам: При достижении объёма трафика 3 000 ГБ скорость ограничивается до 10 Мбит/с до конца расчётного месяца. Скорость может быть восстановлена за 250 р (1000 ГБ)



Плюсы:




  • высокоскоростной доступ в сеть Интернет;


  • стабильная производительность вычислительной системы без скачков и провалов.




Минусы:




  • реальная частота CPU оказалась ниже заявленной;


  • низкая скорость R/W 4K секторов;


  • высокие задержки на маршрутах по России;


  • отсутствие информации об используемых серверах и системе хранения данных.




infobox.ru



infobox.ru — один из старожилов на рынке хостинг услуг. Компания предоставляет хостинг-услуги: регистрация доменных имён, электронная почта, хостинг (размещение сайтов и серверов), а также хостинг бизнес-решений для корпоративных клиентов.



Провайдер: infobox.ru

Дата-центр: Россия г. Санкт-Петербург. Нидерланды, ДЦ EvoSwitch

Платформа виртуализации: Virtuozzo

Триальный период: 5 дней

Время активации сервера: 10 минут



Заявленное оборудование:

Серверное оборудование — Supermicro

Сетевое оборудование — Juniper

Система хранения данных — нет информации



Характеристики тестируемого сервера:

vCPU: 2 x 2.3 (E5-2650v3)

RAM: 2GB

Хранение: 50GB SSD



Результаты тестирования infobox.ru



CPU

Согласно показателям LINPACK частота ЦП виртуальных машин не ограничивается, информация о частоте при оформлении указана на уровне 2.3 GHz.

Частота CPU: 2.414 GHz

Количество CPU: 1

Количество ядер: 2

Число потоков: 2

Среднее значение производительности 20.91 GFlops.

Отклонение от среднего значения: до 19%



График производительности в GFlops






Хорошее среднее значения производительности в GFlops, но имеются провалы в производительности до 19%.



Дисковая подсистема





Тестирование производительности с помощью HD Tune Pro




Исходя из графиков можно предположить, что пользователи активны в работе с дисковой подсистемой. Возможно, используется SDS-решение (программно-определяемое хранилище) или СХД.



Пропускная способность доступа в сеть Интернет












































Местоположение

Download (Mbps)

Upload (Mbps)

Ping (ms)

Москва (Beeline)

126.43

17.66

45

Краснодар (Rostelecom)

103.5

20.34

93

Екатеринбург (Rostelecom)

114.95

18.26

127

Иркутск (Rostelecom)

53.78

19.96

110

Владивосток (Rostelecom)

48.68

17.33

190

Франкфурт (Leaseweb)

193.87

20.31

15



Дополнительные возможности:




  • Резервное копирование


  • Администрирование серверов


  • Лицензии ПО (Microsoft, Parallels)




Доступные образы: Windows Server 2008, 2008 R2, 2012, 2012 R2 и Linux-based

Стоимость: 1500 рублей в месяц за конфигурацию: 2 x 2 GHz / 2 GB RAM / 50 GB SSD / Windows Server 2012 R2

Стоимость дополнительных ресурсов: 10 GB SSD — 200 рублей

Ограничения согласно правилам: Пропускная способность сети 20 Мбит/с.



Плюсы:




  • высокоскоростная дисковая подсистема;


  • производительная вычислительная подсистема.




Минусы:




  • высокие задержки по России;


  • нет возможности изменить конфигурацию виртуальной машины.




1cloud.ru



1cloud.ru — облачный сервис провайдер предоставляющий виртуальные серверы на платформе виртуализации VMware vSphere с облачным функционалом — высокая доступность вычислительных ресурсов и ресурсов хранения.



Провайдер: 1cloud.ru

Дата-центр: Россия г.Москва ДЦ Dataspace. г. Санкт-Петербург ДЦ SDN. Казахстан ДЦ Ahost

Платформа виртуализации: VMware

Триальный период: 3 дня

Время активации сервера: 15 минут



Заявленное оборудование:

Серверное оборудование — Cisco, Dell

Сетевое оборудование — Cisco

Система хранения данных — Dell, NetApp



Характеристики тестируемого сервера:

vCPU: 2 x 2.0 (E7-4850)

RAM: 2GB

Хранение: 40GB SSD



Результаты тестирования 1cloud.ru



CPU

Согласно показателям LINPACK частота ЦП виртуальных машин не ограничивается, информация о частоте при оформлении указана на уровне 2 GHz.

Частота CPU: 2.082 GHz

Количество CPU: 2

Количество ядер: 2

Число потоков: 2

Среднее значение производительности 12.57 GFlops.

Отклонение от среднего значения: до 16%



График производительности в GFlops






Дисковая подсистема





Тестирование производительности с помощью HD Tune Pro






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



Пропускная способность доступа в сеть Интернет












































Местоположение

Download (Mbps)

Upload (Mbps)

Ping (ms)

Москва (Beeline)

19.72

19.78

13

Краснодар (Rostelecom)

19.71

19.64

78

Екатеринбург (Rostelecom)

19.64

16.55

41

Иркутск (Rostelecom)

19.76

16.16

72

Владивосток (Rostelecom)

19.6

12.65

135

Франкфурт (Leaseweb)

19.75

15.62

48



Дополнительные возможности:




  • Резервное копирование


  • Лицензии ПО (Microsoft)




Доступные образы: Windows Server 2008 R2, 2012 R2, Linux-based

Стоимость: 1650 рублей в месяц за конфигурацию: 2 x 2GHz / 2 GB RAM / 40 GB SSD / Windows Server 2012 R2

Стоимость дополнительных ресурсов:




  • 1 vCPU — 110 рублей

  • 1 GB RAM — 315 рублей

  • 1 GB SATA — 3 рублей

  • 1 GB SAS — 5 рублей

  • 1 GB SSD — 20 рублей



Ограничения согласно правилам: 10 Мбит/с гарантированный канал, 100 Мбит/с максимально возможный.



Плюсы:




  • удобная панель управления


  • используется надежное оборудование известных производителей




Минусы:




  • низкая пропускная способность канала и высокие задержки


  • есть недокументированные лимиты на использование ресурсов CPU






cloudlite.ru



Проект компании DataLine по предоставлению вычислительных ресурсов на базе сертифицированных дата-центров по программе TIER III.



Провайдер: cloudlite.ru

Дата-центр: Россия г.Москва ДЦ DataLine NORD / OST.

Платформа виртуализации: VMware

Триальный период: виртуальный сервер не предоставляется

Время активации сервера: 3 минуты



Заявленное оборудование:

Серверное оборудование — Huawei

Сетевое оборудование — Cisco, Juniper

Система хранения данных — SDS



Характеристики тестируемого сервера:

vCPU: 2 x 2.2 (E7-4830 v2)

RAM: 2GB

Storage: 50 GB NL SAS HDD



Результаты тестирования cloudlite.ru



CPU

Согласно показателям LINPACK частота ЦП виртуальных машин не ограничивается, информация о частоте при оформлении указана на уровне 2.2 GHz.

Частота CPU: 2.147 GHz

Количество CPU: 2

Количество ядер: 2

Число потоков: 2

Среднее значение производительности 27.70 GFlops.

Отклонение от среднего значения: до 5%



График производительности в GFlops








Дисковая подсистема





Тестирование производительности с помощью HD Tune Pro




За высокую доступность и отказоустойчивость отвечает VMware VSAN.



Пропускная способность доступа в сеть Интернет












































Местоположение

Download (Mbps)

Upload (Mbps)

Ping (ms)

Москва (Beeline)

9.6

9.47

2

Краснодар (Rostelecom)

9.58

9.6

23

Екатеринбург (Rostelecom)

9.58

9.46

29

Иркутск (Rostelecom)

9.61

9.28

64

Владивосток (Rostelecom)

9.61

8.45

115

Франкфурт (Leaseweb)

9.58

9.44

49



Дополнительные возможности:




  • Резервное копирование


  • Лицензии ПО




Доступные образы: Windows Server 2008 R2, 2012 R2, Linux-based

Стоимость: 1857.6 рублей в месяц за конфигурацию: 2 x 2.2GHz / 2 GB RAM / 50 GB NL SAS HDD / Windows Server 2012 R2

Ограничения согласно правилам: Каждый виртуальный выделенный сервер (VPS/VDS) подключен на гарантированной скорости 10 Мбит/сек



Плюсы:




  • высокая производительность CPU;


  • низкие задержки по России.




Минусы:




  • с лицензией Windows стоимость сильно увеличивается по сравнению с тарифами на Linux;


  • невысокая скорость доступа в сеть Интернет.






mclouds.ru



mclouds.ru хостинг-провайдер, предоставляющий свой сервис на платформе виртуализации от VMware, позиционируется как облачный хостинг провайдер.



Провайдер: mclouds.ru

Дата-центр: г.Москва ДЦ Dataline NORD4

Платформа виртуализации: VMware

Триальный период: 1 день

Время активации сервера: 5 минут



Заявленное оборудование:

Серверное оборудование — HP, Supermicro

Сетевое оборудование — Cisco, Huawei

Система хранения данных — нет информации



Характеристики тестируемого сервера:

vCPU: 2 x 2.6 (E5-2670)

RAM: 2GB

Storage: 40 GB SSD



Результаты тестирования mclouds.ru



CPU

Согласно показателям LINPACK частота ЦП виртуальных машин не ограничивается, информация о частоте при оформлении указана на уровне 2.6 GHz.

Частота CPU: 2.592 GHz

Количество CPU: 2

Количество ядер: 2

Число потоков: 2

Среднее значение производительности 39.74 GFlops.

Отклонение от среднего значения: до 9%



График производительности в GFlops


На графике видна высокая производительность двух вычислительных ядер на уровне 40 GFlops.







Дисковая подсистема





Тестирование производительности с помощью HD Tune Pro






Пропускная способность доступа в сеть Интернет












































Местоположение

Download (Mbps)

Upload (Mbps)

Ping (ms)

Москва (Beeline)

87.9

83.6

3

Краснодар (Rostelecom)

89.4

31.3

17

Екатеринбург (Rostelecom)

97.4

89.1

29

Иркутск (Rostelecom)

76.1

59.7

64

Владивосток (Rostelecom)

91.3

45.1

107

Франкфурт (Leaseweb)

98

91.7

43



Дополнительные возможности:




  • Резервное копирование


  • Лицензии ПО




Доступные образы: Windows Server 2008 R2, 2012 R2, 2016 и Linux-based. Доступна установка из своего образа

Стоимость: 699 рублей в месяц за конфигурацию: 2 x 2.6GHz / 2 GB RAM / 40 GB SSD / Windows Server 2012 R2

Стоимость дополнительных ресурсов:




  • 1 vCPU — 99 рублей

  • 1 GB RAM — 190 рублей

  • 1 GB SSD — 20 рублей



Ограничения согласно правилам: средняя нагрузка за день на аппаратный ресурс Исполнителя, создаваемая Заказчиком не должна превышать следующих установленных

Исполнителем параметров:



a. vCPU: не более 2500 MIPS на vCPU.

b. SSD IOPS: не более 75 IOPS на 1 GB SSD.

c. Средняя пропускная способность: не более 25 Мбит/c на протяжении 8 часов



Плюсы:




  • стабильная и производительная вычислительная и дисковая подсистема;


  • низкие задержки по России.




Минусы:




  • ограниченные ресурсы вычислительной, дисковой подсистемы и доступа в сеть Интернет;


  • нет информации об используемой СХД.




Сводная таблица с критериями оценки






















































































































































































































































































































































































Наименование

Баллы

incloud.ru

ihc.ru

infobox.ru

1cloud.ru

cloudlite.ru

mclouds.ru

Дата-центр

0.6

0.1

0.5

0.3

0.6

0.1

0.6

Информация о ДЦ

0.2

0

0.2

0.1

0.2

0.1

0.2

Информация об инженерных подсистемах

0.2

0.1

0.1

0.2

0.2

0.2

0.2

Сертификация TIER

0.2

0

0.2

0

0.2

0.2

0.2

Информация об оборудовании

0.3

0.3

0

0

0.3

0.3

0.2

Серверное оборудование

0.1

0.1

0

0

0.1

0.1

0.1

Система хранения данных

0.1

0.1

0

0

0.1

0.1

0.0

Сетевое оборудование

0.1

0.1

0

0

0.1

0.1

0.1

Информация о юр.лице

0.3

0

0.3

0.3

0.3

0.2

0.2

Контактные данные

0.1

0

0.1

0.1

0.1

0.1

0.1

Адрес юр.лица

0.1

0

0.1

0.1

0.1

0.1

0.1

Реквизиты компании

0.1

0

0.1

0.1

0.1

0

0

Информация о платформе виртуализации

0.1

0.1

0.1

0.1

0.1

0.1

0.1

Договор оферты

0.4

0.1

0.1

0.1

0.4

0.4

0.4

Договор оферты

0.1

0.1

0.1

0.1

0.1

0.1

0.1

SLA

0.3

0

0

0

0.3

0.3

0.3

Тестирование сервиса

Вычислительная подсистема

0.4

0.2

0.2

0.2

-0.1

0.4

0.4

Соответствие заявленной частоты и выделенной частоты процессора

0.2

0

0

0.2

0.2

0.2

0.2

Стабильность вычислительной подсистемы

0.2

0.2

0.2

0

0

0.2

0.2

Недокументированное ограничение вычислительной подсистемы



* во время тестирования ограничения не были выявлены

-0.3

0*

0*

0*

-0.3

0*

0*

Дисковая подсистема

0.8

0.6

0.5

0.3

0.8

0.6

0.6

Стабильность дисковой подсистемы

0.2

0.2

0.2

0.1

0.2

0.2

0.2

Высокоскоростная дисковая подсистема

0.2

0

0.2

0.2

0.2

0.2

0.2

Высокая доступность данных

0.2

0.2

0

0

0.2

0.2

0.1

Отказоустойчивость дискового хранения

0.2

0.2

0.1

0.1

0.2

0.2

0.1

Сетевое соединение

0.5

0.5

0.4

0.4

0.3

0.3

0.5

Стабильность сетевого соединения

0.2

0.2

0.2

0.2

0.2

0.2

0.2

Низкие задержки по России

0.1

0.1

0

0

0

0.1

0.1

Высокая скорость доступа по России (более 20 мбит/с)

0.2

0.2

0.2

0.2

0.1

0

0.2

Дополнительные услуги

1

0.8

0.5

0.5

0.6

0.8

0.7

Базовая техническая поддержка

0.2

0.2

0.2

0

0

0.2

0.2

Расширенная техническая поддержка

0.2

0

0

0.2

0

0

0

Бесплатная лицензия Windows Server

0.2

0.2

0.2

0.2

0.2

0.2

0.2

Лицензия ПО

0.1

0.1

0.1

0.1

0.1

0.1

0

Гибкое расширение ресурсов

0.3

0.3

0

0

0.3

0.3

0.3

Итого

3,4

1,9

2,1

1,7

2,7

2,8

3





Сводная таблица с результатами тестирования





























































































incloud.ru

ihc.ru

infobox.ru

1cloud.ru

cloudlite.ru

mclouds.ru

CPU GHz заявленная

2

2

2.2

2.6

CPU GHz выделенная

1.597

1.286

2.414

2.082

2.147

2.592

Ср.знач. GFlops

18.86

4.79

20.91

12.57

27.7

39.74

Отклонение от ср.знач. в %

6

2

19

16

5

9

Seq.R Q32T1 (MB/s)

113 (SSD)

695.6 (HDD)

1402 (SSD)

657.5 (SSD)

652.4 (HDD)

1042 (SSD)

Seq.W Q32T1 (MB/S)

113.2 (SSD)

127.4 (HDD)

1300 (SSD)

549.2 (SSD)

443.6 (HDD)

688.1 (SSD)

4 KB Random Read (IOPS)

8143

20603

21531

19874

12785

37023

4 KB Random Write

(IOPS)

3965

1105

32020

20097

6549

21943

Access time (ms)

0.287

0.811

0.400

1.02

3.59

0.228



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



Подводим итоги



Как видно по результатам тестов, уровень качества предоставляемых услуг в плане производительности работы ВМ у всех хостинг провайдеров различный. Приведенные результаты не претендуют на истину в последней инстанции, но я постарался сделать эту информацию максимально объективной. Надеюсь, это поможет сэкономить время тем, кому нужны вычислительные ресурсы, но нет необходимого бюджета на новое оборудование. Выход есть. Рынок облачных хостинг провайдеров в России широк и конкуренция здесь достаточно высока. Считаю, что доверять работу своих бизнес-приложений «облакам» можно и нужно, но следует внимательно относиться к выбору провайдера.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333854/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Многоярусный бэкап PostgreSQL с помощью Barman и синхронного переноса журналов транзакций

Пятница, 21 Июля 2017 г. 12:33 (ссылка)



В Яндекс.Деньгах хранится масса важной для комфортной работы пользователя информации. Настройки профилей и подписки на штрафы тоже нужно бэкапить, чем и занимается у нас связка из Barman Backup & Recovery for PostgreSQL и pg_receivexlog.



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



Как было, и почему это не круто



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



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

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



Делаем правильно



Итого, будем решать следующие задачи:




  1. Обеспечение доступности резервных копий при отказе ДЦ или бэкап-сервера.




  2. Недопущение потери транзакций при выходе мастер-сервера из строя.



Масштаб нашей задачи составляли 20 серверов PostgreSQL 9.5 (10 мастеров и 10 слейвов), обслуживающих 36 баз данных суммарным объемом около 3 ТБ. Но описываемый сценарий подойдет и для пары серверов с критичными БД.



С версии 2.1 в Barman Backup & Recovery появилась возможность записывать поток транзакций не только с мастера, но и со слейв-серверов (реплик).

Общая схема нового решения представлена ниже, она довольно незамысловата:



По одному серверу резервного копирования в каждом ДЦ, конфигурация у них общая (один из плюсов Barman).



Процесс конфигурации выглядит следующим образом:



1. Подключаемся к серверу БД и с помощью пакетного менеджера устанавливаем postgresql-9.5-pgespresso – расширение для интеграции Barman Backup & Recovery c PostgreSQL.

Все команды приводятся для Ubuntu, для других дистрибутивов могут быть отличия:



apt-get install postgresql-9.5-pgespresso


2. Устанавливаем расширение pg_espresso в PostgreSQL:



postgres@db1:5432 (postgres) # CREATE EXTENSION pgespresso


3. Теперь на сервере с Barman нужно создать файл, описывающий настройки резервного копирования для сервера db1 – db1.conf в каталоге /etc/barman.d/ со следующим содержимым:



[db1]
ssh_command = ssh postgres@db1
conninfo = host=pgdb1 user=postgres port=5432
backup_options = concurrent_backup ; позволяет выполнять бэкап с реплики при наличии расширения pg_espresso

archiver = off ; выключаем доставку логов через archive_command
streaming_archiver = on ; включаем доставку логов через механизм репликации
slot_name = barman ; имя слота репликации


4. Далее нужно создать слот репликации, чтобы гарантировать, что мастер не удалит журналы транзакций, которые еще не были получены репликой:



$ barman receive-wal --create-slot db1


5. И проверить, что Barman видит сервер и забирает с него журналы транзакций:



$ barman check db1


Если все команды выполнены правильно, то в результате выполнения команды проверки должно получиться нечто похожее:



Server db1:
PostgreSQL: OK
superuser: OK
PostgreSQL streaming: OK
wal_level: OK
replication slot: OK
directories: OK
retention policy settings: OK
backup maximum age: OK (no last_backup_maximum_age provided)
compression settings: OK
failed backups: OK (there are 0 failed backups)
minimum redundancy requirements: OK (have 7 backups, expected at least 7)
ssh: OK (PostgreSQL server)
pgespresso extension: OK
pg_receivexlog: OK
pg_receivexlog compatible: OK
receive-wal running: OK
archiver errors: OK


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



Отряд не заметил потери бойца



Напомню, что нулевое RPO при восстановлении нам очень важно, поэтому решили подстраховать Barman дополнительным механизмом – pg_receivexlog. Этот процесс находится на отдельном сервере – не на сервере с базой данных – и непрерывно переносит копии журналов транзакций из мастер-ноды в отдельное хранилище журналов транзакций, доступное для реплики. И так для каждого ДЦ отдельно.



Особенность механизма в том, что СУБД не подтвердит приложению запись данных в базу, пока не получит подтверждение от pg_receivexlog об успешном копировании транзакции.



Без этого сохранялась бы вероятность следующего сценария:




  1. Допустим, Иннокентий платит 100 рублей за сотовую связь, операция успешно проводится нашей платежной системой (ПС).




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




  3. Но так как перевод произошел прямо перед аварией, эта транзакция не попала в резервные копии и больше не отразится в истории операций по кошельку Иннокентия.



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



Теперь как настроить чудо механизм синхронного переноса логов:



1. Создаем слот для сборщика логов:



pg_receivexlog --create-slot -S pgreceiver --if-not-exists -h db1


2. Запускаем службы сбора логов с сервера PostgreSQL:



pg_receivexlog -S pgreceiver -d "host=db1 user=postgres application_name=logreceiver" -D /var/lib/postgresql/log/db1/ --verbose --synchronous


*-S: используемый слот репликации. Должен быть создан на первом шаге;*
*-d: строка подключения к базе;*
*-D: каталог, куда будут сохраняться журналы;*
*—synchronous: записывать данные в синхронном режиме;*


3. После запуска pg_receivexlog будет пытаться в синхронном режиме сохранять журналы транзакций в каталог. Таких сборщиков может быть несколько, по одному на сервер PostreSQL. Но чтобы синхронный режим заработал, нужно в настройках СУБД на мастер-ноде указать параметр в конфигурации PostgreSQL:



synchronous_standby_names = 'logreceiver, standby'


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



restore_command = 'scp postgres@logreceiver:/var/lib/postgresql/log/db1/%f* %p'


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



В качестве резюме приведу немного конкретики о времени и объеме бэкапов по описанной в статье схеме. Полный бэкап упомянутых серверов снимается в Яндекс.Деньгах ежедневно и весит около 2 ТБ, на обработку которых бэкап-серверу нужно 5-10 часов. Кроме того, выполняется постоянный бэкап журналов транзакций с помощью перемещения их файлов в хранилище.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333844/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как мы добавили RAM в серверы HPE

Пятница, 21 Июля 2017 г. 10:04 (ссылка)





Качество и надежность DRAM сейчас важнее, чем когда-либо, в основном из-за растущего использования виртуализации серверов. Конечно, стоит отметить что модули RAM, по мнению многих IT-специалистов, являются одним из самых надёжных элементов сервера и выходят из строя последними. Виртуализация имеет много преимуществ, но она значительно увеличивает количество необходимой памяти в сервере для обеспечения оптимальной производительности максимального числа виртуальных машин. По данным HP за 5 лет с 2007 до 2011 средняя память, установленная на всех серверах HP ProLiant, выросла более чем на 500% — от 4 ГБ до более чем 30 ГБ на сервер.



В настоящее время как облачный провайдер мы используем blade-серверы HP ProLiant BL460c Gen8 на шасси HPE BLADESYSTEM C7000 ENCLOSURE. Полностью QuickSpecs тут, обозначим лишь спецификацию RAM.



Standard (Preconfigured Models)

64GB (8 x 8GB) DDR3 1600MHz RDIMMs at 1.5V

64GB (4 x 16GB) DDR3 1866MHz RDIMMs at 1.5V

32GB (4 x 8GB) DDR3 1600MHz RDIMMs at 1.5V

32GB (2 x 16GB) DDR3 1866MHz RDIMMs at 1.5V

32GB (4 x 8GB) DDR3 1333MHz RDIMMs at 1.35V

32GB (2 x 16GB) DDR3 1600MHz RDIMMs at 1.35V

16GB (2 x 8GB) DDR3 1866MHz RDIMMs at 1.5V

16GB (4 x 4GB) DDR3 1333MHz RDIMMs at 1.35V

16GB (2 x 8GB) DDR3 1600MHz RDIMMs at 1.35V



Maximum

(LRDIMM) 512GB (16 x 32GB) up to 1333MHz at 1.35V

(RDIMM) 256GB (16 x 16GB) up to 1866MHz at 1.5V

(RDIMM) 384GB (16 x 24GB) up to 1333MHz at 1.35V

(UDIMM) 128GB (16 x 8GB) up to 1600MHz at 1.5v



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



Отметим, что в случае с использованием в оборудовании для облака, то есть в системах, требующих масштабируемости и отказоустойчивости в ущерб дешевизне, используется регистровая память c функцией коррекции ошибок (ECC RDIMM).



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



В поисках лаконичного ответа был найден White paper от HP, точнее даже два, один 2011 года, а второй 2017. Что мы выделили для себя:




  • HP не является производителем модулей RAM.

  • Когда вы видите бренд HP Qualified Memory, это означает, что DRAM прошла серьёзную проверку качества и тестирование с используем проприетарных диагностических инструментов и специализированных диагностических тестов, чтобы обеспечить высокий уровень производительности и доступности серверов HP ProLiant.








  • До того, как модуль DRAM получит бренд HP Qualified Memory (наклейку), он проходит интенсивный четырехфазный процесс проверки качества. HP задолго до разработки продукта сообщает производителям модулей памяти (Tier 1 memory suppliers) требования к DRAM. Группа HP Memory Core получает модули DIMM непосредственно от поставщика-производителя. На диаграмме процесса HPMQ (HP Memory Qualification) даны краткие описания четырех фаз процесса проверки качества. На наш взгляд, важно обратить внимание на то, что не описано какая доля полученных на проверку модулей отсеивается.





    В результате HPMQ не меняется расположение микросхем, кажется, дизайнер ошибся




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

    HP-validated memory is tested so that it does not get too hot and forget your data. HP-validated memory is tested so that it does not cause the system to shut-down due to power overload.

  • HP Qualified Memory обладает такой же полной гарантией, что и серверы ProLiant.

  • Если будет установлено, что отказ сервера вызван RAM под другим брендом (не-hp) или в любое время будет обнаружено, что сторонняя часть наносит ущерб компонентам или системам HP, стоимость ремонта, включая поврежденные детали HP, оплату труда и проезда, не будет покрываться по стандартной гарантии HP. Но установка сторонней памяти не снимает сервера ProLiant с гарантии HP. Подобное заблуждение часто приводится пользователями IT-форумов как аргумент «за OEM» в ходе обсуждения подбора памяти для сервера.




Сколько стоит HPMQ и сервис HP для покупателя? Для наглядности и понимания об уровне цен приложены скриншоты с Яндекс.Маркета. Мы не предлагаем расценивать это как полноценное исследование рынка, особенно по причине минимальных цен на HP RAM от неизвестных нам продавцов, которые на 60% ниже средней рыночной.











Почему для сравнения мы выбрали оперативную память от Kingston?




  • Каждый серверный модуль Kingston для конкретной системы должен пройти испытания на принудительный отказ. Эта уникальная процедура позволяет отбраковывать потенциально дефектные модули, не допуская их попадания в отгружаемые партии продукции. В том числе, присутствует проверка надёжности при разогреве. Полный список проверок качества здесь.

  • Являясь долговременным членом Совета директоров JEDEC, Kingston Technology способствует созданию отраслевых стандартов для технологий изготовления памяти. Все модули памяти, выпускаемые компанией Kingston, отвечают требованиям JEDEC и основным техническим условиям, применяемым ведущими изготовителями полупроводниковых устройств.

  • Техническая поддержка и тест-драйв. Есть официальное представительство в РФ (в отличии от Crucial, например), по запросу всегда есть необходимое количество плашек для отгрузки. Серверную память можно взять на тест-драйв и посмотреть, как она будет работать в реальных условиях на конкретном сервере.

  • «Пожизненная» гарантия. Если модуль памяти откажет, его заменят по гарантии.



У Kingston есть большое количество различных вариантов модулей RAM. Подходящий можно подобрать на их сайте. Потенциальные проблемы с несовместимостью должны отсутствовать, так как по заявлениям Kingston, модули были протестированы на всех соответствующих вариантах серверов. В нашем случае, мы выбирали для HP BL460C G8, проблем в работе не возникло.



Что дала нам покупка модулей памяти Kingston? При значительном объёме закупки удалось серьёзно сократить бюджет на модернизацию. Нам не удалось выявить значимых отличий в проверке качества RAM от Kingston и HP. Не найдя оснований для того, чтобы оплатить почти в два раза больший счёт, мы выбрали модули Kingston. Это также позволило не перекладывать дополнительные издержки на потребителей наших услуг.



В этой статье мы не пытаемся обратить внимание на дороговизну комплектующих от HP. Более того, мы довольны использованием серверов HP ProLiant и HP BladeSystem. Для поддержки большого количества виртуальных машин на одном физическом сервере требуется больше памяти, больше подключений для хранилищ данных и больше сетевых подключений, поэтому, по нашему мнению, серверы HP, сертифицированные для VMware, являются одними из лучших платформ для виртуализации, так как они были построены «with virtualization in mind».



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




  • VMware VMotion;

  • VMware DRS;

  • VMware HA;

  • и прочие.



Выбранное оборудование для облачного провайдера является основой для построения всей бизнес-системы, которая в конечном счёте должна обеспечить клиентов услугами с высоким уровнем доступности и качества (SLA от 99,95%) по конкурентной цене. Это является причиной поиска оптимальных решений.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333786/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Компания HPE начала продажи новых серверов HPE ProLiant Gen10

Четверг, 20 Июля 2017 г. 17:22 (ссылка)

11 июля HPE начала принимать заказы на новые серверы ProLiant Gen10, и в этом материале мы хотим рассказать о ключевых технологиях и характеристиках моделей в этом юбилейном поколении.



Хотя выпуск нового поколения серверов и совпал с выпуском процессоров Intel Xeon Scalable Family, это была далеко не единственная причина для обновления. Предпосылками стали новые задачи заказчиков HPE. Среди них: появление новых классов нагрузок (в т.ч. требующих обработки больших объемов данных в памяти и высокой производительности дисковой подсистемы), улучшение управляемости аппаратной инфраструктуры (переход на управление через REST API, интеграция с различными средствами автоматизации ИТ, поддержка шаблонов и сценариев), новые модели потребления ИТ-ресурсов (например, финансовые услуги и оплата по мере использования), а также, не в последнюю очередь, новые угрозы в информационной безопасности, связанные с уязвимостью низкоуровневых компонентов серверов (BIOS и прошивок).



Что же нового появилось в серверах HPE ProLiant Gen10 в ответ на все эти задачи. Разберемся по порядку.



Процессоры



Во главе угла стоит повышение производительности сервера с помощью собственных технологий HPE под общим названием Intelligent System Tuning:

Workload Matching (настройка под задачу) – это набор преднастроек сервера под различные конкретные задачи, которые в каждом случае повышают отдачу за счет тонких изменений конфигурации памяти, процессоров, питания, дисковой подсистемы и т.д. (всего существует около 30 регулируемых настроек, поэтому настроить сервер под конкретную задачу самостоятельно может быть непросто)



Jitter Smoothing (сглаживание дрожания). С включением этой технологии, сервер начинает отслеживать «дрожание» частоты процессора в режиме TurboBoost, и сглаживать перепады частоты для устранения задержек обращения к разным уровням памяти, которые возникают при резком изменении частоты. В результате, в требовательных к частоте и задержкам задачах (например, ОС реального времени и некоторые Java-приложения) мы получаем прирост производительности даже сверх обычного прироста в турбо-режиме. Почитать подробно об этой технологии можно здесь: h20565.www2.hpe.com/hpsc/doc/public/display?docId=a00018313en_us

image

Core Boosting (ускорение ядер). Эта технология станет доступной в серверах Gen10 в ближайших релизах (осень 2017 – весна 2018), для некоторых процессоров Intel Xeon Scalable семейств 6000 и 8000. Она предназначена для повышения частоты активных ядер в процессорах Intel Xeon в режиме TurboBoost сверх «обычной» доступной частоты в этом режиме. В результате таких настроек можно оставаться на том же уровне производительности, например, в БД Oracle, работая при этом на меньшем числе ядер. А это прямая экономия денег на лицензиях.

image

Для включения Jitter Smoothing и Core Boosting на сервере должна быть активирована лицензия iLO Advanced или выше. Core Boosting, кроме того, будет работать не на всех процессорах и конфигурациях сервера. Кратко обо всех трех технологиях – здесь: www.hpe.com/h20195/v2/Getdocument.aspx?docname=a00018328enw



Память





Также были доработаны механизмы обеспечения отказоустойчивости памяти. В современных системах, где объем памяти исчисляется сотнями гигабайт, вероятность появления ошибок в каких-то чипах памяти очень высока. Поэтому применение инструментов для обеспечения надежности памяти (RAS) становится все более обоснованным. С поколением Gen10 HPE представила еще один такой инструмент – технологию SmartMemory Fast Fault Tolerance (FFT). С включением FFT упреждающие алгоритмы анализируют состояние чипов памяти, и в случае появления риска для данных в какой-то области памяти в чипе, назначают ей «запасные» области сравнимого объема на том же канале памяти. В результате запись и чтение данных в защищаемой области идет с контролем целостности, и пропускная способность и общий объем падают только для этой маленькой области.



В чем отличие это технологии, например, от механизма Lockstep с DDDC от Intel, который используется в процессорах Xeon E7 сейчас? В том, что с тонким контролем HPE Advanced Error Detection и Fast Fault Tolerance, мы снижаем производительность только при появлении вероятности потери данных и только для малой области памяти, в отличие от Lockstep, где производительность снижается на всех модулях памяти. В результате с FFT в целом по системе пропускная способность падает в среднем не более, чем на 1%. Эта технология также уникальна для HPE и не появится в серверах других производителей еще 2 года по лицензионному соглашению с Intel. В целом, применение современных технологий RAS в серверах HPE, по статистике HPE, снижает число «падений» системы в год (Annual Crash Rate) на 85%. Еще один ответ на вопрос почему память от HPE называется Smart Memory.



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









Другой набор инноваций по работе с памятью – это две технологии энергонезависимой оперативной памяти HPE NVDIMM и HPE Scalable Persistent Memory. Первая – это существующие уже более двух лет модули оперативной памяти, совмещенные с энергонезависимой флешкой (на том же модуле) с питанием от батарейки в сервере. Такие модули видны обычным ОС (Windows и Linux) как очень быстрое блочное устройство — см. эксперименты вот здесь: habrahabr.ru/company/hpe/blog/282395. А некоторым приложениям (например, Microsoft SQL Server 2016) такой модуль виден как особое устройство с побайтной адресацией (как в RAM), но с устойчивостью к отключению питания. При размещении на таких модулях, хвоста лога транзакций (Tail of transaction log) MS SQL Server'а, мы видим прирост производительности базы данных до 4 раз по сравнению с размещением хвоста лога на SSD. Новые модули HPE NVDIMM теперь имеют емкость 8 и 16 ГБ, в то время как для БД SQL размером в несколько сотен гигабайт в большинстве случаев достаточно 1 модуля NVDIMM для размещения хвоста лога транзакций.



HPE Scalable Persistent Memory – это комплексные устройства, построенные на базе серверов HPE ProLiant DL380 Gen10, обычных модулей памяти DDR4 и особого механизма защиты RAM от потери питания с помощью NVMe-накопителей и резервного блока питания с внутренним ИБП в самом сервере. С этим устройством вы можете разместить в памяти до 1 ТБ данных без риска потерять их при отключении электричества, и таким образом многократно ускорить работу многих приложений. Например, во внутренних тестах с MySQL операции Checkpoint (сохранения данных БД из памяти на энергонезависимый носитель) на HPE Scalable Persistent Memory выполнялись в 27 раз быстрее, чем на HDD и в 3 раза быстрее, чем на SSD. А Restore (обратная операция – возвращение данных в память после сбоя) происходила в 13 и 5 раз быстрее соответственно. И кроме того, с такой системой практически любую БД можно превратить в in-memory, многократно повышая ее производительность.

image

Использование NVMe-накопителей также получило очень глубокое развитие. Теперь в каждый сервер можно установить в разы больше NVMe-накопителей (до 20 штук в DL380 Gen10, например), и в одну и ту же дисковую корзину в сервере можно устанавливать и NVMe, и SAS/SATA диски (продолжают существовать и обычные корзины без поддержки NVMe, если она вам не нужна). Плюс, появилась поддержка нового формата накопителей – uFF (micro-Form Factor), которых помещается 2 на место одного SFF-накопителя (объемы 120 и 340 ГБ, SATA). uFF-SSD могут использоваться как загрузочные или кэширующей диски для целого ряда задач, и экономят место в сервере для более емких накопителей под продуктивные данные.



Обновилась и линейка контроллеров. Теперь они быстрее (до 1,6 млн IOPS с контроллера) и могут работать одновременно в HBA и RAID-режиме (какие-то диски на контроллере в одном режиме, какие-то в другом). Полная линейка контроллеров в Gen10 на данный момент выглядит так:

image



iLO 5





Одна и самых мощных новинок поколения Gen10 – усовершенствованная система удаленного управления HPE iLO 5. Кроме более быстрого чипа iLO, который ускоряет операции с удаленной консолью и виртуальными накопителями, появился целый ряд новых возможностей:

image



Технология HPE Silicon Root of Trust – это проверка прошивки iLO на наличие в ней вредоносного кода или повреждений с помощью сверки контрольной суммы с аппаратным чипом внутри системы iLO. Когда прошивка iLO проверена, это средство управления само проверяет прошивки всех остальных компонентов сервера, включая BIOS на предмет вторжения злоумышленников или другие нарушения целостности. В случае обнаружения проблемы, iLO может автоматически или по команде восстановить конкретную прошивку в последнее рабочее состояние из защищенного репозитория прошивок, вернуть сервер к заводским настройкам или не реагировать.



imageЗачем эта технология? Во-первых, прошивка компонента может повредиться в процессе обновления вручную или просто из-за сбоя в микросхеме. Во-вторых, аналитики угроз ИБ с каждым годом обнаруживают все больше уязвимостей в прошивках и другом низкоуровневом коде серверов. Последний громкий пример – найденная уязвимость в патчах для прошивок серверов SuperMicro, которые закупила себе компания Apple (ссылка: arstechnica.com/information-technology/2017/02/apple-axed-supermicro-servers-from-datacenters-because-of-bad-firmware-update). Этот уровень практически не контролируется привычными антивирусами, поэтому и угроза там скрывается значительная.



Уникальность подхода HPE здесь: а) полный контроль над производством прошивок компонентов; все компоненты под брендом HPE имеют специально разработанную, либо проверенную и поставляему только через канал HPE прошивку и, начиная с поколения Gen10, поставляются с цифровой подписью HPE. И б) только HPE разрабатывает и производит собственную систему управления iLO, от софта до микросхем, благодаря чему может встроить в нее средство проверки подписей прошивок.

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



Функциональное улучшение в iLO 5 – теперь средство настройки сервера, включая настройки RAID, под названием Intelligent Provisioning можно запускать прямо из консоли iLO, а не только при загрузке сервера по нажатию F10. Благодаря этому можно избежать лишних перезагрузок сервера.



Быстрее стала проходить и сама процедура загрузки при использовании UEFI-режима BIOS – в среднем загрузка в 3 раз быстрее. Изменился и стал более удобным интерфейс настройки BIOS RBSU, и запустить его тоже можно из Intelligent Provisioning (а его – из iLO).

Большой плюс для пользователей различных средств автоматизации, в том числе в многовендорных окружениях – iLO теперь поддерживает большинство инструкций Open IPMI. И к тому же HPE продолжает лидировать в наполнении стандарта управления «железом» через интерфейс REST API (читайте здесь: habrahabr.ru/company/hpe/blog/268885). Теперь REST API от HPE полностью соответствует стандарту DMTF Redfish, кроме части управления RAID-контроллерами (там пока собственные REST API). Для управления через REST API есть как собственное средство, так и масса вспомогательных средств (например, для Python и PowerShell).



Еще одно новшество – на этот раз в части диагностики неисправностей. Если раньше Active Health System Log (запись «бортового самописца» сервера) можно было только выгрузить через iLO и отправить в Центр поддержки HPE для анализа, то сейчас его можно выкачать на флешку через спецальный USB-порт на лицевой стороне сервера и проанализировать самостоятельно с помощью бесплатного сервиса Active Health System Viewer (http://www.hpe.com/servers/ahsv). Сервис показывает и предлагает решение для 25% возможных уязвимостей, а для остальных – просто значительно облегчает обращение в поддержку, сокращая время на анализ неисправности.

image



Новые модели HPE ProLiant Gen10





Вторая часть нашего обзора – о моделях, которые уже доступны к заказу сегодня. Вот так будет выглядеть весь основной портфель серверов HPE (здесь мы не говорим о линейках Apollo, Integrity и некоторых других):

image



Зеленым выделены те модели, которые можно заказать сейчас. Краткий обзор моделей в картинках:



ProLiant DL360 Gen10











ProLiant DL380 Gen10











ProLiant DL560 Gen10









ProLiant BL460c Gen10 – да, мы продолжаем выпуск блейдов в текущем шасси!









MicroServer Gen10







Кроме того, сейчас доступны к заказу новые серверы для платформы Synergy– SY480 Gen10 и SY660 Gen10, а сама платформа Synergy получила поддержку 25/50 GbE фабрики Mellanox, мощные графические опции и расширение вариантов конфигурации внутренних дисковых полок.



Плюс, существенно обновилась линейка продуктов для высокопроизводительных вычислений (НРС). Представлен новый флагман суперкомпьютерного мира – система HPE SGI 8600 с жидкостным (водяным) охлаждением. Отвечая стремительному прогрессу в мире НРС и потребностям заказчиков HPE, полностью переработана 6000-ная серия – представлена новая высокоинтегрированная система HPE Apollo 6000 Gen10 (узлы XL230k Gen10 и шасси k6000). Для решения широкого спектра задач в области искусственного интеллекта и некоторых других нагрузок, было представлено новое семейство узлов HPE Apollo 10-series, поддерживающих самые современные технологии ускорения вычислений Intel Xeon Phi 7000 и NVIDIA Tesla P100 на шине NVLink.



На этом мы заканчиваем эту статью, и ждем ваших пожеланий – какие технологии, сферы применений и модели серверов нам затронуть в ближайших обзорах и вебинарах? Мы запланировали 4 вебинара на октябрь – вам решать, о чем они будут. Отвечайте в комментариях, пожалуйста.



А пока, много отличных видео о Gen10 можно посмотреть здесь:



www.youtube.com/user/HewlettPackardVideos/videos
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333800/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Когда деревья были большими: как маленький дата-центр ураган пережил

Четверг, 20 Июля 2017 г. 10:48 (ссылка)



Лето 2017 года выдалось богатым на ураганы. А вот у нас тоже был случай. Ровно 7 лет назад наш первый дата-центр на Боровой пережил ураган, который похоронил чиллеры под слоем 10 тонн железа, прилетевшего с соседней крыши. Душещипательные фотографии искореженных чиллеров разошлись по интернету уже давно, а история про восстановление ЦОДа, оставшегося без холода, никогда не публиковалась. Решил поднять архивы и восполнить пробел.



В 2010 году DataLine был начинающим оператором дата-центров. На площадке OST успели запустить только три зала на 360 стоек, на севере Москвы (NORD) был один корпус с одним залом на 147 стоек.





Вот как изменились масштабы нашей инфраструктуры с 2010 года.



Хотя мы сами проектировали и строили, тогда у нас не было выделенной службы эксплуатации. Не было, как сейчас, отдельных специалистов по ДГУ, кондиционерам, электриков – отдавали все по максимуму подрядчикам. Объемы инфраструктуры были небольшие, как, впрочем, и наш опыт. За инженерку тогда отвечали директор по производству, главный энергетик и я, технический директор. На подхвате были еще дежурные инженеры (трое в смене), но они занимались клиентскими запросами и мониторингом.





Один из первых залов дата-центра OST-1 в конце 2009 года.





Так выглядят новые залы в OST сегодня.



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

На площадке работала чиллерная схема на этиленгликоле с тремя чиллерами Emicon в схеме резервирования 2+1. Надо сказать, эти чиллеры так и не вышли на заявленную производителем мощность, но, поскольку нагрузка была небольшая, одного чиллера почти хватало на все три зала.



День первый



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





Кровельное железо свисало с проводов, как белье.



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











По записи системы видеонаблюдения видно, что все железо прилетело за один мощный порыв ветра. Вот что мы потом увидели c записи одной из камер:







На видео часы отстают. Когда все произошло, было уже 18.18.



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





Поврежденная рама и теплообменник фрикулинга первого чиллера. Теплообменник представляет собой “бутерброд”: снаружи рубашка фрикулинга, внутри, с зазором сантиметров пять, такой же на вид теплообменник фреонового конденсатора.





Искореженные вентиляторы одного из чиллеров.



Из пробитых теплообменников фрикулинга хлестал гликоль. Давление в системе холодоснабжения резко упало. Насосы остановились по защите от сухого хода, вырубился последний рабочий чиллер, и вся система холодоснабжения встала (времени было 18:32, две минуты как закончился рабочий день). Несколько секунд мы пребывали в ступоре и не знали, что делать. Потом позвонили подрядчику по холодоснабжению и вызвали аварийную бригаду. По телефону подрядчик посоветовал перекрыть внешний контур, объяснил, где находятся нужные вентили и краны системы подпитки. Мы перекрыли вентили, питающие внешние теплообменники, гликоль перестал течь.



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



В 18:51 начали дозаправлять гликолевые контуры водопроводной водой и постепенно довели давление в системе до рабочего.

В 19.45 приехала аварийная бригада.

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

Пока мы проделывали все эти упражнения, температура гликоля успела вырасти с рабочих значений (7–12° С) до 20 градусов. Один живой чиллер работал с перегрузкой, и периодически один из двух его контуров останавливался по ошибке. После этого нужно было вручную сбросить ошибку на пульте, и через пять минут (защитный интервал) компрессор запускался. Или не запускался. Тогда помогало полное обесточивание чиллера с перезагрузкой.



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





Директор по капитальному строительству тогда сорвал спину, скидывая стальные балки с чиллеров.



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

К 23:00 худо-бедно собрали и запустили второй чиллер, и температура в залах начала медленно опускаться.



К тому времени стемнело, но самое интересное только начиналось. Чиллеры стало вышибать по защите из-за перегрева компрессоров: температура гликоля по-прежнему была высокой несмотря на отключение большей части клиентов.

Начальник производства съездил и купил керхеры, шланги и налобные фонари, чтобы можно было работать ночью. Мы поливали компрессоры чиллеров холодной водой, но это не очень помогало, так как компрессор – это кусок железа весом больше тонны и быстро его не охладить. Теперь, когда чиллер останавливался по ошибке, вместо пяти минут приходилось ждать несколько десятков минут, пока компрессор остынет и ошибка Compressor Overload пропадет.





Сообщение об ошибке, которое нам по очереди показывали то один, то другой чиллер.



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

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





Изменение температуры в холодных коридорах с начала аварии и до ее устранения.

1 — время первой остановки всех чиллеров; 2 — время запуска первого чиллера; 3 — время запуска второго чиллера; 4 — повторная остановка чиллеров; 5 — запуск чиллеров с отключенной тепловой защитой.



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



День второй



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

Гидрометцентр не обманул: снова пекло под 30° С. Из этой собранной на коленке системы и керхеров мы практически без остановки поливали чиллеры, которые продолжали работать с отключенной тепловой защитой.





А вот исторический кадр: чиллеры спасает дежурный сетевой инженер Григорий Атрепьев, ныне руководитель отдела комплексных проектов.



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





Замена вентиляторов на третьем чиллере. Чиллер Emicon RAH1252F с опцией фрикулинга (свободного охлаждения) состоит из двух модулей, в каждом из которых стоит 8 осевых вентиляторов и компрессор Bitzer.

















Заправка фреоном.





Вид на задний двор на следующий день. Еще долго вывозили металлолом.



Что было дальше



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



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



Поскольку чиллеры так и не выдавали заявленной холодильной мощности (а ИТ-нагрузка росла по мере заполнения ЦОДа), приходилось и дальше поливать их в жару. Теплообменники не пережили водных процедур: с годами они обросли известковыми отложениями, а в зазор между теплообменником фрикулинга и фреоновым конденсатором набилась всякая грязь, удалить которую конструкция не позволяла. Через несколько лет мы планово заменили два из трех чиллеров (про это тоже будет увлекательная история, на этот раз без жертв), а на оставшемся срезали теплообменники фрикулинга. Сейчас на площадке OST работает 4 чиллера: два Stulz, Hiref (добавился, когда дата-центр подрос) и один старый Emicon.





Чиллеры на площадке OST в 2017 году.



Клиенты. Несмотря на этот кошмар эксплуататора, клиенты отнеслись с нашей беде с пониманием и даже никто от нас не съехал.



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



Оргвыводы



К таким форс-мажорам сложно подготовиться заранее, но важно из любой аварии сделать правильные выводы. Наши, добытые потом и кровью, были такими:




  1. В Москве тоже бывают ураганы. Это сейчас что ни день, то штормовое предупреждение, а тогда это было в новинку. После той аварии при выборе площадки или готового здания под ЦОД особенно тщательно смотрим, нет ли в опасной близости условных сараев и прочих хлипких строений. Конечно, крышу, которая прилетела на наши чиллеры, соседи перекрывали уже под нашим чутким контролем.




  2. Мы стали сами закупать ЗИП (вентиляторы, компрессоры, запас фреона и пр.) и хранить его у себя. Восстановление прошло бы быстрее, если бы у нас на площадке были хотя бы запасные вентиляторы. В тот раз поставку нужного количества пришлось ждать несколько недель.




  3. Волей-неволей разобрались в устройстве чиллеров, они перестали быть для нас “черными ящиками”. Это нам пригодилось впоследствии, потому что замечательные холодильные машины не перестали ломаться.




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




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




  6. Настроили удаленное управление чиллерами из центра мониторинга.




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




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



Еще мы с особым тщанием занялись проработкой всех ключевых процессов, задокументировали и сопроводили схемами все, до чего смогли дотянуться, и ввели регулярные боевые учения. И если завтра случится какой-нибудь армагеддон, наши ЦОДы будут спасать не 3,5 человека в жанре импровизации, а большая и опытная служба эксплуатации с четкими, отработанными инструкциями. Это позволяет нам не только управлять постоянно растущей сетью из семи дата-центров, но и успешно проходить аудиты и сертификации самых уважаемых и строгих организаций вроде Uptime institute.



А какие стихийные бедствия пришлось пережить вашей серверной/дата-центру и какие полезные выводы вы для себя сделали?


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333578/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Аудит ИТ-инфраструктуры — как быть новичку

Среда, 19 Июля 2017 г. 18:21 (ссылка)

Привет, %username%! Готов поспорить, что рано или поздно все сисадмины относительно небольших компаний сталкиваются с такой волшебной задачей от руководства, как составление проекта развития ИТ-инфраструктуры компании. Особенно если тебе предложили должность и сразу же попросили составить план развития и бюджетирования. Вот и мне однажды поставили такую задачу. О всех подводных камнях, с которыми можно столкнуться, я и напишу. Всем заинтересовавшимся велкам под кат!



Сразу поясню, что вы тут не найдете советов о том, какое оборудование выбирать для тех или иных решений, какие программные продукты выбирать, open source или платное ПО, с какими интеграторами общаться стоит, а с какими нет. Это все полностью индивидуально и будет напрямую зависеть от вас и того, что в итоге вы хотите — залатать дыры в текущем корыте или построить ИТ-инфраструктуру таким образом, чтобы любая задача сводилась к нажатию кнопки “СДЕЛАТЬ ХОРОШО” (да я ленивый).



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



Вот собственно примерный список проблем, с которыми можно столкнуться при проведении аудита ИТ-инфраструктуры:



1. Отсутствие тех, у кого можно хоть что-то спросить — именно такая проблема встала передо мной, когда руководство поручило провести аудит с целью улучшения инфраструктуры в целом. На тот момент я являлся самым старым сотрудником отдела компании и поинтересоваться мне было просто не у кого. По этой причине времени на ковыряние и попытку понять “за каким же это хреном сделано” было затрачено не мало, ведь пока я был простым сисадмином меня почти не посвящали в тонкости организации ИТ-инфраструктуры.



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



3. Отсутствие четкого (документированного) описания текущей инфраструктуры — увы (!) этого не было никогда ранее. Никто и никогда не составлял банальную карту сети офиса. Не описывал как организована связь между филиалами (коих более 10 штук по всей стране). Я уже не говорю про банальную маркировку кабелей на маршрутизаторах.



4. Полное отсутствие документации — вообще! Абсолютно никакой документации не велось в отделе никогда. И это категорически печально. Ведь банальные копии договоров (на телефонию, интернет, обслуживание 1С, аренду хостинга и прочее) хотя бы в электронном виде должны быть в отделе. И это одно из обязательных условий, ведь любой сотрудник отдела ИТ должен знать, к кому обратиться в случае если упал интернет в другом регионе (где время +3 к Москве).



5. Отсутствие общей базы паролей — все пароли были разные и менялись от случая к случаю. Весь этот ворох приходилось держать в голове, т.к. “все что записано однажды — может быть и считано”. Для того, чтобы предоставить новому сотруднику определенный доступ, необходимо переписать в почте (или на бумажке) все логины и пароли и передать их лично ему. А если ты еще не правильно пароль вспомнил… Ужас!



6. Отсутствие информации о том, как все организованно в регионах — имелась информация лишь о том, сколько там человек, кто руководитель и… всё! Т.е. имелась просто абстракция под названием “Региональное представительство в городе Мухосранске, где сидит 15 человек”. Никто никогда не задавался вопросом, как там устроена сеть, какие у нее слабые места, как происходит доступ сотрудников представительства в сеть Интернет, как организован доступ сотрудников к сетевым ресурсам центрального офиса.



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



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



А теперь подробнее о том, как я советовал бы преодолевать все трудности



Я не стану напоминать о том, что необходимо сделать инвентаризацию для того, чтобы понимать с чем работаешь, что является устаревшим, что можно заменить на более производительное. Это обязательное мероприятие. А вот о том, что после переписи всего оборудования надо все разделить всё на категории (активное сетевое, workstaion, bussiness-critical servers and service) напомню. При наличии доступа к административной панели сделать бэкапы конфигураций, описать “что”, “зачем” и “для чего” настроено в конкретной железке, переписать все сетевые адреса серверов, управляемых железок (да простят меня господа сетевики), сетевых хранилищ, принтеров и всего, что имеет доступ к сети (ну кроме рабочих станций).



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



Анализ железячной составляющей это одно из важных мероприятий. Необходимо понимать, насколько актуально на текущий момент времени используемое железо (как сетевое и серверное, так и пользовательские ПК). Обычно на этом этапе выясняется (с поддержкой от бухгалтерии, а так же коммерческих отделов), что вся bussiness-critical информация хранится в виде документов Excell на сервере, у которого жесткие диски работают уже третий гарантийный срок (!) и все удивляются тому, что “файлы по сети медленно открываются” и сам сервер шумит дисками как больной психиатрии стучащий ложкой по кастрюле. А сетевые железки сняты с производства еще за год до того, как их купили в компанию и по отзывам они ужасны. Или например wi-fi в офисе поднят на точках доступа, которые по всем отзывам считаются такой дрянью, которую врагу не пожелаешь.



Далее, необходимо оценить текущие серверные мощности



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



Виртуализируйте все!



Когда парк ваших серверов и сервисов достигает критической массы и вы вынуждены заходя в серверную смотреть, что это за систменик или тыкаться по KVM в поисках нужного сервера, то вам явно требуется виртуализация. Все системы, которые можно запустить на виртуалке необходимо перевести в виртуальную среду (всяческие СКУДы, сервер корпоративного портала, корпоративное облако, etc). Современных, а главное удобных инструментов для этого предостаточно (VMware, Proxmox, Xen, Hyper-V). Просто определитесь с тем, что вам нужно/нравится/можно купить и запускайте в работу.



Виртуализацию в топку! Даешь только хардвер!



Не виртуализируйте критичные вещи — такие как шлюзы, маршрутизаторы, VPN-сервера используемые для аварийного доступа в сеть, сервера 1С (тут в меня могу полететь тухлые помидоры). Важно здраво оценивать все факторы, руководствуясь которыми вы принимаете решение о том, что загонять в виртуальную среду, а что нет. Идеальных решений не существует.



Организация сетей между филиалами



Вопрос довольно обширный и имеет множество решений. От самого простого — выделять каждому удаленному сотруднику логин и пароль для VPN, дорогого — арендовать L2-сеть у одного провайдера и до безумного — наставить самых различных сетевых железок от разных вендоров, с помощью которых организовать доступ в сеть на местах и доступ к сетевым ресурсам внутри компании (сетевые хранилища и т.п.). Оцените все “за” и “против” и примите верное и лучшее решение в конкретно вашем случае. Для простоты и понимания “что делать” и “как делать” смело приглашайте системных интеграторов и консультируйтесь с ними. За спрос не дадут по шее, а дадут понять как можно решить одну и ту же проблему разными способами (дешево и дорого). Уже после пары-тройки таких встреч вы сможете более точно и более четко описать для себя самого все свои хотелки и возможные способы их решения.



После всех выше описанных работ можно приступить к составлению примерного бюджета. Для выбора конкретных моделей оборудования обращайтесь за помощью в специализированные чаты (сам использовал чаты в Телеграм, т.к. там всегда живой народ и больше шансов получить быстрый ответ; список можно загуглить). Все оборудование, которое вы выбираете рассчитывайте с запасом на перспективу и рост потребностей ваших прямых клиентов — сотрудников компании. Больше общайтесь с руководством на тему дальнейшего развития бизнеса компании. Возможно они сами вам подскажут ответ на то, на что вы не знали ответа.



Вместо заключения



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



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



И запомните две вещи:




  1. Идеальной инструкции не существует!

  2. Идеальной защиты не существует!



P.S.: На этом все. Жду ваших комментариев и здравой критики.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333732/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

От репозитория до CI/CD-инфраструктуры в продакшене за неделю

Среда, 19 Июля 2017 г. 14:47 (ссылка)

Обычно в термин «поддержка» вкладывают только один смысл — это реагирование на беды с хостингом, замена битых дисков, настройка веб-серверов и СУБД, общее повседневное администрирование. Но, на самом деле, это только первый уровень контроля стабильности работы любого интернет-проекта.



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



image



Вот такое:



image



И именно об этом пост — о безопасности и стабильности разработки и о том, какими системами и принципами их можно обеспечить. Или, если воспользоваться модными словами — о DevOps и CI/CD.







Зачем?



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



image



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



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



Именно для этого и были придуманы методология DevOps и CI/CD. CI/CD подразумевает наличие отдельной площадки под разработку, отдельного стейджинга и отдельного прода.



image



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



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



Обычно о таких вещах говорят больше в теоретическом ключе. Вот, мол, есть такая штука, как Docker. Тут у нас можно недорого делать контейнеры. Создавать, обновлять, откатывать, всё можно делать безболезненно, не задевая жизненно важные части родительской системы, при этом не загружая ненужными прослойками и сервисами. А потом в другой статье — а вот есть Kubernetes. Он может вставлять и вытаскивать docker-кирпичи в вашем проекте самостоятельно, без ручного вмешательства, просто опишите ему конфигу, как он будет работать. Вот вам три строчки из официальной документации. И в таком вот стиле почти все материалы. Я же хотел бы рассказать о том, как всё это происходит в реальной жизни, отталкиваясь от реальной задачи обеспечения механик безопасной и стабильной разработки.



О ком?



Рассказывать буду на примере сервиса Edwin, помогающего учить английский с помощью бота в Facebook Messenger. Бот @EnglishWithEdwin определяет ваш уровень английского с помощью теста и исходя из этого проводит для вас уроки прямо в мессенджере.



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



Нам же нужно было вникнуть в происходящее и организовать stage-/prod- площадки с возможностью комфортных выкладок обновлений и общего управления инфраструктурой.



Структура проекта



Как Edwin устроен изнутри? Ключевые слова — Python, PostgreSQL, Neo4j, RabbitMQ. Условно архитектуру можно разделить на три больших блока: транспортный, логический и аналитический.



image



В первом блоке — докеризированное приложение-рассыльщик, написанное на питоне, которое через Facebook Gateway получает сообщения из социальной сети, сохраняет их в базу данных и добавляет событие в очередь RabbitMQ.



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



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



Но всё это только предполагаемая структура, т.к. Edwin пришёл к нам, ещё не имея релизной версии проекта, в продакшене он ни разу не светился. Именно настройкой stage-/prod- окружения мы и должны были заняться.



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



Настройка CI/CD



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



Основа всей нашей системы — это docker-контейнеры с сервисами и бизнес-логикой. Контейнеры выбраны для большей универсальности и мобильности в управлении инфраструктурой. Самым популярным инструментом для жонглирования docker-контейнерами на данный момент является Kubernetes от Google (по крайней мере, он больше всех на слуху). Нам же он показался излишне замороченным и структурно переусложнённым, и потому требующим слишком много телодвижений для поддержания работоспособности (и слишком много времени на изначальное понимание). А т.к. сроки введения в строй всей системы CI/CD у нас были сжаты до минимума, мы решили поискать более простые и легковесные решения.



Для хранения шаблонов контейнеров было решено взять (на самом деле, даже не взять, а просто оставить уже выбранный до нас разработчиками) Amazon EC2 Container Registry. В целом, он мало чем отличается от собственноручно поднятого на локалхосте registry. В основном тем, что его не нужно собственноручно поднимать на локалхосте.



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



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



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



Когда серверы под контейнеры настроены, все нужные сервисы докеризированы, остаётся только понять, как организовать, собственно, «непрерывную интеграцию», не нажимая по 500 кнопок каждые полчаса. По итогу остановились на такой системе, как GoCD и небольшой скриптовой обвязке. Почему GoCD, спросите вы меня, а не Jenkins? Ранее, в других проектах, нам приходилось сталкиваться и с тем, и с другим, и по совокупности взаимодействий GoCD показался более простым в настройке, чем Jenkins. Есть возможность создавать шаблоны задач и пайплайнов, на основе которых потом можно генерировать разные производственные цепочки для разных окружений.



Процесс разработки



Понедельник, 6 февраля



Первый день выдался, в общем-то, спокойным. Мы, наконец, получили ТЗ на то, что должны были сделать.



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



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



На основе полученной информации пишем Ansible-рецепты и начинаем установку серверов для продакшена, заводим в Амазоне отдельный VPC, который бы не пересекался с уже имеющимся dev-окружением во избежание неосторожных действий при разработке. Разворачиваем контейнеры со всеми нужными сервисами — PostgreSQL, Neo4j, кодом проекта.



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



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



Вторник, 7 февраля



На отдельном сервере устанавливаем в базовом варианте деплой-панель GoCD и сервис-дискавери Consul.



Как я уже раньше упоминал, Edwin пришли к нам уже с готовой в какой-то степени инфраструктурой под разработку. Для жонглирования контейнерами они использовали Amazon ECS, он же EC2 Container Service. Что-то вроде Kubernetes-as-a-Service. После обсуждения с разработчиками пожеланий на тему будущей структуры проекта и работы с выкладками, было решено от ECS отказаться. Как и многие облачные штуки, он оказался недостаточно прозрачным для контроля происходящих внутри вещей, не хватало очень полезных в имеющейся ситуации вещей, типа задаваемых параметров окружения для одного и того же контейнера. Т.е. нет возможностей один и тот же контейнер использовать в разных пайплайнах, просто переопределив окружение. В амазоновой парадигме приходится создавать по отдельному контейнеру под каждое окружение (на примере сборщика логов можно показать).



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



Остаток дня занимаемся созданием и настройкой пайплайнов для продового окружения в GoCD — сборка кода, пересоздание контейнеров, выкатка новых контейнеров в прод, регистрация обновлённых сервисов в консуле.



Среда, 8 февраля



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



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



Удостоверившись, что всё работает как надо, настраиваем резервные репликации для баз данных в соседних Зонах Доступности, вместе с разработчиками заливаем рабочие данные в продовые базы данных.



Четверг, 9 февраля



Как я уже сказал, на этот момент, в общем-то, минимально необходимые элементы системы CI/CD у нас все установлены и настроены. Мы передаём разработчикам все данные по структуре получившейся системы, они со своей стороны приступают к тестированию всех механизмов сборки и выкладки проекта.



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



Логи решено собирать в Kibana — очень удобный интерфейс для разного рода аналитики. Мы неоднократно сталкивались с ней как на сторонних проектах, так и использовали у себя на внутренних проектах.



За несколько часов поднимаем Kibana, настраиваем сбор логов с сервисов, настраиваем мониторинги всех критичных сервисов на проде.



Пятница, 10 февраля



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



Результаты



image



Что мы получили в итоге? Модульную систему разработки проекта, состоящую из трёх этапов и окружений — dev, stage и prod. Весь проект разделён на отдельные микросервисы, для каждого из которых заведены свои пайплайны.



Когда разработчики выпускают новую версию, они идут в панель GoCD и просто запускают соответствующий пайплайн. Например «раскатать новый логгер на stage», тестируют там, проверяют, что всё работает как надо, потом раскатывают на прод. Если вдруг что-то пошло не так, то опять же, самостоятельно через панель откатывают нужный сервис до нужной версии.



image



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



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



Проблемы, с которыми столкнулись



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



Проблем подкинул Amazon Web Services, на котором хостится этот проект.



При настройке Consul’а столкнулись с интересным затыком. Агенты и доступы к ним прописываются в контейнерах через системные резолверы. Но AMI Linux, используемый Амазоном по умолчанию, несколько отличается от дефолтной CentOS, и работа с резолверами там вынесена в настройки сети Virtual Private Cloud (VPC). При перезапуске сервера Amazon принудительно прописывает свои резолверы. Принудить его не ломать настройки резолва консула у нас пока так и не получилось, к сожалению. Но chattr +i всех спас, так теперь и живём.



Вообще структура VPC и его сетей довольно интересна, и там можно наткнуться на ограничения в очень неожиданных местах. Например, application balancer можно создать только мультизоне доступности, то есть бэкенды должны находиться сразу в нескольких разных availability zones. Для этого у VPC network должна быть разбивка, чтобы там присутствовали адреса в private/public и одной зоны, и другой. А менять разбивку VPC network можно только при создании. И менять VPC у инстансов тоже можно только при создании.



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



Выводы и планы



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



Хотя, конечно, многие могут сказать: «Ага-ага, они десять лет поддерживают проекты типа Хабрахабра и Нашего Радио, а нам тут разглагольствуют про простоту!». Да, действительно, на нашем веку мы видели много разного. И, возможно, как раз это и помогает нам отличать простое от сложного и не наступать на слишком большое количество граблей. Но опять же, если в самом начале разумно подойти к поставленной задаче и правильно подобрать инструменты, не гонясь за «крутостью», то можно значительно облегчить себе жизнь.



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



Какие у нас дальнейшие планы по проекту?



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



Также, похоже, приближается момент, когда нужно будет настраивать автоскейлинг на основных рабочих нодах, т.к. их общее количество постоянно растёт, и экономия на количестве активных серверов в часы минимальной нагрузки поможет сократить затраты.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333650/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_aif_news

Номер на бис. Необычные отели Москвы, которые примут гостей ЧМ-2018

Вторник, 19 Июля 2017 г. 00:21 (ссылка)

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

http://www.aif.ru/sport/structure/nomer_na_bis_neobychnye_oteli_moskvy_kotorye_primut_gostey_chm-2018

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<инфраструктура - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda