Нередки случаи, когда современная компания тянет за собой шлейф из доставшейся в наследство физической инфраструктуры с устаревшим оборудованием, обновлять которое дорого, выбрасывать жалко, а работать совсем небезопасно. Рано или поздно встает вопрос: как быть дальше, в каком направлении двигаться? Порой часть инфраструктуры оставляют как есть, а основные вычислительные мощности переносят на площадку хостинг-провайдера. Практика показывает, что такой подход экономически целесообразен и в целом достаточно эффективен. В подобных случаях возможны различные сценарии. Остановимся подробнее на примере одного из наших клиентов.
Предпосылки проекта
Речь пойдет об одной из крупнейших сетей автосалонов в России, пожелавшей остаться инкогнито. Поэтому не будем использовать имен собственных, а расскажем о том, как живется подобным компаниям, какие технологии они используют и с какими трудностями сталкиваются. Крупный бизнес диктует свои требования к решению задач: это и автоматизация процессов внутри организации, и возможность быстро и оперативно решать возникшие вопросы и обрабатывать заявки пользователей, и многое другое.
Рассматриваемая нами компания занимается продажей и обслуживанием автомобилей, оказывает целый ряд сопутствующих услуг, при этом все основные задачи решаются средствами аутсорсинга и современных облачных технологий. А ведь всего каких-то десять лет назад, когда компания только начинала свою деятельность, мало кто говорил про облака, да и аутсорсинг в ИТ лишь начинал приобретать едва обозримые очертания. Тогда компания ограничивалась одной точкой, десятком сотрудников и серверной комнаткой с несколькими выделенными «железками», где суровые админы решали все задачи самостоятельно.
Но поскольку в нашей стране автомобиль не роскошь, а средство передвижения, число желающих стать автовладельцами постепенно росло. Появилась явная потребность в дополнительных вычислительных мощностях, сервисах и прочих технических моментах. Поэтому руководители компании приняли решение модернизировать ИТ-инфраструктуру в соответствии с актуальными потребностями бизнеса. Было запланировано закупить новое оборудование и развернуть частное облако с использованием технологии виртуализации VMware, поскольку по всем техническим характеристикам именно она покрывала все имеющиеся на тот момент запросы компании. Так и было сделано, причем все работы по-прежнему выполнялись силами собственных инженеров.
Но железо имеет тенденцию устаревать и закупленное на миллионы оборудование может утратить актуальность буквально за несколько лет. С этой проблемой столкнулась и сеть автосалонов. Постоянная гонка за новым и лучшим по силам далеко не всем компаниям. Да и нужна ли она? Куда проще арендовать стойку у надежного поставщика. Покупая услугу Collocation, клиент забывает о многих проблемах — от вечной гонки за новым железом до поддержки и сопровождения самого оборудования. Вот руководство и задумалось об аренде оборудования у надежного хостинг-провайдера. Ведь это намного выгоднее, чем самостоятельно содержать парк серверов. А для разгрузки собственных ИТ-специалистов и высвобождения дополнительного времени на более важные задачи большую часть сервисов лучше перенести в облако, к тому же это позволит наращивать или уменьшать объемы вычислительных ресурсов в соответствии с потребностями.
Случай, когда организации понадобилось вынести в облако необходимые для бизнеса сервисы, далеко не первый. В одной из статей мы уже затрагивали тему IaaS в ритейле, в которой рассказали об опыте использования облачных решений сетью магазинов игрушек Hamleys. Здесь же специфика задач несколько иная.
Расчет необходимых ресурсов
Любые проекты, не важно — маленькие или большие, — связанные с локальной или облачной инфраструктурой, требуют планирования, предварительных расчетов, анализа ситуации и четкого понимания задачи. При переезде в облако необходимо заранее продумать и решить многие вопросы, включая расчет необходимых ресурсов. Ведь если их будет недостаточно, возникнет ряд проблем, связанных с производительностью, временем отклика приложений и работой критически важных сервисов.
В случае с рассматриваемой организацией вопрос переезда в облако упрощался тем, что компания имела рабочие серверы и развернутую виртуальную инфраструктуру на базе VMware. Оставалось лишь осуществить переезд из частного облака в публичное, причем требования к ресурсам сохранялись прежними. Имея статистику по показателям потребляемых мощностей и располагая информацией о требуемой производительности, даже не пришлось прибегать к «лучшим практикам» и инструментам Capacity planning.
Переезд в облако
Поскольку организация решилась на переезд из собственного частного облака на базе VMware в публичное облако ИТ-ГРАДа, было решено там же сосредоточить основные вычислительные мощности. Под свой личный контроль оставили только контроллер домена и несколько сервисов в виде DNS, DHCP.
Аренда оборудования понадобилась для самостоятельного накатывания виртуализации поверх железа провайдера, где были задействованы три типовых, стандартных сервера. Воспользовавшись услугой Collocation, компания сняла с себя вопросы, связанные с поддержкой, обслуживанием и оперативной заменой оборудования в случае необходимости.
И еще один маленький нюанс: в силу того, что основная работа сотрудников автосалонов сводится к активному использованию порталов дистрибьюторов через веб-браузер, им приходится открывать множество вкладок, обрабатывая огромное количество запросов. Вся информация при этом должна сохраняться в базе данных MS SQL, что требует достаточного места для хранения. Все это тоже было учтено при переезде. Также требовалось организовать и обеспечить качественную работу бухгалтерии. Поэтому было принято решение размещать серверы 1С на выделенной площадке поставщика. Такой подход обеспечил безопасную удаленную работу в программе 1С.
Терминальная ферма как основной потребитель облака
Поскольку терминальная ферма Citrix XenApp 7.6 изначально была развернута в частном облаке компании, при переходе в облако провайдера решили сохранить все как есть. То есть сотрудники по-прежнему используют привычный тонкий клиент HP, подключаясь к терминальной ферме. Единственное, что расположена она теперь не в частном облаке компании, а в публичном, у поставщика. Такая перемена мест совершенно прозрачна и абсолютно некритична для конечных пользователей.
Специфика компании такова, что основные мощности облака потребляются терминальной фермой. У сотрудников нет персональных компьютеров, они используют тонкий клиент, за исключением руководителей отделов, которые работают с персональными ноутбуками. Отметим, что тонкий клиент позволяет выполнять стандартизацию рабочих мест пользователей и минимизацию возможностей до уровня «дать ровно столько, сколько необходимо». В связи с особенностью рабочего процесса компании все заявки клиентов поступают в виде http-/https-запросов, что позволяет ограничиваться стандартными браузерами без установки дополнительного программного обеспечения.
Хорошо, когда при реализации проектов происходит осознанный выбор решений, а не «потому, что так делают все». В рассматриваемом примере выбор в пользу Citrix XenApp 7.6 был сделан неспроста. В версии 7.6 имеется прямая интеграция под платформу VMware, то есть существует возможность создавать виртуальные машины VMware и управлять ими прямо из консоли Citrix. Иными словами, администратор, работая с консолью Citrix, может администрировать виртуальные машины VMware, и для этого ему не требуется доступ к самой платформе виртуализации.
Кроме того, в Citrix XenApp 7.6 можно создавать необходимое количество виртуальных терминальных серверов по шаблону из так называемого золотого имиджа. Этот образ содержит всевозможные параметры конфигурации для экземпляров определенных виртуальных машин. Использование терминальных серверов, созданных на основе золотого образа экономит место на системе хранения. Достигается это за счет того, что виртуальные машины ссылаются на основной образ, а все изменения сохраняются в «дельту», которая занимает не так много места. Было принято решение хранить сам образ и дельты на SSD-дисках, благодаря чему удалось ощутить прирост скорости примерно в два раза.
Как используется виртуальная СХД в облаке
В одном из материалов про аренду виртуальной СХД в облаке IaaS мы знакомили читателей с основными возможностями виртуальной системы хранения данных — SVM. Ее используют для различных целей, в том числе и для хранения виртуальных машин, как в случае с рассматриваемой организацией. А прозрачный доступ к файлам обеспечивается средствами сетевой файловой системы NFS (Network File System), основное преимущество которой заключается в возможности работать с удаленным каталогом так, будто он установлен на локальной машине, ограничивая себя лишь шириной канала.
Так как у компании была необходимость в использовании файлового сервера, а стандартного решения Windows для этих целей выделено не было, отличным выходом стало использование NetApp в качестве файлового репозитория. За счет создания DFS-ссылок с контроллера домена на NetApp пользователям компании была выделена общая папка Public. За счет настроенной функциональности создания снимков содержимого каталога пользователи самостоятельно, без участия администратора могут восстанавливать случайно удаленные копии файлов. Также с помощью NetApp SVM был решен вопрос с размещением баз данных SQL и MS Exchange, а также 20 виртуальных серверов.
Основные сложности при переходе в облако
Как правило, основные затруднения при переходе в облако связаны с переносом огромного объема данных и первоначальной настройкой. Именно с такой проблемой и столкнулась рассматриваемая организация. Первоначальная настройка NetApp требовала от сотрудников компании изучения соответствующей функциональности. В своей практике клиенту не приходилось сталкиваться с подобными решениями, поэтому пришлось изучать функционал с нуля, чтобы как минимум на одном языке общаться с инженерами СХД.
Сам же процесс переезда занял около трех месяцев, один из которых ушел на «перетягивание» данных. Как и следует поступать в подобных случаях, переезд был организован плавно, решались не все задачи и сразу, а постепенно и последовательно, по одной, без отрыва основных пользователей от работы.
Прочие вопросы
Организация сети
Поскольку все основные мощности организации сосредоточились в облаке провайдера, из каждой точки (четырех дилерских центров) для связи с удаленной площадкой решили пробросить по два канала. Наличие двух параллельно идущих каналов является страховкой на случай падения одного из них. При этом просто в два раза уменьшается скорость и вместо 200 Гбит на выходе имеется 100, что вполне допустимо для сети автосалонов. Эти каналы объединяют удаленные площадки по принципу «точка — точка», а выход в Интернет осуществляется через облако провайдера.
Обеспечение надежности
Прежде чем перейти в облако, дирекция сети автосалонов задумалась о выборе надежного поставщика услуг. Поэтому обращали внимание как минимум на уровень Tier дата-центра, на используемое им оборудование, организацию безопасности и изоляцию клиентов друг от друга, на то, как быстро осуществляется техническая поддержка, каким образом реализуется резервное копирование и многое другое. На основе всех этих критериев и был выбран поставщик.
Резервное копирование
Вопрос резервного копирования всегда являлся одним из значимых. Провайдер нередко предлагает встроенный функционал резервного копирования, когда выполняется копия целиком взятой виртуальной машины, а плата осуществляется за отдельно взятую единицу. Возможен и другой вариант, когда бэкап сохраняют на отдельно выделенные серверы поставщика. Для кратковременного хранения копий виртуальных машин используются снэпшоты, которые клиент выполняет самостоятельно и чаще всего бесплатно. Именно такой вид кратковременного хранения был выбран рассматриваемой компанией
Итоги
На примере сети автосалонов, прошедшей путь от собственной серверной до переезда в публичное облако, можно сделать вывод: инвестиции оправдали себя. За счет облачных решений удалось отказаться от доставшегося в наследство парка железа, снизить затраты на обслуживание необходимых сервисов, а также повысить уровень надежности, безопасности и отказоустойчивости инфраструктуры.
