По своему опыту, если бы начали обновлять парк серверов сейчас, а не 4 года назад, то начал бы с приобретения пары серверов с большим кол-вом дисков, под отказоустойчивую SMB3 шару, и одного (лучше конечно двух) серверов под гипервизоры (мало дисков, много памяти и хорошие CPU). Мы в схожих стартовых условиях виртуализацию «проспали», теперь наверстываем, перераспределяя мощности. А когда всё будет в гипервизорах можно задуматься о переносе в частное облако — гибче управление, лучше изоляция от сетевых проблем, проще перераспределять нагрузку.
Мы так и не решились развернуть VDI решение, т.к. производство предполагает слишком много существенно разных ролей для рабочих мест. Не уверен, что это было правильное решение, но старый парк техники у нас неплохо задействован для RDS доступа.
Проблемы в общем-то схожие, поэтому и решения — типовые. Виртуализация уже тут отмечена в нескольких комментариях, присоединяюсь, это хорошая штука.
Не упомянули проблему «связности Интернет пространства» в России. Это когда из Казани в Екатеринбург через Новосибирск. ;-) И когда «вдруг» HTTPS/VPN начинает ходить через «людей в черномсером» совершенно непредсказуемым маршрутом.
PS Azure test «съели» на тестах за выходные, всего одной 1С базой. Показали расчет (калькулятор) в месяц биг боссу. Вера в рекламу облаков у него существенно пошатнулась. ;-)
Насчет частного облака и структуры затрат IMHO Вы не до конца раскрыли тему.
Частное облако совсем не обязательно требует космических денег для перехода на него.
Затраты на переход, если текущая серверная часть относительно свежая, не виртуализирована и её мощность имеет «перекосы», «тут густо / тут пусто» могут оказаться отрицательными! Т.е. дать выгоду за счет отказа от покупки избыточных «железок».
Если уже виртуализирована большая часть серверов, то единственные затраты это увеличенный объем работы системных инженеров на время перехода.
Создать «с нуля», если основной серверный парк это 5-10 устаревших трудяг, например на E7520: затраты ровно столько же, сколько и привести ИТ инфраструктуру к классическому актуальному адекватному состоянию. Да, это дорого.
Итого: затраты на железо нужны только если текущая мат.часть устаревшая и не тянет (с трудом тянет/не дает надежности). В этом случае они действительно велики.
Мы сейчас как раз заканчиваем считать проект перехода, получается, что при имеющихся лицензиях и текущем железе наши затраты — только оплата работы инженеров в рамках проекта. Выгоды: упрощение обеспечения отказоустойчивости или сокращение времени отработки отказа. Разумное перераспределение имеющихся мощностей. Упрощение обслуживания и обновления ПО и железа. Возможность быстро и почти без затрат разместить копию всей или части инфраструктуры в «настоящем» облаке в случае необходимости.
Частное облако не обязательно располагается удаленно от основной площадки. Фактор ISP как раз можно таким способом исключить. «Железячное» разделение сетей тоже не обязательно.
Как-то вот так будет точнее, наверное?
PS У нас всё сейчас выполняется на MS Windows Server 2012 R2 + System Center 2012 R2, при этом в работе есть и «старые» сервера (2003/2008R2) и Линукс-сервера (CentOS/ClearOS). Производственное предприятие.
Описанная Вами конфигурация на 90% совпадает с тем, что было на моём предприятии в 2004-м году. Для малых и средних производственных и перерабатывающих предприятий она, увы, типична. Оптимизм статьи, которая Вас подвигла на этот пост я тоже совершенно не разделяю, даже со скидкой на то, что в последнем абзаце автор уточнял
что все вышесказанное относится к субъектам РФ, где культура использования ИТ достаточно развита.
Дело не в «субъекте РФ», а в том, что малый и средний производственный бизнес настолько финансово неконкурентен, что поднятие его эффективности инвестированием в ИТ является экономически невыполнимой задачей.
Для того, чтобы получить ощутимый эффект от инвестиций в ИТ нужна некоторая минимальная пороговая сумма. Того, что есть возможность вложить сейчас, хватает только на «поддержку штанов». И это не вина «плохого менеджмента», или «неграмотных ИТ», и даже не инфраструктурная географическая проблема с Интернетом (за нормальные деньги быстро появляется хороший Интернет даже там, где про него до этого вообще не слышали) — это общая проблема экономической политики государства. Ему не нужен малый и средний сегмент производства. Вообще.
Руки, понятное дело, опускать не стоит, а поступающее финансирование на ИТ имеет смысл тратить, как Вы и написали, не на «облака», а на медленное, но методически правильное подтягивание структуры до управляемой и надёжной. Решающей текущие задачи бизнеса.
Желаю Вам довести ИТ систему до состояния «бизнес доволен, админы заняты приятным делом»!
Только шейпинг + ограничение на максимальное кол-во открытых соединений, чтобы не «положили канал». И полный логгинг активности.
Вся серверная инфраструктура пользуется отдельными от пользователей каналами.
Запрещать тратить рабочее время технологическими средствами на что-то не связанное с работой — непродуктивно.
У нас это административный вопрос. Не выполняешь вовремя работу — могут поинтересоваться, «а не на котяток ли оно убито». И то, в самую последнюю очередь.
Цель нашего государства — получить личный профит. Это значит, что всё, за что оно берется становится дороже и/или хуже.
Себе они какой-нибудь ЦОД под размещение облака скорее всего сделают (по 10-ти кратной цене), однако есть большая вероятность того, что конкуренция опять будет убита, как произошло сейчас с Интернет магазинами.
Приятной неожиданностью для меня стал тот факт, что наше государство начало обращать внимание на новые технологии и решилось задуматься над их использованием.
и после этого пишете
уже понятно в какую сторону поворачивает тенденция, и я не вижу никаких оснований, почему она должна повернуть в другую сторону.
— уже одно это добавляет рисков использования больше, чем все технологические и финансовые проблемы внедрения! :-)
Но с чего вы взяли что «облака уже дешевле по общей стоимости, если строить бизнес «с нуля»»??
1) Дешевле — не значит, что можно обойтись малыми затратами. Т.е. тоже дорого.
2) Для малого и среднего бизнеса «с нуля» есть масса возможностей обойтись именно «идеальной» моделью, арендовав одно-два типовых приложения (SaaS). Создание и поддержка собственной ИТ инфраструктуры под ту же 1С 8.Х обойдется значительно дороже.
3) Для других сценариев — имеет смысл рассматривать соотношение цена/качество и минимально необходимые бизнесу условия SLA при наличии финансового ограничителя. Тут действительно облако может сейчас выйти дороже, но при более высоком SLA, чем в варианте on-premises only.
PS Для Российского малого и среднего бизнеса технология действительно новая, т.к. практическая возможность и целесообразность её использовать стала реальностью совсем недавно.
Дело не в прогнозах, облака уже дешевле по общей стоимости, если строить бизнес «с нуля», а вот реальная ситуация, когда нужен переход очень и очень неоднозначная.
Собственный ЦОД (пускай даже из нескольких слабых серверов) — это основные фонды, облако — операционные расходы, с обязательными регулярными выплатами. Свои сервера можно заложить в банк, а облако можно потерять, если у компании временные финансовые сложности, и это реальный риск. Полная зависимость бизнеса от возможности доступа к облаку — это очень высокий риск. Самый простой пример: облако работает, а на основной площадке бизнеса «почему-то не завезли инетернет». Ну кончился, на всех не хватило. Пара дней и будет. И и и…? Как производству работать без учета?
Теперь рассмотрим модели и расходы. «Идеальная» модель: все потребности бизнеса закрываются одной — двумя типовыми ERP/CRM — это SaaS. Затраты: расходы на аренду ПО, поддержка клиентских мест, необходим минимум своего персонала. «Более реальная модель»: «Идеальная» + стандартные средства общения, например Exchange/Lync. Назовем её SaaS+. Затраты: расходы на аренду ПО, поддержка клиентских мест, администрирование учетных записей, необходимо чуть больше своего персонала. «Ещё более реальная модель»: = предыдущая + ПО, требующее инфраструктуры. Это SaaS + IaaS. Затраты: все предыдущие + _свои_ квалифицированные инженеры для поддержки облачной инфраструктуры. Замечу, что даже 1С 8.Х на нетиповой конфигурации это уже IaaS. «Суровая жызненная модель»: Своя инфраструктура, свой кастомизированный софт, некоторое количество клиентских рабочих мест. Хотим уйти в облако. Начинаем считать: разово переехать — нереально, нужен переходной процесс, во время процесса затраты на «своё» никуда не денутся, но к ним сразу прибавляются затраты на облако. Инженеры поддержки инфраструктуры и специалисты поддержки пользователей на это время дорожают, т.к. работы становится больше и нужна более высокая квалификация. Ликвидность своего ЦОД после перехода — практически нулевая. В перспективе — повышение доступности всех сервисов, однако первый же сбой доступа к облаку вызывает у бизнеса баттхерт «за что я плачу такие деньги, если вы ничего сделать в случае аварии не можете?», плюс неприятное «открытие» для бизнеса, поверившего рекламе «ваши затраты — только облако», что от зависимости и от затрат на своих (или аутсорсных) специалистов поддержки клиентов, ПО и инфраструктуры уйти почему-то не получилось. Итого, радужная картинка превращается в просто обычную: Появилась новая технология, нужно задействовать её плюсы.
PS Верить проектам типа «Электронная Россия» и тому, что там что-то будет сделано на общее благо, да ещё и не через «известное место» — это просто верх наивности, ну или материал для сайта Единой России.
В розыске картинка: физическая топология ЦОД с установленным Azure Pack с обязательными элементами
1) Подключение к нескольким ISP
2) Несколько гипервизоров
3) HNV-шлюз(ы)
4) Невиртуализированная часть сети и её подключение
Есть такая?
Спасибо! Чем дальше, чем интереснее.
Подскажите, есть ли в сети хорошие гайды по переходу от «просто виртуализации» (несколько гипервизоров, в том числе и с заведенными напрямую «хвостами» от ISP) к «частному облаку»?
Обязательно или в таком случае менять топологию физической сети ЦОД, т.е. разделять сети физически, пропуская трафик к частному облаку исключительно через выделенный HNV шлюз?
Если да, то как не сделать именно его точкой отказа?
Спасибо.
Больше полугода пользуюсь Acer W511. Производительности достаточно для Outlook/Lync/Skype. При активной переписке с периодическими разговорами и при подключении через 3G / WiFi батареи хватает на 14-18 часов (без клавиатурного дока — около 8-ми).Однако комфортной работу именно с Word я бы не назвал. 1366 на 768 для удобной работы с большим текстом мало. Презентации — тоже только посмотреть, если нужно. Visio не тупит, но что-то создать в нем — проблема из-за низкого разрешения. Excel — хватило бы и просмотра.
Однако в командировках, как девайс для удаленной «рулежки» и взаимодействия/связи с коллегами — идеален.
Некоторое время пытался пользоваться Asus Pad infinity, убедился, что _для меня_ девайс бесполезен. Полагаю, что его назначение более заточено на развлекательные применения + соцсети.
Если у проекта внедрения более одного руководителя (максимум — более двух) — проект обречен.
Если причина внедрения " у всех есть, а мы что хуже?" — проект является чистым выбросом средств на ветер.
Если для внедрения нужно переписать более ~20% бизнес процессов в типовой «взрослой» ERP — компания требует кардинального пересмотра управления в первую очередь, а внедрение такой кастомизированной ERP системы если и закончится когда-либо, то положительного эффекта не даст никакого.
Или, как минимум, часть информации.
По своему опыту, если бы начали обновлять парк серверов сейчас, а не 4 года назад, то начал бы с приобретения пары серверов с большим кол-вом дисков, под отказоустойчивую SMB3 шару, и одного (лучше конечно двух) серверов под гипервизоры (мало дисков, много памяти и хорошие CPU). Мы в схожих стартовых условиях виртуализацию «проспали», теперь наверстываем, перераспределяя мощности. А когда всё будет в гипервизорах можно задуматься о переносе в частное облако — гибче управление, лучше изоляция от сетевых проблем, проще перераспределять нагрузку.
Мы так и не решились развернуть VDI решение, т.к. производство предполагает слишком много существенно разных ролей для рабочих мест. Не уверен, что это было правильное решение, но старый парк техники у нас неплохо задействован для RDS доступа.
Проблемы в общем-то схожие, поэтому и решения — типовые. Виртуализация уже тут отмечена в нескольких комментариях, присоединяюсь, это хорошая штука.
Не упомянули проблему «связности Интернет пространства» в России. Это когда из Казани в Екатеринбург через Новосибирск. ;-) И когда «вдруг» HTTPS/VPN начинает ходить через «людей в
черномсером» совершенно непредсказуемым маршрутом.PS Azure test «съели» на тестах за выходные, всего одной 1С базой. Показали расчет (калькулятор) в месяц биг боссу. Вера в рекламу облаков у него существенно пошатнулась. ;-)
Частное облако совсем не обязательно требует космических денег для перехода на него.
Затраты на переход, если текущая серверная часть относительно свежая, не виртуализирована и её мощность имеет «перекосы», «тут густо / тут пусто» могут оказаться отрицательными! Т.е. дать выгоду за счет отказа от покупки избыточных «железок».
Если уже виртуализирована большая часть серверов, то единственные затраты это увеличенный объем работы системных инженеров на время перехода.
Создать «с нуля», если основной серверный парк это 5-10 устаревших трудяг, например на E7520: затраты ровно столько же, сколько и привести ИТ инфраструктуру к классическому актуальному адекватному состоянию. Да, это дорого.
Итого: затраты на железо нужны только если текущая мат.часть устаревшая и не тянет (с трудом тянет/не дает надежности). В этом случае они действительно велики.
Мы сейчас как раз заканчиваем считать проект перехода, получается, что при имеющихся лицензиях и текущем железе наши затраты — только оплата работы инженеров в рамках проекта. Выгоды: упрощение обеспечения отказоустойчивости или сокращение времени отработки отказа. Разумное перераспределение имеющихся мощностей. Упрощение обслуживания и обновления ПО и железа. Возможность быстро и почти без затрат разместить копию всей или части инфраструктуры в «настоящем» облаке в случае необходимости.
Частное облако не обязательно располагается удаленно от основной площадки. Фактор ISP как раз можно таким способом исключить. «Железячное» разделение сетей тоже не обязательно.
Как-то вот так будет точнее, наверное?
PS У нас всё сейчас выполняется на MS Windows Server 2012 R2 + System Center 2012 R2, при этом в работе есть и «старые» сервера (2003/2008R2) и Линукс-сервера (CentOS/ClearOS). Производственное предприятие.
Для того, чтобы получить ощутимый эффект от инвестиций в ИТ нужна некоторая минимальная пороговая сумма. Того, что есть возможность вложить сейчас, хватает только на «поддержку штанов». И это не вина «плохого менеджмента», или «неграмотных ИТ», и даже не инфраструктурная географическая проблема с Интернетом (за нормальные деньги быстро появляется хороший Интернет даже там, где про него до этого вообще не слышали) — это общая проблема экономической политики государства. Ему не нужен малый и средний сегмент производства. Вообще.
Руки, понятное дело, опускать не стоит, а поступающее финансирование на ИТ имеет смысл тратить, как Вы и написали, не на «облака», а на медленное, но методически правильное подтягивание структуры до управляемой и надёжной. Решающей текущие задачи бизнеса.
Желаю Вам довести ИТ систему до состояния «бизнес доволен, админы заняты приятным делом»!
Вся серверная инфраструктура пользуется отдельными от пользователей каналами.
Запрещать тратить рабочее время технологическими средствами на что-то не связанное с работой — непродуктивно.
У нас это административный вопрос. Не выполняешь вовремя работу — могут поинтересоваться, «а не на котяток ли оно убито». И то, в самую последнюю очередь.
Себе они какой-нибудь ЦОД под размещение облака скорее всего сделают (по 10-ти кратной цене), однако есть большая вероятность того, что конкуренция опять будет убита, как произошло сейчас с Интернет магазинами.
1) Дешевле — не значит, что можно обойтись малыми затратами. Т.е. тоже дорого.
2) Для малого и среднего бизнеса «с нуля» есть масса возможностей обойтись именно «идеальной» моделью, арендовав одно-два типовых приложения (SaaS). Создание и поддержка собственной ИТ инфраструктуры под ту же 1С 8.Х обойдется значительно дороже.
3) Для других сценариев — имеет смысл рассматривать соотношение цена/качество и минимально необходимые бизнесу условия SLA при наличии финансового ограничителя. Тут действительно облако может сейчас выйти дороже, но при более высоком SLA, чем в варианте on-premises only.
PS Для Российского малого и среднего бизнеса технология действительно новая, т.к. практическая возможность и целесообразность её использовать стала реальностью совсем недавно.
Собственный ЦОД (пускай даже из нескольких слабых серверов) — это основные фонды, облако — операционные расходы, с обязательными регулярными выплатами. Свои сервера можно заложить в банк, а облако можно потерять, если у компании временные финансовые сложности, и это реальный риск. Полная зависимость бизнеса от возможности доступа к облаку — это очень высокий риск. Самый простой пример: облако работает, а на основной площадке бизнеса «почему-то не завезли инетернет». Ну кончился, на всех не хватило. Пара дней и будет. И и и…? Как производству работать без учета?
Теперь рассмотрим модели и расходы.
«Идеальная» модель: все потребности бизнеса закрываются одной — двумя типовыми ERP/CRM — это SaaS. Затраты: расходы на аренду ПО, поддержка клиентских мест, необходим минимум своего персонала.
«Более реальная модель»: «Идеальная» + стандартные средства общения, например Exchange/Lync. Назовем её SaaS+. Затраты: расходы на аренду ПО, поддержка клиентских мест, администрирование учетных записей, необходимо чуть больше своего персонала.
«Ещё более реальная модель»: = предыдущая + ПО, требующее инфраструктуры. Это SaaS + IaaS. Затраты: все предыдущие + _свои_ квалифицированные инженеры для поддержки облачной инфраструктуры. Замечу, что даже 1С 8.Х на нетиповой конфигурации это уже IaaS.
«Суровая жызненная модель»: Своя инфраструктура, свой кастомизированный софт, некоторое количество клиентских рабочих мест. Хотим уйти в облако. Начинаем считать: разово переехать — нереально, нужен переходной процесс, во время процесса затраты на «своё» никуда не денутся, но к ним сразу прибавляются затраты на облако. Инженеры поддержки инфраструктуры и специалисты поддержки пользователей на это время дорожают, т.к. работы становится больше и нужна более высокая квалификация. Ликвидность своего ЦОД после перехода — практически нулевая. В перспективе — повышение доступности всех сервисов, однако первый же сбой доступа к облаку вызывает у бизнеса баттхерт «за что я плачу такие деньги, если вы ничего сделать в случае аварии не можете?», плюс неприятное «открытие» для бизнеса, поверившего рекламе «ваши затраты — только облако», что от зависимости и от затрат на своих (или аутсорсных) специалистов поддержки клиентов, ПО и инфраструктуры уйти почему-то не получилось.
Итого, радужная картинка превращается в просто обычную: Появилась новая технология, нужно задействовать её плюсы.
PS Верить проектам типа «Электронная Россия» и тому, что там что-то будет сделано на общее благо, да ещё и не через «известное место» — это просто верх наивности, ну или материал для сайта Единой России.
1) Подключение к нескольким ISP
2) Несколько гипервизоров
3) HNV-шлюз(ы)
4) Невиртуализированная часть сети и её подключение
Есть такая?
Подскажите, есть ли в сети хорошие гайды по переходу от «просто виртуализации» (несколько гипервизоров, в том числе и с заведенными напрямую «хвостами» от ISP) к «частному облаку»?
Обязательно или в таком случае менять топологию физической сети ЦОД, т.е. разделять сети физически, пропуская трафик к частному облаку исключительно через выделенный HNV шлюз?
Если да, то как не сделать именно его точкой отказа?
Спасибо.
Однако в командировках, как девайс для удаленной «рулежки» и взаимодействия/связи с коллегами — идеален.
Некоторое время пытался пользоваться Asus Pad infinity, убедился, что _для меня_ девайс бесполезен. Полагаю, что его назначение более заточено на развлекательные применения + соцсети.
WindowsGoogle Update реально утомил своей навязчивостью. Жду Windows Phone 8 Dual SIM.Ваш К.О. :-)
Если причина внедрения " у всех есть, а мы что хуже?" — проект является чистым выбросом средств на ветер.
Если для внедрения нужно переписать более ~20% бизнес процессов в типовой «взрослой» ERP — компания требует кардинального пересмотра управления в первую очередь, а внедрение такой кастомизированной ERP системы если и закончится когда-либо, то положительного эффекта не даст никакого.