ранее в 2024 году я писал статьи
что проще всего построить самопал
и просто присосаться в готовую сетевую инфру

что это дало?
это дало бы связность сети и хорошую сеть на которую не жалуются
и дало бы дешевый интернет

но не дало бы отказоустойчивости

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

я так понимаю
случай с какой-то точкой обмена трафиком nLighten
показал что вот эти чуваки тупо не сделали кольцо или резерв сетевого оборудования



vdsina например хранит серверы в одной компании
а оказалось что интернет в другом здании
и второго интернета в том же здании где серверы — не оказалось )

вот это я и называю
«работает до первой аварии»

множество людей считает что те или иные компании супер надежные и позаботились от отказоустойчивости
но на самом деле скорее всего даже у уровня Селектел — не все гладко, просто там аварий еще не случалось за 10 15 лет

такой тест — 100% закончится аварией
так зачем делать аварию добровольно?
лучше подождать «пока само не сгорит» и потом уже восстановиться

конечно МНОГОЕ можно сделать правильно и улучшить
но зачастую полноценный тест — это именно просто авария на часы или сутки и делать подобное желания нет

если авария затягивается на несколько дней — то это уже халтура и пренебрежение, это значит кто-то из команды поленился «подумать на перед что авария 100% когда-ниб будет»
на эту тему можно написать многое
лично я предпочитаю — дробить на мелкие части, если знаю что восстановить монолит качественно не получится
а кто не дробит — потом мучается

meduza.io/feature/2025/09/18/tam-byla-papka-s-pismami-roditeley-kotorye-oni-pisali-drug-drugu-40-let-nazad
novayagazeta.ru/articles/2025/09/16/my-let-na-desiat-postareli-dazhe-plakat-ne-poluchaetsia
bereg.io/feature/2025/09/17/v-podmoskovie-sgorel-sklad-servisa-cherdak-vmeste-s-veschami-rossiyan-kotorye-hranili-tam-veschi-vot-chto-oni-rasskazyvayut

люди хранили там архивы и вечность

вот тоже самое относится как раз к услугам по типу как selectel storage которое должно было хранить картинки 100 лет, но не справилось

вот тоже самое относится как раз к услугам по типу как pdd.yandex.ru которое должно было без изменений хранить в первозданном состоянии все настройки почтовых доменов и ящики хоть 500 лет, но не справилось

теперь люди будут хранить свои вещи у себя в комнатах — больше не доверяя никаким чердакам
теперь люди хранят свои интернет архивы — у себя на серверах и ПК копию еще делают резерв и на usb диск делают еще резерв — больше не доверяя никаким облачным сервисам

так что чувак разрушевший умышленно pdd.yandex.ru — подвел весь рынок облаков
если селектел еще можно было понять, ну не справилось трех кратное, бывает, то яндекс почту убивал умышленно какой-то продакт менеджер — который на самом деле убивал потребительский облачный рынок

сначала идет бордер какой-то
по идее их должно быть два

и тут у меня вопрос
вот допустим «здание» захотело провести 10 отдельных независимых провайдеров проводов
значит нужно 10 бордеров или все 10 проводов можно воткнуть в 1 устройство
вероятно можно в 1 устройство воткнуть, но просто разделить условный провод на 2 части, чтобы задублировать через «2 устройства»

сейчас не буду вдаваться в конкретику т.к. все равно не наша зона ответственности
но предположим что у дата-центров все сделано правильно и задублировано хоть по 10 бордерам, хоть по 2 с 10 провайдерами условными. может у кого-то и 100 провайдеров есть даже в дата-центре хз. эти все вопросы я потом изучу когда буду делать свой каталог дата-центров и записывать все эти нюансы в новом блоге о дата-центрах

потом короче от бордера идет провод до маршрутизатора
оттуда уже идут провода на коммутаторы

и вот получается значит везде всего должно быть по 2
значит в условном здании должно быть 2 основных маршрутизатора
потом в условном «зале» должно быть 2 основных коммутатора
потом из зала идут провода на «ряд» — там тоже 2 основных коммутатора под ряд
потом уже в «стойке» тоже должно быть 2 коммутатора на стойку

так вот, как же это работает
получается вот пусть будет по 48 портов устройство
значит 24 порта будут заняты для того чтобы тупо воткнуться в запасной коммутатор. когда 2 коммутатора соединены проводом просто друг с другом, чтобы был дубликат если один вышел из строя.
так же 2 порта будут заняты основные которые от маршрутизаторов. вероятно даже 4 порта, т.к. маршрутизатора то тоже 2 шт.
получается на сервер остается всего 50% от коммутаторов
50% с первого
50% с второго
а так же серверы еще должны иметь 2 сетевые карты, не так ли
чтобы сервер был сразу подключен к обоим коммутаторам
именно так же делают дубликат или как-то еще
собственно если делать везде 100г порты то железки идут дороже чем старые форм факторы.
но это не так дорого по сравнению с другими частями расхода на «сами серверы»
и мне кажется вполне выполнимо любыми компаниями которые считают себя топ50 рынка

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

далее в здание должно быть заведено 2 отдельных электрических луча от разных поставщиков энергии и чтобы они еще шли не под одному каналу, чтобы этот канал трактор не мог перерезать сразу оба провода (тоже самое и с оптиками с теми 10 ил 100 штуками провайдерами должны быть вырыты отдельные линии чтобы тракторы не могли резать сразу все)
потом тоже самое как с интернетом дублируется по объектам уже
получается на стойку так же выходит 2 линии
получается сервер должен еще иметь 2 БП чтобы подключиться потом на 2 линии
получается что опять же кол-во розеток в стойке тоже сокращется на 50% либо там нужно уже не 2 длинных ПДУ, а 4 ПДУ ставить
тоже самое еще и с ИБП в том числе. но нужны ли ИБП в принципе если у тебя 2 линии горячих работают. возможно ИБП в данном случае и не нужны. не могут же 2 линии автоматически отрубиться. но если эти станции зависят от «района», то вполне вероятно может быть авария полная на районе и отключит всех поставщиков. и тогда ИБП пригодятся. поэтому тут вроде как не нужная вещь, но и не помешает чтобы было. далее еще про дизеля можно поговорить тоже самое ставить по 2 штуки на объект который они запитывают по кол-ву мощности.
все таки энергия — это ответственность дата-центра и здания.
а вот интернет провайдеры — это ответственность хостера мне кажется, нормальный хостер когда свои стойки формирует должен сразу делать нормальных провайдеров в нормальном кол-ве. иначе он не имеет права называться отказоустойчивый. ну и выбирать ДЦ где можно 2 БП на 2 линии подключать в том числе. но вот дизеля всякие это уже вопрос не к хостеру. хотя возможно в каких-то случаях хостер может сам купить для своего зала нужное кол-во резерва, если это ему действительно важно. другой вопрос что дата-центр наверное не продаст, поэтому скажет пошел ты нахуй, иди сам строй свой дц и делай как нравится. варианты могут быть разные как часть ДЦ работает от одного ввода, а часть дц работает от двух вводов или четырех или сколько там кто напихивает. разные сегменты дата-центра под разные виды услуг.

далее потом уже идет софтверное резервирование на уровне хостера
например облачные функции бекапов, сетевых стораджей, san-lun дисков и тому подобное
или как делают в селектел еще серверы разбивают по разным стойкам и в личном кабинете подписываются номера стоек, и клиент при желании может все свои серверы разбить по абсолютно разным стойкам. если вдруг ломается что-то внутри стойки. почему они кстати это сделали? возможно потому что у них нету дубликатов на стойках. ведь если бы были то смысла напоминать о резерве клиенту не было бы. хуй его знает, ведь на сайте то они никак не написали об том, как у них что устроено. а может быть у них есть, но еще и лишнее напоминание клиенту о возможностях собственного резервирования чтобы «уж точно наверняка»

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

вот собственно у вас в стране все так делают?
или это мои фантазии
почему никто раньше не показывал фотки серверов? боялись что-то показать.
почему сейчас никто не пишет на сайтах о «отказоустойчивости»? потому что ее наверное нет.
существует ли хоть один дата-центр описанный как в моем топике? или это фантастика и в реальности все везде работает «до первого трактора» или «первой аварии». но удачно так работает и по 15 лет потому что аварии подобные могут и никогда вовсе не случиться, человек быстрее умрет от старости чем такое произойдет.
поэтому так же встает вопрос о том, а нужна ли отказоустойчивость вообще. но это уже другое рассуждение.

но короче что я хотел сказать
когда клиент условный слышит где-то слово отказоустойчивость он думает именно о том, о чем я сейчас написал.
а вот что имеет ввиду поставщик который рекламирует себя как отказоустойчивое решение — это загадка, уверен, все люди, все компании, все дата-центры имеют АБСОЛЮТНО разные понятия вложенные в это слово.

этот вопрос уже ранее поднимался
как правильно рассказать о надежности

• как клиент обычно воспринимает фразу о резервировании ?
• что еще мне кажется, в восприятии клиента о резервировании
• воля случая или до первой аварии

еще тогда в процессе общения с друзьями началось недопонимание
кто-то говорил о одном — когда писал Тиер3 или 2n+1 — а кто-то думал совсем о другом
поэтому терминами — общаться тупо

так же как тупо писать слово «отказоустойчивость»

нужно именно всегда конкретизировать
только конкретика дает правильное восприятие

вот сейчас случился как раз такой момент восприятия

как мы уже знаем, сейчас клиентами дата-центров становятся алгоритмы, а не люди
hosting.show/alice2k-hosting/mozhno-li-schitat-chto-seychas-klientam-oblakov-vmesto-lyudey-stali-algoritmy-.html
hosting.show/alice2k-hosting/dumayu-aktualno-dobavlyat-v-mire-hostinga-esche-professiyu-testirovschik-prilozheniy-dlya-serverov-i-oblakov.html
hosting.show/alice2k-hosting/400-gigov-na-telegu.html

поэтому вопрос о отказоустойчивости можно задать «по новому»

запускать ML модели на даче? но на крутейшем оборудовании
или в сертифицированном цоде?
есть ли разница?

ML это ведь сервис который можно включить и выключить
это скорее как RDP для клиента или прерываемая виртуалка

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

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

именно потому что задублировать абсолютно каждый компонет в ДЦ практически невозможно
это все равно что начать дублировать
ssd диски в рейде
потом БП на всякий случай
потом лучи
потом щитки
потом вводы энергии
потом сетевые карты
потом свитчи
потом роутеры
потом маршрутизаторы
потом сами вводы оптики
потом дизеля
потом даже баки под топливо само


наверняка каждый ДЦ где-то что-то упустил
и вот случается этот случай и все равно происходит авария
и клиент такой ой блять я же купил сервер в ДЦ а не на даче, как так
и начинает говорить а у меня на даче без резерва 10 лет все работает и диск даже не сгорел

да, реально бывает что человек умирает или сам проект умирает или бизнес умирает быстрее чем наступает эта самая «воля случая» или «первая авария»

так и создается восприятие клиентом услуг

поэтому возможно самый надежный подход — не держать все в одной корзине и заниматься горячим дубликатом
как раз модель 3AZ от ОВХ или geo внутри мегаполиса типо МСК1 МСК2
т.е. суть в чем? относиться к дата-центру как к даче и считать что «воля случая» может наступить в любой момент и не поможет не одна отказоустойчивость самого дата-центра, надеяться только на себя и создать отказоустойчивость самостоятельно через разные GEO

для человека «сервер в цоде» это просто сервер в цоде
т.е. все что ВНУТРИ здания даже не воспринимается как резерв

всякие там дубликаты свитчей
дубликаты роутеров
или дубликаты электрических проводов

для массового клиента, не для электрика или техраня — все эти вещи считаются как «по умолчанию от услуги»
т.е. если человек покупает сервер в аренду, значит он думает что все эти вещи ТАМ УЖЕ ЕСТЬ

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

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

поэтому что можно сделать?
либо рассказывать о внутренних резервах ДЦ и внешних резервах ДЦ — как 2 отдельные страницы с описанием услуг гарантий или sla сделать
либо забить на подобное и написать «у нас дц работает пока не сгорит» — те в прямом смысла нихуя не дублируется внутри дц и любая деталь там работает пока не сгорит, в том числе и сам сервер

либо кто-то возможно начнет пиздеть и будет говорить у нас все резервируется, а потом окажется что вовсе не все
и если такие люди как раз по пунктам не перечислят, или не скажут что у них самопал, то скорее всего клиент по умолчанию будет думать что это прям Тиер-4 какой-то, ибо а зачем сервер из Тиер1 Тиер2 или даже Тиер3? если почитать и углубиться в это, то получится что там все работает «до воли случая». с тем же успехом сервер может и на даче работать. просто люди об этом не знают. они думают «что по умолчанию там везде все дублирует сам ДЦ когда продает вам сервер», но на самом то деле это не так.
поэтому я бы не стал вообще рекламироваться таким средним способом, либо четкое да, либо четкое нет.

вот когда чувак слышит — 2 луча
как думаете что он думает?
он думает что это 2 ебучих отдельных 2N, но никак не N+1
почему так?
потому что любое резервирование просто ебанное слово РЕЗЕРВИРОВАНИЕ — восринимается не как «запасная деталь» а именно как горячий работающий боевой резерв

т.е. когда тебе говорят у нас сервер с 2 БП или 2 ИБП и на каждый из них идет по отдельному лучу

это не значит что это просто 2 луча от одной подстанции внутри ДЦ какой-ниб там электрощитка или что-то такое
для клиента это значит что 2 луча это 2 отдельных энерговвода — 2 отдельных электрических компаний — 2 отдельных основных провода идущими разными маршрутами до здания-ДЦ
вот что думает клиент

тоже самое с остальными вещами которые ПРИХОДЯТ в цод
допустим оптика

так что деление на 2N или N+1
это ебанное убогое деление

НУЖНО ПРОЩЕ писать, простыми словами, либо придумать новую характеристику для массового потребителя