Последние сообщения

А какие есть хостинг панели на несколько серверов?

Я ищу панель управления типа ajenti или vesta но с возможностью удаленно управлять несколькими хостами.

Вообще шикарно если будет возможность расширения функционала и/или поддержка chief/puppet/ansible/etc 

Алексей Герасимов

Webmin кластер, он позволяет создавать кластеры — системы, объединённые в кластер, для централизованного управления несколькими серверами через веб-интерфейс. Ну или тот же ISPmanager

А какие есть хостинг панели на несколько серверов?

Я ищу панель управления типа ajenti или vesta но с возможностью удаленно управлять несколькими хостами.

Вообще шикарно если будет возможность расширения функционала и/или поддержка chief/puppet/ansible/etc 

Ставьте смело ISPmanager Lite. Много документации на русском, всё ставится «из коробки», легко управлять. У наших клиентов хостинга всё работает годами. Из минусов: были замечены жестокие глюки после автоматических обновлений, поэтому обновляться, ИМХО, нужно вручную (с помощью инструментов панели) и сразу проверять работоспособность.

Хорошая панель делает ровно то, что вы и своими руками сделаете.

Если речь идет о стандартной настройке под LAMP.

А почему бы не взять ВПС с готовой панелью уже?
ISPManager чудесна.

Только в A указывают не «адрес локального DNS сервера», а ip конкретного сервера, а тебе нужен CNAME, но и то, там тоже не «адрес локального DNS сервера», а конкретный домен, который ты будешь контролировать в «другом ДНС сервере».

В домене mysite.ru:

blog NS ns.blog.mysite.ru.
ns.blog A x.x.x.x (ip адрес вашего локального сервера)

в домене blog.mysite.ru:
@ SOA ns.blog hostmaster (xxxxxxx) (обычная SOA запись)
ns A x.x.x.x
@ A x.x.x.x
video A y.y.y.y.y
home A z.z.z.z

Учтите, точки имеют значение.

На хостинг, если есть деньги, рекомендовал бы вынести по одной полноценной ноде (ClientAccess+Mailbox) Exchange и как минимум один контроллер, чтобы сделать избыточность.

В филиалы можно поставить RODC, точнее, надо поставить.
Схема такая.
1. Центральный офис. DC01, DC02, Exchange Node.
2. Хостинг. DC03, Exchange Node.
3. Филиалы. RODC(1...n).

Коллега, не рекомендовал бы Вам городить поддомены. Заводите всех в один домен. Создайте сайты, и если позволяет скорость сети, сделайте notify based replication между сайтами.

Чем проще схема, тем безопаснее и понятнее будет система.

Предвидятся явные проблемы при отсутствии Интернета в филиалах. Как авторизоваться если контроллера не видно? Как долго будут отвечать локальные ресурсы, если загружен канал?

Если впн присутствует, я бы, построил лес с физическими или виртуальными подчиненными контроллерами. Просто доверенные транзитивные отношения не предусматривают наследования групповых политик. 

Ставить свой Exch к каждый филиал мне кажется большим расточительством бюджета нежели выделить отдельную машину в роли DC( AD, DHCP, DNS) в каждый филиал и простенький шлюз типа MikroTik.

А так: каждый филиал — отдельный сайт. Если очень хочется — сделать поддомены (site1.contoso.com, site2.contoso.com, и т.д.)

Центральные контроллеры AD — на центральной площадке.

В филиалах — ставим и настраиваем RODC.

Про избыточность отдельного Exchange для каждого филиала — согласен с предыдущим оратором.

А почему «в филиалах разные подсети» — через «но»? :-) Оно именно так и должно быть — у каждой площадки должна быть своя IP-подсеть. А то и не одна, если площадка большая.

Также неясно, что за проблемы у вас с хостингом. Какая разница, на чём реализована инфраструктура — на железе, на виртуалках у вас или на виртуалках у хостинг-провайдера?

Только модель вы предполагаете использовать неправильную — нужно не брать в аренду физический сервер, а брать ресурсы у облачных провайдеров. Если ваш физический сервер чихнёт — у вас поляжет куча всего. Ну да, вам восстановят из бэкапов (возможно, оно даже восстановится). Но времени на это будет потрачено немеряно, и всё это время ваша сеть будет валяться. Если хотите делать сами — нужно:

— брать минимум два сервера для резервирования
— предусматривать отказоустойчивое дисковое хранилище (дисковое хранилище — потому что серверов у вас два, и обоим нужен будет доступ к общей хранилке. То есть — это либо СХД, либо распределённая файловая система (но тогда серверов нужно вам больше, чем 2).

Поэтому с арендой физического железа возни будет гораздо больше, чем купить маленькое облачко у сервис-провайдера. Ну, самые известные примеры — это Amazon, Azure, DigitalOcean. Из отечественных навскидку — КРОК, ДатаЛайн, СофтЛайн, Селектел, Наука-Связь.

Что касается серверов — на DO — на один сервер 1 тб трансфер, имейте это ввиду. Что касается русских проектов с серверами зарубежом — тоже работают отлично. В poiskvps все есть. Цена вопроса для личного VPN на 10-15 человек — рублей 200-300.

Для личного использования (если вы не в Китае), подойдет любой протокол VPN, советую Outline поставить. Самый простой вариант.

Вопрос сложности оплаты опустим. А вот это зря. Сейчас многим приходится отказываться от неплохих вариантов только потому что невозможно их оплатить.

Здесь ответ заключается в ответе на вопрос — что Вы будете делать, если DO в одностороннем порядке расторгнет договор, сказав что-нибудь типа того, что недавно сказал TeamViewer? (а ответ на этот вопрос зависит от того, зачем Вам в основном VPN. Раньше цель была одна — ходить на сервера, забаненные РКН. В нынешние чудные времена появилась вторая — ходить на сервера, которые сами не пускают IP из РФ/РБ)

Вот в зависимости от того, зачем Вам VPN — и ответ на вопрос. Если основная цель — первая, то конечно брать в DO. Если вторая — то лучше у российского хостера. 

Для обхода блокировок со стороны сервисов, Qt, например, российских хостинг с серверами за границей может не подойти. Были прецеденты. Так что, если есть возможность оплатить зарубежный хостинг — надо брать зарубежный

Вероятность блокировки конкретно Вашего VPN, размещенного за границей, далеко не нулевая (у нас любят блокировать целыми сегментами), равно как и возможные проблемы на РУ-хостинге с серверами в Европе (пример дата-центра Яндекса в Финляндии, если не ошибаюсь, довольно показателен, пусть это и не хостинг). Есть и вероятность, что DO или другая компания решит, что им просто не нужны клиенты из РФ и разорвет договора. На всякий случай напомню, текущая ситуация определенно подпадает под определение форс-мажора.

Боюсь, что сейчас выбор правильного решения сродни игре в лотерею, все варианты могут обернуться потерей доступа и соответственно денег.

То есть как понял вместо вариаций используется привязка аналогов/сопутствующих товаров к основной карточке.

— Каждая модификация — отдельный товар (например, «Футболка (синяя, XL)» и «Футболка (черная, M)» — это две разные карточки).

— Связь через артикулы или ID (например, в поле «Сопутствующие товары» или через ручное/API-сопоставление).

Все верно понял? 

Руслан Козырев

Да Вы все верно поняли, можно отключить вариации в настройках товаров (если возможно) или просто не использовать этот функционал.

Создавать товары по отдельности, но с одинаковыми:

— Названием (с уточнением параметра, например, «Футболка [Черная, XL]»).

— Группировочным артикулом (например, основной артикул + постфикс _XL, _BLACK).

— Связать их через «Сопутствующие товары» или через ручное сопоставление.

— Настроить выгрузку так, чтобы маркетплейсы воспринимали их как модификации (например, через общий «Групповой идентификатор» в Ozon или «Родительский артикул» в WB).

Плюсы такого подхода

— Проще выгружать и обновлять (каждый товар — отдельная строка в CSV/XLSX).

— Гибкость — можно легко добавить новый цвет/размер без переделки всей вариативной карточки.

— Совместимость с Ozon/WB, где такой формат используется как стандартный.