Чаще всего какой-то «специальный» маршрут не составляем — едем оптимальным путем по навигатору, так как скорость доставки тоже важна. По ровной дороге едем не более 70—80 км/ч. От случайных кочек защищаемся как раз с помощью мягкой упаковки и ремней — в кузове все надежно зафиксировано, чтобы небольшие неровности не были проблемой.
Если мы точно знаем, что навигатор нас ведет по неровной дороге, то согласовываем с заказчиком объезд. Это важно обсудить заранее, чтобы уложиться в допустимое время простоя оборудования.
Еще один момент — если заказчику это важно, на время перевозки пломбируем грузовик. Это бывает при перевозке особо важных систем, тогда груз может сопровождать еще и служба безопасности заказчика. Один человек садится в кабину к водителю, и одна машина сопровождения едет сзади.
Что будет, если один из PE решит сбойнуть аппаратно или программно, как остальные PE изолированы от этого сбоя?
Резерв организован посредством HSRP. Программный или аппаратный сбой одного PE приведёт к переключению трафика на другое плечо. Для клиентов это будет означать потерю пары пакетов.
Как вы поступаете с префиксами global unicast для интернет, которые должны быть видны и катастрофоустойчивить с двух площадок? Что будет при проблемах со связностью между двумя площадками и внешними префиксами в момент split brain
Префиксы анонсируются с обеих площадок, но в один момент времени трафик в Интернет идёт по одному плечу. Это не проблема, так как пропускная способность линков посчитана с большим запасом. За этим ведётся постоянный мониторинг.
Проблемы со связностью и split brain маловероятны, так как каналы между площадками идут независимыми трассами, на территорию ЦОДа заведены через разные кабельные вводы и подключены к оборудованию в разных энергоцентрах. Это практически исключает их одновременный выход из строя.
Как вы растянули L2 между площадками? Как известно, растянутый L2 делает из двух площадок один домен отказа и облако получается неустойчивым к катастрофам.
Да, L2 растянут между площадками, но это не означает единый домен отказа, только если клиент сам не собрал бридж из двух интерфейсов на своей ВМ. В этом случае клиент потеряет связь со своими ВМ из-за некорректных настроек. Остальные клиенты при этом не пострадают, так как на уровне сетевого оборудования настроен storm-control.
Мы исключаем ситуацию, при которой хосты с одной площадки будут обращаться к СХД на удаленной площадке (используя affinity rules) в штатном режиме. Т.е. запись ведется только на «оригинальный» том (локально), а не на «реплику», и случай, указанный вами, мы исключаем. После восстановления связи данные «выровняются» автоматически.
Да, это правда. С другой стороны нужно понимать, что покупая UTM или NGFW, вы повышаете свои операционные расходы на следующий год. Иначе карета обернется в тыкву). И вместо полноценного решения вы получите дорогой межсетевой экран, без AppControl и обновленных сигнатур.
На счет Bluetooth бытует мнение, что нужно сначала поставить Endpoint Client, а после переустановить драйвер Bluetooth. Баги есть, бесспорно. Многие Endpoint клиенты конфликтуют с ПО на локальной машине.
По поводу автообновлений, я не сторонник такого. Я за то, чтобы контролировать процесс обновлений.
Выбрали RHCE, потому что большая часть поддерживаемых нами ОС — это именно Red Hat и CentOS. К тому же по нашему опыту данный вид сертификации наиболее хорошо проработан с точки зрения общего понимания работы ОС.
Основной рабочий опыт инженеры получают непосредственно в процессе решения эксплуатационных задач по поддерживаемым клиентским системам. У нас внутри есть механизм кураторства для новичков :-)
Пожелания рассказать о географически распределённых кластерах, anycast, multihoming и storage resiliency учтем. Ждите в наших будущих статьях :-)
В целом да, если мы не админим виртуалки клиента, то и на блох не указываем. Пока они оттуда не полезут, конечно. Если видим, что происходит какая-то фигня, то связываемся с заказчиком и лечим проблемную машину. Плюс есть NDA и прочие соглашения, по которым мы не можем лезть внутрь серверов клиента без его ведома.
My bad. Картинка отражает правило проектирования. Оно не описывает вероятность факапа, оно говорит о том, что надежность системы в первую очередь определяется надежностью самого слабого звена. В эксплуатации, конечно, будет "≤".
Вопрос решается кворумом: как только члены DAG перестают видеть друг друга, происходит анализ кворума. Если количество серверов DAG и свидетельских сущностей, участвующих при подсчете, набирает кворум, то площадка остается рабочей, иначе – гаснет.
Информационной системой персональных данных может быть не только «база данных», а в обработку персональных данных входит не только «сбор». Часто в почтовой системе фигурируют данные сотрудников (имя, фамилия, мобильный телефон), сюда же присылают анкеты соискателей для HR, сканы документов, информацию для заказа пропусков и так далее. Поэтому, персональные данные в почтовой системе в 99% случаев есть.
Конечно, можно запретить сотрудникам делать подписи, имена ящиков сделать вида employee123@dtln.ru, удалять вложения к письмам, парсить текст письма на наличие ПДн..., но работать с такой почтовой системой будет не удобно. Лично я бы не смог :)
Кстати в том же office 365 при регистрации содержится предупреждение о том, что все будет храниться не в РФ. Наверное, не просто так.
Как устроена не расскажу, но в Service Pack 7 действительно появилась возможность тестить резервные копии.
Правда, эта фича пока идет с пометкой early release.
Если мы точно знаем, что навигатор нас ведет по неровной дороге, то согласовываем с заказчиком объезд. Это важно обсудить заранее, чтобы уложиться в допустимое время простоя оборудования.
Еще один момент — если заказчику это важно, на время перевозки пломбируем грузовик. Это бывает при перевозке особо важных систем, тогда груз может сопровождать еще и служба безопасности заказчика. Один человек садится в кабину к водителю, и одна машина сопровождения едет сзади.
Резерв организован посредством HSRP. Программный или аппаратный сбой одного PE приведёт к переключению трафика на другое плечо. Для клиентов это будет означать потерю пары пакетов.
Префиксы анонсируются с обеих площадок, но в один момент времени трафик в Интернет идёт по одному плечу. Это не проблема, так как пропускная способность линков посчитана с большим запасом. За этим ведётся постоянный мониторинг.
Проблемы со связностью и split brain маловероятны, так как каналы между площадками идут независимыми трассами, на территорию ЦОДа заведены через разные кабельные вводы и подключены к оборудованию в разных энергоцентрах. Это практически исключает их одновременный выход из строя.
Да, L2 растянут между площадками, но это не означает единый домен отказа, только если клиент сам не собрал бридж из двух интерфейсов на своей ВМ. В этом случае клиент потеряет связь со своими ВМ из-за некорректных настроек. Остальные клиенты при этом не пострадают, так как на уровне сетевого оборудования настроен storm-control.
По поводу автообновлений, я не сторонник такого. Я за то, чтобы контролировать процесс обновлений.
Выбрали RHCE, потому что большая часть поддерживаемых нами ОС — это именно Red Hat и CentOS. К тому же по нашему опыту данный вид сертификации наиболее хорошо проработан с точки зрения общего понимания работы ОС.
Основной рабочий опыт инженеры получают непосредственно в процессе решения эксплуатационных задач по поддерживаемым клиентским системам. У нас внутри есть механизм кураторства для новичков :-)
Пожелания рассказать о географически распределённых кластерах, anycast, multihoming и storage resiliency учтем. Ждите в наших будущих статьях :-)
Залили чистовую версию сюда.
Конечно, можно запретить сотрудникам делать подписи, имена ящиков сделать вида employee123@dtln.ru, удалять вложения к письмам, парсить текст письма на наличие ПДн..., но работать с такой почтовой системой будет не удобно. Лично я бы не смог :)
Кстати в том же office 365 при регистрации содержится предупреждение о том, что все будет храниться не в РФ. Наверное, не просто так.
Правда, эта фича пока идет с пометкой early release.