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

На хостинг, если есть деньги, рекомендовал бы вынести по одной полноценной ноде (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, где такой формат используется как стандартный. 

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

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

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

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

Нет вариации останутся и все ваши вариативные товары тоже, просто расшириться функционал и вы сами сможете выбирать как добавлять и с чем работать дальше. 

Спасибо за ответ Артем, так вариации пропадут в таком случае или нет? 

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

Северсталь

Ну тут вопрос очень спорный, не всем нужно уйти от вариаций, тут слишком много моментов чтоб так однозначно заявить что вариаций не нужны и нужны только сопутствующие товары. В ближайших обновлениях все верно ожидается данная функция но она будет внедрена без ущерба вариациям, а просто как дополнение т.е. проще говоря в карточке товара появиться новая, дополнительная функция в которой можно будет добавить сопутствующие товары. Это позволит решить задачу гибко и вы уже сами будете выбирать что использовать вариации или сопутствующие товары. 

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

Проблема вариативных товаров

— Вариативные товары (например, разные цвета, размеры) могут усложнять выгрузку (импорт/экспорт) из-за особенностей структуры данных.

— Платформы, такие как Ozon и Wildberries, используют другой подход — привязку аналогов/сопутствующих товаров к основной карточке.

Решение: отказ от вариаций в пользу сопутствующих товаров

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

Это делает выгрузку проще и гибче, так как:

— Нет проблем с обработкой вариаций в CSV/XLSX-файлах.

— Легче добавлять новые модификации без перестройки всей структуры.

— Упрощается синхронизация с маркетплейсами.

Техническая реализация в DST Marketplace

— Можно настроить ассоциации товаров (например, через артикулы или ID).

— Можно отключить стандартные вариации и перевести товары в плоский список.

— Возможные API-методы или CSV-шаблоны для такой выгрузки.

Преимущества подхода

— Упрощение работы с каталогом (меньше ошибок при загрузке).

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

— Совместимость с маркетплейсами, которые лучше работают с «плоскими» товарами.