Комментарии 14
>Всех наших битрикс-клиентов мы выносим в отдельные сервера, где есть только битрикс-клиенты.
Какая разница, кто где есть? :)
>Первоначально была идея на наших серверах перейти с SAS-дисков на SSD, но, просчитав стоимость такого перехода, мы поняли, что гораздо выгоднее нужные мощности арендовать.
Блеать, вы же жили в арендованном сервере…
>Главной задачей было – убрать эти очереди к БД, и на тех мощностях которые мы сейчас арендуем у провайдера SIM-Networks – удалось решить эту наболевшую для нашего бизнеса задачу.
+ рисунок внизу.
Искали облако, но поперлись к тому самому хостеру, а еще смотрели других хостеров.
Не проще было сразу на SSD перейти?
Попахивает рекламой хостера. :)
>Вот это падение на отечественном хостинге «всего лишь на 3 минуты» выстраивало большую очередь к нашей БД, подвисали все пользователи и система 1С могла за эти 3 минуты выбить блокировку
У вас просто гнилая архитектура.
С ростом эта проблема опять вернется :)
>было заметно, что хостер не рассчитывал на то, что все клиенты единовременно будут на все 100% использовать арендуемые ими мощности.
Можно подумать, там одни юрики хостят свои бизнес-процессы. :)
Какие именно мощности вы арендовали?
>Комментарий от SIM-Networks
Такие задержки, чаще всего происходят, когда на сервер рассчитанный, скажем на 5 клиентов провайдер размещает 10 клиентов, в (наивной) надежде, что они никогда не будут использовать все свои (уже купленные ими!) мощности. Мы считаем, что если клиент купил место, купил запас мощности – то пустует оно или нет – это уже клиента, и он может делать с ресурсами все что захочет.
Скорее всего перепроданный сервер будет дешевле.
Но не факт.
>И только после года таких мучений, компания хостер согласилась купить специально под нас SSD-полку в свой дата-центр.
Но вы же на ссд переехали только у своего любимого иностранного хостера…
>Провайдер обещал осуществить миграцию всего за сутки. В воскресенье в обед реструктуризация новой полки еще не была закончена и мы начали просить все вернуть как было, на что получили ответ, что на старой арендуемой нами мощности наших данных уже нет (- а мы перенесли, смотрим система поднялась и поэтому старую БД удалили – сказал хостер), хостер решил удалить эти данные, так как считал, что миграция уже произошла и их хранить уже не обязательно ( — Они сошли с ума!? – подумали мы).
Хм, пару раз проводились миграции.
Никогда никакого подтверждения хостеру, что все ок не давал, а он никогда не говорил, что вдруг что, есть старая.
Нужно было самим мигрировать.
>В воскресенье в обед реструктуризация новой полки еще не была закончена
Что это такое?
>Перефразируя эту мысль можно сказать: если вы развиваетесь – считаем что нужно идти в облака.
Хватить толкать маркетинговый бред.
>Мы снова хотим расширяться, так как нам уже не хватает мощности, и серьезно рассматриваем вариант с облаком.
Вы же уже в облаке, нет?
П.С.
Дочитал до конца, это хостер сам себя хвалил :)
Какая разница, кто где есть? :)
>Первоначально была идея на наших серверах перейти с SAS-дисков на SSD, но, просчитав стоимость такого перехода, мы поняли, что гораздо выгоднее нужные мощности арендовать.
Блеать, вы же жили в арендованном сервере…
>Главной задачей было – убрать эти очереди к БД, и на тех мощностях которые мы сейчас арендуем у провайдера SIM-Networks – удалось решить эту наболевшую для нашего бизнеса задачу.
+ рисунок внизу.
Искали облако, но поперлись к тому самому хостеру, а еще смотрели других хостеров.
Не проще было сразу на SSD перейти?
Попахивает рекламой хостера. :)
>Вот это падение на отечественном хостинге «всего лишь на 3 минуты» выстраивало большую очередь к нашей БД, подвисали все пользователи и система 1С могла за эти 3 минуты выбить блокировку
У вас просто гнилая архитектура.
С ростом эта проблема опять вернется :)
>было заметно, что хостер не рассчитывал на то, что все клиенты единовременно будут на все 100% использовать арендуемые ими мощности.
Можно подумать, там одни юрики хостят свои бизнес-процессы. :)
Какие именно мощности вы арендовали?
>Комментарий от SIM-Networks
Такие задержки, чаще всего происходят, когда на сервер рассчитанный, скажем на 5 клиентов провайдер размещает 10 клиентов, в (наивной) надежде, что они никогда не будут использовать все свои (уже купленные ими!) мощности. Мы считаем, что если клиент купил место, купил запас мощности – то пустует оно или нет – это уже клиента, и он может делать с ресурсами все что захочет.
Скорее всего перепроданный сервер будет дешевле.
Но не факт.
>И только после года таких мучений, компания хостер согласилась купить специально под нас SSD-полку в свой дата-центр.
Но вы же на ссд переехали только у своего любимого иностранного хостера…
>Провайдер обещал осуществить миграцию всего за сутки. В воскресенье в обед реструктуризация новой полки еще не была закончена и мы начали просить все вернуть как было, на что получили ответ, что на старой арендуемой нами мощности наших данных уже нет (- а мы перенесли, смотрим система поднялась и поэтому старую БД удалили – сказал хостер), хостер решил удалить эти данные, так как считал, что миграция уже произошла и их хранить уже не обязательно ( — Они сошли с ума!? – подумали мы).
Хм, пару раз проводились миграции.
Никогда никакого подтверждения хостеру, что все ок не давал, а он никогда не говорил, что вдруг что, есть старая.
Нужно было самим мигрировать.
>В воскресенье в обед реструктуризация новой полки еще не была закончена
Что это такое?
>Перефразируя эту мысль можно сказать: если вы развиваетесь – считаем что нужно идти в облака.
Хватить толкать маркетинговый бред.
>Мы снова хотим расширяться, так как нам уже не хватает мощности, и серьезно рассматриваем вариант с облаком.
Вы же уже в облаке, нет?
П.С.
Дочитал до конца, это хостер сам себя хвалил :)
Можете кратко написать, что вы вкладываете в слово «облако».
И чем оно отличается от вдс/выделенного сервера.
И чем оно отличается от вдс/выделенного сервера.
>Всех наших битрикс-клиентов мы выносим в отдельные сервера, где есть только битрикс-клиенты.
Какая разница, кто где есть? :)
Мы выносим всех битрикс-клиентов в отдельные сервера, которые специально сконфигурированы и оптимизированы именно под битрикс.
Дочитал до конца, это хостер сам себя хвалил :)Это говорит клиент, а не хостер.
Не проще было сразу на SSD перейти?— ответ в статье, клиент просчитывал стоимость перехода, и понял что это не выгодно:
Мы просчитывали, что если все нужное нам оборудование мы купим сами, то выйдем в 0 покрытия капитальных затрат только через 3,5 года – и это не окончательные просчеты, так как наша компания постоянно развивается, и сумма затрат на увеличение мощности нашей ИТ-инфраструктуры могла бы увеличиваться в геометрической прогрессии.
Очевидно, большинство ваших комментариев вызвано тем, что возможно в статье не так четко обозначено то, что у клиента не вся инфраструктура целиком и сразу была на арендуемых мощностях (что-то арендовалось на физических и/или виртуальных мощностях, что-то оставалось на собственных серверах), миграция на арендуемые мощности и облака осуществлялась постепенно: от сайта к базе данных и основным бизнес-процессам. И работа с хостинг-провайдерами проводилась поэтапно: вначале сайт, потом 1С; вначале один хостер, потом другой, потом протестировали у себя то же (это к вопросу о «гнилой инфраструктуре»), потом уже третий хостер.
>Главной задачей было – убрать эти очереди к БД, и на тех мощностях которые мы сейчас арендуем у провайдера SIM-Networks – удалось решить эту наболевшую для нашего бизнеса задачу.
+ рисунок внизу.
Искали облако, но поперлись к тому самому хостеру, а еще смотрели других хостеров.
Не проще было сразу на SSD перейти?
Попахивает рекламой хостера. :)
Про SSD — ответ выше, БД была размещена не у того же самого хостера, а у другого. Это говорит сам клиент, а не мы себя хвалим.
У вас просто гнилая архитектура.
С ростом эта проблема опять вернется :)
С ростом у клиента проблема не возвращается, и мы сделаем все, чтобы не вернулась:) 5 лет роста это подтверждают.
Можно подумать, там одни юрики хостят свои бизнес-процессы. :) Какие именно мощности вы арендовали?
Об этом клиент не хочет рассказывать, так как тогда придется озвучить названия тех компаний, опыт с которыми был не очень удачным — пусть это останется тайной.
>И только после года таких мучений, компания хостер согласилась купить специально под нас SSD-полку в свой дата-центр.
Но вы же на ссд переехали только у своего любимого иностранного хостера…
Это было до нас. Речь идет о предыдущем хостере.
>Провайдер обещал осуществить миграцию всего за сутки. В воскресенье в обед реструктуризация новой полки еще не была закончена и мы начали просить все вернуть как было, на что получили ответ, что на старой арендуемой нами мощности наших данных уже нет (- а мы перенесли, смотрим система поднялась и поэтому старую БД удалили – сказал хостер), хостер решил удалить эти данные, так как считал, что миграция уже произошла и их хранить уже не обязательно ( — Они сошли с ума!? – подумали мы).
Хм, пару раз проводились миграции.
Никогда никакого подтверждения хостеру, что все ок не давал, а он никогда не говорил, что вдруг что, есть старая.
Нужно было самим мигрировать.
Тут можно поспорить, но тут становится актуальным вопрос клиентоориентированности, может быть кто-то так работает, но мы считаем это неправильно — когда клиента оставляют один на один с его проблемами. Тем более вы не учли тот момент, что из-за такого подхода хостера (твоя база переехала, а то, что не работает — твои проблемы, мы твою старую базу «убьем» тут же — чего она у нас место занимает!?), у клиента могла остановится работа всей компании на целую неделю — как вы думаете для сети ритейла это ок? Может быть кто-то так работает, но мы так не работаем. Хостеру лучше было удостоверится, что БД у клиента работает и все ок, и только тогда убивать старую.
Вы же уже в облаке, нет?
Пока не полностью, но уже клиент к этому готов, все зависит от поставщика услуг.
Хватить толкать маркетинговый бред.
Речь идет о фактах — никакой воды и инкогнито «одна ритейл-сеть» или что-то такое, что проверить нельзя, указан: клиент, название, кто-что-где, указанны цифры и проблемы, и как их решил клиент с нашей помощью), это — слова клиента, а наши слова о самих себе.
В виду обширности комментария, потерялись важные знаки в последнем абзаце.
Это — слова клиента, а не наши слова о самих себе.
Это — слова клиента, а не наши слова о самих себе.
>Мы выносим всех битрикс-клиентов в отдельные сервера, которые специально сконфигурированы и оптимизированы именно под битрикс.
Чем же они отличаются от других высокопрожорливых? :)
>ответ в статье, клиент просчитывал стоимость перехода, и понял что это не выгодно
Перейти с арендованного SAS на арендованный SSD.
>Очевидно, большинство ваших комментариев вызвано тем, что возможно в статье не так четко обозначено то, что у клиента не вся инфраструктура целиком и сразу была на арендуемых мощностях
Возможно.
>С ростом у клиента проблема не возвращается, и мы сделаем все, чтобы не вернулась:) 5 лет роста это подтверждают.
Это было 5 лет назад? Ок.
Если архитектура гнилая, то, когда она упрется в один сервер, ее трудно будет масштабировать.
>Тут можно поспорить, но тут становится актуальным вопрос клиентоориентированности,
Я не понимаю, как оно мигрировало, что недомигрировало.
Если недомигрировало, то хостеру нужно начитстить место, который он ест.
Если же оно домигрировало, то мои предыдущие опыты говорят, что хостером все удалялось нафиг (может они сохраняли инфу какое-то время у себя, хз).
>Речь идет о фактах
Я о самом утверждении «облака решат все ваши проблемы».
Также вы не ответили об отличиях облаков от классических технологий.
Чем же они отличаются от других высокопрожорливых? :)
>ответ в статье, клиент просчитывал стоимость перехода, и понял что это не выгодно
Перейти с арендованного SAS на арендованный SSD.
>Очевидно, большинство ваших комментариев вызвано тем, что возможно в статье не так четко обозначено то, что у клиента не вся инфраструктура целиком и сразу была на арендуемых мощностях
Возможно.
>С ростом у клиента проблема не возвращается, и мы сделаем все, чтобы не вернулась:) 5 лет роста это подтверждают.
Это было 5 лет назад? Ок.
Если архитектура гнилая, то, когда она упрется в один сервер, ее трудно будет масштабировать.
>Тут можно поспорить, но тут становится актуальным вопрос клиентоориентированности,
Я не понимаю, как оно мигрировало, что недомигрировало.
Если недомигрировало, то хостеру нужно начитстить место, который он ест.
Если же оно домигрировало, то мои предыдущие опыты говорят, что хостером все удалялось нафиг (может они сохраняли инфу какое-то время у себя, хз).
>Речь идет о фактах
Я о самом утверждении «облака решат все ваши проблемы».
Также вы не ответили об отличиях облаков от классических технологий.
Я о самом утверждении «облака решат все ваши проблемы».
— никто этого не утверждал
Это было 5 лет назад? Ок.
— 5 лет назад клиент начал с нами работать, в статье суммированный опыт.
Перейти с арендованного SAS на арендованный SSD.
— точнее — перейти со своего SAS на свой SSD — не выгодно — посчитал клиент, — поэтому решил перейти на арендованный SSD у другого хостера, а после неудачного опыта, перешел к нам.
Чем же они отличаются от других высокопрожорливых? :)
— если бы не отличались, не морочились бы.
Я не понимаю, как оно мигрировало, что недомигрировало.
— хостер (не мы) перенес базу, но она не заработала, а он уже убил «старую» БД клиента.
Еще раз хочу акцентировать ваше внимание, в статье — суммированный опыт за несколько лет работы с клиентом, знакомства и перехода с различными хостинг-услугами и хостерами, и различными видами гибридной ит-структуры клиента: например что-то осталось у клиента, что-то было у других хостеров, что-то было у нас — но потом уже многое что из ит-инфраструктуры клиента переехало к нам.
Что-то с цифрами мне не очень понятно.
Какие-то смешные цифры: полторы тысячи документов в сутки, 50 килобайт текста в документе, 100(сто!) накладных за 16 минут… Это 1С что ли такой тормозной?
ИМХО что-то где-то не так…
Какие-то смешные цифры: полторы тысячи документов в сутки, 50 килобайт текста в документе, 100(сто!) накладных за 16 минут… Это 1С что ли такой тормозной?
ИМХО что-то где-то не так…
Дело в обработках, каким могла подвергаться одна накладная, вот поэтому на тесте у клиента 100 накладных могли грузиться 16 минут:
Нужно отдельно сказать о том, какие обработки проходила почти каждая накладная. Сам по себе этот документ весил не очень много – около 50 кб в текстовом, определенном формате, тут важно какому процессу обработок подвергался каждый документ. Каждая накладная проходила такие обработки:
— распознавание контрагента;
— распознавание SKU позиции по таблице соответствия;
— сложная обработка по ценообразованию (есть государственные ограничения, есть таможенные ограничения, цена дистрибьютора — проверка стоимости по всем этим и другим параметрам);
— происходила проверка этого товара на складе, если он был – ставился резерв, если нет – формировался заказ;
Если учесть, что у нас есть 111 аптек, на каждую аптеку есть как минимум 10 дистрибьюторов, а еще каждая накладная может иметь разные позиции: НДС-товар, не НДС-товар, это не говорим уже о других свойствах – продукт должен хранится в холодильнике, например. Проверка 1 накладной могла осуществляться по 20 (!) позициям.
Я не вижу ничего сложного в перечисленных операциях, обычная работа базы данных.
В одном из наших проектов несколько сотен устройств сдают журналов на порядка полумиллиона транзакций в день, в текстовых файлах, с разборкой, проверкой, обработкой, построением связей, с пиковой сдачей в вечерний период. Причем коммерсанты тут же идут за отчетами на веб, а операторы там же занимаются другой работой.
Всем этим делом, не особо напрягаясь, занимается сервер тысяч за десять(скорее даже дешевле) баксов и не требует никаких ССД.
В одном из наших проектов несколько сотен устройств сдают журналов на порядка полумиллиона транзакций в день, в текстовых файлах, с разборкой, проверкой, обработкой, построением связей, с пиковой сдачей в вечерний период. Причем коммерсанты тут же идут за отчетами на веб, а операторы там же занимаются другой работой.
Всем этим делом, не особо напрягаясь, занимается сервер тысяч за десять(скорее даже дешевле) баксов и не требует никаких ССД.
> 2013 год – планы перехода с собственных SAS на собственные SSD (экономически не выгодно),
Что-то я математику не сложу. Как может оказаться экономически невыгодно модернизировать собственную инфраструктуру, чем арендовать у провайдера, для компании, которая потребляет больше вычислительной мощности, чем половину одного физического сервера? Как может собственный сервер + собственный админ + электроэнергия быть дороже, чем чужой такой же сервер + чужой админ + чужая электроэнергия + чужие операционные расходы + чужие налоги + чужая маржа? Я понимаю экономию, которая достигается за счет того, что провайдер VPS разделяет ресурсы одного физического сервера на десяток клиентов. Но если вам для вашего бизнеса нужен сервер целиком, то экономии в случае аренды тут быть не может.
Что-то я математику не сложу. Как может оказаться экономически невыгодно модернизировать собственную инфраструктуру, чем арендовать у провайдера, для компании, которая потребляет больше вычислительной мощности, чем половину одного физического сервера? Как может собственный сервер + собственный админ + электроэнергия быть дороже, чем чужой такой же сервер + чужой админ + чужая электроэнергия + чужие операционные расходы + чужие налоги + чужая маржа? Я понимаю экономию, которая достигается за счет того, что провайдер VPS разделяет ресурсы одного физического сервера на десяток клиентов. Но если вам для вашего бизнеса нужен сервер целиком, то экономии в случае аренды тут быть не может.
Я правильно понимаю — аптекари не уложились по требуемым мощностям в ограничения виртуального хостинга (которые есть у всех хостеров), после этого арендовали сервера у SIM-Networks, мощностей (внезапно!) стало хватать, после чего SIM-Networks рассказали что все — как всегда, а они дартаньяны?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы чуть не потеряли 5 000 000 гривен в месяц из-за «неправильного» хостинга: история клиента