Директор по развитию hoster.by Павел Богданов и системный архитектор компании Роман Гировка рассказали, как маркетологи искусственно поддерживают моду на облачные технологии, и объяснили, что хостинг данных устроен гораздо сложнее.
«Когда нечего сказать — обычно говорят: «Облако»…”
Павел. Технологии и принципы облаков — явление не новое. Технологии, на которых строятся облачные сервисы, были разработаны ещё в конце 90-х — начале 2000-х. Но до Беларуси они дошли с опозданием лет на 10 — где-то в 2013–2014 годах. Поэтому, если в Европе или США облака уже не вызывают ажиотажа, то в нашей стране наблюдается некий хайп, который не утихает, в первую очередь, с подачи маркетологов.
Роман. Когда нечего сказать — обычно говорят: «Облако»…
Павел. Когда облака появлялись в США, это было связано с переходом на подписную модель. Раньше, до создания облачных платформ Amazon, было принято покупать огромное количество физических серверов и вкладывать большие деньги в их обслуживание. Но концепция облаков изменила правила игры: отныне пользователь платил только за использование ресурсов провайдера и не тратил тысячи или миллионы долларов на дорогостоящее железо. Подписка позволяла гибко использовать ресурсы — увеличивать или уменьшать мощности при необходимости.
В последние годы переход на подписную модель происходит и в Беларуси. Для сравнения: темпы роста облачного направления по рынку Беларуси соответствуют мировым — порядка 30% в год. Что касается наших клиентов, то только в 2018 году «облачных» стало на 90% больше. Но у многих белорусских ИТ-директоров присутствуют завышенные ожидания от облачных технологий. А между тем, любая технология — это всего лишь инструмент для решения производственных задач.
Роман. Размещение и обработка данных может быть разной. Кроме облачных серверов, это могут быть выделенные серверы, виртуальные выделенные серверы (VPS), виртуальный хостинг. Причём, у нас, например, виртуальный хостинг работает на операционной системе, которая называется CloudLinux. Это интересно, ведь «клауда» там особо и нет. Это пример, как маркетинг создаёт путаницу в терминологии.
Облако — это один из серверов, с которым удобно совершать определенные действия: управлять, масштабировать, бэкапить.
«Даже самого большого сервера становится мало»
Павел. Существует два вида роста серверной системы: вертикальный и горизонтальный. Вертикальный рост — это увеличение количественных показателей: в сервере было два процессора, мы добавили ещё один. При таком росте есть физические ограничения. Нельзя в сервер поставить больше «железа», чем запланировано.
При горизонтальном росте ресурсы внутри системы распределяются между узлами, которые объединены в единый кластер, обеспечивающий масштабирование, отказоустойчивость и возможность переносить большие нагрузки. Облако тоже является кластером в этом понимании. В облаке работают различные виртуальные машины, которые «размазаны» по кластеру. В случае выхода из строя одного из узлов виртуальная машина автоматически мигрирует на другой узел.
Роман. Реализация кластерных решений напрямую зависит от задач, которые ставят перед нами клиенты. Кому-то важна отказоустойчивость. Приходит клиент и говорит: «У меня нагрузка небольшая, но очень важно, чтобы мой сервис был максимально защищён от сбоев». Наша задача в таком случае — задублировать основные узлы, чтобы при неполадках дубли узлов переключились на запасные.
Или сервисы клиентов испытывают большие нагрузки. В таком случае мы делаем так, чтобы запросы выполнялись не на одном сервере баз данных, а на двух, трёх и больше.
А для кого-то важна масштабируемость. У такого клиента, например, три сервера баз данных, но через полгода он планирует рост бизнеса. Это не очевидно, но в некоторых инфраструктурах проблема масштабирования может стоять остро.
Мы стараемся строить универсальные решения в плане реализации — можно использовать любые серверы: VPS, выделенные серверы, облако, гибридные решения.
В некоторых случаях вертикальный рост может достигнуть предела. Случается так, что бизнес клиента растёт, и в рамках одного сервера его размещение становится невозможным. Даже самого большого сервера становится мало. Вот тут-то и необходимо перейти на горизонтальный рост с помощью кластеризации.
И выделенный сервер, и облако могут работать в одной инфраструктуре. В таком случае гибридный кластер объединяет и группу выделенных серверов, и облака, чтобы они могли решать задачи повышенной сложности. А к этой системе будет, например, подключена бухгалтерия 1С. Всё будет работать как одно целое. Но клиент будет иметь дело только с конечным интерфейсом.
Это пример мощной системы. Для наглядности: крупный белорусский интернет-магазин использует гибридный кластер следующих параметров: 14 серверов, 180 виртуальных процессоров, 96 физических ядер и более терабайта оперативной памяти.
Пример гибридного отказоустойчивого кластера высокой нагрузки
Павел. Но при этом есть сервисы, которым необходим вертикальный рост — кластеризуются они плохо. Например, базы данных. Приведу пример. У одного крупного интернет-магазина есть серверы баз данных, которые не помещаются в облако. Поэтому мы заказали для них очень мощные выделенные серверы — мощнее облачных в два-три раза. Выделенные серверы берут на себя обработку баз данных. В то же время front-end-приложения находятся в облаке и хорошо масштабируются горизонтально. В этом случае облачные решения удачно сочетаются с «традиционными» серверами.
Для ситуаций, когда конечная виртуальная машина клиента пожирает все ресурсы и программно её разделить невозможно, как раз подходят выделенные серверы, которые полностью справляются с нагрузкой. Потому что в облаке это сделать физически невозможно.
«Не стоит заморачиваться, облако или не облако — важно понимать конечную цель»
Роман. Облако или выделенный сервер — это инструменты, позволяющие решать определенные задачи. Поэтому очень важно, чтобы клиент понимал, что он хочет получить.
Разберём несколько ситуаций. Клиент приходит и говорит, что у него постоянная нагрузка на базы данных. И с ней не справляется один сервер — нужно три. И мы предоставляем три «железных» сервера.
Другая ситуация: клиент хочет иметь возможность в случае непредвиденных нагрузок подключать дополнительные 20-30% мощностей. Это можно сделать, подключив не выделенные серверы (ведь отключённые выделенные серверы будут стоить столько же, сколько и включённые), а организовав работу в облаке. В облаке будут включаться дополнительные мощности на время действия акции в интернет-магазине клиента или в иных похожих случаях.
Облако хорошо подойдёт и в тех ситуациях, когда программисты клиента ведут разработку. Разработчики что-то сделали, потестировали — выключили сервер. Тарификация облака почасовая, так можно экономить деньги.
В облаке удобно производить масштабирование и бэкапить данные — а это вопрос безопасности. В случае выделенного сервера бэкапить можно на ещё один физический сервер или выделенный отдельный диск в текущем сервере. Но если что-то случится с сервером, то этот диск уже не поможет. То есть надо думать о втором сервере или облачном хранилище. А в облаке бэкапить данные просто — это можно делать по расписанию или вручную в три клика.
Но клиенту не стоит заморачиваться, как организовать процесс — в облаке или не в облаке. Он должен понимать конечную цель и задачу.
Павел. Основные клиенты, которые используют облако — это различные инфраструктурные проекты, которые выносят в облако различные CRM и ERP-системы, собственные разработки. Мобильные приложения, которые используют back-end. Или, например, приложения по поиску маршрутных такси. Приложение работает на мобильном телефоне, а back-end в виде баз данных и обработки информации находится у нас в облаке.
Или, допустим, бухгалтерии в большой компании нужно до 20-го числа подбить все акты и отправить в налоговую отчёты. Это время больших нагрузок на серверы 1C, серверы баз данных и т. д. На это время можно увеличить размер сервера в облаке, а затем снова вернуть в исходное положение.
Давайте резюмирую. Облако — это сокращение затрат: не надо покупать большой сервер. Это удобство управления и создания бэкапов. Важно для почасового бизнеса, который не может ждать несколько суток, пока восстановятся данные, иметь возможность быстрого восстановления из этого бэкапа. Ну и возможность получения гибкого ресурса, чтобы обеспечить резкое увеличение нагрузки. Сегодня вы работаете в обычном режиме, завтра потребуются дополнительные мощности — и вы сможете быстро увеличить параметры сервера. А кластер — эта система призванная выдерживать постоянные высокие нагрузки, обеспечивая высокую доступность сервера. Доступность данных в кластере в разы выше, чем доступность данных в отдельных виртуальных машинах.
«Все когда-то теряли данные»
Павел. Есть два типа безопасности в облаке. Первый тип — это безопасность хранения данных. История про исчезновение данных с облака — типичная. Если почитать «Хабр», можно найти огромное количество историй, когда провайдер полностью терял конечные данные. Но если к этим историям присмотреться внимательнее, то можно увидеть, что виновниками, как правило, становились молодые облачные провайдеры.
«Яндекс» — последний пример. Они запустили облако в сентябре прошлого года. А буквально месяц назад часть серверов просто удалили из-за человеческой ошибки. Это история про опыт провайдера. Мы ведь тоже набивали шишки и тоже когда-то теряли данные. Но уже тогда делали бэкапы и страховали себя. Поэтому надо понимать, что такая проблема типична для неопытных провайдеров, у которых ещё нет глубокого понимания всей специфики работы облака. У опытных специалистов случаи потери данных крайне немногочисленны.
Роман. А я расскажу про второй тип безопасности — безопасность от взлома, хакерских атак. Что облако, что любой другой сервер, который подключён к интернету, должен обслуживаться квалифицированным персоналом, который сможет обеспечить правильные настройки безопасности, контроль доступа, своевременное обновление пакетов и операционной системы.
Совсем недавно была найдена уязвимость в почтовом сервисе Exim. По оценкам, несколько миллионов серверов, подключённых к интернету в данный момент, имеют эту уязвимость и могут быть атакованы. Что стало причиной? Какой-то программист, который писал эту программу, написал её так, что она стала уязвима. Какой-то администратор не настроил автоматическое обновление или не обновил вовремя. Поэтому цепочка человеческих ошибок и привела к проблемам.
Вот свежий случай из нашей практики. Обращается клиент: «У меня на сервере аномальный трафик. Не понимаю, откуда». Условно, у него был трафик 100 Гб в месяц, а тут за три дня — 3 терабайта. Начали выяснять. А у этого клиента разработчики что-то тестируют на облачном сервере. На всех серверах нормальные пароли, а на этом — условный QWERTY. Его автоматически подобрали и началось…
То есть в компании заказчика посчитали, что тестовый сервер не столь важен, и на него можно ставить ненадёжный пароль. Но этот сервер имел доступ к другим серверам, и, соответственно, через него могли взломать всю инфраструктуру. Была угроза огромных проблем для бизнеса. Поэтому и должен быть комплексный подход к безопасности.
«Сисадмин, способный обслуживать сложные системы, обходится дорого»
Роман. Наша зона ответственности — серверная инфраструктура, зона ответственности разработчика — создание кода. Для него системы, которые мы проектируем и эксплуатируем, выглядят, как один сервер с одной точкой входа. Допустим, у нас работает 8 серверов, которые работают, как один кластер и распределяют нагрузку. Разработчик заходит через SSH или FTP, заливает туда код — и всё. Для него это просто один компьютер, на который он залил код. Дальше система сама распределяет его по серверам.
Надо понимать, что системный администратор, который способен обслуживать сложные системы, дорого обойдётся бизнесу. Да и ему самому будет неинтересно работать только на одном проекте. За проекты, где предполагается, что заказчик будет сам заниматься администрированием, как правило, серьёзные провайдеры не берутся, понимая, что в таком случае клиент столкнётся с таким ворохом проблем, что решить их будет крайне затруднительно.
Павел. К ситуации, когда мы можем делать и обслуживать кластеры, мы пришли не сразу. Все учатся на ошибках. Когда-то мы думали, что провайдер просто отдаёт оборудование конечному клиенту, и этим бизнес и ограничивается. Но, как оказалось, конечный клиент не готов брать на себя администрирование. И если такие инициативы были, то они приводили к тому, что системы попросту переставали работать. Нам снова приходилось браться за них и настраивать. Поэтому мы и просим у нашего заказчика подробное описание того, что он хочет увидеть в конечном итоге.
«Зачастую уровень технических специалистов, работающих на провайдера чуть выше, чем уровень среднего технического специалиста отрасли. И приобретая услуги провайдера, консалтинг и облачные технологии, компания покупает ещё и накопленный опыт эксплуатации различных систем».
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.