Это понятно… А сколько должно быть сетевых у сервера и какой пропускной способностью они должны обладать :)
В общем всякое решение под свои нужды — iSCSI наверное будет неплох для решения, где сотрудники работают с базовыми программами + интернет. Где нет нагрузки на диск…
Можно скопировать диск и присвоить ему новый таргет. Это не проблема.
Меня вот больше интересует то — как будет себя вести сеть, когда все будут активно работать с диском.
Аплинки на сервере не выдержат, да и если там не будет быстрого рейда — потери производительности будут довольно сильными.
Для галочки это наверное интересно попробовать, но все же в продакшен удобнее использовать тонкого клиента. имхо.
Доверили тестировать Exchange 2010, с тем, чтобы в последующем перейти на него с облачного Гугла, который не всех устраивал.
Т.к. в дальнейшем намечался переход — решили поднять сервер в боевой среде. Процесс тестирования был довольно длительным и был подготовлен детальный проект по переходу. Было поднято три сервера на виртуальных машинах, с отказоустойчивостью. Разнесенные по площадкам и с кластеризованным хранилищем.
Особо тщательно была протестирована фича выкачивания почты из гугла и переноса ее на Exchange. Для того, чтобы хранить ее в защищенном месте, с возможностью бекапирования и восстановления. Этот процесс был автоматизирован с помощью скриптов и выглядел следующим образом:
— в Outlook пользователя создается учетная запись для почтового ящика, который находится в облаке google и выкачивается полностью в локальный pst
— после этого через power shell средствами Exchange объединяется почтовый ящик находящийся на exchange и на google (это все было автоматизированно скриптами — надо было лишь оставить включенными все компы, запустить скрипт, он сам пробегался по онлайн ПК, находил pst и объединял с ящиком)
— параллельно изменяются mx записи и вуаля — пользователь начинает пользоваться Outlook, со всеми его плюшками, без какой-либо потери сервиса.
В один из прекрасных дней, когда все было оттестировано и осталось дождаться отмашки о переходе на Exchange — пришло известие о том, что Exchange слишком дорог и останемся на облачном google.
Жалко конечно, но тестирование сворачиваем — заходим на Exchange, чтобы грамотно все вытереть — сначала удаляем все ящики. Выделяем все созданные инбоксы, а созданы были в процессе тестирования больше 70 процентов ящиков, жмем правой кнопкой и особо не задумываясь — выбираем пункт «удалить ящик» вместо «отключить»
Происходит это в 9 утра, в четверг, люди на работу подтягиваются не спеша — много и к 10 и к 11 подходит. Но в этот день все смогли работать только с 3 часов дня — восстанавливали AD из бекапа, т.к. все учетки вытерлись. (компания больше 400 человек)
Восстанавливать AD 2008 это тоже веселая история, но в другой раз :)
Тестируйте все на тестовых юзерах :)
Пока в сети будет пара портов, на которых не включен STP — такую сеть можно положить. Не важно — корпоративная это сеть или уровня провайдера. Так что говорить о умирании STP можно только на сетях, в которых доступ к каждому порту контролируется физически.
Бред. Как без spanning-tree вы сможете подключить свичи несколькими патчами и заставить по одним транкам гонять половину vlan, а половину по другим, при этом если одна половина транков падает, то включается вторая и через оставшуюся половину ходит снова весь трафик.
LAG — прекрасное дополнение, но только дополнение. И по большей части прекрасное для избыточности подключения серверов.
Зачем заводить в AD учетки мак адресов, когда можно воспользоваться dot1.x(не так уж оно и срашно) и авторизовываться по учеткам юзеров…
Представьте, что у вас организация в 1000 пользователей — не страшит заведение лишних 1000 учеток?
В общем всякое решение под свои нужды — iSCSI наверное будет неплох для решения, где сотрудники работают с базовыми программами + интернет. Где нет нагрузки на диск…
Меня вот больше интересует то — как будет себя вести сеть, когда все будут активно работать с диском.
Аплинки на сервере не выдержат, да и если там не будет быстрого рейда — потери производительности будут довольно сильными.
Для галочки это наверное интересно попробовать, но все же в продакшен удобнее использовать тонкого клиента. имхо.
Т.к. в дальнейшем намечался переход — решили поднять сервер в боевой среде. Процесс тестирования был довольно длительным и был подготовлен детальный проект по переходу. Было поднято три сервера на виртуальных машинах, с отказоустойчивостью. Разнесенные по площадкам и с кластеризованным хранилищем.
Особо тщательно была протестирована фича выкачивания почты из гугла и переноса ее на Exchange. Для того, чтобы хранить ее в защищенном месте, с возможностью бекапирования и восстановления. Этот процесс был автоматизирован с помощью скриптов и выглядел следующим образом:
— в Outlook пользователя создается учетная запись для почтового ящика, который находится в облаке google и выкачивается полностью в локальный pst
— после этого через power shell средствами Exchange объединяется почтовый ящик находящийся на exchange и на google (это все было автоматизированно скриптами — надо было лишь оставить включенными все компы, запустить скрипт, он сам пробегался по онлайн ПК, находил pst и объединял с ящиком)
— параллельно изменяются mx записи и вуаля — пользователь начинает пользоваться Outlook, со всеми его плюшками, без какой-либо потери сервиса.
В один из прекрасных дней, когда все было оттестировано и осталось дождаться отмашки о переходе на Exchange — пришло известие о том, что Exchange слишком дорог и останемся на облачном google.
Жалко конечно, но тестирование сворачиваем — заходим на Exchange, чтобы грамотно все вытереть — сначала удаляем все ящики. Выделяем все созданные инбоксы, а созданы были в процессе тестирования больше 70 процентов ящиков, жмем правой кнопкой и особо не задумываясь — выбираем пункт «удалить ящик» вместо «отключить»
Происходит это в 9 утра, в четверг, люди на работу подтягиваются не спеша — много и к 10 и к 11 подходит. Но в этот день все смогли работать только с 3 часов дня — восстанавливали AD из бекапа, т.к. все учетки вытерлись. (компания больше 400 человек)
Восстанавливать AD 2008 это тоже веселая история, но в другой раз :)
Тестируйте все на тестовых юзерах :)
LAG — прекрасное дополнение, но только дополнение. И по большей части прекрасное для избыточности подключения серверов.
Представьте, что у вас организация в 1000 пользователей — не страшит заведение лишних 1000 учеток?