Интересно, какой там размер самой тяжелой базы, что нельзя было спокойно перетащить полный дамп БД, а потом в технологическое окно накатить дифференциальную копию?
Для каждого проекта миграции мы выбираем оптимальные решения с точки зрения трудозатрат, времени миграции, времени простоя и технологических возможностей. При передаче данных большую роль играет не только объем передаваемых данных, но и ширина канала. Очень часто исходящий интернет имеет довольно маленькую пропускную способность. В данном проекте идеально подошел автоматизированный процесс с использованием Хайстекс. И на текущий момент этот метод лидирует в наших проектах за счет своей простоты.
Чаще чем сервер СУБД? Перегружен в каком плане, какие ресурсы?
Нагрузка на процессор сервера приложений является частым явлением. Процессор сервера СУБД испытывает меньшие нагрузки.
Почему это выяснилось уже в процессе миграции, а не до? Что за интересный такой кейс? Можно подробнее рассказать?
Как переносили лицензии? При тестовой миграции по сути нужен двойной набор лицензий, как решали этот вопрос?
За счет дефицита времени не всегда получается провести полноценный аудит, а в рамках экспресс-аудита невозможно охватить абсолютно все аспекты. В данном случае сервер баз данных мигрировался как есть, что не ухудшило его показателей после миграции. После миграции мы проводили анализ нагрузки на все подсистемы, чтобы убедиться, что не осталось узких мест, даже если отсутствуют жалобы от пользователей. Миграция позволила расшить узкое место в процессорных ресурсах, что автоматически перекинуло нагрузку на диски. В исходной инфраструктуре как раз не хватало процессорных мощностей, поэтому диски чувствовали себя хорошо.
Лицензии переносились с помощью резервных пин-кодов после миграции сервера лицензирования в облако. Это одна из ручных операций, которая всегда должна учитываться в плане миграции.
Кажется, что статья как раз состоит из технических моментов, которыми мы хотели поделиться. Возможно, у вас остались какие-либо вопросы, на которые не удалось получить ответ исходя статьи, напишите в комментариях, вернемся с ответом
В разное время сеть администрировалась различными специалистами, как правило, подрядчиками. В результате получилась довольно запутанная конфигурация из ipsec-ов, таблиц и политик маршрутизации. Где-то маршруты шли сразу на центральный роутер, где-то транзитом через другие роутеры. На этапе тестирования это не вскрылось, так как тесты проводились только из главного офиса и с одной из площадок, где все было хорошо.
Что касается сервера SQL, то тут целое поле для деятельности в плане неверных настроек. Самая простая и распространенная ошибка – при форматировании диска выбирается дефолтный размер блока в 4KB, когда для SQL рекомендуется блок 64KB, что реально ускоряет его работу
Доступность, масштабируемость и техподдержка – это в точку. По отзывам наших клиентов, обеспечить это силами собственного штата и имеющимися бизнес-процессами, часто бывает сложно. Поэтому выгоднее отдавать эти задачи на аутсорс, чтобы сконцентрироваться на задачах бизнеса.
Ну и кроме того, в каждом конкретном случае архитектура размещения систем просчитывается с учетом различных требований и рисков. Если считать совокупную стоимость владения тем или иным ресурсом, то там очень много параметров, которые следует учитывать: от простой покупки железа до процессов защиты данных, мониторинга, резервного копирования, администрирования, надежности, технической поддержки железа и так далее и так далее.
В рамках данного проекта мы связаны политикой конфиденциальности, поэтому, к сожалению, не можем раскрывать точные цифры. Но возьмем как идею для будущей статьи.
Непонятно. У заказчика был древний медленно работающий хлам, его перевели на современное оборудование, которому пришлось ДОПОЛНИТЕЛЬНО по сравнению с этим старым хламом докидывать мощности? Это как же так насайзили?
Не насайзили. Большинство проектов специфичны и не всегда включают в себя простую миграцию с одной инфраструктуры на другую. Расчет любого сайзинга производится на основе некоторых средних параметров для сеансов пользователей для конкретной конфигурации 1С. В конкретном случае эти показатели могут отличаться от средних в любую сторону. Поэтому после миграции может потребоваться корректировка сайзинга. Миграция ядро-в-ядро обычно экономически не целесообразна, так как влечет излишние затраты. Поэтому сайзинг считается по сути с нуля. Плюс в этом случае у заказчика уже были проблемы с производительностью, то есть система уже тормозила, поэтому мощности и настройки корректировались до момента, пока не стало тормозить
При компенсации в виде "уменьшения стоимости услуг на время простоя" SLA обещать можно примерно любой. :)
Заказчикам важна гарантированная доступность услуги, а не последующая компенсация, поскольку она не решит проблемы потерянного времени и денег в случае простоя сервисов компании. Поэтому мы сосредотачиваемся именно на поддержании необходимого SLA
Переход в облако позволяет оптимизировать как минимум затраты на услуги специалистов 1С, так как можно взять эту услугу у провайдера облака (при наличии у него соответствующих компетенций) на требуемые часы для поддержки платформы или разработки нужного функционала. Такая услуга может обходиться дешевле по сравнению с содержанием собственного специалиста, если он нужен не на 100% рабочего времени.
Стоимость облака также следует рассматривать по сравнению с затратами на покупку, обслуживание и обновление собственного железа и операционной системы.
Один из важных аспектов, где часто применяется облако – необходимость найти временные мощности для целей разработки, тестирования, обновлений, миграций и так далее. Если под эти задачи закупать железо, то возникнет вопрос – куда его потом деть.
В целом, оптимизация затрат – это достаточно сложный вопрос, требующий расчета в каждом конкретном случае. Да, есть компании, которые не выиграют от перехода в облако – и это скрывать бессмысленно. Но есть компании, которым комплексная услуга предоставления 1С из облака будет обходиться дешевле содержания собственной системы.
Да, конечно. Здесь также нужно отметить, что штрафы предусмотрены не только за полную недоступность услуги, но и за снижение ее качества на 20%. Ведь при достаточной деградации производительности услуг Облака, размещенные в нем ИТ-системы заказчика могут перестать функционировать, хотя Облако формально было доступно.
SLA на Облако K2 Cloud для размещения 1С составляет 99,95% и является наиболее технологически жестким на рынке. Заказчик может получить SLA выше 99,95%, например, 99,99%. Для этого нужно:
Разместить ИТ-сервис на 2 площадках K2 Cloud;
Передать функции администрирования и развития архитектуры ИТ-сервиса K2 Cloud. Это расширит область ответственности K2 Cloud, за счет чего команда K2 Cloud сможет влиять на параметры RPO/RTO и сможет повысить SLA на конкретный ИТ-сервис заказчика
Хорошей практикой в облаке является вынос сервиса лицензирования на отдельную машину, параметры которой не меняют, в отличие от рабочих серверов
Если речь идет об изменении (уменьшении или увеличении) ресурсов виртуальной машины, то, конечно, не слетает
Для каждого проекта миграции мы выбираем оптимальные решения с точки зрения трудозатрат, времени миграции, времени простоя и технологических возможностей. При передаче данных большую роль играет не только объем передаваемых данных, но и ширина канала. Очень часто исходящий интернет имеет довольно маленькую пропускную способность. В данном проекте идеально подошел автоматизированный процесс с использованием Хайстекс. И на текущий момент этот метод лидирует в наших проектах за счет своей простоты.
Нагрузка на процессор сервера приложений является частым явлением. Процессор сервера СУБД испытывает меньшие нагрузки.
За счет дефицита времени не всегда получается провести полноценный аудит, а в рамках экспресс-аудита невозможно охватить абсолютно все аспекты. В данном случае сервер баз данных мигрировался как есть, что не ухудшило его показателей после миграции. После миграции мы проводили анализ нагрузки на все подсистемы, чтобы убедиться, что не осталось узких мест, даже если отсутствуют жалобы от пользователей. Миграция позволила расшить узкое место в процессорных ресурсах, что автоматически перекинуло нагрузку на диски. В исходной инфраструктуре как раз не хватало процессорных мощностей, поэтому диски чувствовали себя хорошо.
Лицензии переносились с помощью резервных пин-кодов после миграции сервера лицензирования в облако. Это одна из ручных операций, которая всегда должна учитываться в плане миграции.
Мы наблюдаем другой тренд. Можете поделиться примерами, чтобы обсудить поподробнее?
Кажется, что статья как раз состоит из технических моментов, которыми мы хотели поделиться. Возможно, у вас остались какие-либо вопросы, на которые не удалось получить ответ исходя статьи, напишите в комментариях, вернемся с ответом
В разное время сеть администрировалась различными специалистами, как правило, подрядчиками. В результате получилась довольно запутанная конфигурация из ipsec-ов, таблиц и политик маршрутизации. Где-то маршруты шли сразу на центральный роутер, где-то транзитом через другие роутеры. На этапе тестирования это не вскрылось, так как тесты проводились только из главного офиса и с одной из площадок, где все было хорошо.
Что касается сервера SQL, то тут целое поле для деятельности в плане неверных настроек. Самая простая и распространенная ошибка – при форматировании диска выбирается дефолтный размер блока в 4KB, когда для SQL рекомендуется блок 64KB, что реально ускоряет его работу
Доступность, масштабируемость и техподдержка – это в точку. По отзывам наших клиентов, обеспечить это силами собственного штата и имеющимися бизнес-процессами, часто бывает сложно. Поэтому выгоднее отдавать эти задачи на аутсорс, чтобы сконцентрироваться на задачах бизнеса.
Ну и кроме того, в каждом конкретном случае архитектура размещения систем просчитывается с учетом различных требований и рисков. Если считать совокупную стоимость владения тем или иным ресурсом, то там очень много параметров, которые следует учитывать: от простой покупки железа до процессов защиты данных, мониторинга, резервного копирования, администрирования, надежности, технической поддержки железа и так далее и так далее.
В рамках данного проекта мы связаны политикой конфиденциальности, поэтому, к сожалению, не можем раскрывать точные цифры. Но возьмем как идею для будущей статьи.
Не насайзили. Большинство проектов специфичны и не всегда включают в себя простую миграцию с одной инфраструктуры на другую. Расчет любого сайзинга производится на основе некоторых средних параметров для сеансов пользователей для конкретной конфигурации 1С. В конкретном случае эти показатели могут отличаться от средних в любую сторону. Поэтому после миграции может потребоваться корректировка сайзинга. Миграция ядро-в-ядро обычно экономически не целесообразна, так как влечет излишние затраты. Поэтому сайзинг считается по сути с нуля. Плюс в этом случае у заказчика уже были проблемы с производительностью, то есть система уже тормозила, поэтому мощности и настройки корректировались до момента, пока не стало тормозить
Заказчикам важна гарантированная доступность услуги, а не последующая компенсация, поскольку она не решит проблемы потерянного времени и денег в случае простоя сервисов компании. Поэтому мы сосредотачиваемся именно на поддержании необходимого SLA
Переход в облако позволяет оптимизировать как минимум затраты на услуги специалистов 1С, так как можно взять эту услугу у провайдера облака (при наличии у него соответствующих компетенций) на требуемые часы для поддержки платформы или разработки нужного функционала. Такая услуга может обходиться дешевле по сравнению с содержанием собственного специалиста, если он нужен не на 100% рабочего времени.
Стоимость облака также следует рассматривать по сравнению с затратами на покупку, обслуживание и обновление собственного железа и операционной системы.
Один из важных аспектов, где часто применяется облако – необходимость найти временные мощности для целей разработки, тестирования, обновлений, миграций и так далее. Если под эти задачи закупать железо, то возникнет вопрос – куда его потом деть.
В целом, оптимизация затрат – это достаточно сложный вопрос, требующий расчета в каждом конкретном случае. Да, есть компании, которые не выиграют от перехода в облако – и это скрывать бессмысленно. Но есть компании, которым комплексная услуга предоставления 1С из облака будет обходиться дешевле содержания собственной системы.
Да, конечно. Здесь также нужно отметить, что штрафы предусмотрены не только за полную недоступность услуги, но и за снижение ее качества на 20%. Ведь при достаточной деградации производительности услуг Облака, размещенные в нем ИТ-системы заказчика могут перестать функционировать, хотя Облако формально было доступно.
SLA на Облако K2 Cloud для размещения 1С составляет 99,95% и является наиболее технологически жестким на рынке.
Заказчик может получить SLA выше 99,95%, например, 99,99%. Для этого нужно:
Разместить ИТ-сервис на 2 площадках K2 Cloud;
Передать функции администрирования и развития архитектуры ИТ-сервиса K2 Cloud. Это расширит область ответственности K2 Cloud, за счет чего команда K2 Cloud сможет влиять на параметры RPO/RTO и сможет повысить SLA на конкретный ИТ-сервис заказчика