Сообщество - Лига Сисадминов

Лига Сисадминов

2 410 постов 18 930 подписчиков

Популярные теги в сообществе:

7
Вопрос из ленты «Эксперты»

Разграничение прав на шары

Всем доброго времени суток!
Есть сервер SRV-JANUS (Windows2016 русская версия), на котором поднят контроллер домена POS.local. В домене есть два сайта internal (192.168.0.0/23) и external (192.168.5.0/24). Сервер SRV-JANUS смотрит в сайты двумя физическими портами (192.168.0.6 и 192.168.5.6).

Также на сервере поднят DFS с двумя расшаренными папками POS.local/Share/Обмен (физически расположена на E:/Exchange) и POS.local/Share/Общая (физически расположена на D:/Storage).

Нужно для папки POS.local/Share/Обмен дать доступ для всех пользователей домена, а для папки POS.local/Share/Общая дать доступ только доменным пользователям, которые авторизовались через компьютеры, которые входят в сайт internal. Причем пользователи могут авторизовываться под своей учеткой как в internal, так и в external.

Подскажите, пожалуйста, в какую сторону копать. Перепробовал и NTFS разграничение и DFS. Но уперся в то, что могу ограничивать только права пользователей без привязки к конкретным машинам.

59

Хабр пробивает донья или будьте осторожны в копроблогах - 03

Для ЛЛ: Мало кто знает, например, что у слова "дно" есть форма множественного числа - и это не "днища", а "донья". Про дичь и чушь в копроблогах Хабра.

На этот раз отличился копроблог RUVDS со статьей «Почему мы перешли на RAID 10».

Сначала вспомним базу.

RAID 0 - Striped Disk Array without Fault Tolerance.
Плюсы: пишем на все диски, читаем со всех дисков.
Write penalty – отсутствует.
Минусы: потеряли диск – потеряли данные.
Минимальное число дисков – 2.

RAID 1 – Mirror
Плюсы: пишем на все диски одинаковые данные, читаем со всех дисков.
потеряли диск – ну и ладно, считали все что было с оставшегося.
Write penalty – х2. То есть, чтобы записать 1 бит, надо выполнить и дождаться выполнения двух операций – на, условно, первый и второй диски, то есть на запись Mirror будет в два раза медленнее.
Минусы: полезная емкость - пополам (/2) для two-way mirror, бывает и 3-way
Минимальное число дисков – 2.

RAID 5 – одинарная четность.
Плюсы: пишем на все диски данные, и на один диск – итоги XOR. При выходе из строя любого диска – заменяем диск, применяем математику, восстанавливаем данные.
Write penalty (точнее, rewrite penalty) – 4, 4 операции: считать данные, считать четность, записать новые данные, записать новую четность.
Минусы: при выходе из строя еще одного диска – теряем данные.
Полезная емкость – N-1
Минимальное число дисков – 3 (данные, данные, четность)

RAID 6 – двойная четность.
Плюсы: пишем на все диски данные, и на два  диск – на один xor, на другой другую математику. При выходе из строя любого диска – заменяем диск, применяем математику, восстанавливаем данные.
Точно переживет выход из строя еще одного диска.
Минусы: Write penalty (точнее, rewrite penalty) – 6, 4 операции: считать данные, считать две четности, записать новые данные, записать две новые четности.
Полезная емкость – N-2
Минимальное число дисков – 4 (данные, данные, четность, четность)

RAID 10 – собираем два Raid 1, из них собираем Raid 0.
RAID DP, Raid triple parity – тройная четность плюс немного математической магии.

Немного магии.
Все производители RAID, как совсем железных, так и программных, используют разные фокусы для ускорения работы. Тут и буфер чтения и записи на raid, и mirror accelerated parity (MS), и SSD буфер на запись, и Write Anywhere File Layout (WAFL) – когда данные не перезаписываются, а пишутся в новые адреса, много тут всякой магии.

И немного современности.
Современные all-flash СХД могут вообще не использовать Raid 10. Те же Huawei Oceanstor Dorado используют Raid-5, RAID 6, RAID-TP (см. OceanStor Dorado 6.0.0 Basic Storage Service Configuration Guide)
Плюсы очевидны, емкость не пополам, а -2, -3, что легко компенсируется дедупликацией и сжатием. Скорость отличная за счет внутренних буферов (на батарейке) по 512 мб и больше.

Современные гиперконвергентные системы и вариации на тему Redundant Array of Inexpensive Servers (RAIS) or Redundant Array of Independent Nodes (RAIN) вообще не оперируют терминами raid, вместо этого используя термины Redundancy Factor (RF) и failure to tolerate (FTT) – то есть, число единиц хранения, которые могут выйти из строя. Про это можно почитать
Design and Operation Considerations When Using vSAN Fault Domains
Fault tolerance and storage efficiency on Azure Stack HCI and Windows Server clusters

Теперь, вспомнив базу, пойдем к статье - Почему мы перешли на RAID 10, и с первой строки
Недавно у нас развалился RAID 5.

Вопрос в чем. Идет 2025 год. Калькуляторы надежности рейдов в зависимости от числа неустранимых ошибок и наработки на отказ давно написаны, хотя там можно и руками посчитать. С 2010х существует эмпирическое правило – из дисков выше 1 Тб строить только R6. Откуда у них взялся R5, на каких дисках и на каком устройстве вы это собрали и зачем?

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

Он мог задать всего один вопрос. R5 ? Тогда мы не идем к вам. Так то серьезные дяди выкладывают статистики наработки разных моделей и партий дисков -  вот тут, Backblaze Drive Stats for Q1 2024.

Потом очень искренне смеялся над фразой, что ни одна схема резервирования RAID не даёт стопроцентной гарантии сохранности данных.

Дает 99.9999 и еще сколько то девяток – скажем, метрокластер в RAID-TP. Вполне достаточно.

Раньше всё хранилось в RAID 5 (в абсолютном большинстве случаев)

В RUVDS – ни ногой, что еще сказать. Плюс, а что поверх? Автор пишет про диски на отдельном сервере, значит у них поверх намазано? А что? Что из SDS требует именно RAID ? Да, вроде бы, ничего, и более того, всему что я видел из RAIN – локальные raid прямо противопоказаны.

В большинстве случаев это рабочая ситуация.

В современном мире с текущей надежностью механических дисков это не рабочая ситуация. Похоже, в RUVDS не смогли даже в онлайн калькулятор надежности.
О чем я и пишу уже скоро год – идет медленное, незаметное, подгнивание качества ИТ кадров. Все было хорошо, а потом у них R5.

В RAID 10 — резервирование 2N: это два RAID 1,

Это не так. R10 не защитит от выхода из строя второго диска из пары, поэтому там надежность не 2N.

Фактически переход на RAID 10 означает плюс два или плюс три диска в каждый сервер. Это дорого: диски, конечно, — расходники, но при этом недешёвые.

Заявление на построение отказоустойчивости на уровне отдельного диска для хостинга означает отсутствие любой системы RAIN – то есть, при отказе не диска, а контроллера, точно получим недоступность, и возможно и потерю данных.

Это NVMe-RAID?
Нет. У нас везде — SSD: они хорошо соединяются в массивы.

NVME это интерфейс. То есть выбор интерфейса стоит между SAS, SATA и NVME.
SSD – стандарт диска, причем с уходом Optane – других и нет, выбор идет между QLC SSD vs. SLC vs. MLC vs. TLC.
Поэтому формулировка NVME RAID попросту бессмысленна,  да и NVME SSD отлично собираются в RAID , хотя и с определенной потерей производительности, но я про это раньше писал.
Только это не нужно, точнее бессмысленно, если серверов хотя бы три и можно собрать RAIN. Лучше, конечно, 6 серверов. 8-10 в самый раз.

Кластер — это другой хороший отказоустойчивый подход. Но там уже сам кластер становится точкой отказа, и практика показывает, что не такой уж и редкой.

Почему сразу кластер? Можно хранить на внешней СХД. RAIN, нормальный , теплый и проприетарный, тоже не взрывается, кроме как от кривых рук.

Вместо заключения.

Всего на хабре 400-500 активно голосующих участников, и число голосующих который год падает. Статья набрала сотню плюсов, а точнее +78 и -2. То есть 78 человек из 400 считают статью с кучей ошибок – вполне нормальной. Ну что тут сказать. Допустим 10-20 голосов это чистая накрутка, и остается 50\500, 10% людей, которых к системам хранения пускать нельзя.
Silent Data Corruption , она же bit rot – вот и она, только в кадрах - люди принципиально не понимают, что тут не так

Показать полностью
45

Хабр пробивает донья или будьте осторожны в копроблогах - 01

Для ЛЛ: Мало кто знает, например, что у слова "дно" есть форма множественного числа - и это не "днища", а "донья".

С пару лет назад я почти перестал читать Хабр, а с год назад читать перестало иметь смысл – ну окей, печатный орган министерства по борьбе с ИТ репостит статьи «Как мы в едином порыве одобряем устаревание серверов Гугля» или «депутат, которому интернет приносят в папке, сказал что-то». Добавить унылые копроблоги с песнями «у нас все хорошо, вовсе мы и не валялись неделю, ваш МТС» и «приходите к нам, у нас есть откаты» (это не МТС и статью уже удалили).
Фоном идут комментаторы вида «я увидел вашу статью в два ночи и немедленно вспомнил пароль от аккаунта, который не использовал три года, вот насколько мерзотная ваша статья».

Однако, наш дурдом зажигает огни, и к статьям про похудение, поведение, дистанционное управление добавили статьи от маркетологов, которым статью писал ЯндексЖПТ. Ничем иным объяснить такой упешный поиск на ровном месте, на бильярдном столе, ямы с г, объяснить невозможно.

Статья называется “Я проверил, сколько вы платите за одинаковое железо в разных облаках”, и такого донного уровня я не видел с тех пор, как Гилева в очередной раз тыкали носом в абсолютное не понимание того, как работают виртуальные среды. Довели беднягу Гилева – он и комментарии удалил, и профиль удалил.

Что же в статье не так? Для начала, это статья в копроблоге «H3LLO.CLOUD» - то есть, никакой адекватности от нее ждать не приходится, но это еще ладно.

Шутки начинаются с самого начала:
Чем короче полоска, тем, вероятно, больше вас переподписывают или более старое железо предлагают. Что это за график — ниже
Идея очень простая: покупаю одинаковые тарифы на одинаковом железе

Так все же, автор заказывает одинаковое железо или не совсем одинаковое? Похоже, что автор вообще не понимает, что он покупает в облаке, и дальше наглядно это демонстрирует.

Но, перед тем как идти дальше, будет немного Пикабу образовательного.

Образовательное будет обязательно содержать ошибки и опечатки. Я недавно смог спутать Эдди Мерфи и Орландо Джонса, и нет мне оправдания. Ну хоть не спутал с Кетрин Зета Джонс.

Серверная виртуализация работает (в части управления процессорами) очень просто.
Сначала все процессорное время разбивается на слоты (слайсы). Примерно по 0.05 секунды.
Каждые 2-30 миллисекунд (1/1000 секунды) планировщик проверяет нагрузку на физических ядрах, и выдает таймслот (слайс) для исполнения vCPU <> pCPU.
для ESXi таймслот (слайс) по умолчанию – 50 миллисекунд.
vSphere 6.7 U2 & later CPU Scheduler modes: Default, SCA v1 and SCA v2
Performance of vSphere 6.7 Scheduling Options, 2019

Для Hyper-V размеры этого слота в открытой документации где-то были, но это не точно.
Для KVM и Xen мне лень искать.

Дальше начинается магия. Для тех, кто документацию и книги не читает, вся жизнь наполнена чудесами и магией, но, впрочем, как говорил один покойник, any sufficiently advanced technology is indistinguishable from magic.

Все современные сервера идут с преднастройками High performance \ Balanced \ Optimal power, плюс с возможностью авторазгона части ядер, плюс с вариантом «как именно спит процессор» - в C1 или C6, с mwait или без. И заодно угадайте, настраивает ли клауд провайдер свои сервера оптимальным образом, а точнее, проверяет ли их настройки, особенно после обновлений BIOS, и обновляет ли он этот BIOS.

У виртуальных машин могут быть приоритеты. Для процессорных ядер желательно, чтобы данные были в пределах Numa ноды. Для многопроцессорных машин желательно удерживать Strict Co–Scheduling или хотя бы Relaxed Co-scheduling. Дальше есть Latency Sensitivity. И все это время никакой жесткой привязки контекста исполнения процесса виртуальной машины к ядру – нет.

И только после этой магии, раздачи задач на CPU scheduler, начинается явление «переподписки» или соотношение:
«сколько всего виртуальных ядер выделено на все виртуальные машины хоста : сколько ядер (физических) у нас есть. При этом, поскольку у нас (обычно, так то сделать можно) нет никакого жесткого прибивания «этот контекст исполняется здесь», то переподписка может нас волновать, а может и не волновать. Если у вас сервер набит только базами данных, то лучше не надо, если какие-то веб сервисы, то и 4:1 нормально. Если VDI, то и 10:1 ок.
Статьи и заметки по теме:
Acceptable logical CPU oversubscription and vCPU ready time ;
CPU Oversubscription.
Дальше начинается общеизвестный факт, что CPU планировщик в ESXi будет получше планировщика в Linux – KVM (Red hat), что и дает ощутимые бонусы при переподписке. Если же у инженеров облака руки не кривые, то какие-то настройки KVM они покрутят. Но это не точно.

Теперь, вспомнив базу, вернемся к методике измерений в статье.

В качестве тестов был использован Geekbench 6, но не указано – он был взят «из коробки» или собран. Если из коробки, то из какой? Если собран, то как?

Как легко заметить из текста ниже, автор вообще не заморочился привести модель процессора, которую ему, кстати, гипервизор в виртуальную среду отдает. Как и не показал фактическую рабочую частоту процессора при тестах.

Не менее интересно, что автор вместо попыток анализа, написал про ощущение переподписки. Не попытку оценить CPU ready \ Cpu Steal Time. Ничего. Только «ощущения» и «чувствуется». В отрыве от частоты и каких-то метрик, кроме выполнения рандом теста.

В комментариях творится парад бреда, вида “Shared/Dedicated CPU”. Azure, например, оперирует только Azure Dedicated Hosts, в AWS тоже такого странного выбора нет – см. Supported CPU options for Amazon EC2 instance types.

Или де в комментариях автор статьи (km1337) пишет

Это когда физический CPU распределяется между несколькими виртуальными машинами так, что каждая использует достаточно малую его часть.

Как легко заметить, никакого разделения физических ядер \ CPU по частям нет. Есть очередь исполнения, есть планировщик набивания очереди исполнения. Конечно, при богатой фантазии это можно представить и как «разделение».

Огня в комментариях добавляет и Timeweb_Cloud с их:
У нас не OpenStack, а собственный KVM еще с 2016 года. Все компоненты кастомные и запатентованные.

OpenStack все же оркестратор, а KVM – гипервизор. В переводе на русский, звучит как-то на уровне «у нас управление движением автобусов идет не на автостанции, у нас свой автобус».

Далее надо сказать, что даже для трех серверов можно настроить DRS, Distributed Resource Scheduler, который будет пытаться отбалансировать виртуальный машины так, чтобы нагрузка была сделана более-менее равномерно в пределах кластера. Поскольку у автора статьи за сутки ничего не произошло, то вопрос, который можно было поднять, это именно работа DRS или, возможно, разнородное железо в кластерах облака. Но, ничего этого не сделано.

Модная концовка.

В очередной раз убедиться в том, что есть корреляция "компания дно" и "компания ведет дноблог на хабре" - бесценно.

Показать полностью
Отличная работа, все прочитано!