Отличная новость! Если ли шанс, что ваш клиент групповых политик будет со временем совместим с другими дистрибутивами Linux? Debian, Ubuntu, Astra? У нас разные задачи у разных подразделений и заставить всех использовать только один дистрибутив Linux пока что не представляется возможным. А ваш подход для миграции с AD мне кажется наиболее правильным, удобным и реалистичным.
Артём, спасибо! Несколько вопросов, если позволите. В этот раз мы указываем список нод эластика в текстовом файле, потому что этот способ лучше. Тогда почему в первой статье цикла вы так не сделали?
Второй вопрос касается ноды балансировщика, которая «Coordinating only» — я правильно понимаю, что это потенциальная точка отказа? Если у нас не будет работать этот эластик, то и кибана в целом ничего не покажет. Получается по-хорошему надо и балансировщик дублировать, а это уже получается к трём нодам кластера ещё два балансера — не перебор ли? Насколько он вообще нужен, при каком объёме нагрузки вы его рекомендуете? Просто раньше этой ролью не пользовались и непонятно, стоит ли начинать.
Артём, спасибо за статью! Подскажите по опыту (или по официальной документации) — если покупаются физические узлы исключительно под elasticsearch ноды, то какие лучше в них поставить процессоры (потоки или частота важнее?) и сколько памяти? Мне казалось, что я находил статьи о том, что не стоит в ноды эластика ставить больше 64ГБ оперативки, потому что Java, обратный индекс и вот это и всё. И если памяти будет больше, то в итоге скорость работы будет ниже. Эта информация всё ещё актуальна? Берём ноду на 64ГБ, ставим -Xmx32g и всё будет в порядке?
Не совсем так, по умолчанию (и по рекомендациям МС) агент SCOM работает из-под системы и с компами по сети и доменом ничего сделать не может. Это важно.
Не знаю, может ли выборка из порядка 15 хостов и 4 хранилкок общей сложностью примерно в сотню дисков являться репрезентативной, но в целом прям совсем ужасов именно о проблемах с файловой системой я за два года использования вспомнить не могу.
Однако минусы и косяки всё-таки встречались. Например, со временем оказалось, что block cloning, который так хорошо работает на пару с Veeam, весьма требователен к объёму оперативной памяти — лучше иметь на сервере по 1 Гб ОЗУ на каждый терабайт ReFS хранилища, ну или по крайней мере не ставить в реп на 20-40 ТБ меньше 32 гигов. В противном случае в момент удаления старой цепочки бэкапов механизм очистки ReFS скушает всю оперативку и сервер просто зависнет. Как временное решение на сервере с 16 Гб ОЗУ нам приходилось удалять файлы по одному, следить за расходом памяти и перезагружаться вручную 2-3 раза. С добавлением памяти проблема полностью ушла.
Также в этом году MS что-то нахимичил с обновлением драйвера ReFS и при некоторых операциях в Veeam, например, Health Check, скорость падала очень сильно. Всё полностью исправили в июльском обновлении, как временное решение можно было руками подменить файл драйвера на более старый, например, мартовский.
Ещё, конечно, хотелось бы получить дедупликацию для ReFS, для некоторых сценариев, типа VDI это было удобно. Также немного не хватает возможности закрепить конкретный файл на быстром или медленном тире в случае использования двух или трёх уровневого SOFS/S2D, хотя NTFS это позволял. С другой стороны на ReFS и перемещение данных между горячим и холодным тиром происходит постоянно, а не по расписанию, как раньше.
Наверное стоило упомянуть, что ReFS у нас используется (по крайней мере пока что) исключительно как файловая система на физических серверах — хранилки под Hyper-V на SOFS или S2D, а также бэкапный репозиторий Veeam B&R 9.5.
Плюс в том, что не нужно никогда делать chkdsk (точнее его не удастся запустить в принципе), файловая система всегда сканирует себя и лечится самостоятельно при необходимости. На ReFS наконец-то динамические VHDX диски работают с такой же скоростью, что и статические. Но даже если создавать статику (например, под Exchange), то она будет создана моментально независимо от размера — очень удобно.
На пару с Veeam файловая система ReFS позволяет задействовать функционал block cloning и почти «бесплатно» создавать synthetic full бэкапы, а занимать на диске они будут как обычный маленький инкремент.
Внутри виртуалок, если речь идёт о винде, по-прежнему исключительно NTFS, потому что часто нужно и квотирование и дедупликация — кстати тоже очень полезная фишка, которой в 2008R2 не было и в помине.
Решительно не разделяю ваших тёплых чувств к этому старью. Мне не нравился 2012, но очень хорошо зашёл 2012R2 — по моим ощущениям самая стабильная и отточенная за последние годы. 2016 в первый год был явно сырым, но сейчас уже можно пользоваться с удовольствием.
Пуск — это дело привычки, я уже не могу без менюшки, которая вылезает по клику правой кнопкой мыши в десятке и сервере 2016 — там есть практически все оснастки, которые нужны в повседневной работе.
Опять же консоль появилась удобная из коробки, можно и cmd и PowerShell нормально растянуть на весь экран и пользоваться ctrl+c/ctrl+v.
Обновления куммулятивные — это очень удобно, не понимаю я радости копания в десятках мелких пакетов, которые в последние месяцы всё хуже и хуже ставятся на измученные жизнью 2008 R2. Само собой мы ждём неделю после выхода, потом две недели на тестовой группе, потом все остальные. Да, порой что-то ломается, но либо сразу есть workaround, либо можно не ставить одно обновление и дождаться исправления в следующем месяце.
Современный Hyper-V, ReFS, Storage Spaces, Storage Spaces Direct, Server Core без графики с удалённым управлением оснастками или через PoSH — всё это активно используем и с сентября 2017 года никаких значимых нареканий на новый Windows Server не было.
Отправлял заявку, но не получил никакого ответа — ни положительного, ни отрицательного. Долгое рассмотрение, отказ или что-то не работало и стоит отправить заявку повторно?
Спасибо за интересный материал! Хотелось бы услышать авторитетное мнение о том, как правильно защититься от угрозы — «Выход из строя коммутатора top-of-the-rack». Потому что как спланировать сервера и каналы между ЦОДами вполне понятно, а вот как обезопасить себя от поломки корневого маршрутизатора — не совсем. Понятно, что они кластеризуются, но всё равно остаются близко друг от друга и пожар/потоп порушит всю такую сеть целиком.
Там есть подвох — следующая задача запустится только в том случае, если предыдущая закончилась со статусом Success или Warning. Так что если она Fail, то и остальные тоже будут Fail. По крайней мере в Veeam B&R 8 было так.
Не буду утверждать, что я точно прав и тестировал всё по фэн-шую, если получится перепроверить и поделиться развёрнутым и аргументированным результатом — обязательно это сделаю. Было это уже больше полугода назад, возможно ещё пришлось поменять размер блока на самом CSV-томе, не только на VHDX файле. Сделать новый том с дефолтными настройками боюсь уже не смогу — весь объём отдан под рабочую нагрузку.
Виталий, я тоже подтверждаю результаты, которые получились у инженеров Dataline, хотя в нашем случае разница была не столь значительная: SSD Tier, VHDX созданный со секторами по умолчанию — порядка 300 Мбайт/с на запись в тесте diskspd, после создания нового VHDX с секторами 512/512 — порядка 1200 МБайт/с в таком же тесте. К сожалению, сейчас не могу воспроизвести всё повторно и показать повторные логи, но на неделе может быть получится, если это действительно вызывает такие сомнения.
Также об этой проблеме очень часто упоминает Алексей Кибкало на своих курсах по Hyper-V, системах хранения, кластеризации и не только.
Да, я не совсем правильно выразился: разумеется Storage Spaces поддерживает SATA-диски, но не в варианте Scale-Out файлового сервера, когда одной или несколькими JBOD-полками управляют 2 и более контроллеров. JBOD-полка должна быть именно SAS`овская и никак иначе. Если сервер один и SS используется в качестве простого «программного RAID`а», то да, диски могут быть любыми. Ссылка на технет: https://technet.microsoft.com/en-us/library/hh831739(v=ws.11).aspx
Спасибо, что поделились полезным опытом! Жалко, что маловато просмотров и совсем нет комментариев, хотя тема, на мой взгляд, интересная и перспективная.
Обратите внимание, что у вас в статье явно закралась ошибка: классический Storage Spaces, что в 2012R2, что в 2016 не умеет работать с SATA и NVMe дисками — только (NL-)SAS. Эта фича появляется только в Storage Spaces Direct, так что лучше исправить текст, дабы не вводить людей в заблуждение.
Сейчас у себя в компании тестируем S2D, правда на относительно старом оборудовании и с 10 gbe сетью без поддержки RDMA — пока не удаётся заставить работать систему с нормальной скоростью при использовании SSD дисков в качестве кэша и со стабильно высокой скоростью при использовании горячего/холодного тира и ReFS.
Интересно почитать, какие у вас возникли трудности при тестировании S2D и как вы с ними боролись. Подписался на блог, жду новых статей :)
Не забывайте, что скоро официальный релиз Windows Server 2016, а там есть редакция Nano, которая, в том числе, поддерживает роль файлового сервера и крутые программные аналоги RAID, в том числе RAID-6 (RAID DP). И весит она совсем мало и работает с флешки и апдейты, заставляющие перезагружаться, обещают выпускать всего 4-6 раз в год. Да, это не для всех, да надо будет много разбираться с настройкой в консоли и управлять этим только удалённо, но я бы всё равно главным недостатком Windows Server считал его цену, а не странные мифы и придирки.
Спасибо за наглядный материал! Не планируется ли что-то подобное, но на примере так называемого commodity-железа. Типа Supermicro или хотя бы разработок от отечественных компаний. Потому что все эти облака и аппаратные снимки — это здорово, но санкции и режим заставляют работать несколько по-другому. Спасибо!
Чаще всего встречаю использование pgAdmin.
Отличная новость! Если ли шанс, что ваш клиент групповых политик будет со временем совместим с другими дистрибутивами Linux? Debian, Ubuntu, Astra? У нас разные задачи у разных подразделений и заставить всех использовать только один дистрибутив Linux пока что не представляется возможным. А ваш подход для миграции с AD мне кажется наиболее правильным, удобным и реалистичным.
Спасибо за полезную статью! Почерпнул для себя несколько новых приёмов и в целом всё лучше улеглось в голове.
Второй вопрос касается ноды балансировщика, которая «Coordinating only» — я правильно понимаю, что это потенциальная точка отказа? Если у нас не будет работать этот эластик, то и кибана в целом ничего не покажет. Получается по-хорошему надо и балансировщик дублировать, а это уже получается к трём нодам кластера ещё два балансера — не перебор ли? Насколько он вообще нужен, при каком объёме нагрузки вы его рекомендуете? Просто раньше этой ролью не пользовались и непонятно, стоит ли начинать.
Однако минусы и косяки всё-таки встречались. Например, со временем оказалось, что block cloning, который так хорошо работает на пару с Veeam, весьма требователен к объёму оперативной памяти — лучше иметь на сервере по 1 Гб ОЗУ на каждый терабайт ReFS хранилища, ну или по крайней мере не ставить в реп на 20-40 ТБ меньше 32 гигов. В противном случае в момент удаления старой цепочки бэкапов механизм очистки ReFS скушает всю оперативку и сервер просто зависнет. Как временное решение на сервере с 16 Гб ОЗУ нам приходилось удалять файлы по одному, следить за расходом памяти и перезагружаться вручную 2-3 раза. С добавлением памяти проблема полностью ушла.
Также в этом году MS что-то нахимичил с обновлением драйвера ReFS и при некоторых операциях в Veeam, например, Health Check, скорость падала очень сильно. Всё полностью исправили в июльском обновлении, как временное решение можно было руками подменить файл драйвера на более старый, например, мартовский.
Ещё, конечно, хотелось бы получить дедупликацию для ReFS, для некоторых сценариев, типа VDI это было удобно. Также немного не хватает возможности закрепить конкретный файл на быстром или медленном тире в случае использования двух или трёх уровневого SOFS/S2D, хотя NTFS это позволял. С другой стороны на ReFS и перемещение данных между горячим и холодным тиром происходит постоянно, а не по расписанию, как раньше.
Плюс в том, что не нужно никогда делать chkdsk (точнее его не удастся запустить в принципе), файловая система всегда сканирует себя и лечится самостоятельно при необходимости. На ReFS наконец-то динамические VHDX диски работают с такой же скоростью, что и статические. Но даже если создавать статику (например, под Exchange), то она будет создана моментально независимо от размера — очень удобно.
На пару с Veeam файловая система ReFS позволяет задействовать функционал block cloning и почти «бесплатно» создавать synthetic full бэкапы, а занимать на диске они будут как обычный маленький инкремент.
Внутри виртуалок, если речь идёт о винде, по-прежнему исключительно NTFS, потому что часто нужно и квотирование и дедупликация — кстати тоже очень полезная фишка, которой в 2008R2 не было и в помине.
Пуск — это дело привычки, я уже не могу без менюшки, которая вылезает по клику правой кнопкой мыши в десятке и сервере 2016 — там есть практически все оснастки, которые нужны в повседневной работе.
Опять же консоль появилась удобная из коробки, можно и cmd и PowerShell нормально растянуть на весь экран и пользоваться ctrl+c/ctrl+v.
Обновления куммулятивные — это очень удобно, не понимаю я радости копания в десятках мелких пакетов, которые в последние месяцы всё хуже и хуже ставятся на измученные жизнью 2008 R2. Само собой мы ждём неделю после выхода, потом две недели на тестовой группе, потом все остальные. Да, порой что-то ломается, но либо сразу есть workaround, либо можно не ставить одно обновление и дождаться исправления в следующем месяце.
Современный Hyper-V, ReFS, Storage Spaces, Storage Spaces Direct, Server Core без графики с удалённым управлением оснастками или через PoSH — всё это активно используем и с сентября 2017 года никаких значимых нареканий на новый Windows Server не было.
Не буду утверждать, что я точно прав и тестировал всё по фэн-шую, если получится перепроверить и поделиться развёрнутым и аргументированным результатом — обязательно это сделаю. Было это уже больше полугода назад, возможно ещё пришлось поменять размер блока на самом CSV-томе, не только на VHDX файле. Сделать новый том с дефолтными настройками боюсь уже не смогу — весь объём отдан под рабочую нагрузку.
Также об этой проблеме очень часто упоминает Алексей Кибкало на своих курсах по Hyper-V, системах хранения, кластеризации и не только.
Обратите внимание, что у вас в статье явно закралась ошибка: классический Storage Spaces, что в 2012R2, что в 2016 не умеет работать с SATA и NVMe дисками — только (NL-)SAS. Эта фича появляется только в Storage Spaces Direct, так что лучше исправить текст, дабы не вводить людей в заблуждение.
Сейчас у себя в компании тестируем S2D, правда на относительно старом оборудовании и с 10 gbe сетью без поддержки RDMA — пока не удаётся заставить работать систему с нормальной скоростью при использовании SSD дисков в качестве кэша и со стабильно высокой скоростью при использовании горячего/холодного тира и ReFS.
Интересно почитать, какие у вас возникли трудности при тестировании S2D и как вы с ними боролись. Подписался на блог, жду новых статей :)