Конечно. Но ghettoVCB создает только полный слепок ВМ. А предложенное решение на базе Bareos поддерживает дифференциальное и инкрементное резервное копирование. Плюс у ghettoVCB весьма ограниченные возможности по ведению журналов и контролю за корректностью выполнения заданий.
Речь в статье идет именно о провайдерах облачных услуг, типа IaaS. Это предполагает инфраструктуру облака, где задачи по вычислению, по хранению, по коммутации — разнесены аппаратно и управляются централизовано специализированными программными комплексами.
Статья не имела целью научить способам реализации, она несет рекомендательный характер. За методами реализации следует обращаться в соответствующие компании, либо изучать матчасть
И конечно же, всем не нужны «широкие» каналы, параметры облака подбираются под конкретные требования проекта. Важно, чтобы провайдер облачных услуг был в состоянии предложить вам выбор.
Дело в обработках, каким могла подвергаться одна накладная, вот поэтому на тесте у клиента 100 накладных могли грузиться 16 минут:
Нужно отдельно сказать о том, какие обработки проходила почти каждая накладная. Сам по себе этот документ весил не очень много – около 50 кб в текстовом, определенном формате, тут важно какому процессу обработок подвергался каждый документ. Каждая накладная проходила такие обработки:
— распознавание контрагента;
— распознавание SKU позиции по таблице соответствия;
— сложная обработка по ценообразованию (есть государственные ограничения, есть таможенные ограничения, цена дистрибьютора — проверка стоимости по всем этим и другим параметрам);
— происходила проверка этого товара на складе, если он был – ставился резерв, если нет – формировался заказ;
Если учесть, что у нас есть 111 аптек, на каждую аптеку есть как минимум 10 дистрибьюторов, а еще каждая накладная может иметь разные позиции: НДС-товар, не НДС-товар, это не говорим уже о других свойствах – продукт должен хранится в холодильнике, например. Проверка 1 накладной могла осуществляться по 20 (!) позициям.
Я о самом утверждении «облака решат все ваши проблемы».
— никто этого не утверждал
Это было 5 лет назад? Ок.
— 5 лет назад клиент начал с нами работать, в статье суммированный опыт.
Перейти с арендованного SAS на арендованный SSD.
— точнее — перейти со своего SAS на свой SSD — не выгодно — посчитал клиент, — поэтому решил перейти на арендованный SSD у другого хостера, а после неудачного опыта, перешел к нам.
Чем же они отличаются от других высокопрожорливых? :)
— если бы не отличались, не морочились бы.
Я не понимаю, как оно мигрировало, что недомигрировало.
— хостер (не мы) перенес базу, но она не заработала, а он уже убил «старую» БД клиента.
Еще раз хочу акцентировать ваше внимание, в статье — суммированный опыт за несколько лет работы с клиентом, знакомства и перехода с различными хостинг-услугами и хостерами, и различными видами гибридной ит-структуры клиента: например что-то осталось у клиента, что-то было у других хостеров, что-то было у нас — но потом уже многое что из ит-инфраструктуры клиента переехало к нам.
>Всех наших битрикс-клиентов мы выносим в отдельные сервера, где есть только битрикс-клиенты.
Какая разница, кто где есть? :)
Мы выносим всех битрикс-клиентов в отдельные сервера, которые специально сконфигурированы и оптимизированы именно под битрикс.
Дочитал до конца, это хостер сам себя хвалил :)
Это говорит клиент, а не хостер.
Не проще было сразу на SSD перейти?
— ответ в статье, клиент просчитывал стоимость перехода, и понял что это не выгодно:
Мы просчитывали, что если все нужное нам оборудование мы купим сами, то выйдем в 0 покрытия капитальных затрат только через 3,5 года – и это не окончательные просчеты, так как наша компания постоянно развивается, и сумма затрат на увеличение мощности нашей ИТ-инфраструктуры могла бы увеличиваться в геометрической прогрессии.
Очевидно, большинство ваших комментариев вызвано тем, что возможно в статье не так четко обозначено то, что у клиента не вся инфраструктура целиком и сразу была на арендуемых мощностях (что-то арендовалось на физических и/или виртуальных мощностях, что-то оставалось на собственных серверах), миграция на арендуемые мощности и облака осуществлялась постепенно: от сайта к базе данных и основным бизнес-процессам. И работа с хостинг-провайдерами проводилась поэтапно: вначале сайт, потом 1С; вначале один хостер, потом другой, потом протестировали у себя то же (это к вопросу о «гнилой инфраструктуре»), потом уже третий хостер.
>Главной задачей было – убрать эти очереди к БД, и на тех мощностях которые мы сейчас арендуем у провайдера SIM-Networks – удалось решить эту наболевшую для нашего бизнеса задачу.
+ рисунок внизу.
Искали облако, но поперлись к тому самому хостеру, а еще смотрели других хостеров.
Не проще было сразу на SSD перейти?
Попахивает рекламой хостера. :)
Про SSD — ответ выше, БД была размещена не у того же самого хостера, а у другого. Это говорит сам клиент, а не мы себя хвалим.
У вас просто гнилая архитектура.
С ростом эта проблема опять вернется :)
С ростом у клиента проблема не возвращается, и мы сделаем все, чтобы не вернулась:) 5 лет роста это подтверждают.
Можно подумать, там одни юрики хостят свои бизнес-процессы. :) Какие именно мощности вы арендовали?
Об этом клиент не хочет рассказывать, так как тогда придется озвучить названия тех компаний, опыт с которыми был не очень удачным — пусть это останется тайной.
>И только после года таких мучений, компания хостер согласилась купить специально под нас SSD-полку в свой дата-центр.
Но вы же на ссд переехали только у своего любимого иностранного хостера…
Это было до нас. Речь идет о предыдущем хостере.
>Провайдер обещал осуществить миграцию всего за сутки. В воскресенье в обед реструктуризация новой полки еще не была закончена и мы начали просить все вернуть как было, на что получили ответ, что на старой арендуемой нами мощности наших данных уже нет (- а мы перенесли, смотрим система поднялась и поэтому старую БД удалили – сказал хостер), хостер решил удалить эти данные, так как считал, что миграция уже произошла и их хранить уже не обязательно ( — Они сошли с ума!? – подумали мы).
Хм, пару раз проводились миграции.
Никогда никакого подтверждения хостеру, что все ок не давал, а он никогда не говорил, что вдруг что, есть старая.
Нужно было самим мигрировать.
Тут можно поспорить, но тут становится актуальным вопрос клиентоориентированности, может быть кто-то так работает, но мы считаем это неправильно — когда клиента оставляют один на один с его проблемами. Тем более вы не учли тот момент, что из-за такого подхода хостера (твоя база переехала, а то, что не работает — твои проблемы, мы твою старую базу «убьем» тут же — чего она у нас место занимает!?), у клиента могла остановится работа всей компании на целую неделю — как вы думаете для сети ритейла это ок? Может быть кто-то так работает, но мы так не работаем. Хостеру лучше было удостоверится, что БД у клиента работает и все ок, и только тогда убивать старую.
Вы же уже в облаке, нет?
Пока не полностью, но уже клиент к этому готов, все зависит от поставщика услуг.
Хватить толкать маркетинговый бред.
Речь идет о фактах — никакой воды и инкогнито «одна ритейл-сеть» или что-то такое, что проверить нельзя, указан: клиент, название, кто-что-где, указанны цифры и проблемы, и как их решил клиент с нашей помощью), это — слова клиента, а наши слова о самих себе.
Книга, по которой написана статья, действительно достойна внимания (не читал, но хочу): www.amazon.com/Rethinking-Positive-Thinking-Science-Motivation/dp/1617230235
Читал об этой книге, что автор написала ее на основе многих исследований.
Перевода на русский нет, что странно, видел перевод на украинский: bookinstein.com.ua/pereglyad-pozitivnogo-mislennya
Есть приложение, которое сделано по плану WOOP — play.google.com/store/apps/details?id=de.parrotmedia.woopbusiness&hl=ru
И конечно же, всем не нужны «широкие» каналы, параметры облака подбираются под конкретные требования проекта. Важно, чтобы провайдер облачных услуг был в состоянии предложить вам выбор.
— никто этого не утверждал
— 5 лет назад клиент начал с нами работать, в статье суммированный опыт.
— точнее — перейти со своего SAS на свой SSD — не выгодно — посчитал клиент, — поэтому решил перейти на арендованный SSD у другого хостера, а после неудачного опыта, перешел к нам.
— если бы не отличались, не морочились бы.
— хостер (не мы) перенес базу, но она не заработала, а он уже убил «старую» БД клиента.
Еще раз хочу акцентировать ваше внимание, в статье — суммированный опыт за несколько лет работы с клиентом, знакомства и перехода с различными хостинг-услугами и хостерами, и различными видами гибридной ит-структуры клиента: например что-то осталось у клиента, что-то было у других хостеров, что-то было у нас — но потом уже многое что из ит-инфраструктуры клиента переехало к нам.
Это — слова клиента, а не наши слова о самих себе.
Мы выносим всех битрикс-клиентов в отдельные сервера, которые специально сконфигурированы и оптимизированы именно под битрикс.
Это говорит клиент, а не хостер.
— ответ в статье, клиент просчитывал стоимость перехода, и понял что это не выгодно:
Очевидно, большинство ваших комментариев вызвано тем, что возможно в статье не так четко обозначено то, что у клиента не вся инфраструктура целиком и сразу была на арендуемых мощностях (что-то арендовалось на физических и/или виртуальных мощностях, что-то оставалось на собственных серверах), миграция на арендуемые мощности и облака осуществлялась постепенно: от сайта к базе данных и основным бизнес-процессам. И работа с хостинг-провайдерами проводилась поэтапно: вначале сайт, потом 1С; вначале один хостер, потом другой, потом протестировали у себя то же (это к вопросу о «гнилой инфраструктуре»), потом уже третий хостер.
Про SSD — ответ выше, БД была размещена не у того же самого хостера, а у другого. Это говорит сам клиент, а не мы себя хвалим.
С ростом у клиента проблема не возвращается, и мы сделаем все, чтобы не вернулась:) 5 лет роста это подтверждают.
Об этом клиент не хочет рассказывать, так как тогда придется озвучить названия тех компаний, опыт с которыми был не очень удачным — пусть это останется тайной.
Это было до нас. Речь идет о предыдущем хостере.
Тут можно поспорить, но тут становится актуальным вопрос клиентоориентированности, может быть кто-то так работает, но мы считаем это неправильно — когда клиента оставляют один на один с его проблемами. Тем более вы не учли тот момент, что из-за такого подхода хостера (твоя база переехала, а то, что не работает — твои проблемы, мы твою старую базу «убьем» тут же — чего она у нас место занимает!?), у клиента могла остановится работа всей компании на целую неделю — как вы думаете для сети ритейла это ок? Может быть кто-то так работает, но мы так не работаем. Хостеру лучше было удостоверится, что БД у клиента работает и все ок, и только тогда убивать старую.
Пока не полностью, но уже клиент к этому готов, все зависит от поставщика услуг.
Речь идет о фактах — никакой воды и инкогнито «одна ритейл-сеть» или что-то такое, что проверить нельзя, указан: клиент, название, кто-что-где, указанны цифры и проблемы, и как их решил клиент с нашей помощью), это — слова клиента, а наши слова о самих себе.