Не работает поиск «Search Inventory» в клиенте VMware

При попытке поиска в окне Search Inventory выпадает окно

Это происходит в том случае, если осуществлён вход с отметкой «Use Windows session credentials».

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


VMware: Невозможно выключить или перезагрузить виртуальную машину

Сегодня столкнулся с тем, что внешне подвисшая виртуальная машина (остановились VMware Tools) отказывалась перезапускаться. Команда Reset валилась по таймауту (как с vCenter, так и напрямую с хоста ESXi), попытки погасить её по питанию тоже не приносили успеха.

В логах появлялось примерно следующее:

Приходится применять «низкоуровневую» магию — консоль. На это есть несколько способов.

1. esxcli

1. Получаем список запущенных виртуальных машин

при этом вывод будет следующим:

Имя ВМ и её идентификатор (World ID) в первой и второй строчках соответственно

2. Выключаем ВМ командой

WorldNumber — это World ID, в типе выключения использовал force, так как уже всё равно.

3. Проверяем первой командой, что ВМ выключилась (вывода по ней быть не должно). Дальше можно запустить ВМ обратно штатными средствами.

2. vim-cmd

1. Получаем список виртуалок

Вывод команды следующий:

2. Узнаём статус работы нужной ВМ

Вывод команды:

3. Выключаем ВМ (первый способ мягкий, второй — жёсткий)

3. kill

Применяем стандартную *nix утилиту kill

1. Получаем список процессов с виртуальными машинами

Вывод команды примерно следующий:

В этом выводе нам нужно второе число (в моём случае 8816107), которое указывает на родительский процесс vmx

2. Посылаем в процесс приказ завершиться

В моём случае это

3. Если в течение 30 секунд ВМ не завершила работу, то убиваем её с особым цинизмом


Проектирование хостов: горизонтальное или вертикальное масштабирование?

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

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

  • Рэковое исполнение или блэйд?
  • Количество процессорных сокетов на хост?
  • Количество ядер на сокет?
  • Гигагерцы на ядро?
  • Гигабайты оперативной памяти на домен NUMA (сокет)?
  • Потребление электричества на шасси/хост/сокет/ядро/гигагерц/планку памяти/домен NUMA?
  • Стоимость шасси/хоста/сокета/ядра/гигагерца/планки памяти/домена NUMA?
  • Ограничения NUMA?
  • Плюсы от Hyper-Threading?
  • Домены отказа в рамках шасси/рэка/стойки/датацентра?
  • Гиперконвергентные вычисления? – необходимо помнить о сети и хранении данных

Следующий вопрос: «Как сделать правильный выбор? Какие инструменты необходимо использовать?»

Для начала ответьте на следующие вопросы:

  • Какой профиль нагрузки? (равномерная или пиковая) – необходимо собрать как минимум два месяца данных по загрузке в дневном, недельном и месячном циклах. Используйте VMware Capacity Planner или Microsoft Accessment and Planing Toolkit.
  • Какой бюджет? – Это ограничение может напрямую конфликтовать с требованиями по нагрузке.
  • Существуют ли в датацентре ограничения по площади/питанию/охлаждению?
  • Какой требуется уровень защиты (на примере vSphere HA – N+1, N+2 и т. д.)
  • Какой процент закладывать на перегрузку, будущий рост и риски миграции?

Зависимость от процессорной загрузки показывается на этой картинке:

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

  1. Соотношение vCPU к pCore – этот параметр обычно используется для предварительного подсчёта количества необходимых хостов. Обычно принимаются значения от 1 до 12- в зависимости от рекомендаций вендора. Максимальное соотношение для vSphere 5.5  и 6.0 — 32. Рекомендуемое — 5-8. Это только процессорное распределение и оперативная память не учитыается.
  2. Пиковое количество гигагерц.
  3. Пиковое потребление памяти.

Формулы представлены ниже. Значение «избыточность» — это количество хостов, запланированных под отказ.


Обратите особое внимание на документ Configuration Maximums для vSphere; нет смысла проектировать 40 гипервизоров на кластер, если ограничение — максимум 32, или 7000 виртуальных машин на кластер, если больше 4000 невозможно.

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

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


Стратегия расширения СХД

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

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

  • Традиционные полноценные (монолитные) общие хранилища
  • Ускорение Flash-Cache на стороне сервера
  • Расширяемые NAS
  • Конвергентная инфраструктура
  • Гиперконвергентная инфраструктура

Традиционные общие хранилища

99% всех людей, кто связан с СХД, едут на этом танке. Единый дисковый массив SAN от IBM, Hitachi или EMC, подключенный через Fiber Channel к вашей отказоустойчивой фабрике SAN и следом к серверной инфраструктуре vSphere через избыточные отказоустойчивые HBA. Если у вас больше одного массива, то второй более чем вероятно будет старше первого, так как в первую очередь мы говорим о капитальных инвестиция, совершаемых с частотой около трёх лет. Плюшки по типу федерации хранилищ, автотиеринга и глобального кэша — то, что входило в вашу последнюю закупку.

Основные вендоры: EMC, IBM, Hitachi, Brocade, QLogic и т. д.

Ускорение Flash-Cache на стороне сервера

Если вы уже один раз вложились в хранилище SAN, то флэш-ускорение на серверной стороне (уровня гипервизора или гостевой ОС) может существенно продлить жизнь вашей инфраструктуре. Учтите, флэш-ускорение может быть внедрено только после анализа и разработки, но не в попытках поиска «волшебства» в затыкании слабых мест.

Вендоры: VMware vFRC, PernixData FVP, EMC XtremSF/XtremCache и т. д.

Заметка: Как альтернативу, стоит попробовать оптимизацию чтения/записи внутри гостевой ОС, например Condusiv V-locity

Расширяемое хранилище NAS

В последнее время производители недорогих хранилок NAS стали начинять их скоростными дисками SAS и SSD. Идея состоит в том, чтобы изначально купить достаточное количество нод NAS и прикрыть первичные требования, а потом докупать ноды по мере роста. Плюсы состоят в том, что вместо инвестиций в Fiber Channel просто задействуются свободные порты 10 Гб.

Также необходимо отметить, что VMware внедрила поддержку протокола NFS v4.1. Не забываем, что Microsoft выдаёт отличные показатели с SMB 3.0 на Hyper-V.

Вендоры: NetApp, IBMHP, EMC и т. д.

Конвергентная инфраструктура

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

Вендоры: NetApp FlexPod, VCE vBlock, HP ConvergedSystem, Dell и т. д.

Гиперконвергентная инфраструктура

Физические рэковые серверы с массивами JBOD (“Just a Bunch Of Disks”, «Просто набор дисков»), где общее хранилище с отказоустойчивостью, репликацией и тиерингом организуется программно. Если ваша политика подразумевает использование исключительно блэйд серверов, то для гиперконвергентной инфраструктуры придётся изменить её на закупки рэковых серверов.

Несколько интересных фактов о гиперконвергентных вычислениях:

  • Управление, DMZ и подобные сегменты в идеале требуют физической изоляции для безопасности и соответствия требованиям. Обычно мы разделяем их на логическом уровне (VLAN), но любой аудитор безопасности будет требовать именно физического разделения.
  • VDI (инфраструктура виртуальных рабочих столов) – гиперконвергенция и VDI идеально подходят друг другу.

Стратегия построения датацентра


Картинка для затравки

 

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

  • Публичное облако – Вы не заботитесь об обустройстве датацентра, это сделали за вас. Фактически вы доверяете сторонней компании в предоставлении вам услуг за плату. Плюс: уменьшение капитальных вложений и операционных расходов, уменьшение времени внедрение. Минус: Время на миграцию данных и сервисов, возможные проблемы с сопровождением и совместимостью.
  • Гибридное облако – У вас есть существующая инфраструктура разного типа и, вместо того, чтобы расширять её, вы используете сервис гибридного облака (например IaaS, SaaS, PaaS, DaaS) и подключаете вашу организацию через IPSec VPN (Site-to-Site) или SSL VPN (User-to-Site).  Плюсы: Сохранение контроля надо основным сайтом, уменьшение капитальных вложений и операционных расходов. Минусы: Время на миграцию данных и сервисов, возможные проблемы с сопровождением и совместимостью.
  • Колокейшн (совместное размещение) – Вы арендуете рэковые места или стойко-места в датацентре провайдера, отвечающего за фабрику; вам необходимо только установить активное оборудование на место и управлять им. Плюсы: уменьшение капитальных вложений, уменьшение времени внедрения, датацентр с его инженерными системами не ваша головная боль. Минусы: вы не владеете датацентром, увеличение операционных расходов.
  • Полный цикл – Вы строите датацентр полностью по вашему проекту и целиком удовлетворяющий вашим требованиям. Плюсы: это ваша собственность, уменьшение операционных расходов. Минусы: увеличение капитальных вложений, увеличение времени на проектирование, заказ, строительство и внедрение, ограничения по пространству/экологическим требованиям.
  • Существующий ЦОД в существующем здании– Вы имеете или покупаете здание, где уже есть датацентр. Плюсы: это ваша собственность, уменьшение операционных расходов, возможность расширения, уменьшение времени внедрения. Минусы: увеличение капитальных вложений, непрогнозируемое время на поиск и покупку.
  • Модульный ЦОД – У вас есть некоторый участок с охраняемым периметром, производитель поставляет модульный датацентр, построенный из стандартных морских контейнеров, по необходимости. Вы их размещаете и стыкуете вместе словно кубики Лего. Плюсы: это ваша собственность, мобильность/модульность/масштабируемость, уменьшенные операционные расходы, уменьшенное время внедрения. Минусы: увеличение капитальных затрат, время на заказ и доставку.

 

Основные вопросы:

  • Обслуживание и совместимость – Имеете ли вы доступ к оборудованию вашего заказчика? Как обеспечивается совместимость систем?
  • Стоимость внедрения и стоимость обслуживания (капитальные и операционные расходы) – Разовые инвестиции или рассрочка/лизинг? Каков ваш бюджет?
  • Время на внедрение – Здесь и сейчас или годы проектирования и управления проектом? Есть время подождать или это срочный заказ бизнеса?
  • Метод внедрение – “Быстрое решение” или “Длительное внедрение”? Проекты, подразумевающие длительное и поэтапное внедрение с подрядчиками и субподрядчиками всегда подразумевают риск срыва сроков.
  • «Зелёная» энергетика – Имеются ли требования по выбросам, классу энергопотребления и т. д. Возможно стоит рассматривать построение датацентра в холодной климатической зоне.
  • Расположение – Окраины города с двумя электрическими подстанциями, множественные подключения к провайдерам, удалённость от трасс, в том числе воздушных, отсутствие исторических данных по природным или антропогенным катаклизмам и т. д.

 

Компоненты ЦОД:

  • Уровень рейтинга института Uptime – Tier-1 или Tier-4? Ориентировочно $100K на сертификацию.
  • Электропитание – ИБП 1+1, ИБП N+1 или интегрированное решение (генератор и ИБП как единое решение), внешние генераторы, ячейки питания, расстояние от подстанции.
  • Полы – Есть фальшпол или нет? С постоечным охлаждением фальшпол не нужен. Также необходимо учитывать климатическое оборудование при стресс-тестах.
  • Метод охлаждения – Компрессор или чиллер? Компрессор используется для малых или средних датацентров, чиллер более сложен, но масштабируется на большие решения.
  • Охлаждение – «Традиционное» с фальшполами (необходимо организовывать «горячие» и «холодные» коридоры. Активное оборудование забирает холодный воздух из «холодного» коридора и отдаёт нагретый воздух в «горячий» коридор. Или же использование индивидуального охлаждения каждой стойки.
  • Разводка кабелей питания и данных – Под полом или в каналах над стойками?
  • Мониторинг – Видеонаблюдение, энергоснабжение, температура, влажность, детекторы протечек, детекторы дыма (как часть системы пожаротушения).
  • Система пожаротушения – Выбор системы автоматизации. Раздельная система автоматизации на каждое помещение в ЦОДе?
  • Физическое размещение – Единый машинный зал с рядами стоек или раздельные функциональные помещения (ИБП, генератор, серверы, СРК, безопасность, сетевая часть, ISP/DSP, и т.д.). Резервирование площади под плановый рост (10 лет, 20 лет)?
  • Физическая безопасность – Система блокировок на дверях и стойках. В масштабах датацентра – периметр, подземная часть, доступ к инфраструктурному и инженерному оборудованию, доступ операторов.

 

В догонку 

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

План внедрения

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

Стандартно План проекта «101» выглядит так:

  • Старт проекта
  • Определение требований – Что хочет заказчик? В чём заказчик нуждается?
  • Фаза проектирования – Разработка Архитектурного проекта и Сопровождающей документации
  • Проверка проекта – Пересмотр ключевых моментов, построение тестовой среды, оценка бюджета, запрос цен и т д.
  • Заказ по спецификации – Поставка оборудования (в случае необходимости) должна занимать 4-8 недель (в зависимости от расположения) и Программного обеспечения в течение недели (лицензионные ключи и активация поддержки; большинство программных продуктов можно скачать в любое время).
  • Сопутствующая инфраструктура – инфраструктура, не входящая в vSphere, но взаимодействующая с ней (AD, DNS и т. д.)
  • Обучение персонала – (если необходимо)
  • Конфигурирование – Построение системы по Руководству по конфигурации
  • Тестирование – Функциональное, Интеграционное, Соответствия и Производительности, все тесты согласно Плану тестирования
  • Первичный запуск – Проверка работы стандартных операций и запуск пилотной группы пользователей
  • Пусковая инженерная поддержка – Полная поддержка в течение нескольких месяцев с момента запуска (при необходимости)
  • Запуск – Всё проверено и соответствует требованиям заказчика
  • Миграция – конвертация P2V, миграция V2V (при необходимости)
  • Завершение проекта

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

После того, как вы закончите ваш проект, вы найдёте трещины и недостатки (ваша «поверхность атаки»), так как идеального проекта не существует. Значительная часть вашей работы до полноценного внедрения – это поиск и устранение всех недостатков в процессе Конфигурации, Тестирования и фазы Первичного запуска. Причина, по которой мы занимаемся тестированием и первичным запуском – это необходимость удостовериться в том, что наш проект соответствует требованиям заказчика и получить отклик от пользователей о любых существующих проблемах.

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

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


Матрица решений

Одно из постоянных требований при разработке дизайна информационных систем – постоянный контроль и измерение того, как хорошо вписывается ваш Логический и Физический дизайн в требования заказчика. Это одна из причин, почему необходимо начинать работу с чистого листа и не использовать никаких шаблонов и наработок – они могут повлиять на фундамент процесса.

Основной посыл: сначала закончите Концептуальную модель, потом Логический дизайн и только после этого работайте над Физическим дизайном.

 

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

  • R01 – Все критично важные приложения должны иметь SLA в 99.99%
  • R02 – Не должно быть единой точки отказа
  • R03 – И т. д.
  • C01 – У заказчика есть два датацентра, которые необходимо использовать. Между ними 300 км.
  • C02 – Необходимо задействовать существующую СХД Вендора А Модель Б. Заказчик только закончил расширение и апгрейд инфраструктуры хранения данных.
  • C03 – И т. д.
  • A01 – Существующая СХД даст заказчику запаса по ёмкости на три года.

 

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

  • Опции решения в Логическом дизайне: Протоколы СХД могут быть FC, FCoE, iSCSI, NFS или DAS
  • Решение Логического дизайна SLDC01: Протокол СХД будет Fiber Channel
  • Ссылки на требования: R01, R02, C02
  • Конфликты требований: Нет
  • Уточнение: У заказчика есть единая СХД на Fiber Channel, которую необходимо использовать
  • Последствия: Требуются две SAN-фабрики, на каждом хосте должно быть по два HBA
  • Риски: Каждый хост vSphere имеет ограничение на 255 уникальных LUN и каждый датастор vSphere может иметь максимальный объем 64TB

 

Соответственно, необходимо создавать индексы для решений в Логическом дизайне. Вычисления – CLDCxx, Сеть – NLDCxx, СХД – SLDCxx, Резервное копирование/восстановление – BRLDCxx, Безопасность – SECLDCxx и т. д.

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

  • Опции решения в Физическом дизайне: СХД должна быть произведена вендором, поддерживающим FC, FCoE, iSCSI, NFS или DAS
  • Решение Физического дизайна SPDC01: СХД Вендора А Модель Б подходит
  • Ссылки на требования: SLDC01 (Внимание: здесь мы не указываем R01, R02 или C02, так как это уже упомянуто в SLDC01)
  • Конфликты требований: Нет
  • Уточнение: У пользователя есть СХД Вендора А Модель Б, которую можно задействовать на ближайшие три года.
  • Последствия: Общее хранилище уровня предприятия, отказоустойчивые управляющие модули СХД, RAID-1/0, RAID-5 и RAID-6 доступны, Meta-LUN требуется для больших СХД.
  • Риски: СХД Вендора А Модель Б приближается к дате EOL (End of life), о чём недавно вышел анонс. Заказчику необходимо иметь стратегию миграции на более новую СХД в следующем цикле апгрейда.

Также как и в Логическом дизайне, в Физическом дизайне необходимо иметь набор индексов: Вычисление – CPDCxx, Сеть – NPDCxx, СХД – SPDCxx и т. д.

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


Эта таблица демонстрирует иерархическое соответствие:

  • Решений Логического дизайна и Концептуальной модели
  • Решений Физического дизайна и Концептуальной модели

Любой текст, помеченный красным – конфликт проектирования и должен быть устранён.

Концептуальная модель Решения Логического дизайна

(#, секция, страница #, пункт)

Решения Физического дизайна

(#, секция, страница #, пункт)

Кол-во
R01 (критичный SLA 99.99%) SLDC01, 1.1.1.1, 1, протокол СХД FC 1
R02 (нет единой точки отказа) SLDC01, 1.1.1.1, 1, протокол СХД FC 1
R03 (и т. д.) 0
C01 (Два ДЦ – 300 км) 0
C02 (СХД Вендора А Модель Б) SLDC01, 1.1.1.1, 1, протокол СХД FC 1
C03 (и т. д.) 0
A01 (Три года у СХД Вендора А Модель Б) 0

 

Эта таблица демонстрирует иерархическое соответствие:

  • Решений Физического дизайна и Решений Логического дизайна

Любой текст, помеченный красным – конфликт проектирования и должен быть устранён.

Решения Логического дизайна

(#, секция, страница #, пункт)

Решения Физического дизайна

(#, секция, страница #, пункт)

Кол-во
SLDC01, 1.1.1.1, 1, протокол СХД FC SPDC01, 1.1.1.2, 2, СХД Вендора А Модель Б 1

 

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

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

 


Пропорции и баланс

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

 

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

Примерные доли в дизайне инфраструктуры виртуализированного ЦОДа уровня предприятия:

  • Цели бизнеса (нетехнические и переданные вам самим заказчиком) – 4 to 5
  • Клиентские запросы10 to 20
  • Ограничения дизайна – 5 to 10
  • Допущения дизайна – 5 to 10
  • Логический дизайн – 50 to 60
  • Физический дизайн – 100 to 120

Плохие пропорции

“Перевёрнутая пирамида” – у вас сотни частей бизнес-целей, клиентских запросов, ограничений и допущений дизайна в Концептуальной модели, и всего лишь несколько пунктов решений в Логическом и Физическом дизайнах. Нет никакого способа соотнести такой дизайн с требованиями заказчика.


“Прямоугольник” – каждый слой находится в соотношении 1:1 между Концептуальной моделью, Логическим и Физическим дизайнами. Можно создать дизайн с сотнями элементов на каждом уровне, но это будет совершено немасштабируемо и очень сложно к прочтению, пониманию и обновлению.

Поле возможностей

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


Примеры

  • Цели бизнеса: Уменьшить расход капитала, уменьшить операционные издержки, увеличить гибкость бизнеса, уменьшение времени выхода на рынок
  • Пользовательские запросы: Нет единой точки отказа, автоматизированные операции, оптимальные быстродействие и масштабируемость, четыре девятки доступности
  • Ограничения дизайна: Пользователь отдаёт предпочтению ВендоруХ, должен быть использован последний стабильный выпуск обновления вендорского софта/прошивок
  • Допущения дизайна: Датацентр имеет достаточно площади, питания и охлаждения
  • Логический дизайн: СХД по технологии IP, фабрика LAN построена по технологии дерева
  • Физический дизайн: Вендор А, Продукт В будет использован для СХД, Вендор Х Продукт З для построения сети передачи данных
  • Конфигурационные настройки: Таблица с настройками СХД, презентующий NFS для гипервизора

 


Хороший логический дизайн

Энтерпрайз-архитекторы в целом инстинктивно понимают разницу между Концептуальной моделью (требования, ограничения и допущения) и Физическим дизайном (вендор АБВ, продукт А с настройками Х). К сожалению, большинство архитекторов испытывают трудности с Логическим дизайном, так как он абстрактен и лежит в теоретической плоскости. Подавляющая масса энтерпрайз архитекторов продолжительное время работают с одним вендором, поэтому дизайн строится относительно этого вендора, его продуктов и функций, предоставляемых продуктами. Тем не менее, Логическая модель должна быть независима от вендора.

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

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

Хороший логический дизайн позволяет вам позже сменить вендора.

Когда вы смотрите на Логический дизайн, спросите себя, можете ли вы отдать его пресейл-менеджеру абсолютно любого вендора для разработки конкретного технического решения (Физического дизайна)?

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

Пример плохого Логического дизайна (были предварительно выбраны решения VMware vSphere/View, HP ProLiant, Windows Server 2012 R2 и Oracle 12c):

  1. Три или более хоста ESXi требуются для кластера HA/DRS
  2. Будет использована технология vSphere HA для защиты от отказа уровня хоста и виртуальной машины
  3. Будет использована технология vSphere DRS для балансировки рабочей нагрузки в каждом кластере ESXi
  4. Отдельный сервер vCenter будет использован для инфраструктуры View
  5. Хосты кластера ESXi на серверах HP ProLiant DL 360 G9 должны быть установлены в различных стойках
  6. vCenter должен быть установлен на Windows Server 2012 R2
  7. vCenter должен использовать Oracle 12c Enterprise Database
  8. vSphere будет работать с СХД только по Fiber Channel

По факту мы видим Физический дизайн маскированный под Логический дизайн.

Переписанный хороший Логический дизайн (даём шанс всем вендорам):

  1. Три или больше хоста гипервизоров требуются для вычислительного кластера
  2. Механизм защиты рабочей среды уровня гипервизора должен предоставлять возможность перезапуска виртуальной машины в случае отказа хоста, виртуальной машины, приложения в виртуальной машине
  3. Средство управления виртуальной инфраструктурой должно предоставлять механиз балансировки ресурсов в кластере гипервизоров для оптимизации использования ресурсов CPU, RAM, сети и системы хранения данных
  4. Должны использоваться раздельные средства управления виртуальной инфраструктурой для инфраструктуры виртуальных рабочих столов и серверной виртуализации
  5. Кластеризованные хосты виртуализации должны быть распределены по разным шасси блейд-серверов и/или рэковых серверов, расположенных в разных стойках
  6. Средство управления виртуальной инфраструктурой может быть виртуальным модулем или пакетом приложений на существующей гостевой операционной системе
  7. Средство управления виртуальной инфраструктурой может использовать внутреннюю или внешнюю базу данных
  8. Хост виртуализации должен поддерживать блочную или IP систему хранения данных

Восстановимость и доступность

В дизайне инфраструктуры существуют пять показателей : Доступность, Управляемость, Быстродействие, Восстановимость и Безопасность. В этой статье рассматриваем то, как Восстановимость затрагивает Доступность.

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

 

Эта диаграмма поможет нам во время чтения статьи. Вы также можете нарисовать подобную картинку на основании своей инфраструктуры.

VCDX Availability ExplainedДоступность

Бизнес хорошо понимает термин «девяток доступности», которые отражаются следующим образом:

  • Две 9 – 99% = 3.65 дня простоя в год (просто достижимо, менее интересно)
  • Три 9 – 99.9% = 8.76 часа простоя в год
  • Четыре 9 – 99.99% = 52.6 минуты простоя в год
  • Пять 9 – 99.999% = 5.26 минуты простоя в год (трудно достичь, очень круто)

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

Второе, что нам необходимо понять, SLA действует только в рабочее время бизнеса (например, с 9:00 до 18:00) или  24×365?

Плановое окно простоя

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

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

Анализ потерь бизнеса (BIA)

Анализ потерь бизнеса позволяет посчитать стоимость простоя сервиса (в час) и позволяет перевести бизнесу потерю сервиса в понятные риски при нарушении SLA. В отличие от «девяток доступности» это более точно и технически проще для использования в рамках отражения каждого сервиса:

  • RPO – Recovery Point Objective — Точка отката: Определяет максимальный возраст данных, на которые возможно откатиться в случае аварии.
  • RTO – Recovery Time Objective — Время на восстановление: Определяет максимальное время, требуемое для восстановления данных.
  • WRT – Work Recovery Time — Время запуска сервисов: Определяет необходимое время для запуска сервисов после восстановления в стостояние способности обслуживать производственные запросы.
  • MTD – Maximum Tolerable Downtime — Максимальное время отказа: Сумма RTO и WRT, которая определяет полное время, необходимое для работ по восстановлению систем от отказа до полного запуска бизнес-процессов.

Если переводить девятки доступности в RPO, RTO, WRT и MTD, мы получим нечто вроде этого:

  • Две 9 – 99% = RPO 24 часа / RTO 24 часа / WRT 12 часов / MTD 36 часов
  • Три 9 – 99.9% = RPO 8 часов / RTO 6 часов / WRT 2 часа / MTD 8 часов
  • Четыре 9 – 99.99% = RPO 15 минут / RTO 40 минут / WRT 10 минут / MTD 50 минут
  • Пять 9 – 99.999% = RPO 5 минут / RTO 3 минут / WRT 2 минут / MTD 5 минут

От чего мы защищаемся?

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

  • Единая точка отказа (железо или софт) – отказ внутри датацентра, который нормально защищается механизмами вроде высокой доступности (High Availability), кластеризации приложений (Application Clustering), кластеризации баз данных (Database Clustering) и балансировкой нагрузки (Load-balancing).
  • Отказ сайта – основной датацентр становится полностью неспособным обслуживать запросы (природные катаклизмы, человеческий фактор и т. д.).
  • Случайное удаление данных – администратор непреднамеренно портит базу данных, диск, хранилище данных и т. д., которые могут не реплицироваться на удалённый сайт.
  • Намеренное удаление данных – администратор целенаправленно повреждает критические данные и системы, которые реплицируются на удалённый сайт. Этот случай наиболее тяжёлый в плане защиты и восстановления.

Расписание резервного копирования

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

  • Образ системы– полная консистентная копия всей гостевой операционной системы (файл vmdk или весь том NFS/Meta-LUN).
  • Уровень приложения – посредством агента резервного копирования внутри ОС
  • Уровень базы данных – посредством агента резервного копирования внутри ОС
  • Файловая система – полная консистентная копия части гостевой операционной системе (агент резервного копирования внутри ОС).
  • Запись логов БД– отдельный сервер баз данных, настроенный на захват логов.

Время восстановления

Необходимо представлять, сможете ли вы восстановить данные, удерживая RPO в рамках RTO:

  • Образ системы – может занимать секунды.
  • Уровень приложения – может занимать минуты.
  • Уровень базы данных – должно занимать минуты.
  • Файловая система – должно занимать минуты.
  • Воспроизведение логов БД – должно занимать минуты.
  • Переключение на другой сайт – должно занимать минуты или часы в зависимости от уровня автоматизации.

Если у вас четыре или пять девяток доступности, необходимо быть сильно уверенным в том, что использование логирования БД способно уместиться в RTO (через воспроизведение логов после восстановления БД). В этом случае поможет уменьшение промежутков между резервными копиями.

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

Runbook

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

Сложность управления

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

Доступность сервисов

Убедитесь в том, что вы сконфигурировали время жизни записей DNS (DNS Time-To-Live (TTL)) и глобальный межсайтовый балансировщик корректно. В частности, DNS TTL должна быть меньше периода RTO.