Последние сообщения блогов

Mikrotik resuscitation

0

Металверк Metalverk

18.12.202222:0318.12.2022 22:03:57

Друзья ловите лайфхач по реанимации микрота:
Как известно вышла ОС7, естественно сырая. Очень нужен был IPv6 из коробки и млею от ZeroTier, выждал несколько релизов, наслушался положительных отзывов и решил накатить. Всё делал по науке, через нетинсталл, с форматированием памяти. Парк большой и на одном споткнулся. Свежий дистрибутив нетинсталла 7.6 устройства не видит, посмотрел фактори firmware оказалась 6.44, скачал с оф. сайта с архива релиз 6.44, устройство увидело но не шьёт. Процесс начинается и тут же статус реди, вообще никак! Почитал форумы народ тоже в ступоре, причём та же картина и на старых версиях, никто ничего толком не знает. Путём экспериментов нашёл работающий способ. А теперь внимание! Запускаете нетинсталл под админом версии фактори firmware Вашего устройства, как только устройство определится, микрот с установленной связью не трогаем, закрываем нетинсталл и открываем новый, последнего релиза. Т.к сервер уже был поднят и соединение состоялось, микрот без проблем цепляется к новому серверу нетисталла, и весь функционал работает по умолчанию. Лёгким нажатием кнопки инсталл, форматируем память и зашиваем новый релиз. Два месяца жёсткой эксплуатации никаких траблов не выявили. Таким же способом реанимировал ещё пару устройств, которые давно умерли, но рука не поднималась выбросить. Пользуетесь!

Металверк Metalverk

18.12.202222:0318.12.2022 22:03:57

Просмотров: 729 Комментариев: 0 0

Теги: Mikrotik netinstall firmware

failover cluster

0

Металверк Metalverk

25.08.201915:2125.08.2019 15:21:53

Если раньше мы говорили, что бэкапы это наше всё, то с современным уровнем развития технологий, всё больше приходит понимание, что кластеризация это будущее доступное уже сейчас. Причём, если раньше мы знали о подобных технологиях, но они были астрономически дорогими и сложными и доступными только крупным организациям, то сейчас, начиная с зачатков spaces storage, мы имеем уже s2direct и полноценную кластеризацию не только приложений но и серверов в целом, без необходимости отдельных схд, что даёт полноценную отказоустойчивую кластеризацию на доступных и не дорогих серверных решениях.
Если раньше мы автобэкапировали базы на все доступные носители, что не раз спасало в критических ситуациях, но требовалось много времени для реанимации нод, что приводило к простою, а время как известно деньги. То сейчас, грамотно реализуя failover cluster, хотя бы даже всего на двух нодах, мы добиваемся работоспособности всего предприятия при падении одного из нод. В итоге, как водится: озадачился я в начале лета обеспечить отказоустойчивость серверов. Задачу я поставил себе во-первых, сделать растянутый кластер, т.е. я не хотел привязывать себя к одному месту, мало ли, свет выключат или ещё какой форсмажор. Во-вторых, никакого зависимого схд, при его отключении весь смысл отказоустойчивости исчезает. И в-третьих максимально, все серверные решения, такие как SQL сервер и сервер информационной базы, Web сервер информационной базы, бэкап этого Web-сервера, FTP сервер для обменов, файловый сервер, пул видео серверов всей периферии, SMTP сервер для почты, DNS и DHCP сервера для локальной архитектуры сети, сервер телефонии + SMS сервер и контроллер домена, всё это разместить именно в кластере с делегированием распределения нагрузки в том числе и при отказах нод.
Первое что я сделал понимая, что необходим широкий канал для миграции и репликации, это провёл переговоры с кровопийцами-провайдерами ), в итоге удалось купить по сходной цене каналы достаточной проп. способности.
Далее не желая зависеть от географии, часть серверов я решил разместить в облаке, для чего также по сходной цене приобрёл хостинг. Следующим этапом ревизия существующего железа. Значительных модернизаций не потребовалось, единственное что пришлось добавить объём хранения. Ничего не покупал, просто задействовал то что пылилось на полках.
Далее настройка: прочёл литератуку, перевёл несколько статей, чтобы не мучить железо, решил тренироваться на виртуальных машинах. Проблем не возникло, все настроил с первого раза, но когда стал переходить на железо, возникли траблы. Во-первых железо разнородное а вендор рекомендует идентичное. Во-вторых пришлось помучиться с хранением, s2d поддерживает шину SAS, а у меня и raid и всё что угодно. Короче кто пойдет по моему пути, сэкономлю Вам время дам пару советов:
- на всех узлах брандмауэр разрешаем порты TCP - 4899, 860, 3260; UDP – 3343
- на всех серверах, диспетчер ДНС ставим сервер пересылки наш центр шлюз + на всех сетевухах убираем автоматическое назначение метрики + желательно суффикс прописать.
- вот здесь пришлось помучиться, нашёл путём перебора ключей в реестре:
В пауэршеле проверяем BusType:
Get-Disk | select Number, FriendlyName, OperationalStatus, Size, PartitionStyle, BusType | sort Number | ft -AutoSize
меняем шину дисков на SAS: на обоих нодах правим в реестре:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\iaStorAVC\Parameters вместо 8 ставим a

- s2d не понимает неопределенные типы дисков:
проверяем тип носителей: Get-PhysicalDisk | Select-Object FriendlyName, UniqueID, BusType, mediatype
далее, если тип носителей каких нибудь дисков не определён в пауершеле под админом set-physicaldisk -UniqueID "ваш номер" -mediatype HDD, но всё это надо делать когда диски уже в пуле, иначе данные не сохраняются!

- когда создаёшь виртуал диск из пула, может возникнуть трабл из за одинаковых имён дисков, переименуй их:
Get-PhysicalDisk | Select-Object FriendlyName, UniqueID
set-physicaldisk -UniqueID "Ваш номер" -NewFriendlyName "нужное имя"
- были проблемы с репликацией виртуалок, устранил путём правки соответствия адресов и имен хостов в файле hosts, просто прописал имя DNS и IP каждого сервера вручную на всех нодах.
В итоге после тестов запустил в продакшн. Учётная прога по скорости формирования отчётов и проведения доков как реактивный самолёт пятого поколения по сравнению с кукурузником. Я сделал по две ноды в двух офисах + две виртуалки в облаке, таким образом я избавился от переживаний что выключат свет или инет. Сделал краш, отключал поочередно пять серверов, имитировал сбои, отключал службы, все процессы автоматом мигрировали на единственный оставшийся работающим сервак, это впечатляет, это уровень работы полноценного дата центра, это действительно невероятно крутбл! А кроме того я могу управлять всеми бизнес-процессами из любой точки планеты.
P.S. а автобэкапы я всё же оставил, технологии хорошо, а бережёного Бог бережет)

Металверк Metalverk

25.08.201915:2125.08.2019 15:21:53

Просмотров: 2173 Комментариев: 0 0

Теги: failover cluster, pool, s2d, storage spaces, отказоустойчивая кластеризация

траблшутинг RAM на железе для гипервизора

0

Металверк Metalverk

23.05.201915:2223.05.2019 15:22:39

Может пригодится кому: после наката обновлений стал наблюдаться коматоз виндовой серверной ОС.
симптомы: резкая утечка RAM и BSOD.
После диагностики диагноз: балунинг на уровне хоста гипервизора, в какой то момент гостевые ОС переизбыточно используют файл подкачки и в результате своп.
терапия: контроллер на мамке по дефолту криво отрабатывает ECC, включение соответствующей галочки в биосе успешно лечит проблему.

Металверк Metalverk

23.05.201915:2223.05.2019 15:22:39

Просмотров: 1766 Комментариев: 0 0

Теги: RAM ECC