Представьте: у вас крупная компания с офисами от Москвы до Дальнего Востока, сотни объектов, тысячи вахтовиков и древний сервер 1С, который едва справляется с нагрузкой. Похоже на ночной кошмар.
В этой статье я расскажу, как решить эту проблему, перенеся пять конфигураций 1С и запустив их в облаке за 4 часа. Вы узнаете о подводных камнях миграции, неожиданных сложностях и о том, как мы уложились в такое короткое время. И, возможно поймете, что вам тоже давно пора в облако.
Но сначала давайте познакомимся. Меня зовут Анжелика Захарова, я менеджер облачных проектов в K2 Cloud, а также product-owner по проектам миграции систем 1С в Облако K2.
Причины миграции
В тот раз нашим заказчиком стала крупная компания с офисами в Москве и на Дальнем Востоке. Она обслуживает производственные активы и вахтовые поселки, организует бытовую эксплуатацию зданий на производственных площадках. В зоне ответственности компании — сотни объектов и около пяти тысяч вахтовиков.
Основная бизнес-система заказчика — 1С — была развернута на стареньком сервере в московском офисе. Эта масштабная инсталляция из пяти конфигураций автоматизировала бухгалтерию, документооборот, управление автотранспортом и еще уйму всяких процессов. Из-за расположения офисов сотрудники заказчика работали с ней практически круглосуточно.
Локальная инфраструктура перестала удовлетворять потребности компании по трем причинам:
Во-первых, приложения 1С работали крайне медленно. Пользователи постоянно жаловались на низкую производительность системы.
Во-вторых, были проблемы с масштабированием. Апгрейд или покупка нового оборудования требовали значительных затрат времени и денег. Этот вопрос стал особенно актуальным в связи с планами увеличить число пользователей 1С со 160 до 300 человек.
В-третьих, компании не хватало квалифицированных специалистов для обслуживания инфраструктуры. Команда из трех ИТ-специалистов не успевала оперативно восстанавливать работу сервера при сбоях.
Заказчик провел финансовую оценку и пришел к выводу, что перенос 1С в облако выгоднее, чем замена сервера и расширение штата для его обслуживания. В нашем лице компания нашла провайдера, который предоставил строгое SLA и был бы готов сделать все «под ключ» — полностью взять ответственность за миграцию и настройку 1С.
Очевидные сложности с переносом 1С
Итак, перед нами поставили задачу перенести все пять конфигураций в К2 Облако. Казалось бы, типовой кейс по миграции: поднимайте виртуальные машины, стягивайте на них данные и настраивайте сетевую связность — делов-то. Однако продукт 1С был критически важен для бизнеса: вся работа компании зависела от него, так что действовать нужно было быстро и без ошибок. Из-за расположения офисов оказалось, что программа 1С активна чуть ли не 22 часа в сутки. Это задало максимально жесткие временные рамки для миграции. Стандартный метод экспорта-импорта базы средствами 1С сразу отпал из-за этих ограничений. Дополнительные проблемы создавал большой объем данных заказчика, а также особенности конфигураций. У каждой из них своя специфика нагрузки.
Наш департамент, специализирующийся на таких проектах, использует систему ранжирования конфигураций 1С и специальный калькулятор для расчета оптимального сайзинга. Сложность заключается в разнообразии клиентских приложений: где-то используются тонкие клиенты, а где-то — толстые, основанные на старых конфигурациях. Эти различия существенно влияют на планирование миграции и настройку облачной инфраструктуры.
Подготовка к старту проекта
В общем, нельзя было бросаться с места в карьер. Пока коллеги анализировали конфигурации, мы решили убедиться, что инфраструктура готова к миграции с точки зрения архитектуры.
Первое, что нужно сделать в таких случаях — разделить роли между разными виртуальными машинами: сервер 1С, веб-сервер, сервер MSQL, терминальный сервер и так далее. Это снижает нагрузку на сервер приложений 1С, который часто бывает перегружен. Разделение ролей уменьшает количество общих процессов, что значительно повышает производительность каждой виртуальной машины. Такой подход эффективнее, чем бесконечное наращивание мощности.
Кроме того, важно проверить настройки виртуальных машин: количество и частоту ядер процессора, объем оперативной памяти и емкость дисков. В инфраструктуре с большим legacy они часто бывают настроены неоптимально. Заодно мы подсказали админам, как организовать безопасное подключение к 1С через веб, клиенты и терминальный сервер с учетом того, что они скоро окажутся в облаке.
Наконец мы настроили систему резервного копирования с учетом требуемых параметров RTO (время восстановления) и RPO (точка восстановления). Как известно, администраторы делятся на два типа: те, кто не бэкапят, и те, кто уже хорошенько обжегся, и поэтому бэкапят. Так что мы уделили особое внимание резервному копированию базы данных. Использовали собственный сервис, работающий на уровне платформы и гипервизора.
Тестовая миграция
Процесс миграции всегда связан с серьезными рисками. Среди них потеря данных, увеличение времени простоя сверх расчетного, проблемы с запуском виртуальной машины в облаке и сбои вплоть до критических ошибок. От потери данных мы застраховались, но смягчить другие риски можно, только проверив работу системы на практике.
Для оперативной связи мы создали группу в мессенджере, где собрали технических специалистов с обеих сторон и провели тестовую миграцию. Процесс прошел даже лучше, чем мы рассчитывали. Все выдохнули, как выяснилось потом, преждевременно.
Перенос 1С
Чтобы уложиться в минимальное время, мы использовали подход, проверенный на других проектах: постепенно, без спешки скопировали основной объем исторических данных, а затем, сразу после отключения серверов заказчика, перенесли дельту — изменения с момента первой репликации. Для этого использовали Хайстекс Акура. В К2 Облаке уже установлена серверная часть этого решения, так что нужно было только развернуть агенты у заказчика и запустить репликацию.
Затем, в согласованный выходной день мы запустили саму миграцию. Если бы мы переносили все данные сразу, из-за низкой скорости канала между офисом и облаком переезд занял бы несколько дней, однако на перенос дельты хватило четырех часов. На всю миграцию, начиная с заключения договора до полного переноса всех функций 1С в облако ушло 18 дней. Таким образом, переезд практически не повлиял на рабочие процессы. За одним «но». Здесь начались настоящие сложности, к сожалению, порой избежать их невозможно.
Непредсказуемые сложности с переносом 1С
Несмотря на успешную тестовую миграцию, система 1С заказчика сперва начала сбоить.
Первой причиной стала сетевая инфраструктура заказчика. В точности повторить ее топологию в рамках теста невозможно. Сетевые инженеры, которые изначально создавали сеть и настраивали связи между площадками, уже не работали в компании. Их преемники не знали всех тонкостей системы.
Мы совместно изучали сеть, но все равно были упущены несколько важных деталей. Эти особенности «выстрелили» уже после переноса — возникли проблемы с маршрутизацией до нескольких удаленных объектов. Стали звонить вахтовики, у которых внезапно пропал доступ к 1С. Мы решали эти проблемы, заново прокидывая маршруты в индивидуальном порядке.
Вторая проблема заключалась в том, что миграция 1-в-1 была невозможна. У заказчика попросту было слишком старое оборудование. И хотя в теории мы подобрали оптимальные сайзинги, на практике конфигурации пришлось дополнительно настраивать для увеличения производительности дисков. Вдобавок в процессе выяснилось, что у заказчика была неверная конфигурация SQL-сервера. Это тоже пришлось быстро фиксить.
В итоге на окончательную настройку и оптимизацию 1С ушла еще пара дней.
В чём профит для заказчика?
Стоили ли итоговые 20 дней работы и вложенные средства полученного результата? Ответ на этот вопрос всегда индивидуален. В этом кейсе заказчик получил от переезда в К2 Cloud четыре существенных преимущества:
Значительное ускорение работы 1С. Благодаря современному железу система стала работать быстрее и отзывчивее. Пользователи перестали жаловаться на лаги, работать стало приятнее.
Уверенность в высокой доступности инфраструктуры и быстром решении проблем со стороны провайдера. Здесь работает наш стандартный облачный SLA с доступностью 99,95%, который является одним из самых жестких на рынке. Передача ответственности за систему специалистам Облака значительно снижает нагрузку на персонал заказчика.
Масштабируемую облачную платформу, способную поддержать любое запланированное расширение инфраструктуры 1С. Заказчик получил доступ к нашей облачной консоли и всей платформе. Теперь компания может легко увеличивать ресурсы виртуальной машины или разворачивать новые виртуальные серверы по мере необходимости. Бонусом идут: развертывание баз данных, настройка кэширования, управление брокерами сообщений и многое другое. Например, если возникнет потребность быстро создать кластер баз данных в тестовом контуре, это можно сделать всего за несколько кликов.
Техническую поддержку. Мы обучили админов заказчика работе с облачной инфраструктурой, предоставили подробную техническую документацию по каждому сервису в консоли Облака. Хотя количество обращений сократилось, заказчик по-прежнему может в любой момент с нами проконсультироваться. Три линии специалистов и рабочая группа, созданная на этапе миграции, продолжают работать.
Заключительные рекомендации
Если вы планируете перенести 1С в облако, начните с тестовой миграции. Многие провайдеры, включая нас, предлагают бесплатный пробный доступ. Это поможет развеять сомнения и выявить возможные проблемы. Однако помните: не все сложности можно предусмотреть заранее.
Тестовая миграция позволит оценить работу 1С в облачной среде, оценить затраты на поддержку системы и понять, оправдан ли переход. В некоторых случаях, например, если компания недавно обновила свои сервера или не планирует расширение бизнеса, перенос может оказаться нецелесообразным.
Тем не менее, для многих компаний с сильным IT-отделом облачное решение с круглосуточной поддержкой часто оказывается выгодным. Среди наших клиентов — госорганизации, крупные корпорации и системообразующие банки.
Обратите внимание: подход «вот вам ресурсы, делайте, что хотите» устарел. Он вынуждает заказчика выделять под работу с облачными сервисами большой штат IT-специалистов, что не всегда оправдано. Выбирайте провайдера, которому можно доверить и перенос, и поддержку системы. Ищите партнера, способного обеспечить уверенность в том, что при любых проблемах вы получите компетентную помощь.
Комментарии (24)
ramil_trinion
25.09.2024 13:31Ваша статья больше похожа на пресс релиз.
Никакой конкретики, и пользы 0. Вы рекламируете свои услуги, не поленитесь и напишите нормальный текст, интересный и полезный. Корпоративной подписки недостаточно чтобы получить клиентов с хабра.
jackchickadee
25.09.2024 13:31окей, давайте совместно поинтересуемся.
Мы совместно изучали сеть, но все равно были упущены несколько важных деталей.
это каких например ? маршрут туда - туннель или VPN сюда, доступ либо есть либо нет. если сложнее: каналы перегружены трафиком, каналы плохого качества, потери пакетов. еще сложнее - адская смесь из L2 и L3, запутанная топология, дублирующие каналы + динамический роутинг. как писала тут одна дизайнер, усложнять всегда легче чем упрощать.
у заказчика была неверная конфигурация SQL-сервера.
тоже интересно. что там можно натворить такого неверного ?
AnZakharova Автор
25.09.2024 13:31+1В разное время сеть администрировалась различными специалистами, как правило, подрядчиками. В результате получилась довольно запутанная конфигурация из ipsec-ов, таблиц и политик маршрутизации. Где-то маршруты шли сразу на центральный роутер, где-то транзитом через другие роутеры. На этапе тестирования это не вскрылось, так как тесты проводились только из главного офиса и с одной из площадок, где все было хорошо.
Что касается сервера SQL, то тут целое поле для деятельности в плане неверных настроек. Самая простая и распространенная ошибка – при форматировании диска выбирается дефолтный размер блока в 4KB, когда для SQL рекомендуется блок 64KB, что реально ускоряет его работу
jackchickadee
25.09.2024 13:31спасибо за ответ.
На этапе тестирования это не вскрылось, так как тесты проводились только из главного офиса и с одной из площадок
а полное вскрытие существующей топологии сети заказчик не оплатил и/или ему не предлагали ?
Что касается сервера SQL, то тут целое поле для деятельности в плане неверных настроек.
да ладно. MS SQL server прощает много ошибок настройки в т.ч. описанную вами,
отвечая на это снижением производительности в 5-10%. кластер NTFS в 4KB ерунда.
выравнивание раздела - более важно, делается примерно так:Here is an example in which the D: drive is created on disk 0, aligned with an offset of 1,024 KB, and formatted with a file allocation unit (cluster) size of 64 KB.
C:>diskpart
Microsoft DiskPart version 6.0.6001
Copyright (C) 1999-2007 Microsoft Corporation.
On computer: ASPIRINGGEEKDISKPART> list disk
Disk ### Status Size Free Dyn GPTDisk 0 Online 186 GB 0 B
DISKPART> select disk 0
Disk 0 is now the selected disk.
DISKPART> create partition primary align=1024
DiskPart succeeded in creating the specified partition.
DISKPART> assign letter=d
DiskPart successfully assigned the drive letter or mount point.
DISKPART> format fs=ntfs unit=64K nowaitостальные рекмоендации здесь:
https://learn.microsoft.com/en-us/mem/configmgr/core/understand/site-size-performance-faq
ildarz
25.09.2024 13:31+1У заказчика попросту было слишком старое оборудование. И хотя в теории мы подобрали оптимальные сайзинги, на практике конфигурации пришлось дополнительно настраивать для увеличения производительности дисков.
Непонятно. У заказчика был древний медленно работающий хлам, его перевели на современное оборудование, которому пришлось ДОПОЛНИТЕЛЬНО по сравнению с этим старым хламом докидывать мощности? Это как же так насайзили?
наш стандартный облачный SLA с доступностью 99,95%, который является одним из самых жестких на рынке.
При компенсации в виде "уменьшения стоимости услуг на время простоя" SLA обещать можно примерно любой. :)
AnZakharova Автор
25.09.2024 13:31Непонятно. У заказчика был древний медленно работающий хлам, его перевели на современное оборудование, которому пришлось ДОПОЛНИТЕЛЬНО по сравнению с этим старым хламом докидывать мощности? Это как же так насайзили?
Не насайзили. Большинство проектов специфичны и не всегда включают в себя простую миграцию с одной инфраструктуры на другую. Расчет любого сайзинга производится на основе некоторых средних параметров для сеансов пользователей для конкретной конфигурации 1С. В конкретном случае эти показатели могут отличаться от средних в любую сторону. Поэтому после миграции может потребоваться корректировка сайзинга. Миграция ядро-в-ядро обычно экономически не целесообразна, так как влечет излишние затраты. Поэтому сайзинг считается по сути с нуля. Плюс в этом случае у заказчика уже были проблемы с производительностью, то есть система уже тормозила, поэтому мощности и настройки корректировались до момента, пока не стало тормозить
При компенсации в виде "уменьшения стоимости услуг на время простоя" SLA обещать можно примерно любой. :)
Заказчикам важна гарантированная доступность услуги, а не последующая компенсация, поскольку она не решит проблемы потерянного времени и денег в случае простоя сервисов компании. Поэтому мы сосредотачиваемся именно на поддержании необходимого SLA
ildarz
25.09.2024 13:31Просто у меня есть чуть-чуть опыта в сайзинге оборудования, в т.ч. под 1С, поэтому в данном случае мне была бы интересна конкретика - как работало у клиента, что предложили ваши специалисты и к чему пришли в итоге.
Zeqular
25.09.2024 13:31Пока коллеги анализировали конфигурации,
Сгорел исходный сервак и мы потеряли все данные.
Это у меня мозг на автомате дописал)
mixsture
25.09.2024 13:31А где цифры денег то? Сколько стоила миграция? Каков ежемесячный платеж относительно цены "старого сервера"? Через сколько месяцев платежей "старый сервер" стал бы экономически выгоднее новых условий? А сколько денег планировалось на новый сервер?
vis_inet
25.09.2024 13:31Да, очень интересно узнать экономику этого мероприятия.
Зачастую аренда становится дороже своего через не сильно продолжительное время.
AnZakharova Автор
25.09.2024 13:31В рамках данного проекта мы связаны политикой конфиденциальности, поэтому, к сожалению, не можем раскрывать точные цифры. Но возьмем как идею для будущей статьи.
soltyy00
25.09.2024 13:31Сейчас в “моде” обратные кейсы -1С из облака к себе
AnZakharova Автор
25.09.2024 13:31Мы наблюдаем другой тренд. Можете поделиться примерами, чтобы обсудить поподробнее?
BillGilbertN
25.09.2024 13:31Извините, но статья для Хабра откровенно слабая. Это же технический сайт, верно? Ну так потрудитесь описать хоть какие-то подробности проблем, с которыми вы (по вашей же собственной недоработке) столкнулись.
AnZakharova Автор
25.09.2024 13:31Кажется, что статья как раз состоит из технических моментов, которыми мы хотели поделиться. Возможно, у вас остались какие-либо вопросы, на которые не удалось получить ответ исходя статьи, напишите в комментариях, вернемся с ответом
Unbearability
25.09.2024 13:31+1Интересно, какой там размер самой тяжелой базы, что нельзя было спокойно перетащить полный дамп БД, а потом в технологическое окно накатить дифференциальную копию?
>снижает нагрузку на сервер приложений 1С, который часто бывает перегружен
Чаще чем сервер СУБД? Перегружен в каком плане, какие ресурсы?
>в процессе выяснилось, что у заказчика была неверная конфигурация SQL-сервера
>на практике конфигурации пришлось дополнительно настраивать для увеличения производительности дисков.
Почему это выяснилось уже в процессе миграции, а не до? Что за интересный такой кейс? Можно подробнее рассказать?
Как переносили лицензии? При тестовой миграции по сути нужен двойной набор лицензий, как решали этот вопрос?AnZakharova Автор
25.09.2024 13:31Интересно, какой там размер самой тяжелой базы, что нельзя было спокойно перетащить полный дамп БД, а потом в технологическое окно накатить дифференциальную копию?
Для каждого проекта миграции мы выбираем оптимальные решения с точки зрения трудозатрат, времени миграции, времени простоя и технологических возможностей. При передаче данных большую роль играет не только объем передаваемых данных, но и ширина канала. Очень часто исходящий интернет имеет довольно маленькую пропускную способность. В данном проекте идеально подошел автоматизированный процесс с использованием Хайстекс. И на текущий момент этот метод лидирует в наших проектах за счет своей простоты.
Чаще чем сервер СУБД? Перегружен в каком плане, какие ресурсы?
Нагрузка на процессор сервера приложений является частым явлением. Процессор сервера СУБД испытывает меньшие нагрузки.
Почему это выяснилось уже в процессе миграции, а не до? Что за интересный такой кейс? Можно подробнее рассказать?
Как переносили лицензии? При тестовой миграции по сути нужен двойной набор лицензий, как решали этот вопрос?
За счет дефицита времени не всегда получается провести полноценный аудит, а в рамках экспресс-аудита невозможно охватить абсолютно все аспекты. В данном случае сервер баз данных мигрировался как есть, что не ухудшило его показателей после миграции. После миграции мы проводили анализ нагрузки на все подсистемы, чтобы убедиться, что не осталось узких мест, даже если отсутствуют жалобы от пользователей. Миграция позволила расшить узкое место в процессорных ресурсах, что автоматически перекинуло нагрузку на диски. В исходной инфраструктуре как раз не хватало процессорных мощностей, поэтому диски чувствовали себя хорошо.
Лицензии переносились с помощью резервных пин-кодов после миграции сервера лицензирования в облако. Это одна из ручных операций, которая всегда должна учитываться в плане миграции.
Roland21
25.09.2024 13:31Если один старенький сервер (это примерно какой?) тянул 5 баз, то тут или базы на самом деле не особо большие либо количество пользователей/операций не особо много.
Насколько было вообще экономически целесообразно отдавать все (!) в облако большой вопрос...jackchickadee
25.09.2024 13:31Насколько было вообще экономически целесообразно отдавать все (!) в облако большой вопрос...
люди надеются что станет лучше. за надежду готовы платить. посмотрим что они будут говорить через 1-2 года хехе. заодно навели порядок в сети - уже польза.
saag
Удивительно, ведь шаблон мышления руководителя таков, что ему надо все иметь под рукой - сотрудников, конфиденциальную информацию, 1С.
jackchickadee
шаблон мышления таков, что если контора намерена проработать 3 и более лет, то свое железо выгоднее любых "облаков".
mgis
Я тоже так долго думал. На деле оказалось, что крупному бизнесу важнее доступность, масштабируемость и техподдержка.
Местячковые бизнесы в расчет не берем.
AnZakharova Автор
Доступность, масштабируемость и техподдержка – это в точку. По отзывам наших клиентов, обеспечить это силами собственного штата и имеющимися бизнес-процессами, часто бывает сложно. Поэтому выгоднее отдавать эти задачи на аутсорс, чтобы сконцентрироваться на задачах бизнеса.
Ну и кроме того, в каждом конкретном случае архитектура размещения систем просчитывается с учетом различных требований и рисков. Если считать совокупную стоимость владения тем или иным ресурсом, то там очень много параметров, которые следует учитывать: от простой покупки железа до процессов защиты данных, мониторинга, резервного копирования, администрирования, надежности, технической поддержки железа и так далее и так далее.