• Виртуальные Check Point'ы: чек-лист по настройке
    0
    Спасибо! С IPsec есть заморочки, приходится использовать SNX и идти через SSL VPN.
  • Виртуальные Check Point'ы: чек-лист по настройке
    0
    Да, это правда. С другой стороны нужно понимать, что покупая UTM или NGFW, вы повышаете свои операционные расходы на следующий год. Иначе карета обернется в тыкву). И вместо полноценного решения вы получите дорогой межсетевой экран, без AppControl и обновленных сигнатур.
  • Виртуальные Check Point'ы: чек-лист по настройке
    0
    На счет Bluetooth бытует мнение, что нужно сначала поставить Endpoint Client, а после переустановить драйвер Bluetooth. Баги есть, бесспорно. Многие Endpoint клиенты конфликтуют с ПО на локальной машине.
    По поводу автообновлений, я не сторонник такого. Я за то, чтобы контролировать процесс обновлений.
  • Эволюция сайта — взглядом Linux-админа дата-центра
    0
    MMik,navion, спасибо за комментарии.

    Выбрали RHCE, потому что большая часть поддерживаемых нами ОС — это именно Red Hat и CentOS. К тому же по нашему опыту данный вид сертификации наиболее хорошо проработан с точки зрения общего понимания работы ОС.

    Основной рабочий опыт инженеры получают непосредственно в процессе решения эксплуатационных задач по поддерживаемым клиентским системам. У нас внутри есть механизм кураторства для новичков :-)

    Пожелания рассказать о географически распределённых кластерах, anycast, multihoming и storage resiliency учтем. Ждите в наших будущих статьях :-)
  • Эволюция сайта — взглядом Linux-админа дата-центра
    0
    В целом да, если мы не админим виртуалки клиента, то и на блох не указываем. Пока они оттуда не полезут, конечно. Если видим, что происходит какая-то фигня, то связываемся с заказчиком и лечим проблемную машину. Плюс есть NDA и прочие соглашения, по которым мы не можем лезть внутрь серверов клиента без его ведома.
  • Эволюция сайта — взглядом Linux-админа дата-центра
    0
    My bad. Картинка отражает правило проектирования. Оно не описывает вероятность факапа, оно говорит о том, что надежность системы в первую очередь определяется надежностью самого слабого звена. В эксплуатации, конечно, будет "≤".
  • Эволюция сайта — взглядом Linux-админа дата-центра
    0
    Тут ведь как… Можно и Убунту сделать стабильной, но есть еще трудозатраты по поддержке. Отсюда и предпочтение к Красной Шапке.
  • Эволюция сайта — взглядом Linux-админа дата-центра
    0
    Мне, как админу не важно — битрикс, вордпресс, джумла или что-то еще. Модули разные, а проблемы и схема масштабирования примерно похожи.
  • Работаем в облаке на Hyper-V, часть 4: создание резервных копий виртуальной машины
    0
    cyreex Рад сообщить, что теперь доступно резервное копирование и на Veeam.
  • Семинар «Пустячок, а приятно: 20 мелочей, которые сделают работу в серверной по-настоящему комфортной», 4 июля, Москва
    0
    Просим прощения. Действительно, видео удаляли, чтобы вырезать из трансляции время кофе-брейков :-)
    Залили чистовую версию сюда.
  • Семинар «Пустячок, а приятно: 20 мелочей, которые сделают работу в серверной по-настоящему комфортной», 4 июля, Москва
    0
    Как и обещали — ссылка на трансляцию сегодняшнего семинара. Начинаем в 11:00-11:15
  • Семинар «Пустячок, а приятно: 20 мелочей, которые сделают работу в серверной по-настоящему комфортной», 4 июля, Москва
    0
    Будет онлайн трансляция, ссылку опубликуем в день семинара на нашей странице в Facebook. Заходите посмотреть :-)
  • Операция “Миграция”: если ваша почта где-то там, а надо, чтобы была здесь
    0
    Вопрос решается кворумом: как только члены DAG перестают видеть друг друга, происходит анализ кворума. Если количество серверов DAG и свидетельских сущностей, участвующих при подсчете, набирает кворум, то площадка остается рабочей, иначе – гаснет.
  • Операция “Миграция”: если ваша почта где-то там, а надо, чтобы была здесь
    0
    Информационной системой персональных данных может быть не только «база данных», а в обработку персональных данных входит не только «сбор». Часто в почтовой системе фигурируют данные сотрудников (имя, фамилия, мобильный телефон), сюда же присылают анкеты соискателей для HR, сканы документов, информацию для заказа пропусков и так далее. Поэтому, персональные данные в почтовой системе в 99% случаев есть.

    Конечно, можно запретить сотрудникам делать подписи, имена ящиков сделать вида employee123@dtln.ru, удалять вложения к письмам, парсить текст письма на наличие ПДн..., но работать с такой почтовой системой будет не удобно. Лично я бы не смог :)

    Кстати в том же office 365 при регистрации содержится предупреждение о том, что все будет храниться не в РФ. Наверное, не просто так.
  • Чтобы карета не превратилась в тыкву, или зачем нужны тестовые восстановления из резервных копий
    +1
    Как устроена не расскажу, но в Service Pack 7 действительно появилась возможность тестить резервные копии.
    Правда, эта фича пока идет с пометкой early release.



  • Вредные советы по настройке резервного копирования и несколько баек
    +1
    да, это отдельная проблема. Вот одна из таких историй, где после того, как прижгло, руководство решило таки инвестировать в инфраструктуру для резервного копирования. https://www.reddit.com/r/sysadmin/comments/63gs2s/update_to_got_hit_bad_tonight/
  • Работаем в облаке на Hyper-V, часть 4: создание резервных копий виртуальной машины
    0
    P.S. У вас на скриншоте кнопка «BAAS/Add DPM Server» дает выбрать Veeam.

    В текущей конфигурации нашего облака бэкап на Veeam не доступен. Опция на тестировании, отсюда и присутствие в админском портале :-)
  • Работаем в облаке на Hyper-V, часть 4: создание резервных копий виртуальной машины
    0
    Спасибо за вопрос. SPF в данном случае не используется. На стороне WAP функциональность реализовали с помощью скриптов.
  • Дата-центр по системе Станиславского: как устроен корпоративный театр DataLine
    0
    Спасибо, так отрадно, что наш рассказ о том, как мы горим (в лучшем смысле) своим театром, нашел отклик :-)
  • Дата-центр по системе Станиславского: как устроен корпоративный театр DataLine
    +1
    Спасибо :-) В целом у нас вход только по приглашениям, но, черт возьми, так приятен ваш отклик, что давайте мы вас пригласим :-). Напишите нам в личку или на pr@dtln.ru – и мы пришлем приглашение на следующую премьеру (она у нас в ноябре).
  • Дата-центр по системе Станиславского: как устроен корпоративный театр DataLine
    0
    Состав самый разношерстный – правда, технические специалисты и финансовый департамент в основном предпочитают смотреть спектакли Театра, а не играть в них :-) В условном «постоянном составе» сейчас менеджмент (от производства до бэкофиса), маркетинг и продажи, аккаунт-менеджеры, HR и отдел закупок.
  • Дата-центр по системе Станиславского: как устроен корпоративный театр DataLine
    0
    Спасибо!) Касательно двух спектаклей тут такой момент: театр – довольно затратное по времени и деньгам удовольствие, и даже условно простой спектакль (но все-таки спектакль, а не импровизированный капустник) требует немалых «вложений» ото всех участников.
    Поэтому мы просто запускаем внутри другие вдохновляющие проекты, чтобы каждый нашел себе что-то по душе и по силам. :-)
  • Network Controller: программно-определяемые сети в Windows Server 2016. Часть 1: возможности и службы
    0
    Спасибо!
  • Network Controller: программно-определяемые сети в Windows Server 2016. Часть 1: возможности и службы
    0
    Canary Network Diagnostics работает в связке с Network Controller. Через NC происходит обмен данными. Более подробно о том, как работает Canary Network Diagnostics, можно будет сказать, когда появится официальный релиз
  • Как тестируют ДГУ в дата-центре
    +3
    Спасибо за вопрос. Вы как раз обратились по адресу, про бесперебойность — это к нам. :-)
    Постараемся ответить, но если не совсем верно поняли вопрос, извините.

    По существу ЦОД — это уже сложная система с разделением электропитания по уровням устойчивости.

    1. объекты, подключенные к городскому питанию без ДГУ. Такие объекты отключаются во время пропадания города;
    2. гарантированное энергоснабжение. Работают с ДГУ, но без ИБП;
    3. бесперебойное энергоснабжение. С ДГУ и ИБП;
    4. бесперебойное, да еще и 2N зарезервированное.

    ВСЕ стойки с оборудованием, понятное дело, подключены к последнему типу, так как мы коммерческий ЦОД и не можем управлять критичностью сервисов, которые крутятся в стойках наших клиентов. В корпоративных ЦОД так можно делать, вынося, например тестовые среды в менее зарезервированные стойки, и экономя на инфраструктуре.

    А дальше — интереснее. Так, половина кондиционеров подключена бесперебойно, а половина только на гарантированном питании. То же самое с освещением: аварийный свет на ИБП, остальной — нет.

    К тому же ИТ-нагрузка подключается к одним ИБП (резерв 2N), а всё остальное — к другим.

    И этот список можно продолжать долго. :-)
  • Облако на Microsoft Hyper-V, часть 3: хранилище Storage Spaces
    0
    VitalKoshalew, отвечаем на вопросы в данной ветке комментариев.

    Уже тут вопрос — как разворачивали? Если через WDS изнутри виртуальной машины, то не в эмулируемый ли сетевой адаптер упёрлись? Если же просто шло копирование файла .vhdx из библиотеки (например, средствами SCVMM), то к чему вся дальнейшая теория о том, как диск виден изнутри виртуальной машины?

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

    Если не секрет, что за модель SSD? И что за прошивка такая «дефолтная»? Заводская при наличии у производителя обновлённой? То есть вы строили систему, не обновив предварительно все прошивки до текущих? Не говоря уже о проблемах старых прошивок как таковых, вас техподдержка Dell бы завернула, случись что, попросив сначала обновить прошивку, а потом приходить. Если с остальными компонентами та же проблема, то всё исследование нужно начинать сначала.

    На момент возникновения проблемы у вендора не было новой прошивки, но у производителя SSD она была. Взвесив все за и против, мы решили перейти на нее.

    Что до одновременного доступа с разных узлов кластера, как именно это влияло на производительность при развёртывании одной-двух машин? Даже если был redirected I/O с одного из узлов, такого падения быть не должно было на 40-гигабитной сети, а уж реально задействовать балансировку нагрузки на SoFS в вашей задаче можно только в очень специфическом случае: одновременное копирование двух .vhdx на два отдельных CSV, каждый из которых покрывает все условные «шпиндели» системы.

    Влияло именно multipoint connection – одновременная работа с дисками двух нод SOFS. Страдала в конечном итоге запись на физические диски.

    Схема неверна. В верхней части должно быть:
    Virtual Disk 512e (512/4096) — диски виртуальных машин

    Виртуальные машины видят .vhdx диски, созданные с параметрами по умолчанию, как 512e и соответственно оптимизируют запись. Старые .vhd диски по умолчанию эмулируют 512n.

    Вот как выглядит .vhdx файл:
    > get-vhd… |fl *sector*
    LogicalSectorSize: 512
    PhysicalSectorSize: 4096

    А вот вид изнутри виртуальной машины:
    > get-disk|fl *sector*
    LogicalSectorSize: 512
    PhysicalSectorSize: 4096

    Кстати, что после всех изменений показывают ваши виртуальные машины? Если вы не пересоздавали все .vhdx с ручным указанием размера физического сектора, то они всё так же считают, что у них физический сектор 4kB и производят RMW при записи одиночных 512 байт.

    Вы несколько невнимательно читаете: подсистема ввода-вывода СХД (а не внутри ВМ) начинает учитывать физический сектор ТОЛЬКО в самом низу этой схемы. Все остальные слои оперируют с логическим сектором.

    Кстати, что после всех изменений показывают ваши виртуальные машины? Если вы не пересоздавали все .vhdx с ручным указанием размера физического сектора, то они всё так же считают, что у них физический сектор 4kB и производят RMW при записи одиночных 512 байт.
    Это привело к выполнению политики Read-Modify-Write: чтение сектора 4К в кэш, правка необходимых 512 байт, запись 4К обратно на диск. Как следствие, к катастрофическому падению производительности дисковой подсистемы во время записи в 8 раз.

    Не совсем понятно, как такое может произойти на реальной нагрузке.

    Смотрите ответы выше и ниже.

    Первый вопрос: откуда возьмутся случайные 512-байтовые записи (кроме специально настроенного синтетического теста)? Начиная с Windows Server 2012 все структуры .vhdx выровнены по 4kB (именно поэтому они и представляются виртуальной машине по умолчанию как 512e, а vhd представлялись как 512n). Операционная система внутри VM знает, что физический сектор — 4kB. NTFS использует кластер минимум 4kB. Файлы, как правило, много больше 4kB. Даже SQL Server получает от системы информацию, что физический сектор — 4kB и выравнивает запись по границе 4kB.

    Если идёт запись блока большого размера, он передаётся вниз через подсистемы ввода-вывода блоками до 64kB. Такие примерно блоки и отсылаются в самый низ — на физические носители, плюс NCQ позволяет ещё более оптимизировать запись.
    Чтобы в этом убедиться, достаточно для CSV посмотреть в Performance Monitor следующую метрику: Physical Disk -> Avg. Disk Bytes/Write. К сожалению, она высчитывает среднее арифметическое, включая в него и 0 при простое, но чем ближе загрузка к 100%, тем более отчётливо показатель приближается к 64kB.

    Вообще говоря, физический сектор размером 4kB это условная, фальшивая цифра для SSD: реально минимальный блок перезаписи на SSD может достигать нескольких мегабайт, потому все контроллеры внутри используют что-то вроде WAFL и 3.5kB дополнительных данных их ничуть не затормозят.

    Таким образом, для того, чтобы вызвать RMW в виртуальной машине, нужно записать одиночные 512 байт, и ничего вокруг не писать, иначе, при последовательной записи, максимум произойдут RMW операции для первого и последнего физического сектора, и то, при условии ошибки выравнивания, которые может только само приложение создать, так как и файловая система, и .vhdx выровнены по границе 4kB или больше. Более того, данный физический сектор не должен быть нигде закэширован, то есть виртуальная машина не должна была его до этого читать. Честно говоря, мне сложно представить нагрузку, при которой эти дополнительные операции как-либо заметно ухудшат производительность.

    Давайте отделим мух от котлет: обмен данными с устройствами типа «жесткий диск» (неважно физическими или виртуальными) в конечном итоге сводится к обмену секторами. Здесь все проблемы вызывал виртуальный CSV том – именно на участке файл виртуального диска -> CSV том и работает RMW.

    В таблице ниже показаны значения скорости до и после внедрения этого решения. В случае “после” проверка проводилась одновременным запуском тестирования DiskSpd на 15 виртуальных машинах.

    Хотелось бы увидеть подробности методики тестирования. Настораживает уже сама формулировка, которая подразумевает, что тестирование «до» и «после» проводилось по различным методикам.
    Были ли виртуальные диски, на которых производилось тестирование, pinned к hot tier? Что показывал непосредственно перед тестированием Get-FileStorageTier для этих файлов? Если они не были принудительно помещены (с обязательной оптимизацией после Set-FileStorageTier) в hot tier, то тестировалась «погода на Марсе» — во время первого и второго тестирования они могли быть полностью или частично в hot или cold tier, да ещё влияние оказывало соотношение объёма Storage Spaces Write Cache (по умолчанию — 1GB) с объёмом записываемой информации, а также скорость пополнения Storage Spaces Write Cache и скорости его сброса. Ну и, конечно же, настройки тестирования — если тестировалась случайная запись 512-байтовыми блоками при отключенном кэше, то такой нереальный access pattern мог немного просадить производительность. Но даже при таких настройках что-то не верится в 8-кратную разницу. Намного больше похоже на 8-кратную разницу (возможно, несколько сглаженную кэшем) между скоростью доступа к данным, лежавшим в cold tier и данным, перемещённым в hot tier после того, как их только что туда-сюда скопировали.

    Storage Spaces Write Cache используется только для операций случайной записи, вся остальная запись идет через SSD тир. Холодные данные потом перемещаются на медленный уровень. Даже если убрать SSD тир, сделать однородный пул из 512е SATA/SAS дисков, проблема все равно останется. Цифра 8 взялась не случайно – это подтверждено тестами.

    Не обижайтесь, но заявления вида «инженеры Microsoft, разработавшие новую систему и протестировавшие её перед релизом сверху донизу, а также все, кто не первый год её эксплуатируют, ошиблись, а я, первый раз взяв её в эксплуатацию, сразу нашёл ошибку и сам её исправил» воспринимаются с очень большой долей скептицизма. Нужно очень тщательно обосновать свои выводы.

    Обижаться не на что :-) Если оно было действительно «протестировано перед релизом сверху донизу», то в России были бы еще сервис-провайдеры, использующие Storage Spaces для своего публичного облака.

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

    В Microsoft обращались? Они подтвердили ваши выводы?

    Обращались в Premier Support, месяц общались со специалистами до третьей линии. Проблему в итоге решили сами. По поводу подтверждения выводов – принцип работы дисков никак не соотносится с решениями Microsoft (за исключением момента с созданием по умолчанию CSV тома с логическим секторов в 4К на основе дисков 512n и 512e). По поводу ссылки и комментариев – не смогли воспроизвести, потому что и SSD, и SATA диски были 512n.
  • Облако на Microsoft Hyper-V, часть 3: хранилище Storage Spaces
    0
    PSVITAmins, спасибо за комментарий и интерес к статье.

    NVM-диски, действительно не поддерживаются Storage Spaces, но о них мы и не говорим. А с SATA-дисками Storage Spaces работать умеет :-)

    Желаем удачи с тестированием S2D. Своими результатами обязательно поделимся в блоге, следите за новостями.
  • Работаем в облаке на базе Hyper-V, часть 2: развертывание Exchange Server
    0
    Подсеть /хх для BGP — AS (autonomous system), а не PI.

    Из плюсов — основа сервиса: высокопроизводительная инфраструктура, круглосуточная техподдержка и размещение ВМ в топовом ЦОД Tier 3.
  • Работаем в облаке на базе Hyper-V, часть 2: развертывание Exchange Server
    +1
    отказоустойчивая сеть для OWA, которую нереально получить новой компании (PI давно не выдают)

    Уточните, что в данном случае имеете в виду под PI?

    IronPort у вас не разместить

    Если речь идет о решении Cisco Iron Port, то его можно развернуть на виртуальной среде.

    В статье мы показали сценарий развертывания Exchange Server с DAG, задачи сравнить все перечисленные решения не было. Какая конфигурация Вас интересует — Office 365, гибрид Office 365 с Exchange у нас, или виртуальная инфраструктура на Hyper-V? Есть всё. Пришлите запрос на request@dtln.ru, посчитаем.
  • Работаем в облаке на базе Hyper-V, часть 2: развертывание Exchange Server
    0
    Опечатку исправили, спасибо.

    Можно просто «v=spf1 mx -all»

    Да, вы правы, можно и так.
  • Работаем в облаке на базе Hyper-V, часть 1: знакомство с панелью управления
    0
    Владимир, пока с такой проблемой не сталкивались. Если столкнемся — будет стимул прокачаться и починить.