Я и не пытался никого напугать. Собственно, я так и сказал —
Восстанавливать контроллеры из резервной копии не нужно. В случае проблем с контроллером правильным будет удалить его из домена, переставить сервер начисто и заново ввести его в домен в роли контроллера. Однако, есть сценарии, где резервная копия — ваш единственный выбор. Например, если вся ваша AD DS инфраструктура была уничтожена и вам надо её восстановить.
А операцию описывал потому, что многие о ней вообще не знают, а для общего развития, на мой взгляд, знать такие вещи полезно.
Это будет очень странный «каверзный вопрос»:) Всё таки, такие вещи стоит знать обычно для широты кругозора, в реальной работе большая часть админов с ними не пересекается никогда.
«Страшного» ничего. Просто в зависимости от того как давно была снята копия, был ли контроллер держателем FSMO ролей на момент резервного копирования и сейчас, был ли он физическим или виртуальным сервером список действий может несколько меняться.
Со времён 2008 сервера чистка метаданных старого контроллера делается в пару кликов. Установка нового сервера, как правило операция автоматизированная. Соответственно, создание новго контроллера не очень трудозатратная, безрисковая и всегда проходящая одинаково операция.
Именно поэтому Microsoft рекомендует избегать восстановления контроллеров из резервной копии, если есть возможность просто ввести новый. Т.е. не то чтобы этого нельзя было делать. Просто, обычно, лучше сделать по другому.
«операция исключения идентификаторов» не гуглится совсем. «инвалидация» всё таки исопльзовалась раньше и при чтении статей на английском сразу ассоциируется с правильным термином. Я надеялся, что кто-то знает общеупотребимый термин, который я пропустил.
Я так понял из текста стаьи, что суть Swarming в том, чтобы прием заявок осуществляла сборная группа, включающая в себя продвинутых инженеров и решала только то, что можно очень быстро решить, а остальное переводила в группу решения, которая тоже на основе ротации работает. Таким образом, все члены команды не теряют связь с «землёй», видят, что происходит с приложением, имеют возможность поломать голову над сложными задачками. Грубо говоря, «прокачиваются» равномерно.
Не уверен, что я понял правильно, и, действительно, хотел бы увидеть экономическое обоснование такого подхода, для компаний не занимающихся разработкой софта. Хотя и для занимающихся разработкой, зачастую иметь первую линию полубесплатных людей очень привлекательно по деньгам (как пользователь я эту линию люто ненавижу:))
artemlight, наверное, ответит что он имел ввиду, но, как мой вариант ответа:
— Обработка и хранения ваших конфиденциальных данных. То что составляет коммерческую тайну компании имеет смысл держать на доверенном железе. По крайней мере, спокойнее.
— Системы управления технологическим процессом. Зачем выносить в облако системы контролирующие работу и обрабатывающие данные от ваших станков на заводе, например? Будет очень глупо, если с обрывом WAN канала, ваш завод встанет.
— Аналогично с системами управления инженерными компонентами здания. Тоже не ясно зачем выносить в облако то, что собирает данные с локальных датчиков и должно управлять реакцией на эти данные.
Этот страх он скорее от непонимания того, как это правильно готовить. Можно ведь разносить компоненты ваших систем и уводить в облако стейтлесс системы, которые не хранят конфиденциальных данных. Или использовать облако для быстрого развертывания инфраструктуры обработки гигантских массивов публичных данных и потом сворачивания всего этого с отправкой результата к вам «на землю».
А риски они есть всегда. Когда вы держите сервера в датаруме, ваше здание может сгореть. Когда в чужом ЦОДе, ваш провайдер может перейти дорогу кому не надо и к нему придут маски шоу с отключением всего и вся. У любого варианта есть свои риски и ими нужно управлять понимая их.
Эта перевод самой понравившейся мне статьи по нововведениям в Active Directory. Она дает примерное понимание того, что там есть и ключевые слова для поиска деталей.
Если вы видели статью луче, я буду благодарен за ссылку. В следующий раз переведу того автора:)
Странно. По тону, вы как будто, со мной спорите. А, по сути, написано тоже самое.
Я, как раз, и говорю, что типовой сценарий для облака это
— Небольшая компания. Вот появилось желание заиметь географически распределённые ресурсы для отказоустойчивости, а денег на аренду места в двух ЦОД и канала между ними нет. Или еще какого экзотичесокго функционала захотелось. Ну неужели покупать всё сопутствующее железо? ПРоще в облаке взять.
— Динамические среды. Приложения с ОЧЕНЬ разной нагрузкой. Веб приложения с наплывами клиентов, системы ИИ (некоторые) и т.д. Какой смысл держать под парами железа для фронтэнда, чтобы справится с рождественским наплывом клиентов, например? Проще держать эту часть в облаке. где она будет гибко масштабироваться по нагрузке.
Понятно, что компании с серьёзной локальной инфраструктурой и более менее стабильными нагрузками оставят все «на земле». Им так и спокойнее и, объективно, комфортнее. Хотя и они интересуются облаками — разместить там тестовые среды (которые опять же хочется быстро разворачивать и быстро убирать по необходимости) или компоненты для удалённых офисов (вместо аренды места у десятка мелких региональных провайдеров (если таких офисов много, они маленькие и раскиданы по всему земному шару).
У вех инструментов есть свое применение. Есть оно и у облаков. А хайп маркетологов, что всё уедет в облака, он должен со временем пройти, да.
Ну, справедливости ради, это было в 2012 году и, вроде, с Azure MS учла проблемы Silverlight. ПО крайней мере сервисы Azure часто меняются так как просило комьюнити.
Не выдавливать уж. Просто сотношение цена\функционал будет давить все мелкие компании в облака. Не только в облака MS.
Собственно, это два основных сценария ля облака — компании с динамической нагрузкой (кгда не выгодно постоянно держать достаточно локального железа чтбы комфортно проходить редкие пики) и маленькие компаии (когда хочется отказоустоячивости и богатого функционала, но денег, чтобы развернуть нужные компоненты у себя, нет).
Основная причина проблем — сложно работать со столь быстро развивающимся продуктом. Иногда, сложно обеим сторонам и нам и МС.
А так, да, хорошо идут. Azure, вроде, очень неплохо продаётся.
А операцию описывал потому, что многие о ней вообще не знают, а для общего развития, на мой взгляд, знать такие вещи полезно.
Со времён 2008 сервера чистка метаданных старого контроллера делается в пару кликов. Установка нового сервера, как правило операция автоматизированная. Соответственно, создание новго контроллера не очень трудозатратная, безрисковая и всегда проходящая одинаково операция.
Именно поэтому Microsoft рекомендует избегать восстановления контроллеров из резервной копии, если есть возможность просто ввести новый. Т.е. не то чтобы этого нельзя было делать. Просто, обычно, лучше сделать по другому.
«операция исключения идентификаторов» не гуглится совсем. «инвалидация» всё таки исопльзовалась раньше и при чтении статей на английском сразу ассоциируется с правильным термином. Я надеялся, что кто-то знает общеупотребимый термин, который я пропустил.
Не уверен, что я понял правильно, и, действительно, хотел бы увидеть экономическое обоснование такого подхода, для компаний не занимающихся разработкой софта. Хотя и для занимающихся разработкой, зачастую иметь первую линию полубесплатных людей очень привлекательно по деньгам (как пользователь я эту линию люто ненавижу:))
— Обработка и хранения ваших конфиденциальных данных. То что составляет коммерческую тайну компании имеет смысл держать на доверенном железе. По крайней мере, спокойнее.
— Системы управления технологическим процессом. Зачем выносить в облако системы контролирующие работу и обрабатывающие данные от ваших станков на заводе, например? Будет очень глупо, если с обрывом WAN канала, ваш завод встанет.
— Аналогично с системами управления инженерными компонентами здания. Тоже не ясно зачем выносить в облако то, что собирает данные с локальных датчиков и должно управлять реакцией на эти данные.
А риски они есть всегда. Когда вы держите сервера в датаруме, ваше здание может сгореть. Когда в чужом ЦОДе, ваш провайдер может перейти дорогу кому не надо и к нему придут маски шоу с отключением всего и вся. У любого варианта есть свои риски и ими нужно управлять понимая их.
Если вы видели статью луче, я буду благодарен за ссылку. В следующий раз переведу того автора:)
Я, как раз, и говорю, что типовой сценарий для облака это
— Небольшая компания. Вот появилось желание заиметь географически распределённые ресурсы для отказоустойчивости, а денег на аренду места в двух ЦОД и канала между ними нет. Или еще какого экзотичесокго функционала захотелось. Ну неужели покупать всё сопутствующее железо? ПРоще в облаке взять.
— Динамические среды. Приложения с ОЧЕНЬ разной нагрузкой. Веб приложения с наплывами клиентов, системы ИИ (некоторые) и т.д. Какой смысл держать под парами железа для фронтэнда, чтобы справится с рождественским наплывом клиентов, например? Проще держать эту часть в облаке. где она будет гибко масштабироваться по нагрузке.
Понятно, что компании с серьёзной локальной инфраструктурой и более менее стабильными нагрузками оставят все «на земле». Им так и спокойнее и, объективно, комфортнее. Хотя и они интересуются облаками — разместить там тестовые среды (которые опять же хочется быстро разворачивать и быстро убирать по необходимости) или компоненты для удалённых офисов (вместо аренды места у десятка мелких региональных провайдеров (если таких офисов много, они маленькие и раскиданы по всему земному шару).
У вех инструментов есть свое применение. Есть оно и у облаков. А хайп маркетологов, что всё уедет в облака, он должен со временем пройти, да.
Собственно, это два основных сценария ля облака — компании с динамической нагрузкой (кгда не выгодно постоянно держать достаточно локального железа чтбы комфортно проходить редкие пики) и маленькие компаии (когда хочется отказоустоячивости и богатого функционала, но денег, чтобы развернуть нужные компоненты у себя, нет).
Это тренд от которого, наверное, не уйти.