суббота, июля 04, 2009
Блокировка пользовательского сеанса в MacOS X
Не буду заниматься копи-пастом, приведу ссылку на Хабр. Читаю и заливаюсь скупыми мужскими слезами.
четверг, июля 02, 2009
ДР Миллера
Сегодня
По словам
вторник, июня 30, 2009
Очередной перл переводчиков
Воображение моё потрясают словесные конструкции сии. Йода, магистр который, говорить так не помышлял даже...
Кластеризация Exchange
Разбираюсь с кластеризацией Exchange 2007, иногда перевожу куски статей для личного пользования. по предложению Бурята выкладываю сюда некоторые куски, вдруг еще комунить понадобится =)
Нижеследующий текст - мой малопрофессиональный перевод содержательной части данной статьи: http://blogs.technet.com/mcs-ireland-infrastructure/archive/2007/12/20/what-s-new-in-exchange-2007-clustering.aspx
Переводить "воду" не люблю, потому придетсяо бойтись без авторских рассуждений.
4 новых системы кластеризации и 4 новых сокращения.
Ура – 4 новых сокращения, чтобы смущать наших коллег и начальников и выглядеть умным. Итак:
• SCC - Single Copy Cluster
• LCR - Local Continuous Replication
• CCR - Cluster Continuous Replication
• SCR - Standby Continuous Replication
Давайте рассмаотрим их поближе.
1. SCC - Single Copy Cluster – «Классическая кластеризация»
Изначальный тип кластеризации теперь известен как Single Copy Cluster. Это там, где мы обеспечиваем избыточность для наших серверов, но все еще имеем единую точку отказа – общие диски, содержащие кворум кластера, базы данных Exchange и логи. В E2007 основы работы данной системы не изменились, однако появилось некоторое число дополнений и улучшений. Вот наиболее важные из них:
• В предыдущих версиях, когда вы инсталлировали Exchange, вы все получали в одном решении и должны были отключать все, что вам не требовалось. Это распространялось и на кластера, и имело тенденцию приводить к появлению функционала, который никогда не использовался. В Е2007, используя концепцию ролей сервера, вы можете выбрать, какую роль вы хотите получить – хранилища, концентратора, пограничного сервера или сервера объединённых коммуникаций. В этом случае Single Copy Cluster (и все другие типы кластеров) распространяются только на роль сервера хранилища. Это упрощение крайне выгодно. Отказоустойчивость остальных ролей достигается другими методами – NLB и т.п.
• В предыдущих версиях Exchange, в случае отказа одной базы данных в группе хранения из-за проблем с дисковой подсистемой весь сервер имел fail-over из-за чего на больших серверах это приводило к большим проблемам. В Е2007 упавшая база данных отмонтируется, в то время как остальные продолжают функционировать. Теперь вы можете восстанавливать разрушенную базу данных отдельно.
• В прошлых версиях Single Copy Cluster требовал серьёзных навыков в администрировании кластеров и связанных с ними моментов. В Е2007 большая часть управления кластерами теперь часть Exchange Management Shell. Вам все еще требуется немного поработать администратором кластеров (или попросить кого-нибудь это сделать за вас), но вы можете контролировать процесс используя новые коммандлеты в EMS. Да, вам придётся учить EMS, но это не так уж и плохо.
2. Continuous Replication - LCR, CCR, SCR – Непрерывная репликация
В мире электронной почты принцип репликации приносит большую выгоду – вспомните о режиме кэширования Outlook. Репликация – это здорово, репликацию мы любим. Непрерывная репликация (CR), известная также как пересылка логов (log shipping) – это проверенная концепция корпоративных баз данных. Как это работает в Exchange? Вот так:
• Начиная с E2000, у нас были группы хранения и в каждой группе хранения базы данных и логи. В Е2007 все схоже, но с одной ключевой разницей, требующейся для поддержки CR – разрешена только одна база данных и один ассоциированный набор логов на каждую группу хранения (Вы можете иметь до 50 групп хранения). Это изменение облегчает пересылку логов, являющуюся «сердцем» CR.
• Используя CR, вы имеете «живую копию» ваших данных – обновляемую напрямую конечными пользователями. На диске (исключая то, что находится а памяти), это «изображается» суммой базы данных (.edb) и не подтверждённые транзакции в лог-файле. Это классический метод создания высоконадежных баз данных.
• Когда вы проводите первоначальный запуск CR (используя командлеты), вы берёте вашу работующую базу данных и копируете в другое место (лучше всего на разные физические диски, находящиеся на одном или даже на разных серверах). Как только файлы логов заполняются на рабочем сервере, непрерывно копируются в это новое местоположение и замещают старые. Этот способ позволяет поддерживать вашу рабочую и ожидающую базы данных практически идентичными (другое название – асинхронная пересылка логов). В E2007 размер файла лога уменьшен с 5 мегабайт до 1, что упрощает процесс – меньше лог, быстрее передаётся файл и меньше потенциальный разрыв между активным и пассивным узлом. Но как мне кажется, ваши пользователи не желают терять НИЧЕГО. Как этого добиться? В Е2007 есть решение – оно называется Transport Dumpster.
• Transport Dumpster – это компонент роли сервера-концентратора. Примерно это выглядит так – сервер-концентратор сохраняет копию каждого сообщения (только в ролях CCR, LCR) за определённый период. В случае экстренного восстановления новоактивированный кластер запрашивает у всех концентраторов передать все, что накопилось в Transport Dumpster’е. Если сообщение уже есть – его отбрасывают, если нет – доставляют. Это не гарантирует полной безопасности, но позволит вам в случае падения поднять почтовую систему с минимальными потерями данных.
LCR, CCR и SCR – это различные варианты этого решения со своими плюсами и минусами. В LCR репликация может производиться на самом сервере. В CCR используется другой вариант Windows Clustering, называемый Majority Node Set для создания 2-х нодового кластера. SCR можно комбинировать SCC, LCR и CCR для получения целого набора интересных возможностей.
Нижеследующий текст - мой малопрофессиональный перевод содержательной части данной статьи: http://blogs.technet.com/mcs-ireland-infrastructure/archive/2007/12/20/what-s-new-in-exchange-2007-clustering.aspx
Переводить "воду" не люблю, потому придетсяо бойтись без авторских рассуждений.
4 новых системы кластеризации и 4 новых сокращения.
Ура – 4 новых сокращения, чтобы смущать наших коллег и начальников и выглядеть умным. Итак:
• SCC - Single Copy Cluster
• LCR - Local Continuous Replication
• CCR - Cluster Continuous Replication
• SCR - Standby Continuous Replication
Давайте рассмаотрим их поближе.
1. SCC - Single Copy Cluster – «Классическая кластеризация»
Изначальный тип кластеризации теперь известен как Single Copy Cluster. Это там, где мы обеспечиваем избыточность для наших серверов, но все еще имеем единую точку отказа – общие диски, содержащие кворум кластера, базы данных Exchange и логи. В E2007 основы работы данной системы не изменились, однако появилось некоторое число дополнений и улучшений. Вот наиболее важные из них:
• В предыдущих версиях, когда вы инсталлировали Exchange, вы все получали в одном решении и должны были отключать все, что вам не требовалось. Это распространялось и на кластера, и имело тенденцию приводить к появлению функционала, который никогда не использовался. В Е2007, используя концепцию ролей сервера, вы можете выбрать, какую роль вы хотите получить – хранилища, концентратора, пограничного сервера или сервера объединённых коммуникаций. В этом случае Single Copy Cluster (и все другие типы кластеров) распространяются только на роль сервера хранилища. Это упрощение крайне выгодно. Отказоустойчивость остальных ролей достигается другими методами – NLB и т.п.
• В предыдущих версиях Exchange, в случае отказа одной базы данных в группе хранения из-за проблем с дисковой подсистемой весь сервер имел fail-over из-за чего на больших серверах это приводило к большим проблемам. В Е2007 упавшая база данных отмонтируется, в то время как остальные продолжают функционировать. Теперь вы можете восстанавливать разрушенную базу данных отдельно.
• В прошлых версиях Single Copy Cluster требовал серьёзных навыков в администрировании кластеров и связанных с ними моментов. В Е2007 большая часть управления кластерами теперь часть Exchange Management Shell. Вам все еще требуется немного поработать администратором кластеров (или попросить кого-нибудь это сделать за вас), но вы можете контролировать процесс используя новые коммандлеты в EMS. Да, вам придётся учить EMS, но это не так уж и плохо.
2. Continuous Replication - LCR, CCR, SCR – Непрерывная репликация
В мире электронной почты принцип репликации приносит большую выгоду – вспомните о режиме кэширования Outlook. Репликация – это здорово, репликацию мы любим. Непрерывная репликация (CR), известная также как пересылка логов (log shipping) – это проверенная концепция корпоративных баз данных. Как это работает в Exchange? Вот так:
• Начиная с E2000, у нас были группы хранения и в каждой группе хранения базы данных и логи. В Е2007 все схоже, но с одной ключевой разницей, требующейся для поддержки CR – разрешена только одна база данных и один ассоциированный набор логов на каждую группу хранения (Вы можете иметь до 50 групп хранения). Это изменение облегчает пересылку логов, являющуюся «сердцем» CR.
• Используя CR, вы имеете «живую копию» ваших данных – обновляемую напрямую конечными пользователями. На диске (исключая то, что находится а памяти), это «изображается» суммой базы данных (.edb) и не подтверждённые транзакции в лог-файле. Это классический метод создания высоконадежных баз данных.
• Когда вы проводите первоначальный запуск CR (используя командлеты), вы берёте вашу работующую базу данных и копируете в другое место (лучше всего на разные физические диски, находящиеся на одном или даже на разных серверах). Как только файлы логов заполняются на рабочем сервере, непрерывно копируются в это новое местоположение и замещают старые. Этот способ позволяет поддерживать вашу рабочую и ожидающую базы данных практически идентичными (другое название – асинхронная пересылка логов). В E2007 размер файла лога уменьшен с 5 мегабайт до 1, что упрощает процесс – меньше лог, быстрее передаётся файл и меньше потенциальный разрыв между активным и пассивным узлом. Но как мне кажется, ваши пользователи не желают терять НИЧЕГО. Как этого добиться? В Е2007 есть решение – оно называется Transport Dumpster.
• Transport Dumpster – это компонент роли сервера-концентратора. Примерно это выглядит так – сервер-концентратор сохраняет копию каждого сообщения (только в ролях CCR, LCR) за определённый период. В случае экстренного восстановления новоактивированный кластер запрашивает у всех концентраторов передать все, что накопилось в Transport Dumpster’е. Если сообщение уже есть – его отбрасывают, если нет – доставляют. Это не гарантирует полной безопасности, но позволит вам в случае падения поднять почтовую систему с минимальными потерями данных.
LCR, CCR и SCR – это различные варианты этого решения со своими плюсами и минусами. В LCR репликация может производиться на самом сервере. В CCR используется другой вариант Windows Clustering, называемый Majority Node Set для создания 2-х нодового кластера. SCR можно комбинировать SCC, LCR и CCR для получения целого набора интересных возможностей.
Подписаться на:
Сообщения (Atom)