Комментарии 26
Удивительно, ведь шаблон мышления руководителя таков, что ему надо все иметь под рукой - сотрудников, конфиденциальную информацию, 1С.
шаблон мышления таков, что если контора намерена проработать 3 и более лет, то свое железо выгоднее любых "облаков".
Я тоже так долго думал. На деле оказалось, что крупному бизнесу важнее доступность, масштабируемость и техподдержка.
Местячковые бизнесы в расчет не берем.
Доступность, масштабируемость и техподдержка – это в точку. По отзывам наших клиентов, обеспечить это силами собственного штата и имеющимися бизнес-процессами, часто бывает сложно. Поэтому выгоднее отдавать эти задачи на аутсорс, чтобы сконцентрироваться на задачах бизнеса.
Ну и кроме того, в каждом конкретном случае архитектура размещения систем просчитывается с учетом различных требований и рисков. Если считать совокупную стоимость владения тем или иным ресурсом, то там очень много параметров, которые следует учитывать: от простой покупки железа до процессов защиты данных, мониторинга, резервного копирования, администрирования, надежности, технической поддержки железа и так далее и так далее.
Ваша статья больше похожа на пресс релиз.
Никакой конкретики, и пользы 0. Вы рекламируете свои услуги, не поленитесь и напишите нормальный текст, интересный и полезный. Корпоративной подписки недостаточно чтобы получить клиентов с хабра.
окей, давайте совместно поинтересуемся.
Мы совместно изучали сеть, но все равно были упущены несколько важных деталей.
это каких например ? маршрут туда - туннель или VPN сюда, доступ либо есть либо нет. если сложнее: каналы перегружены трафиком, каналы плохого качества, потери пакетов. еще сложнее - адская смесь из L2 и L3, запутанная топология, дублирующие каналы + динамический роутинг. как писала тут одна дизайнер, усложнять всегда легче чем упрощать.
у заказчика была неверная конфигурация SQL-сервера.
тоже интересно. что там можно натворить такого неверного ?
В разное время сеть администрировалась различными специалистами, как правило, подрядчиками. В результате получилась довольно запутанная конфигурация из ipsec-ов, таблиц и политик маршрутизации. Где-то маршруты шли сразу на центральный роутер, где-то транзитом через другие роутеры. На этапе тестирования это не вскрылось, так как тесты проводились только из главного офиса и с одной из площадок, где все было хорошо.
Что касается сервера SQL, то тут целое поле для деятельности в плане неверных настроек. Самая простая и распространенная ошибка – при форматировании диска выбирается дефолтный размер блока в 4KB, когда для SQL рекомендуется блок 64KB, что реально ускоряет его работу
спасибо за ответ.
На этапе тестирования это не вскрылось, так как тесты проводились только из главного офиса и с одной из площадок
а полное вскрытие существующей топологии сети заказчик не оплатил и/или ему не предлагали ?
Что касается сервера 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: ASPIRINGGEEK
DISKPART> list disk
Disk ### Status Size Free Dyn GPT
Disk 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
Если уж картинки на английском, пишите правильно: "1Ass"
У заказчика попросту было слишком старое оборудование. И хотя в теории мы подобрали оптимальные сайзинги, на практике конфигурации пришлось дополнительно настраивать для увеличения производительности дисков.
Непонятно. У заказчика был древний медленно работающий хлам, его перевели на современное оборудование, которому пришлось ДОПОЛНИТЕЛЬНО по сравнению с этим старым хламом докидывать мощности? Это как же так насайзили?
наш стандартный облачный SLA с доступностью 99,95%, который является одним из самых жестких на рынке.
При компенсации в виде "уменьшения стоимости услуг на время простоя" SLA обещать можно примерно любой. :)
Непонятно. У заказчика был древний медленно работающий хлам, его перевели на современное оборудование, которому пришлось ДОПОЛНИТЕЛЬНО по сравнению с этим старым хламом докидывать мощности? Это как же так насайзили?
Не насайзили. Большинство проектов специфичны и не всегда включают в себя простую миграцию с одной инфраструктуры на другую. Расчет любого сайзинга производится на основе некоторых средних параметров для сеансов пользователей для конкретной конфигурации 1С. В конкретном случае эти показатели могут отличаться от средних в любую сторону. Поэтому после миграции может потребоваться корректировка сайзинга. Миграция ядро-в-ядро обычно экономически не целесообразна, так как влечет излишние затраты. Поэтому сайзинг считается по сути с нуля. Плюс в этом случае у заказчика уже были проблемы с производительностью, то есть система уже тормозила, поэтому мощности и настройки корректировались до момента, пока не стало тормозить
При компенсации в виде "уменьшения стоимости услуг на время простоя" SLA обещать можно примерно любой. :)
Заказчикам важна гарантированная доступность услуги, а не последующая компенсация, поскольку она не решит проблемы потерянного времени и денег в случае простоя сервисов компании. Поэтому мы сосредотачиваемся именно на поддержании необходимого SLA
Пока коллеги анализировали конфигурации,
Сгорел исходный сервак и мы потеряли все данные.
Это у меня мозг на автомате дописал)
А где цифры денег то? Сколько стоила миграция? Каков ежемесячный платеж относительно цены "старого сервера"? Через сколько месяцев платежей "старый сервер" стал бы экономически выгоднее новых условий? А сколько денег планировалось на новый сервер?
Сейчас в “моде” обратные кейсы -1С из облака к себе
Извините, но статья для Хабра откровенно слабая. Это же технический сайт, верно? Ну так потрудитесь описать хоть какие-то подробности проблем, с которыми вы (по вашей же собственной недоработке) столкнулись.
Интересно, какой там размер самой тяжелой базы, что нельзя было спокойно перетащить полный дамп БД, а потом в технологическое окно накатить дифференциальную копию?
>снижает нагрузку на сервер приложений 1С, который часто бывает перегружен
Чаще чем сервер СУБД? Перегружен в каком плане, какие ресурсы?
>в процессе выяснилось, что у заказчика была неверная конфигурация SQL-сервера
>на практике конфигурации пришлось дополнительно настраивать для увеличения производительности дисков.
Почему это выяснилось уже в процессе миграции, а не до? Что за интересный такой кейс? Можно подробнее рассказать?
Как переносили лицензии? При тестовой миграции по сути нужен двойной набор лицензий, как решали этот вопрос?
Интересно, какой там размер самой тяжелой базы, что нельзя было спокойно перетащить полный дамп БД, а потом в технологическое окно накатить дифференциальную копию?
Для каждого проекта миграции мы выбираем оптимальные решения с точки зрения трудозатрат, времени миграции, времени простоя и технологических возможностей. При передаче данных большую роль играет не только объем передаваемых данных, но и ширина канала. Очень часто исходящий интернет имеет довольно маленькую пропускную способность. В данном проекте идеально подошел автоматизированный процесс с использованием Хайстекс. И на текущий момент этот метод лидирует в наших проектах за счет своей простоты.
Чаще чем сервер СУБД? Перегружен в каком плане, какие ресурсы?
Нагрузка на процессор сервера приложений является частым явлением. Процессор сервера СУБД испытывает меньшие нагрузки.
Почему это выяснилось уже в процессе миграции, а не до? Что за интересный такой кейс? Можно подробнее рассказать?
Как переносили лицензии? При тестовой миграции по сути нужен двойной набор лицензий, как решали этот вопрос?
За счет дефицита времени не всегда получается провести полноценный аудит, а в рамках экспресс-аудита невозможно охватить абсолютно все аспекты. В данном случае сервер баз данных мигрировался как есть, что не ухудшило его показателей после миграции. После миграции мы проводили анализ нагрузки на все подсистемы, чтобы убедиться, что не осталось узких мест, даже если отсутствуют жалобы от пользователей. Миграция позволила расшить узкое место в процессорных ресурсах, что автоматически перекинуло нагрузку на диски. В исходной инфраструктуре как раз не хватало процессорных мощностей, поэтому диски чувствовали себя хорошо.
Лицензии переносились с помощью резервных пин-кодов после миграции сервера лицензирования в облако. Это одна из ручных операций, которая всегда должна учитываться в плане миграции.
Если один старенький сервер (это примерно какой?) тянул 5 баз, то тут или базы на самом деле не особо большие либо количество пользователей/операций не особо много.
Насколько было вообще экономически целесообразно отдавать все (!) в облако большой вопрос...
сообщите, пожалуйста, размеры базы mssql, их количество, физическую конфигурацию серверов, кол-во пользователей, использовался ли always on?
1С летит на юг — наш опыт миграции в K2 Облако