Как стать автором
Обновить

Один большой сервер на хозяйстве

Время на прочтение10 мин
Количество просмотров13K
Всего голосов 37: ↑37 и ↓0+37
Комментарии26

Комментарии 26

Пост годных мыслей. Очень расстраивает, что когорта традиционных системных инженеров (хакеров), которые знают стек от железа до системного софта, а еще могут и патч на C накатать и применить чтобы скомпилировать некомпилируемое почти исчезла в мире Linux. Хотя, предположу, что в мире FreeBSD они еще остались.

Не исчезла, просто померкла на фоне лавины XxxOps'ов.
Сам вынужден был перековаться, но руки то помнят..

Никуда они не исчезли. Просто на фоне количества они скрадываются.

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

Она исчезла т.к. спрос исчезает, всё идет по пути максимального упрощения

НЛО прилетело и опубликовало эту надпись здесь

а потом "бамс и вдруг нужна избыточность, и ты идешь и покупаешь второй "супер" сервер, а потом и третий. И часто получается, что 3 меленьких сервера стоят дешевле 1 навороченного, а выполняют те-же задачи, но обладают нужной избыточностью...

В отрыве от задач (и реальности), все железо прекрасно..

НЛО прилетело и опубликовало эту надпись здесь

Сейчас многие банки переводят вычисления в облако. В нашем подразделении только за тест-окружения мы платили Амазону по 200+ тыс баксов в месяц, и стоимость росла и росла по мере перевода тестов в облако. Плюс, своя команда из шести CloudOps-ов. И никто никогда не сравнивал стоимость аренды физических серверов со стоимостью облака. Но переход на облако даже не обсуждался - так решили большие боссы.

НЛО прилетело и опубликовало эту надпись здесь

Туда сюда

Ну тут даже и не поспоришь )

Свои сервера это - сетевые инженеры, дц инженеры, электрики, механики, кондиционерщики, те же девопсы, отдел закупок, отдел учёта, склады, контракты на обслуживание всего-всего, контракты на питание, на топливо.. И в нескольких экземплярах почти все, потому что дежурства. Конечно, это всё можно сократить до пары человек, пока ответственности немного, а ещё люди болеют, отдыхают после дежурства и просто в отпусках, увольняются.. те же 6 человек как минимум и выходит. И чем выше нужна надёжность, тем больше нужно всякого народа и железа.
Конечно, если это ДЦ то имеет смысл. Но большинству облако + несколько девопсов с учётом всех расходов выходит заметно меньше.

Плюс у всяких банков есть pci dss c понятием контролируемого доступа, приватные облака не просто так дороже обычных облаков.

Это же не про РФ речь? Или события, начиная с февраля, ничему не научили?

Это совсем не про РФ.

НЛО прилетело и опубликовало эту надпись здесь

т.к. "все" "привыкли" к облакам, то и у себя делают облако

... и правильно делают. Cloud repatriation не просто мода. А нормальный расчёт
1) Удобно 2) Управляемо 3) очень небольшой overhead на виртуализацию.

чаще на openstack

Далеко не факт. Разве что под санкциями, или если есть уже свои спецы именно под эту платформу. Hyper-V и VMWare списывать рано )

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

Побуду вредным оппонентом.

Вот цены на лямбду AWS: $0,20 за миллион запросов плюс $0,0000166667 за ГБ-секунду оперативной памяти

...

Премия за бессерверные вычисления по сравнению с серверным инстансом составляет 5,5 раз.

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

Для облака мне не нужно нанимать сисадминов!

Да, это так. Просто они теперь называются Cloud Ops...

Как-то непонятно. Всю статью автор писал про один сервер в облаке против одного железного сервера. Одним сервером в облаке может и программист управлять и директор (если он из технарей). Кроме того, автор "забыл" упомянуть, что сервер нужно амортизировать, держать ЗИП, обновлять и т.д. То есть это натурально целый человек. Плюс доп. работа для бухгалтеров. Плюс доп. аренда помещений. Допустим, по расценками северо-востока США (где обретается автор), это тысяч 150 дополнительно. Тогда арифметика выглядит совсем по-другому.

И нет причин полагать, что облачные ЦОДы будут падать реже, чем ваши отдельные серверы.

Облачные ЦОДы обслуживаются профессионалами, чья основная работа состоит в именно в обслуживании этих ЦОДов. Наш отдельный сервер обслуживается админом (который на все руки мастер) когда не надо обновлять винду у главбуха или тянуть новый ethernet-кабель вместо старого. Это достаточно веская причина полагать что облачный ЦОД будет падать реже. А ещё у него дублированное электропитание и подключение к интернету. А в нашем офисе — нет.

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

В итоге - да - свой админ/***Опс будет нужен. Но все вопросы с ЗИП-ами, инфраструктурой и т.п. - решает арендодатель сервера.

И если фирме нужен такой сервер, то вряд ли это фирма "1,5 землекопа" - так что +1 наёмный работник или контрактник - это не бог весть какое увеличение нагрузки.

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

Пример:
Текущая контора (стартап) хранит все в облаке (AWS): слупила Series-A, и решила что не будет заморачиваться с собственной инфраструктурой.
Спустя 2 года выделена отдельная команда, которая подсчитывает расходы на AWS и пытается их снижать. Пользы мало - обычная prod нагрузка пожирает ресурсы: базы, вычисления.

теперь посчитайте стоимость датацентра (на самом деле двух если нужен drp) или места под сервера в чужом дц, каналы, сетевое оборудование, ups... SAN если нужен..
Обслуживание..

Один сервер в вакууме дешевле облака.. если что то больше, то надо считать

Подсчитали. Иначе не писал-бы.
В предыдущей компании хостил с 2005, параллельно подключил AWS.
AWS для DR и Dev. Дата центр для Prod. Пытались перенести прод на AWS. Дорого.
Свои серверы тоже подсчитал - дешевле получилось купить пару серверов и colo в дата центре, чем растущие расходы за облако.

я бы посмотрел на такие расчёты.

Интересно бы посмотреть на такие расчеты. У нас не получилось сделать на своих серверах дешевле - нагрузка в разные часы может отличаться в десятки раз и она предсказуема - в AWS мы просто арендуем разные мощности в разное время суток, под разные задачи разные типы серверов и архитектур.
Естественно, если у вас облако - это пару серверов работающих 24/7, то облако выглядит лишним.

Мы делали комбинированную среду. Физ серверы + облако, выходило идеально.

Отлично. Но самый главный аргумент ПРОТИВ облачных серверов я не нашел.

Облачный провайдер обычно расположен у буржуев. И в любой момент... нет, не так... В ЛЮБОЙ МОМЕНТ может выкинуть вас со своего хостинга по политическим или еще каким педерастическим соображениям. И весь ваш бизнес рухнет в одночасье.

Свой сервер в подсобке такой фигни с вами не выкинет.

обычно расположен у буржуев

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

А если посмотреть внимательно на статью, то этот минус в статье четко указан.

Вот он

Но проблема в том, что облачные маркетологи настойчиво пытаются продать нам «нативную облачную архитектуру». Это такие вещи, как микросервисы в группах виртуальных машин с автоматическим масштабированием и легионами балансировщиков нагрузки. А также разные специфические продукты, с помощью которых нас привязывают к вендору. Это могут быть бессерверные вычисления и управляемые БД высокой доступности. Есть веская причина, по которой продавцы облачных решений продвигают свою «облачную архитектуру» — это выгодно им!

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий