Имхо, слишком обширная тема для комментов. Кластер часто дорог, в каждом софте еще и реализуется по своему - в итоге на поддержку нужно больше спецов. В случае краха хоста ВМ тихо запускается на другой ноде, никакого восстановления из архива не нужно - для виртуалки это выглядит, будто нажали "ресет". Другое дело, что если у 1С (ну чисто энтерпрайзный подход) программный ключ, он может увидеть изменение аппаратной конфигурации и встать в позу. Да и заметка не про 1С. :)
зы Для полноценной работы failover в виртуализации нужен shared storage, напр., СХД подключенная к хостам по FC.
В том посыл статьи и состоял - открыть глаза на особенности лицензирования Майкрософт. Юристов для составления схем и соглашений в МС выбирали грамотно. Некоторые недобросовестные партнеры (это вы минусуете мне карму? :)) предлагают такие схемы и некоторые невнимательные заказчики на это соглашаются. Но отвечать при проверке заказчику, а не продавцу.
Касаемо виртуализации - действительно, не все однозначно. Однако тесты показывают неплохие результаты и для 1С. В энтерпрайзе у виртуализации задача несколько смещается от сверхпроизводительности в сторону доступности. Как быстро вы восстановите работу своего сервиса в случае аппаратного сбоя? С виртуализацией это лишь время перезапуска ВМ на другой ноде.
По ядрам — не в тему статьи, но M$ дает четкий ответ на этот вопрос:
When running SQL Server in a physical OSE, all physical cores on the server must be licensed. Т.е. лицензировать нужно по физическим ядрам.
Но если речь о ВМ, то лицензировать следует все виртуальные ядра:
Similar to the Per Core licensing model in physical OSEs, all virtual cores (v-cores) supporting virtual OSEs that are running instances of SQL Server 2017 software must be licensed accordingly.
Что касается нескольких экземпляров в одной ОС простите, одном операционном окружении :), то ограничений на их кол-во нет:
Each server license allows customers to run any number of SQL Server instances in a single OSE, either physical or virtual.
Засеките время, затраченное службой ТП и пользователем на запуск и интерпретацию iperf'а. Умножьте на количество пользователей с жалобами. Потом на количество дней. Переведите в деньги, которые теряет бизнес. Это как пример.
iperf — прекрасный инструмент, но не для них.
Да, для небольшой конторы в 3-4-5 десятков человек Librespeed не более чем игрушка.
На машине в ЦОДе? Вероятно, у Вас иначе, но мы не можем позволить себе такую роскошь и разрешить всем пользователям запускать любые программы на серверах.
Запускать у соседа? И что они измерят? :)
1. Да, это просто. Для нас с вами. Я Вам завидую, если все ваши пользователи без труда смогут запустить командную строку, скопировать программу, запустить с параметрами, внятно интерпретировать результат, да еще и поделиться им. ))
2. И iperf -s тоже где-то надо запустить, что не каждому пользователю позволено.
3. Была попытка запустить пункт 2 демоном. Но, в силу пункта 1, оно не прижилось…
Да, он по сути программный. Однако управляется нормально, причем единообразно и в M$ Окнах, и в Linux, и в ESXi (который, будучи энтерпрайзным продуктом, чисто программные массивы не поддерживает вообще). Об управлении из ОС есть раздел в статье.
После замены диска контроллер сам соберет массив без каких либо дополнительных настроек со стороны ОС.
О потенциальной опасности этого (как, впрочем, и любого другого с железной составляющей) контроллера против программного массива есть предупреждение. Но надо помнить, что идеальная надежность — штука почти не достижимая и надо понимать, против каких рисков какие меры следует применять.
Обратите внимание, драйвер rhel7u8 спокойно работает в текущей CentOS 7.9. И в 6-ке конкретно на этой машине пройдено не мало апдейтов, все ровно. Благо, она в парке всего одна с таким адаптером. Год лежала без дела, дождалась, нашлось ей применение. )
На грабли можно наступить и с отказом вполне надежных настоящих аппаратных и Адаптеков и LSI — через это тоже проходили.
Выпилили старье — и не надо держаться за это «наследие». Оно тянет назад. Нет смысла поддерживать его во всем многообразии везде и всюду. Ядро будет несоразмерно распухшим. Старому железу — старые ОС, 7-ка еще до 2024 поддерживается.
Никого не оправдываю, но у всех бывают ошибки. И у Intel'а и RH и M$ и у <впишите своего любимого вендора>. RedHat не так часто вносит критические изменения и для этого есть какие-то причины. А если что-то и не работает, у Вас же есть подписка и можете обратиться в ТП? )) Ну а если нет — система живет без гарантии, на свой страх и риск. Об этом всегда следует помнить, не зависимо от от любви или ненависти к Linux. Равно как и в ОС от M$ тоже случаются чудеса, кратно усиливающиеся после обновлений, вплоть до BSoD.
В документации ОС процесс обновления описан как для 5-ки (и более ранним)), так и по 7-ке, в статье есть ссылка на него. Любопытные могут ознакомиться, там много интересного. Есть и по 8.
Опять же в родной документации к ОС есть и описание этой ситуации. В статье также есть на нее ссылка.
Перевод чего? Если уже говорить о переводах, то это скорее что-то около HPE-шное. Но статья — туториал, а не перевод. Просто обмен опытом по вполне конкретной задаче. На HPE-шные ресурсы тоже указаны ссылки.
Итого: статья полное пошаговое руководство по конкретной задаче с отсылкой к первоисточникам.
Не за что!
Я бы не стал разводить холиворы, и статьи не об этом — не было идеи сравнения этих продуктов. Очень много зависит от сценария использования, для крупных я бы смотрел в сторону oVirt. Что oVirt/RHV, что KVM/RHEL — продукты одного разработчика. Кто, как не они смогут их лучше в комплексе приготовить?
Где-то попадалась фраза типа «Проксмокс красивше. Овирт функциональнее.» :) Имхо, oVirt/RHV более зрелый продукт. Не удалось найти, как сейчас в Proxmox VE обстоит с FC/FCoE.
OpenNebula правильнее сравнивать с OpenStack, не oVirt или PVE. Т.е. позиционирование у продуктов разное, oVirt/RHV/Proxmox VE/vSphere — это enterprise virtualization (или infrastructure virtualization, кому как нравится), OpenNebula/OpenStack — cloud platform.
Полноценное сравнение — обширная тема, недостаточно одного комментария. В любом случае, каждый сценарий уникален и требует индивидуального подхода. Где-то лучше PVE, где-то oVirt, где-то vSphere и т.д. Хорошо, когда есть выбор и можно и нужно делать его осознанно, и самостоятельно пощупать.
По VDO
Есть интерес поиграться в лабе, но так дедупликацией у нас занимаются СХД на аппаратном уровне. Поэтому нет, под промышленной нагрузкой не использовали.
Продолжение будет по мере возможности. )
На CentOS 8 текущая стабильная 4.3.9 официально не поддерживается (у нее требования 7.7 or later but < 8). А вот 4.4, которая сейчас 4.4.0 Alpha, наоборот, ориентирована на 8-ку (Some of the features included in oVirt 4.4.0 Alpha require content that will be available in CentOS Linux 8.1).
Сергей, спасибо за комментарий!
Практически со всем соглашусь, но, во избежание разрастания статьи умышленно старался сократить ее, нещадно отсекая многие важные вещи, а аудиторию в заголовке обозначил как SMB. Боролся даже с желанием хотя бы простецкий график типа darkstat прикрутить! А вообще статья — проба пера, OpenVPN просто первый под руку попался. )
600+ — уже не самый типовой SMB. Как правило, специалисты в такой организации знают и понимают как строить подобные системы и для них статья мелковата, хотя может подойти как quick start.
По пунктам.
Настройка межсетевого экрана помещена в секции настройка сети. Дабы не затрагивать инфрастуктуру, архитектуру которой предугадать в статье невозможно, предложил фильтровать встроенным iptables. Да, персонализация ACL не затронута. Анонсировать стоит только нужные маршруты, а маршрут по умолчанию на клиенте не меняется.
RADIUS используется не в каждом SMB.
На разных клиентах импорт профиля проходит довольно гладко, с этим проблем замечено не было. Если бы выдавался набор файлов в виде конфига, сертификатов, ключей… Это пользователю объяснить было бы сложно. Но с профилем и инструкцией с картинками большинство пользователей с этой задачей справляются самостоятельно.
Клиентская сторона за пределами статьи, ибо кратко описать эту боль невозможно. Трудно предсказать, что и в какой конфигурации нас будет ожидать по ту сторону туннеля.
Статистика — обширная тема, и не в каждой организации есть СБшники. Но да, она не менее важна, чем мониторинг и архивация.
Если у коллег возникнет предложение, можно написать статью типа «продвинутые настройки OpenVPN» или «OpenVPN для 1000 пользователей».
Имхо, слишком обширная тема для комментов. Кластер часто дорог, в каждом софте еще и реализуется по своему - в итоге на поддержку нужно больше спецов. В случае краха хоста ВМ тихо запускается на другой ноде, никакого восстановления из архива не нужно - для виртуалки это выглядит, будто нажали "ресет". Другое дело, что если у 1С (ну чисто энтерпрайзный подход) программный ключ, он может увидеть изменение аппаратной конфигурации и встать в позу. Да и заметка не про 1С. :)
зы Для полноценной работы failover в виртуализации нужен shared storage, напр., СХД подключенная к хостам по FC.
В том посыл статьи и состоял - открыть глаза на особенности лицензирования Майкрософт. Юристов для составления схем и соглашений в МС выбирали грамотно. Некоторые недобросовестные партнеры (это вы минусуете мне карму? :)) предлагают такие схемы и некоторые невнимательные заказчики на это соглашаются. Но отвечать при проверке заказчику, а не продавцу.
Касаемо виртуализации - действительно, не все однозначно. Однако тесты показывают неплохие результаты и для 1С. В энтерпрайзе у виртуализации задача несколько смещается от сверхпроизводительности в сторону доступности. Как быстро вы восстановите работу своего сервиса в случае аппаратного сбоя? С виртуализацией это лишь время перезапуска ВМ на другой ноде.
Прошу прощения, PostgreSQL мне импонирует много больше, но какое отношение к теме статьи?
When running SQL Server in a physical OSE, all physical cores on the server must be licensed. Т.е. лицензировать нужно по физическим ядрам.
Но если речь о ВМ, то лицензировать следует все виртуальные ядра:
Similar to the Per Core licensing model in physical OSEs, all virtual cores (v-cores) supporting virtual OSEs that are running instances of SQL Server 2017 software must be licensed accordingly.
Что касается нескольких экземпляров в
одной ОСпростите, одном операционном окружении :), то ограничений на их кол-во нет:Each server license allows customers to run any number of SQL Server instances in a single OSE, either physical or virtual.
iperf — прекрасный инструмент, но не для них.
Да, для небольшой конторы в 3-4-5 десятков человек Librespeed не более чем игрушка.
Запускать у соседа? И что они измерят? :)
2. И iperf -s тоже где-то надо запустить, что не каждому пользователю позволено.
3. Была попытка запустить пункт 2 демоном. Но, в силу пункта 1, оно не прижилось…
После замены диска контроллер сам соберет массив без каких либо дополнительных настроек со стороны ОС.
О потенциальной опасности этого (как, впрочем, и любого другого с железной составляющей) контроллера против программного массива есть предупреждение. Но надо помнить, что идеальная надежность — штука почти не достижимая и надо понимать, против каких рисков какие меры следует применять.
На грабли можно наступить и с отказом вполне надежных настоящих аппаратных и Адаптеков и LSI — через это тоже проходили.
Выпилили старье — и не надо держаться за это «наследие». Оно тянет назад. Нет смысла поддерживать его во всем многообразии везде и всюду. Ядро будет несоразмерно распухшим. Старому железу — старые ОС, 7-ка еще до 2024 поддерживается.
Опять же в родной документации к ОС есть и описание этой ситуации. В статье также есть на нее ссылка.
Перевод чего? Если уже говорить о переводах, то это скорее что-то около HPE-шное. Но статья — туториал, а не перевод. Просто обмен опытом по вполне конкретной задаче. На HPE-шные ресурсы тоже указаны ссылки.
Итого: статья полное пошаговое руководство по конкретной задаче с отсылкой к первоисточникам.
Я бы не стал разводить холиворы, и статьи не об этом — не было идеи сравнения этих продуктов. Очень много зависит от сценария использования, для крупных я бы смотрел в сторону oVirt. Что oVirt/RHV, что KVM/RHEL — продукты одного разработчика. Кто, как не они смогут их лучше в комплексе приготовить?
Где-то попадалась фраза типа «Проксмокс красивше. Овирт функциональнее.» :) Имхо, oVirt/RHV более зрелый продукт. Не удалось найти, как сейчас в Proxmox VE обстоит с FC/FCoE.
OpenNebula правильнее сравнивать с OpenStack, не oVirt или PVE. Т.е. позиционирование у продуктов разное, oVirt/RHV/Proxmox VE/vSphere — это enterprise virtualization (или infrastructure virtualization, кому как нравится), OpenNebula/OpenStack — cloud platform.
Полноценное сравнение — обширная тема, недостаточно одного комментария. В любом случае, каждый сценарий уникален и требует индивидуального подхода. Где-то лучше PVE, где-то oVirt, где-то vSphere и т.д. Хорошо, когда есть выбор и можно и нужно делать его осознанно, и самостоятельно пощупать.
По VDO
Есть интерес поиграться в лабе, но так дедупликацией у нас занимаются СХД на аппаратном уровне. Поэтому нет, под промышленной нагрузкой не использовали.
На CentOS 8 текущая стабильная 4.3.9 официально не поддерживается (у нее требования 7.7 or later but < 8). А вот 4.4, которая сейчас 4.4.0 Alpha, наоборот, ориентирована на 8-ку (Some of the features included in oVirt 4.4.0 Alpha require content that will be available in CentOS Linux 8.1).
Практически со всем соглашусь, но, во избежание разрастания статьи умышленно старался сократить ее, нещадно отсекая многие важные вещи, а аудиторию в заголовке обозначил как SMB. Боролся даже с желанием хотя бы простецкий график типа darkstat прикрутить! А вообще статья — проба пера, OpenVPN просто первый под руку попался. )
600+ — уже не самый типовой SMB. Как правило, специалисты в такой организации знают и понимают как строить подобные системы и для них статья мелковата, хотя может подойти как quick start.
По пунктам.
Если у коллег возникнет предложение, можно написать статью типа «продвинутые настройки OpenVPN» или «OpenVPN для 1000 пользователей».