Transcription
[музыка]
Начнём с вопроса: кто такой системный администратор?
Это человек, который занимается настройкой и отвечает за штатную работу компьютерной техники, сетей и программного обеспечения.
Совокупность этого называется IT-инфраструктурой.
Её можно сравнить с инфраструктурой города: есть система вроде водоснабжения, электричества, дорог, вывоза мусора и прочее.
Они нужны, чтобы люди могли спокойно жить и работать в городах.
Также и в IT: без нормальной инфраструктуры пользователи не смогут спокойно работать.
Хоть инфраструктура есть во всех городах, но в каждом она уникальна.
Так и IT-инфраструктура везде устроена по-разному, но база одна и та же.
Поэтому ответ на вопрос, как устроена эта структура, зависит от компании.
Давайте мы создадим свою компанию со своей инфраструктурой.
Говорим с провайдером, он нам даёт роутер и интернет.
Берём какой-нибудь системный блок и называем его термином, ставим на него Linux, поднимаем какой-нибудь сервис и выдаём IP-адрес, чтобы связать между собой пользователей, сервер и роутер.
Покупаем какой-нибудь простой свитч и подключаем всё между собой медными патч-кордами.
Вот и готова наша инфраструктура, и всё работает.
Пока в один из дней кто-то случайно не положит что-то тяжёлое на кабель, идущий к серверу.
Кабель испортится, и сервер становится недоступным, а вы в этот день взяли отгул.
Пользователи не могут зайти на сервер, клиенты недовольны, и вам срочно нужно ехать в офис и подключать новый кабель.
Вся эта история знакомит нас с таким термином, как СТУФ (Single Point of Failure) — единая точка отказа.
Это такой элемент системы, выход из строя которого приводит к остановке работы сервиса.
Сервис не в плане программы в системе, а в плане услуги для потребителя.
Так вот, в нашей инфраструктуре кабель, соединяющий сервер со свитчом, был единой точкой отказа.
Он вышел из строя, и сервер стал недоступен.
Даже если операционка работает, программа внутри тоже работает, для пользователя она недоступна.
С.П.Ф. — это движущая сила, это один из главных терминов, отвечающих на большинство вопросов, в том числе, почему инфраструктура устроена так, а не иначе.
Впрочем, вы всё поймёте.
Давайте продолжим.
Конечно, мы могли бы просто заменить кабель и надеяться, что это больше не повторится.
Но мы поступим умнее и попытаемся предотвратить эту ситуацию.
В интернете мы нашли ответ, как это сделать.
Не к теме НГ: мы можем объединить в системе два порта.
Один будет работать, а второй ждать.
Если с первым портом или кабелем что-то случится, всё переведётся на второй порт.
Так мы соединили сервер со свитчом двумя портами.
Ну и заодно решили также поступить с роутером — мало ли, и там что-то случится с кабелем.
Можно было бы использовать сельскими компьютерами заморочиться, но у нас портов на свитче так много.
А если у озера повредится кабель, он мартыновой фай пересесть, и всё вроде нормально.
Пока в один из дней на сервере не выходит из строя сетевой адаптер.
А так как вышел из строя адаптер, к которому были подключены оба кабеля, опять сервис стал недоступен.
Опять пользователи недовольны, и чтобы решить эту проблему и предотвратить в будущем, мы покупаем два сетевых адаптера.
Если один из них выйдет из строя, всё автоматически переведёт на второй.
А в это время купим новый адаптер.
И сами знаете, что потом вышел из строя свитч.
Как мы это решим и предотвратим?
Правильно, купим два свитча.
Один кабель воткнём в один свитч, второй — во второй.
Ну и связи между собой свитчами.
Теперь, какой бы из кабелей ни вышел из строя, сеть продолжит работать.
Да, ну почти.
У нас сеть вяжут в первую же подключив два свитча между собой двумя кабелями, мы создали петлю.
Если вкратце, свитчи начнут пересылать друг другу одни и те же пакеты, которые будут лавинообразно множиться и в итоге забьют всю сеть, из-за чего вся сеть станет недоступной.
И мы находим решение этой проблемы: нужны свитчи поумнее.
Они все называются управляемыми свитчами, то есть менеджер свитч.
У них много полезного функционала, который бы нам пригодился.
Например, агрегация портов.
Димка Крики — это тот же самый миг теле, но со стороны свитча.
Если с тупыми свитчами нам приходилось один из кабелей держать в режиме ожидания, то теперь мы можем использовать оба кабеля.
Мало того, что будет отказоустойчивым, ещё и будут использоваться оба кабеля одновременно.
Раньше у нас использовался тип агрегации портов активной и backup.
То есть один из портов был в режиме ожидания.
Теперь оба порта будут активны.
Этот тип агрегации называется LACP, его ещё часто называют 802.3ad.
Под таким названием он описан в стандартах.
LACP позволяет соединять несколькими портами только два устройства.
То есть мы по LACP можем соединить два свитча.
А как нам LACP использовать между сервером и двумя свитчами, чтобы оба порта были активны, при том что получается три устройства: два свитча и один сервер?
Для этого современные свитчи поддерживают так называемый M-LAG — мультичасти с лак.
Агрегация портов между несколькими устройствами.
Так мы можем объединить в одну группу порты на первом и на втором свитче.
Сервер будет думать, что с другой стороны одно устройство — один свитч.
Поэтому на нём получится настроить LACP с поддержкой M-LAG.
Теперь у нас выросла скорость сети и отказоустойчивость.
Но теперь-то у нас сеть точно не упадёт.
Рано радуетесь, теперь вышел из строя роутер.
Ну вот, не везёт нам.
Что делать дальше?
Правильно, покупать два роутера.
Окей, мы подключили второй роутер, но ведь у него другой адрес.
А наши пользователи для выхода в интернет используют в качестве gateway только один адрес.
Что нам теперь, бегать везде менять gateway?
Как же нам на двух роутерах поставить один и тот же адрес?
Технически так нельзя делать, у каждого устройства должен быть свой IP-адрес.
Но есть протокол VRRP, который позволяет разделить IP-адрес на два устройства.
Сначала этим адресом пользуется одно устройство, но если оно перестанет работать, IP начнёт работать на другом.
Скажем, если всё работает, то адрес 254 будет на первом роутере, а если первый роутер выйдет из строя, второй роутер возьмёт себе этот адрес.
Ну теперь-то точно всё.
А тут сюрприз от провайдера: интернет лег, кто-то что-то копал и повредил линию.
Интернет будет через пару часов.
Ну и что нам теперь, два интернет-провайдера покупать?
А вы думали? Нет, да, нужен второй провайдер.
Кстати, а СП — это интернет-сервис-провайдер, то есть интернет-провайдер.
На этом этапе начинаются танцы с буквами, потому что нередко один провайдер даёт только один кабель.
То есть на два роутера его не подключить.
И тут надо либо подключать один роутер к одному провайдеру, либо подключать провайдеры к свитчу.
Но тогда свитч становится единой точкой отказа.
Можно воткнуть один кабель в один свитч, а второй кабель во второй свитч.
Но тогда при падении свитча переключиться и интернет-канал, что обычно не критично, но будет неприятно.
Два разных провайдера дают два разных публичных адреса.
Соответственно, один из ваших адресов станет недоступен, и те, кто по нему подключались, скажем, на ваши веб-сервера, потеряют доступ.
Но и это можно обойти, если у DNS провайдера настроить проверку доступности IP.
Но давайте такие дебри оставим на потом.
Ладно, сейчас нормализовалось, на неё теперь можно положиться.
Вряд ли, сне возможно проблема в реальной инфраструктуре.
Свитчей будет побольше, но это просто количество, суть останется так же.
Роутер и по-разному можно объединять.
Мы с вами разобрали GARP, который является стандартным открытым протоколом.
Они редко в компаниях, два роутера программно работают в одном кластере, и переход IP-адресов реализован иначе через внутренний софт этого роутера.
И после того, как вы с трудом объяснили начальству все проблемы, с трудом выбили бюджет, у вас ложится сервер.
В этот момент у вас в голове зарождается много мыслей, среди которых есть термины RPO и RTO.
RPO (Recovery Point Objective) — это максимальный период времени, за который могут быть потеряны данные.
Никто не хочет терять данные, но и делать бэкапы ежесекундно и хранить кучу бэкапов выйдет нереально дорого.
Поэтому вы начинаете соглашаться, что если что-то пойдёт не так, вы готовы потерять данные, например, за два последних часа.
Это ваш RPO.
Соответственно, бэкапы должны делаться примерно с такой периодичностью.
RTO (Recovery Time Objective) — промежуток времени, в течение которого система может оставаться недоступной.
То есть сколько времени вам нужно будет, чтобы вернуть всё как было.
За это время успеете поставить новый диск, восстановить на его бокам и всё запустить.
Но чтобы избежать повторения ситуации, вы решаете приобрести второй диск и настроить RAID.
У вас два сетевых адаптера, два диска.
Что может пойти не так? Например, сгорел блок питания.
Но второй блок питания на компьютер не поставишь.
Зато мы наконец-то можем избавиться от этого хлама и купить настоящий сервер.
У него есть RAID-контроллер, процессор и оперативка, рассчитанная на постоянную работу, и много всего полезного.
Например, отслеживание состояния всего оборудования.
Залов два блока питания.
Теперь-то что может пойти не так?
Почему бы не выйти из строя операционной системе или не сгореть патерики?
Как насчёт второй материнки?
А вот никак.
Что же, придётся раскошелиться, нужно купить второй сервер и сделать кластер.
Кластер можно сделать на основе гипервизора, чтобы всё было в виртуалках, и они запускались на разных серверах.
Но делать кластер из серверов очень плохая затея, потому что если сервера потеряют связь друг с другом, так орды из них посчитает, что упал второй сервер и картой попытается запустить виртуалки.
Тогда получится каша, с большой вероятностью всё приведёт к порче данных.
Поэтому кластер нужно сделать из трёх серверов.
Если выйдет из строя один сервер, другие два продолжат работать.
Если какой-то сервер увидит, что потерял связь с двумя, то он посчитает, что проблема в нём и не станет запускать виртуалки.
Окей, предположим, помер один из серверов.
Как запустить виртуалку с того сервера, но другом?
Файлы виртуалки-то лежат на сервере, который недоступен.
Что, постоянно бэкапить виртуалки с одного сервера на другой?
Тогда при падении сервера мы будем терять часть данных, а мы этого не хотели бы.
Нам нужно данные держать как-то централизовано, чтобы они были одновременно доступны на всех трёх серверах.
Для этого есть готовые решения — системы хранения данных, часто называемые SAN.
Это эдакий сервер, где куча дисков, который нужно для раздачи пространства на серверах.
Сервера подключаются к специальному свитчу, называемому SAN-свитчом.
Он подключен к сторожу, на нём создаются виртуальные диски, а сервера видят эти диски.
И это не обычная сеть, которую мы изучали, а именно Storage Area Network.
То есть одновременно у вас работает и обычная сеть, где ходят сетевые пакеты, и также есть пара адаптеров оптических, которые выделены для доступа к дискам по сети.
Такая сеть называется SAN (Storage Area Network).
SAN сам по себе имеет два контроллера, то есть что-то вроде материнок.
Поэтому для отказоустойчивости нет необходимости покупать вторую сторону.
Внутри сторожа есть и RAID, и дупликация, и снапшоты, и куча других технологий, полезных для хранения данных.
За счёт того, что все три сервера будут видеть одни и те же виртуальные диски, виртуалки будут спокойно перемещаться с одного сервера на другой.
Такая инфраструктура, когда есть несколько серверов и система хранения данных, называется классической.
Есть и другие, но это отдельная тема.
Итак, у нас накопились сервера, системы хранения данных и свитчи.
Всё это оборудование сильно греется, выделяет много тепла и очень чувствительно к окружению.
Стандартная температура, при которой такое оборудование чувствует себя в порядке, взята 20 градусов.
Скажем, при 30 и 35 градусах могут начаться проблемы, и даже что-то испортится.
Также влажность должна быть где-то 40 процентов.
Такое окружение в обычных условиях организовать сложно, да и шум от серверов не даст вам спокойно работать.
Поэтому всё это оборудование нужно хранить в специальных комнатах с подходящими условиями — серверных комнатах.
Но и чтобы всё это оборудование не ставить на пол, есть специальные металлические шкафы, называемые раками.
Они стандартизированы, в основном высота и ширина у многих шкафов одинаковые.
В раках есть промежутки пространств, называемые юнитами или просто по-русски — монтажная единица.
У неё высота где-то четыре с половиной сантиметра.
Серверов, свитчей и прочего оборудования, как правило, высота соответствует этим юнитам.
Скажем, обычно свитч занимает 1 юнит, сервер — 1-2, иногда 4 юнита, в зависимости от мощностей и древности этих серверов.
Есть определённые требования к серверам: откуда должен поступать воздух, как он должен циркулировать.
Должны быть специальные кондиционеры для регулирования температуры и влажности в серверной, специальные системы мониторинга окружения, чтобы следить за температурой и влажностью и другими параметрами.
А также специальные системы пожаротушения.
В общем, в серверных комнатах огромное количество требований.
Что, думаете, потратив столько денег и собрав такую серверную, вы избавитесь от единой точки отказа?
Как бы не так!
В один день вас просто вырубает электричество.
Это же не ваше вино, что можно с этим поделать?
Что-то я не слышал, чтобы у Гугла свет отрубили, и поэтому недоступен.
Так что берём деньги в руки и покупаем UPS.
Но домашние не подойдут.
Вы в курсе, сколько электричества жрёт всё это оборудование?
Нужны UPS помощнее.
Если у вас один-два шкафа оборудования, то сойдут UPS для раков.
Да и на 1 UPS рассчитывать не стоит, поэтому нужно минимум два.
А бывает, что оборудования много, да и вы не хотите, чтобы по всему зданию пропадал свет.
Поэтому можно по два UPS хоть в отдельную комнату выделить.
Но это уже не совсем касается IT.
Нам важно, чтобы сервера работали, чтобы сервис был доступен.
А что, если электричество пропадёт надолго?
Разбиваем последнюю копилку и проводим вторую линию электричества.
Один блок питания и UPS сажаем на одну линию, второй блок — на вторую.
Даже если электричества с одной стороны не будет, на другой всё будет работать.
Что, думаете, на этом всё?
А если серверную затопит?
Если по всему городу пропадёт электричество?
Если на город упадёт метеорит?
Что, из-за этого бизнес должен перестать работать?
Как бы не так!
Строим копию нашего дата-центра в другом здании, другом городе, другой стране, другом континенте, другой планете.
Чтобы не случилось, наша инфраструктура должна работать.
Вы думаете, Илон Маск осваивает Марс для людей?
Поверьте, первое, что там появится, — дата-центр.
Теперь вы понимаете, почему S.P.F. — главный термин в IT и почему это такое дорогое удовольствие.
Есть много других нюансов, которые я не упомянул, но со временем вы многому научитесь.
Да, не каждая компания строит запасной дата-центр, но вы растёте как специалист, когда вместо одного кабеля подключается два.