Управление Vlan'ами в последней версии на crs (может на других моделях тоже, не проверил ещё) вполне ок стало =) раньше был лютый костыль, а про железку, имхо, не реально за 150$ получить чип с аппаратной поддержкой шифрования.
Логика такая, когда это делает ОС, то процессор должен посчитать хеш пакета и направить его в нужный интерфейс, когда это происходит на аппаратном уровне, то вполне возможно, что карточки сами решат через какой интерфейс посылать пакет.
Но я правда не нашёл пруфов. Просто мысли в слух.
Скорее всего вопрос производительности, настройка через драйвер = аппаратная обработка (с высокой долей вероятности), настройка через ОС = обработка процессором.
Про бесплатную версию Windows Hyper-V я знаю, именно потому и пишу про версии с полноценным GUI, но спасибо за уточнение, про Datacenter редакцию действительно важно.
Я ведь правильно понял, что можно взять любой сервер от %ФИРМА_ПРОИЗВОДИТЕЛЬ% и сделать тоже самое? Главное наличие карточки от Intel с поддержкой Teaming и 802.1q?
Присоединяюсь. Не самый идеальный гипервизар по «толщине», но по функционалу сейчас обгоняет некоторые аналоги и по цене не кусачий (если смотреть версии с полноценным GUI)
Так же у себя на нескольких серверах его использую, что с двумя физ. картами, что с одной из двух.
у меня в доме такое сделал Ростелеком и вот знаете что я скажу про «одна никак не затрагивает другую в плане скорости и качества передачи данных» когда вижу шестьдесять (!!!) других сетей с силой сигнала выше среднего, я вам скажу что вы ошибаетесь.
Смена версии платформы мало влияет на то что мы настроили.
Внутри версии 8.3 мы обновляем её прозрачно, с версии 8.2 на 8.3 я сам обновлял конфигурации через простую конвертацию (встроенную в конфигуратор), а на 8.4 если и нужно будет переходить, то либо будет тот же «конвертатор» — либо через перезагрузку в DT.
Разделение данных именно для этого и создано. Данные многих организаций лежат в одной общей для них конфигурации. Пользователей так же можно разделить. Не мечта — но вполне себе съедобный кактус.
Вот ответ от нашей замечательной программистки:
«Если разделитель включен в режиме „независимо“, тогда возможности обратиться в одном запросе к нескольким разделенным областям нет. Надеемся, что в ближайших релизах платформы такая возможность появится.»
Думаю переход в одну базу, не важно разделённую или нет, зависит скорее от:
1. Как ведётся учёт в этих организациях? Одинакового или нет?
2. Одинаков ли план счетов?
3. Кто работает с базами, один и те же пользователи?
4. Нужно ли видеть сводные отчёты, сальдооборотки?
Если на все пункты (наверняка это не всё, но больше я сходу не могу припомнить) ответ «нет» — то лучше не объединять.
Плюс нужно учесть размеры баз, если большие — то лучше не объединять.
Так же советую поговорить об этом с бухгалтером — она, наверняка, может сказать свои доводы, к которым стоит прислушаться.
Спасибо за замечание. Почитал ещё раз условия лицензионного соглашения, согласен с вами — наш текст звучит не однозначно (и скорее всего релевантный только для наших условий). Внесу правки в статью.
Вы не поверите… Но в какой то степени именно для сохранения ссылочной целостности! =)
При загрузке больших баз в разделённую область мы частенько ловили ошибки, переход на режим мухи отдельно от котлет справочники отдельно \ данные отдельно исправил такое поведение.
Загрузка у нас тоже вот вот будет в автоматическом режиме — что минимизирует человеческий фактор. Мне показалось что тема перелива данных через различные механизмы выходит за рамки статьи и\или заслуживает отдельной. И к тому же утверждать что мы что-то делаем не руками, когда на самом деле мы делаем это руками — не честно. Пишем как есть, если кто-то продвинется дальше нас (и потом ещё и статью напишет) будет здорово!
Проблема пока с регламентными заданиями, что оказались общими — они не видны в списке, только в режиме конфигуратора. Это затрудняет их настройку и отслеживание статуса.
По поводу необъяснимых глюков если кто-то что-то поправит — конечно мы об этом подумали — мы так не делаем =) Объяснение наверное звучит как то слабовато, но вы попробуйте, это правда работает!
Мы используем предпоследний релиз 8.3 безбожных глюков у нас нет, само разделение мы используем уже несколько месяцев, в последний начали массовый перевод организаций.
В реальности, в режиме конфигуратора при входе в область вам недоступно ни одно действие, на любой чих вы получаете ошибку «Действие недоступно при установленном разделении данных» — ни открыть конфигурацию ни выгрузить в dt данные области это не позволяет. Возможно в более старых версиях это работало.
Но я правда не нашёл пруфов. Просто мысли в слух.
Так же у себя на нескольких серверах его использую, что с двумя физ. картами, что с одной из двух.
… и после этих слов уже действительно ничего не понятно =)
Внутри версии 8.3 мы обновляем её прозрачно, с версии 8.2 на 8.3 я сам обновлял конфигурации через простую конвертацию (встроенную в конфигуратор), а на 8.4 если и нужно будет переходить, то либо будет тот же «конвертатор» — либо через перезагрузку в DT.
«Если разделитель включен в режиме „независимо“, тогда возможности обратиться в одном запросе к нескольким разделенным областям нет. Надеемся, что в ближайших релизах платформы такая возможность появится.»
1. Как ведётся учёт в этих организациях? Одинакового или нет?
2. Одинаков ли план счетов?
3. Кто работает с базами, один и те же пользователи?
4. Нужно ли видеть сводные отчёты, сальдооборотки?
Если на все пункты (наверняка это не всё, но больше я сходу не могу припомнить) ответ «нет» — то лучше не объединять.
Плюс нужно учесть размеры баз, если большие — то лучше не объединять.
Так же советую поговорить об этом с бухгалтером — она, наверняка, может сказать свои доводы, к которым стоит прислушаться.
При загрузке больших баз в разделённую область мы частенько ловили ошибки, переход на режим мухи отдельно от котлет справочники отдельно \ данные отдельно исправил такое поведение.
Загрузка у нас тоже вот вот будет в автоматическом режиме — что минимизирует человеческий фактор. Мне показалось что тема перелива данных через различные механизмы выходит за рамки статьи и\или заслуживает отдельной. И к тому же утверждать что мы что-то делаем не руками, когда на самом деле мы делаем это руками — не честно. Пишем как есть, если кто-то продвинется дальше нас (и потом ещё и статью напишет) будет здорово!
По поводу необъяснимых глюков если кто-то что-то поправит — конечно мы об этом подумали — мы так не делаем =) Объяснение наверное звучит как то слабовато, но вы попробуйте, это правда работает!
Мы используем предпоследний релиз 8.3 безбожных глюков у нас нет, само разделение мы используем уже несколько месяцев, в последний начали массовый перевод организаций.
В реальности, в режиме конфигуратора при входе в область вам недоступно ни одно действие, на любой чих вы получаете ошибку «Действие недоступно при установленном разделении данных» — ни открыть конфигурацию ни выгрузить в dt данные области это не позволяет. Возможно в более старых версиях это работало.