Обещанного три года ждут. Или два. Часть 0 - вместо пролога. HA, FT и как не надо строить информационные системы.
Привет, Пикабу! С вами nervmaniac и это - наконец-то - первый выпуск моей передачи об информационных технологиях.
С первым выпуском я опоздал от обещанной даты на пару лет. Почему? Потому что времени не было. Ну и, наверное, потому что я ленивый уёбок :)
Как сказал один известный всем товарищ - "Поехали!"
Меня зовут Антон, я занимаюсь ИТ уже... Много лет :) Если точнее - мой официальный стаж почти четыре года, а неофициальный уже перевалил за 10. в 20 лет это много - и мало.
Эмбрион айтишника во мне в свое время зародил парень-эникейщик, который знает "много где помалу". Надеюсь, я смогу так же разбудить интерес к нашей профессии хотя бы у пары человек - это будет уже что-то.
За эти четыре года я успел поработать админом в техникуме (~1к машин), техническим специалистом в довольно крупном системном интеграторе и выездным инженером техподдержки юрлиц.
Начался мой путь с того, что я начал в 10 с чем-то лет потихоньку подхалтуривать переустановкой маздаев, изгнанием вирусни и прочим непотребством. В 14 лет у меня появился свободный комп (как сейчас помню - атлон 999 МГц, 256 мег рамы и винт 20 гигабайт), и я на нём ради интереса развернул контроллер домена со стандартными сетевыми службами, и дальше с ним постоянно игрался. "Заболел" ИТ я примерно тогда :)
После 9 класса я, не видя никакой пользы от лишних двух классов, в которых меня будут учить ставить галочки в тестах, пошёл в колледж по соответствующей специальности и начал всерьёз заниматься ИТ.
С середины 3 курса я начал там же работать падаваном админов из разряда поди-принеси-подай-пошёл-на-хуй-не-мешай, и за полтора года дорос до перца, на котором держится ~70% серверной и сетевой
инфраструктуры сего чудного учреждения. Передавать это новому чуваку было обидно, честно говоря :)
Через несколько месяцев после окончания сего ОУ ушёл в системную интеграцию, провёл несколько крупных и не очень проектов как специалист по Windows Server и VMware vSphere, а потом так же технично свинтил в техподдержку.
Протянул я там недолго, примерно через полгода меня достала беготня по городу, и сейчас опять нахожусь в свободном плавании. Благо, за все это время у меня появилось несколько своих заказчиков, которые периодически меня зовут для разных работ по моему профилю.
Короче, хватит истории.
Сегодня я хочу поговорить о том, как НАДО и НЕ НАДО строить сервернуюсетевую инфраструктуру.
За все время своей работы я неоднократно сталкивался с ярчайшими примерами вышеозначенного... не знаю даже, как сказать, распиздяйства, наверное. Со временем понимаешь, что если тебе наплевать, насколько хорошо работают твои системы, и насколько быстро их можно починить, чтобы контора могла опять нормально работать - то ты хуёвый админ.
Когда-то я тоже был таким же(в том случае сеть тянули ещё до меня, но я на спокойную переделку в свободное время забил), и в один момент произошла беда: взяла и разом наебнулась сеть двух корпусов, после чего:
1) Я получил некислых пиздюлей;
2) Открыв в одном крыле потолки, получил по голове десятимегабитным свитчом на 24 порта, обмотанным половиной бухты меди;
3) По ходу поисков я тихо охуевал от количества петель в сети (на 5 этажей корпуса их оказалось порядка 27 штук);
4) После шести часов поисков (благо, удалось локализовать до корпуса) источником проблем оказалась скрутка, в которой несколько пар (которые непонятно как раньше не коротили) начали коротить между собой и устроили в локалке, не без помощи петель, мощнейший broadcast storm;
5) После починки сети я потратил два рабочих дня и два выходных чтобы распутать такие же как в п.2 логова человека-паука почти по всему зданию(забегая вперёд, скажу, что на перетяжку только одного корпуса ушло ~8 км меди и две с половиной недели времени).
Как это произошло? Просто. Старые админы забивали на сеть как могли, сеть изначально строилась "на отъебись" и расширялась так же; результат - геморрой плюс потери времени.
Так что же делать?
1) Изначально проектировать сеть под её рост, покупать сетевое оборудование с некоторым запасом по портам (которые имеют свойство периодически отъезжать и вообще кончаться);
2) Не делать на отъебись. Если надо протащить 4 кабеля - тащи 4 кабеля, а не втыкай китайский говнолинк за триста рублей;
3) Если ты пришёл в контору, а там всё очень плохо - потихоньку переделывай. Сэкономишь самому себе и своим последователям много времени;
4) Вся сеть должна документироваться. С привязкой к плану знания, плюс в виде отдельной логической и физической схемы. Протянул патч-корд, повесил розетку - сразу задокументировал. За этот и предыдущий пункт в один момент сам себе спасибо скажешь. Или следующий админ тебе спасибо скажет.
5) Мало времени, надо аж вчера? Не ебёт. Никаких времянок, либо сразу делай нормально, либо отложи до того момента, как сможешь сделать хорошо. Ибо, как известно, нет ничего более постоянного, чем временное. А потом это разгребать... Ну ты понял.
6) Что-то идёт не так? Чини. Прямо вот сейчас. Не надо делать костыли и откладывать починку на потом - потому что "потом" ты окинешь взглядом творящуюся вокруг вакханалию и у тебя возникнет стойкое желание повеситься.
Что ещё бывает?
Бывают сыплющиеся диски. Бывают горящие блоки питания и дисковые контроллеры. Бывают сбои по питанию. Бывает лето с температурой за бортом +45. Бывают вирусы-шифровальщики. Бывают молнии, бьющие в медь, бывают прорванные батареи и всякое прочее непотребство. Все так просто не охватить.
Что бы ни случилось, лучше всего это предупредить и сделать всё красиво и надёжно. Как?
А тут мы подходим к двум самым важным терминам для любой системы, остановка которой повлечёт за собой остановку работы учреждения целиком или его части. То есть, на это время контора прекратит получать бабло, а на заднице админа начнет сам собой выделяться вазелин.
High Availability, оно же HA или высокая доступность и Fault Tolerance, оно же FT или устойчивость к сбоям. Эти термины очень между собой близки, поговаривают даже, что это одно и то же.
Что же это за страшные басурманские слова?
HA - это характеристика системы, которая значит, что твоя система будет иметь маленький даунтайм (время простоя), может быть восстановлена, и насколько быстро это происходит. Чаще всего эти два слова говорятся про кластеры.
FT - это характеристика системы, которая показывает, насколько ей(системе) должно стать плохо (читай, сколько компонентов должно сломаться), чтобы она загнулась совсем и её пришлось в авральном режиме оживлять.
В первую очерель надо сказать, что время простоя - это самое важное. Вполне понятно и логично, что чем меньше твоя система простаивает, тем больше контора может получить денег с её помощью.
Как сделать его меньше? А вот тут уже в дело вступает FT.
1) Low level fault tolerant services, низкоуровневые сервисы отказоустойчивости. Твоя система должна состоять из более-менее независимых друг от друга подсистем, и каждая из них должна быть отказоустойчивой.
2) Single point of failure, одна точка отказа. Строить и использовать систему, которая развалится при отказе одного из компонентов - это хуёвая идея. Гораздо лучше, если компоненты будут между собой хотя бы условно независимы, т.е, при отвале одного из них отвалится только часть функциональности.
3) Redundancy, оно же избыточность. Это когда в твоей системе избыточное количество компонентов. Как пример - зеркальный RAID-массив, два сетевых адаптера, подключенных в два разных свитча и так далее. Можно один раз пожадничать при закупке, а потом охуеть от восстановления системы.
К избыточности есть два подхода. Это Active-Active и Active-Passive. В первом случае два или более одинаковых компонента работают одновременно, во втором запасной компонент заводится только при отказе основного, причем второй вариант гораздо сложнее, но зато дешевле. Такие дела.
В плане избыточности хорошей практикой является:
1) Более одной ветки питания на сервернуюцентр обработки данных(ЦОД), более одного блока питания(БП) на сервер или каждую критичную железку, каждый БП подключать в отдельную ветку;
2) Зеркальные (RAID1) дисковые массивы на серверах или системах хранения данных (СХД);
3) Дублирование сети. В моей практике чаще всего уходили в Страну вечной охоты диски и сетевые устройства (свитчи, роутеры, сетевые карты и неудачно задетые патч-корды). Еще полезно ;
4) Ещё раз, дублирование ВСЕГО. Так, конечно, дороже, но в один не особо прекрасный момент тебе не придётся рвать волосы на жёппе.
5) Собственные источники питания. Бесперебойники, генераторы и так далее - все эти крутые вещи позволят твоей системе работать некоторое время, даже если нагнутся основные ветки питания. Ну или хотя бы дадут время для сохранения данных, чтобы не потерять ничего важного.
6) Кластеры. Хорошей идеей является запускать копии критичных систем на разных физических серверах так, чтобы они функционировали как одна. Если с одним из серверов кластера что-то пойдёт не так, и он уйдёт в даун - твоя система будет продолжать жить.
7) Самое крутое, и, естественно, самое дорогое - дублирование поверх всего вышеописанного еще и ЦОДа. Оно же Disaster Recovery или DR. Это когда полная копия твоей системы (или всего ЦОДа) в случае большого пипца (а-ля нагнулись оба источника питания вместе с генератором, тайфун, торнадо, землетрясение или ещё какая-нибудь большая пи- то есть, беда) поднимается в другом, физически удалённом датацентре.
Ещё бэкапы. Бэкапы, бэкапы, и ещё раз бэкапы. Бэкапь всё. Бэкапь по графику, все критичные данные - не реже, чем раз в сутки, а лучше чаще. Бэкапь всё перед каждым обновлением и установкой нового ПО, никто не знает, что может случиться. Ещё круто и полезно делать бэкапы на разные физические носители, например, на диски и ленточку.
Когда что-то пойдёт не так, ты опять скажешь себе спасибо - восстановить из резервной копии гораздо быстрее и удобнее, чем разворачивать систему заново или её чинить.
И под конец хочу привести ЯРЧАЙШИЙ пример того, как НЕ НАДО делать.
На фирме одного моего знакомог
С первым выпуском я опоздал от обещанной даты на пару лет. Почему? Потому что времени не было. Ну и, наверное, потому что я ленивый уёбок :)
Как сказал один известный всем товарищ - "Поехали!"
Меня зовут Антон, я занимаюсь ИТ уже... Много лет :) Если точнее - мой официальный стаж почти четыре года, а неофициальный уже перевалил за 10. в 20 лет это много - и мало.
Эмбрион айтишника во мне в свое время зародил парень-эникейщик, который знает "много где помалу". Надеюсь, я смогу так же разбудить интерес к нашей профессии хотя бы у пары человек - это будет уже что-то.
За эти четыре года я успел поработать админом в техникуме (~1к машин), техническим специалистом в довольно крупном системном интеграторе и выездным инженером техподдержки юрлиц.
Начался мой путь с того, что я начал в 10 с чем-то лет потихоньку подхалтуривать переустановкой маздаев, изгнанием вирусни и прочим непотребством. В 14 лет у меня появился свободный комп (как сейчас помню - атлон 999 МГц, 256 мег рамы и винт 20 гигабайт), и я на нём ради интереса развернул контроллер домена со стандартными сетевыми службами, и дальше с ним постоянно игрался. "Заболел" ИТ я примерно тогда :)
После 9 класса я, не видя никакой пользы от лишних двух классов, в которых меня будут учить ставить галочки в тестах, пошёл в колледж по соответствующей специальности и начал всерьёз заниматься ИТ.
С середины 3 курса я начал там же работать падаваном админов из разряда поди-принеси-подай-пошёл-на-хуй-не-мешай, и за полтора года дорос до перца, на котором держится ~70% серверной и сетевой
инфраструктуры сего чудного учреждения. Передавать это новому чуваку было обидно, честно говоря :)
Через несколько месяцев после окончания сего ОУ ушёл в системную интеграцию, провёл несколько крупных и не очень проектов как специалист по Windows Server и VMware vSphere, а потом так же технично свинтил в техподдержку.
Протянул я там недолго, примерно через полгода меня достала беготня по городу, и сейчас опять нахожусь в свободном плавании. Благо, за все это время у меня появилось несколько своих заказчиков, которые периодически меня зовут для разных работ по моему профилю.
Короче, хватит истории.
Сегодня я хочу поговорить о том, как НАДО и НЕ НАДО строить сервернуюсетевую инфраструктуру.
За все время своей работы я неоднократно сталкивался с ярчайшими примерами вышеозначенного... не знаю даже, как сказать, распиздяйства, наверное. Со временем понимаешь, что если тебе наплевать, насколько хорошо работают твои системы, и насколько быстро их можно починить, чтобы контора могла опять нормально работать - то ты хуёвый админ.
Когда-то я тоже был таким же(в том случае сеть тянули ещё до меня, но я на спокойную переделку в свободное время забил), и в один момент произошла беда: взяла и разом наебнулась сеть двух корпусов, после чего:
1) Я получил некислых пиздюлей;
2) Открыв в одном крыле потолки, получил по голове десятимегабитным свитчом на 24 порта, обмотанным половиной бухты меди;
3) По ходу поисков я тихо охуевал от количества петель в сети (на 5 этажей корпуса их оказалось порядка 27 штук);
4) После шести часов поисков (благо, удалось локализовать до корпуса) источником проблем оказалась скрутка, в которой несколько пар (которые непонятно как раньше не коротили) начали коротить между собой и устроили в локалке, не без помощи петель, мощнейший broadcast storm;
5) После починки сети я потратил два рабочих дня и два выходных чтобы распутать такие же как в п.2 логова человека-паука почти по всему зданию(забегая вперёд, скажу, что на перетяжку только одного корпуса ушло ~8 км меди и две с половиной недели времени).
Как это произошло? Просто. Старые админы забивали на сеть как могли, сеть изначально строилась "на отъебись" и расширялась так же; результат - геморрой плюс потери времени.
Так что же делать?
1) Изначально проектировать сеть под её рост, покупать сетевое оборудование с некоторым запасом по портам (которые имеют свойство периодически отъезжать и вообще кончаться);
2) Не делать на отъебись. Если надо протащить 4 кабеля - тащи 4 кабеля, а не втыкай китайский говнолинк за триста рублей;
3) Если ты пришёл в контору, а там всё очень плохо - потихоньку переделывай. Сэкономишь самому себе и своим последователям много времени;
4) Вся сеть должна документироваться. С привязкой к плану знания, плюс в виде отдельной логической и физической схемы. Протянул патч-корд, повесил розетку - сразу задокументировал. За этот и предыдущий пункт в один момент сам себе спасибо скажешь. Или следующий админ тебе спасибо скажет.
5) Мало времени, надо аж вчера? Не ебёт. Никаких времянок, либо сразу делай нормально, либо отложи до того момента, как сможешь сделать хорошо. Ибо, как известно, нет ничего более постоянного, чем временное. А потом это разгребать... Ну ты понял.
6) Что-то идёт не так? Чини. Прямо вот сейчас. Не надо делать костыли и откладывать починку на потом - потому что "потом" ты окинешь взглядом творящуюся вокруг вакханалию и у тебя возникнет стойкое желание повеситься.
Что ещё бывает?
Бывают сыплющиеся диски. Бывают горящие блоки питания и дисковые контроллеры. Бывают сбои по питанию. Бывает лето с температурой за бортом +45. Бывают вирусы-шифровальщики. Бывают молнии, бьющие в медь, бывают прорванные батареи и всякое прочее непотребство. Все так просто не охватить.
Что бы ни случилось, лучше всего это предупредить и сделать всё красиво и надёжно. Как?
А тут мы подходим к двум самым важным терминам для любой системы, остановка которой повлечёт за собой остановку работы учреждения целиком или его части. То есть, на это время контора прекратит получать бабло, а на заднице админа начнет сам собой выделяться вазелин.
High Availability, оно же HA или высокая доступность и Fault Tolerance, оно же FT или устойчивость к сбоям. Эти термины очень между собой близки, поговаривают даже, что это одно и то же.
Что же это за страшные басурманские слова?
HA - это характеристика системы, которая значит, что твоя система будет иметь маленький даунтайм (время простоя), может быть восстановлена, и насколько быстро это происходит. Чаще всего эти два слова говорятся про кластеры.
FT - это характеристика системы, которая показывает, насколько ей(системе) должно стать плохо (читай, сколько компонентов должно сломаться), чтобы она загнулась совсем и её пришлось в авральном режиме оживлять.
В первую очерель надо сказать, что время простоя - это самое важное. Вполне понятно и логично, что чем меньше твоя система простаивает, тем больше контора может получить денег с её помощью.
Как сделать его меньше? А вот тут уже в дело вступает FT.
1) Low level fault tolerant services, низкоуровневые сервисы отказоустойчивости. Твоя система должна состоять из более-менее независимых друг от друга подсистем, и каждая из них должна быть отказоустойчивой.
2) Single point of failure, одна точка отказа. Строить и использовать систему, которая развалится при отказе одного из компонентов - это хуёвая идея. Гораздо лучше, если компоненты будут между собой хотя бы условно независимы, т.е, при отвале одного из них отвалится только часть функциональности.
3) Redundancy, оно же избыточность. Это когда в твоей системе избыточное количество компонентов. Как пример - зеркальный RAID-массив, два сетевых адаптера, подключенных в два разных свитча и так далее. Можно один раз пожадничать при закупке, а потом охуеть от восстановления системы.
К избыточности есть два подхода. Это Active-Active и Active-Passive. В первом случае два или более одинаковых компонента работают одновременно, во втором запасной компонент заводится только при отказе основного, причем второй вариант гораздо сложнее, но зато дешевле. Такие дела.
В плане избыточности хорошей практикой является:
1) Более одной ветки питания на сервернуюцентр обработки данных(ЦОД), более одного блока питания(БП) на сервер или каждую критичную железку, каждый БП подключать в отдельную ветку;
2) Зеркальные (RAID1) дисковые массивы на серверах или системах хранения данных (СХД);
3) Дублирование сети. В моей практике чаще всего уходили в Страну вечной охоты диски и сетевые устройства (свитчи, роутеры, сетевые карты и неудачно задетые патч-корды). Еще полезно ;
4) Ещё раз, дублирование ВСЕГО. Так, конечно, дороже, но в один не особо прекрасный момент тебе не придётся рвать волосы на жёппе.
5) Собственные источники питания. Бесперебойники, генераторы и так далее - все эти крутые вещи позволят твоей системе работать некоторое время, даже если нагнутся основные ветки питания. Ну или хотя бы дадут время для сохранения данных, чтобы не потерять ничего важного.
6) Кластеры. Хорошей идеей является запускать копии критичных систем на разных физических серверах так, чтобы они функционировали как одна. Если с одним из серверов кластера что-то пойдёт не так, и он уйдёт в даун - твоя система будет продолжать жить.
7) Самое крутое, и, естественно, самое дорогое - дублирование поверх всего вышеописанного еще и ЦОДа. Оно же Disaster Recovery или DR. Это когда полная копия твоей системы (или всего ЦОДа) в случае большого пипца (а-ля нагнулись оба источника питания вместе с генератором, тайфун, торнадо, землетрясение или ещё какая-нибудь большая пи- то есть, беда) поднимается в другом, физически удалённом датацентре.
Ещё бэкапы. Бэкапы, бэкапы, и ещё раз бэкапы. Бэкапь всё. Бэкапь по графику, все критичные данные - не реже, чем раз в сутки, а лучше чаще. Бэкапь всё перед каждым обновлением и установкой нового ПО, никто не знает, что может случиться. Ещё круто и полезно делать бэкапы на разные физические носители, например, на диски и ленточку.
Когда что-то пойдёт не так, ты опять скажешь себе спасибо - восстановить из резервной копии гораздо быстрее и удобнее, чем разворачивать систему заново или её чинить.
И под конец хочу привести ЯРЧАЙШИЙ пример того, как НЕ НАДО делать.
На фирме одного моего знакомог