Всё о о Microsoft Exchange Server и электронной почте.

Вебкаст «Разговоры об ИТ» № 52 пройдет в среду 25 марта с 21:00 до 23:00

Как обычно, в среду, пройдет еженедельный вебкаст «ExchangeRUS—Разговоры об ИТ» № 52, на котором ИТ-специалисты со всей России будут обсуждать текущие проблемы.

Меня сегодня не будет из-за очень важного события, но Самарская ИТ мафия обещала мне помочь и провести встречу. Выделенной темы нет, будет беседа обо всем подряд, но возможно ребята и приготовят сюрприз. Я постараюсь присоединиться попозже.

Если у Вас есть вопросы по технологиям, то на них смогут ответить: я по MS Exchange Server, Вася Гусев[MVP] по PowerShell и Александр Станкевич[MVP] по Windows.

ВХОД в LiveMeeting

(начнет работать за 30 мин до встречи)

Для участия нужна гарнитура(наушники+микрофон), Интернет и клиент Live Meeting 2007(15Mb). Желательно использовать USB гарнитуру.

Запись встречи VIDEO:Разговоры об ИТ. Выпуск №52. «Решение проблем». Максим Ефремов(RAR) 5.12 MB Скачано 877 раз

Запись встречи VIDEO:Разговоры об ИТ. Выпуск №52. «Exchange Storage Calculator и JetStress». Артем Синицын(RAR) 25.48 MB Скачано 840 раз

Похожие посты:

  • anton

    Попал не с начала, что очень обидно. Возник такой вопрос, хорошо я определил, что притык по  загрузке Jetstress в 8 потоков. Что теперь  делать  с Exchange 2007, где теперь это использовать, т.е. как это  использовать  ?

  • Artyom Sinitsyn

    Досадный момент, что Вы попали на встречу не с самого начала, будет легко исправлен как только Паша Нагаев выложил прямо в этом посте ссылку на запись вчерашней встречи целиком.
    Как только Вы получили максимальное значение Thread Count (8), при котором у Вас все почтовые базы и директории журанов транзакций проходят тест успешно (Значение Overall Test Result = Pass), посмотрите в отчете производительности значение IOPS.
    Это значение IOPS должно превышать (лучше даже существенно превышать) то значение IOPS, которое было получено для Вашей системы в результате расчета требований с помощью Mailbox Server Storage Requirements Calculator.
    За подробностями этого процесса обращайтесь к записи вчерашней встречи.
    Напоследок, примите пожелание удачи!

  • http://www.exchangerus.ru Pavel Nagaev

    Первый доклад выложил. Пришлось собирать заново, на остлушку времени не было, поэтом все как было, так и есть.

    Попозже выложу второй доклад.

  • Artyom Sinitsyn

    Действительно, ссылка — битая. Думаю, завтра Паша всё поправит.
    От себя отмечу, что тема небольшого доклада Максима Ефремова скорее обзор методологии локализации, устранения и предотвращения проблем. Некий концепт траблшутинга (troubleshooting), если позволите.

  • solaris24

    Станно было слышать что SCR никто не использует или использую но мало. С успехом пользуюсь этой технологией. Сервера территориально стоят в разных местах. Плюс, когда начались проблемы с железом на одном сервере, с успехом перещел на целевой сервер SCR за 30мин, хоть это и был плановый переход.
    У меня все роли стоят на одном сервере, поэтому предпочтение отдал SCR, а не CCR, т.к. для CCR нужно ещё докупать 2 сервера и CCR сложнеее в поддержке и администрировании.

  • Artyom Sinitsyn

    Про использование SCR я говорил исключительно из своего практического опыта работы с заказчиками. Используют редко, потому как далеко не каждая компания располагает сразу двумя датацентрами.
    Тем более сравнивать напрямую технологию CCR с SCR нельзя, так как CCR — это технология High Availability, а SCR — это технология Site Resilience. В идеале они дополняют друг друга. в завершение SCR не предоставляет возможности автоматического переключения в случае выхода из строя одного из узлов.
    Вот когда Вы заключите с заказчиком SLA доступности сервисов Exchange Server 2007, в котором будет прописан уровень доступности 99,7, тогда по другому взглянете на выбор между CCR и SCR. Цель определяет средства, и никак иначе =)

  • solaris24

    согласен, ССR хорош если выйдет из строя один из узлов кластера. Но ведь CCR обеспечивает доступность только роли Mailbox, а если из строя выйдет узел с остальными(HUB, CAL) ролями??? получаеться  для этих ролей, нужно иметь ещё один сервер, вообщем минимум 5 серверов нужно иметь для полноценной доступности с использованием CCR.
    А так в связке LCR+SCR, нужно всего два сервера. Да и требования к доступности сервисов, тоже у меня на высоком уровне, и напрямую связаны с размером зарплаты ) Но если будут ещё пару свободных серверов, может и перейду на CCR.

  • Artyom Sinitsyn

    Так все технологии непрерывной репликации относятся исключительно к роли Exchange Mailbox Server: и LCR, и CCR и SCR. Остальные роли Exchange Server 2007 для отказоустойчивости необходимо дублировать, то есть вводить в эксплуатацию дополнительны серверы с этими ролями.
    Самая минимальная отказоустойчивая топология предполагает использование 4 серверов: 2x HUB+CAS и 2x MBX, объединенных в CCR-кластер. Если необходимо обеспечить отказоустойчивость на уровне географической площадки, нужно добавить по крайне мере ещё один сервер под SCR Target Server.

  • http://okrylov.wordpress.com Oleg Krylov

    А простой в 30 минут в серьезной организации может привести к снижению зарплаты до 0 и свежевыданным статусом безработного. Это время превышает месячный простой по стандартному SLA (99,9%)

  • http://www.exchangerus.ru Pavel Nagaev

    «требования к доступности сервисов» — Доступность — CCR, SCC.       SCR —  это технология быстрого запуска системы в случае краха основной и с доступностью связана косвенно. Скажем авария произошла в час ночи. До тех пор, пока Вы не придете на работу, система будет не доступна. Какая же это доступность?