Когда руководство переживает за свои данные (как бы не попали куда не следует), то это или к изучению шифрования, или к покупке кислоты для диска, или к поиску заморских ЦОД. Если выбор пал на перенос сервера подальше из страны, то возникает целый ворох неочевидных проблем с его использованием остальным офисом. В статье будет про сценарий переноса 1С в европейский дата-центр и про настройку "самонаводящегося" IPSec.
Ведь дьявол кроется в деталях.
В одной из организаций мне довелось заниматься переносом некоторых ее сервисов на немецкий выделенный сервер. Почему выделенный сервер и именно в Германии — не принципиально, поэтому примем как данность. Казалось бы, банальный VPN и удаленный доступ к сервисам — что вообще может пойти не так?
Изучаем пациента
Большая часть пользователей компании работают с тонких клиентов на ферме терминальных серверов, а периметр охраняет роутер с межсетевым экраном D-Link DFL-800 с сотней поднятых туннелей IPsec. Этот же роутер отвечает за резервирование WAN.
Для переноса выбрали несколько баз 1С, конфигурация которых осложняется множеством обменов и обработок, которые используют другие БД и сетевые ресурсы. Написано все это уже неизвестно кем, поэтому спросить совета не получилось. Пользователи авторизуются в 1С с использованием Active Directory, что менять не хотелось бы.
Из-за всего этого сделать еще один терминальный сервер в Германии – не лучшая идея: работа RDP внутри RDP (тонкие клиенты) оставляет желать лучшего, да и банальная печать на перенаправленных принтерах превращается в квест. Неплохим вариантом могла бы стать виртуализация приложений не базе Citrix XenApp, но после долгосрочной аренды выделенного сервера бюджета оставалось не настолько много.
Чтобы изменения в СУБД и инфраструктуре стремились к нулю, нужно было делать прозрачный VPN для находящегося в тысяче километров сервера. За основу взяли типовой туннель IPSec на базе Windows и ответной части на D-Link. Это достаточно распространенное решение с минимальными вложениями.
Осталось ответить на три простых вопроса:
Как перепрописать пути к базам паре десятков пользователей?
Как переключить IPsec в случае сбоя основного WAN-канала в офисе? Механизм IPSec в Windows подобной возможности по умолчанию не предлагает.
- Хватит ли роутеру сил для поддержки еще одного довольно нагруженного туннеля?
Начнем по порядку.
Медленно добавляем машину в домен...
В результате всех махинаций сервер должен стать полноправным членом домена и видеть всю локальную сеть через зашифрованный канал. Общая схема получилась такой (не оригинально, но для общего представления лучше нарисовать):
В качестве исходных данных, для иллюстрации:
IP-адреса основного и резервного провайдера офиса 1.2.3.4 и 1.2.3.5;
Локальная сеть офиса 192.168.0.0/24;
Внутренний адрес D-Link 192.168.0.1;
- Внешний адрес сервера 5.4.3.2.
Для установки туннеля нужно выполнить несколько команд на роутере и сервере.
На D-Link:
Добавим алгоритмы IPsec и IKE:
add IKEAlgorithms Medium DES3Enabled=True SHA1Enabled=True add IPsecAlgorithms Medium DES3Enabled=True SHA1Enabled=True
Добавим внешний адрес сервера:
add IP4Address IP_Remote Address=5.4.3.2
Добавим ключ на IPsec:
add PSK Key_Remote Type=ASCII PSKAscii=MegaSecureKey Comments=MegaSecureKey
Сам туннель:
add IPsecTunnel Remote_Server LocalNetwork=InterfaceAddresses/lannet RemoteNetwork=IP_Remote RemoteEndpoint=IP_Remote IKEAlgorithms=Medium IPsecAlgorithms=Medium AuthMethod=PSK PSK=Key_Remote AddRouteToRemoteNet=True PFS=PFS NATTraversal=Off KeepAlive=Manual KeepAliveSourceIP=lan_ip KeepAliveDestinationIP=IP_Remote AutoInterfaceNetworkRoute=False
Активируем настройки:
activate
- И подтверждаем их, чтобы умный роутер не откатил изменения:
commit
На Windows:
Создаем политику, но не назначаем ее:
netsh ipsec static add policy ipsec assign=no mmpfs=yes mmsec="3DES-SHA1-2"
Добавляем действие фильтра:
netsh ipsec static add filteraction name=ipsec action=negotiate qmpfs=yes qmsec="ESP[3DES,SHA1]:3600s"
Настраиваем два фильтра, в одну и другую стороны:
netsh ipsec static add filter filterlist=win2dfl srcaddr=5.4.3.2 dstaddr=192.168.0.0 dstmask=255.255.255.0 mirrored=no
netsh ipsec static add filter filterlist=dfl2win dstaddr=5.4.3.2 srcaddr=192.168.0.0 srcmask=255.255.255.0 mirrored=no
Создаем два правила политики с для фильтров:
netsh ipsec static add rule name=win2dfl policy=ipsec filterlist=win2dfl filteraction=ipsec tunnel=1.2.3.4 psk=MegaSecureKey
netsh ipsec static add rule name=dfl2win policy=ipsec filterlist=dfl2win filteraction=ipsec tunnel=5.4.3.2 psk=MegaSecureKey
- Применяем политику:
netsh ipsec static set policy name=ipsec assign=yes
Теперь туннель заработал.
Нужно отметить, что при работе с более свежими DFL лучше себя зарекомендовал IPsec средствами брандмауэра Windows. Настройка производится в контексте netsh advfirewall consec.
После поднятия туннеля подготовим сетевые параметры сервера с помощью магии wmi, после чего можно добавлять в домен:
wmic nicconfig where IPEnabled=TRUE call SetDNSServerSearchOrder ("192.168.0.2","192.168.0.3")wmic nicconfig call SetDNSSuffixSearchOrder (mylocaldomain.com)Получившийся туннель работал на скорости около 24 Mbps при заявленном потолке для VPN в 60 Mbps. Поскольку потолок нужно делить пополам из-за дуплекса – неплохой результат для приемлемой работы 1С.
Заменить всем пути к базам и не сойти с ума
Автоматическое добавление путей к базам 1С было реализовано чудовищным скриптом, построчно заполняющим файл ibases.v8i в профиле пользователя. Такому варианту есть и более удачные альтернативы.
Предположим, что у нас есть две базы и две группы безопасности — buh и torg. Тогда механизм автоматического подключения выглядит так:
Cоздание двух текстовых файлов в общей папке: buh.v8i и torg.v8i;
Для каждого файла нужно дать доступ на чтение только соответствующей группе безопасности;
- Содержание файлов следующее:
buh.v8i:
[Бухгалтерия]
Connect=Srvr="servername";Ref="buh";
ClientConnectionSpeed=Normal
App=ThickClient
WA=1
Version=8.3torg.v8i:
[Торговля]
Connect=Srvr="servername";Ref="torg";
ClientConnectionSpeed=Normal
App=ThickClient
WA=1
Version=8.3
Всем пользователям нужно прописать пути к обоим этим файлам с помощью файла 1CEStart.cfg. Можно его положить в профиль пользователя групповыми политиками (%appdata%\1C\1CEStart). При работе всех пользователей на терминальном сервере достаточно положить этот файл в C:\ProgramData\1C\1CEStart. Содержание файла следующее:
CommonInfoBases=\\путь_к_общей_папке\buh.v8i
CommonInfoBases=\\путь_к_общей_папке\torg.v8iТеперь пользователи в зависимости от членства в группе безопасности будут иметь определенный набор баз в 1С. При перемещении БД достаточно поменять только содержимое файлов v8i.
Но в том проекте решили проявить уважение к истории и решить проблему красиво чуть позже. На помощь временно пришел AutoIT с простеньким скриптом:
#include <File.au3>
;Собираем в массив файлы конфигурации 1с
local $aArray = _FileListToArrayRec ("путь к DFS-шаре с профилями пользователей", "ibases.v8i",1,1,0,2)
if @error <> 1 then
;Перебираем массив
for $i=1 to $aArray[0]
$iLine=0
While 1
$iLine += 1
$sLine = FileReadLine($aArray[$i],$iLine )
If @error = -1 Then ExitLoop
;если находим в строке конфига нужную нам базу…
If StringInStr($sLine, 'Ref="Нужная база ";') Then
;…То меняем в имя сервера
_ReplaceStringInFile($aArray[$i],$sLine,StringReplace($sLine,"Имя старого сервера","Имя нового сервера"))
EndIf
WEnd
Next
EndIfВозможно на Powershell вышло бы изящнее – тут на вкус и цвет.
Не отпускай!
Когда принципиально удаленные БД стали доступны для работы, настала очередь "шашечек" резервного WAN-подключения.
Конечно, можно настроить два туннеля через разных провайдеров, но не хотелось лишний раз нагружать и без того уставшую железку. Нужно было лишь научить IPSec подключаться по другому адресу в случае недоступности основного.
Нам поможет простой скрипт CMD:
@echo off
Rem задаем адреса IP основного и резервного канала.
Set office1=1.2.3.4
Set office2=4.3.2.1
Rem проверяем туннель пингом локального адреса:
Ping 10.0.0.10 -n 3
Rem если адрес недоступен
if errorlevel 1 (
rem проверяем доступность основного канала интернет
ping %office1% -n 3
rem если и он не доступен – проверяем резервный канал
if errorlevel 1 (
ping %office2% -n 3
rem если уж и он недоступен – значит в офисе проблемы. Пишем в лог
if errorlevel 1 (
echo %date% %time% office down >> check-ipsec.txt
) else (
Rem если же резервный канал доступен – переключаем туннель
echo %date% %time% reset tun office2 >>check-ipsec.txt
netsh ipsec static set rule id=1 policy=ipsec tunnel=%office2%
netsh ipsec static set policy name=ipsec assign=no
netsh ipsec static set policy name=ipsec assign=yes
ping 10.0.0.10 -n 3
)
) else (
Rem если же основной канал в порядке, а туннеля нет
rem значит нужно переключить туннель обратно, или он просто завис.
echo %date% %time% reset tun office1 >> check-ipsec.txt
netsh ipsec static set rule id=1 policy=ipsec tunnel=%office1%
netsh ipsec static set policy name=ipsec assign=no
netsh ipsec static set policy name=ipsec assign=yes
ping 10.0.0.10 -n 3
)
)
Ставим сценарий в автозапуск каждые пять минут, и вопрос с отказоустойчивым IPSec-подключением на этом решен. Переключение каналов со стороны D-link DFL описывать не буду, там все банально, да и инструкции есть на официальном сайте.
Но бухгалтеры негодуют
Заказчик остался доволен, в отличие от его бухгалтеров. Неторопливая работа 1С из-за недостаточно производительного VPN, конечно, раздражает. Особенно недобрые взгляды отдел ИТ ловил в период сдачи отчетности. Чтобы сделать удаленную 1С более отзывчивой, позже запланирована замена роутера на D-Link DFL-870, в котором обещан гигабитный VPN.
Тем не менее, бюджетный перенос баз за границу можно считать состоявшимся.
Комментарии (90)
vladadm
20.01.2017 14:47+31Ска, в обертке RdpApp, прекрасно работает, я бы сказал — летает, на 10-15 юзерах на 1 тунель, при 10-15мбитах в тунеле (ipsec). Т.е — примерно по 1мбиту на юзера, основная нагрузка только при отправке на локальную печать. Остальная «неторпливость» — зависит уже от платформы, тюнинга субд, сервера, и прочих mtu :)
DrPass
20.01.2017 15:01+4Неторопливая работа 1С из-за недостаточно производительного VPN, конечно, раздражает.
Пересадите их на терминальный сервер, который стоит в том же датацентре. Это решит все проблемы с производительностью интерфейса. Правда, добавит проблем тем клиентам, которые используют подключенное к 1С торговое оборудование, всякие ТСД, сканеры штрих-кодов и карт и т.д. Если они, конечно, есть.
qwertyRu
20.01.2017 15:05можете написать значения ping до сервера через тунель (по внутреннему каналу) до него же только без туннеля?
dimskiy
20.01.2017 15:09Если не изменяет склерз, то задержки были в районе 30-40 мс
qwertyRu
20.01.2017 15:13размер может оказаться не главное. 30-40 мс, до Германии это может быть напрямую. А добавляет ли канал свои задержки и какие? если будет возможность, посмотрите
pwrlnd
20.01.2017 16:52+1Мне вот интересно, где вы такие мифы читаете, что туннель добавляет большие задержки? Современный софт на современном железе добавит максимум несколько мс при большой нагрузке и всё.
PS: OpenVPN, нагрузка 30-40 мбит.
root@xxx:~# ping 222.222.222.222 PING 222.222.222.222(222.222.222.222) 56(84) bytes of data. 64 bytes from 222.222.222.222: icmp_req=1 ttl=52 time=16.8 ms 64 bytes from 222.222.222.222: icmp_req=2 ttl=52 time=16.6 ms 64 bytes from 222.222.222.222: icmp_req=3 ttl=52 time=16.7 ms 64 bytes from 222.222.222.222: icmp_req=4 ttl=52 time=16.6 ms 64 bytes from 222.222.222.222: icmp_req=5 ttl=52 time=16.5 ms ^C --- 222.222.222.222 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4004ms rtt min/avg/max/mdev = 16.590/16.693/16.874/0.155 ms root@xxx:~# ping 10.10.10.1 PING 10.10.10.1 (10.10.10.1) 56(84) bytes of data. 64 bytes from 10.10.10.1: icmp_req=1 ttl=64 time=17.2 ms 64 bytes from 10.10.10.1: icmp_req=2 ttl=64 time=17.0 ms 64 bytes from 10.10.10.1: icmp_req=3 ttl=64 time=16.8 ms 64 bytes from 10.10.10.1: icmp_req=4 ttl=64 time=17.0 ms 64 bytes from 10.10.10.1: icmp_req=5 ttl=64 time=16.9 ms ^C --- 10.10.10.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 16.896/17.024/17.210/0.196 msqwertyRu
20.01.2017 16:59причем здесь мифы?
есть решение, хочется узнать всесторонние подробности. Простое любопытство.
vladadm
20.01.2017 15:13Пинг по тунелям: 109мс — из Владика, 10мс — Воронеж, 20мс — Краснодар (это разбросанные, дальние, от сервера города).
Пинг по их внешним адресам (города в том же порядке): 112мс, 10мс, 23мсqwertyRu
20.01.2017 15:25т.е. особо не влияет
vladadm
20.01.2017 15:33До 100мс — норм. Открытие диалогов, новых окон документов — происходит в ту же секунду, когда произошел клик, печать — к сожалению идёт с задержкой — до 5 секунд. У нас основной критерий — есть среднепаршивые нагруженные отчеты по базе (базы в районе 200гб) — их построение и вывод не должен занимать 5 сек. Для самых тяжелых — 15. Но это действительно тяжёлые отчеты. :)
Периодически у нас бываю жалобы, начинается тупняк в работе — решается чаще всего передергиванием туннеля, или игрой с mtu.
Но так, чтобы прямо на глаз было заметна разница между работой с базой локально и удалённо — заметно только на пингах выше 100.
talifan
20.01.2017 15:11+2Дело, я думаю, не в ширине канала, а в задержках до Германии. Так что смена VPN на гигабит с большой долей вероятности скорости не добавит.
osipov_dv
20.01.2017 15:25+1Насколько я помню, начиная с версии 8.2 можно у пользователей прописать ссылку на файл ibases.v8i ведущую не в appdata, а на сервер. Мы делали на DFS шаре netlogon, все замечательно работало, файл хранился в 1 месте и читался при запуске 1cstart.exe (вроде так называется).
Sergey-S-Kovalev
20.01.2017 20:26Я наивно полагал, что тема прописывания баз уже давно закрыта :)
Легкое управление списками баз 1Сosipov_dv
20.01.2017 20:42Да, так и делали только еще в 2014 году, была тоже похожая тема. Нам было проще — не требовалось прятать базы. Очень прикольно, что можно добавлять базы руками персонально. (для разрабов было полезно)
rub_ak
20.01.2017 15:37Пробывали туннели на D-Link DFL-860E гигабит не тянули (у нас правда весь трафик проходил (темное волокно)), перешли на самосборные железки на базе mitx корпуса, сетевушек intel, и процессора i5 (а потом когда появились i3 с aes-ni на них), и ubuntu server с openvpn (тут пришлось тюненговать: размеры пакетов, буферы, и тд).
PS ещё на винде помогает отключение на сетевушках RSS и чего-то ещё. (пользователи жаловались, что XP быстрей работало)
avelor
20.01.2017 16:11у 860e согласно офф.сайту 60 мегабит максималка в впн-е. с дуплексом — пополам.
а вот 870й интереснее, читаю про него.rub_ak
20.01.2017 17:59Не обратил внимания что писалось про 870, и честно говоря не знал что новая dfl вышла, мы когда делали туннели была только 860
avelor
20.01.2017 18:12недавно вышла, 860 с производства сняли. якобы зверь-машина:) пока вопрос насколько стабильно там работает WW-прошивка с нормальным шифрованием…
rub_ak
20.01.2017 22:28Когда нам понадобился туннель на 1Gb, цена была 250к рублей (cisco asa подходила и была одной из дешевых, это был 2013Год. Может и другие были, но из известных брендов дешевле не нашли.)
Но нам даже понравилось, поставили бесплатный ESXI и несколько виртуалок подняли, потом туда ещё один туннель добавился на 1Gb.
Jump
20.01.2017 16:39А не проще ли было вместо выноса баз на далекий забугорный сервер вынести их на обычный сервер, с зашифрованными дисками?
KonstantinSpb
20.01.2017 18:11Да, тем более есть удобное решение https://wiki.recompile.se/wiki/Mandos
antonzubkoff
20.01.2017 16:46Делал подобное пару лет назад. Mikrotik + EoIP + RemoteApp для решения проблем со скоростью работы толстого клиента. Никаких костылей и танцев с бубнами.
Gring76
20.01.2017 17:22Я для таких целей поднимаю OpenVpn. Железки стОят в несколько раз дешевле, под любые платформы. Хоть роутинг, хоть bridge…
Производительность устраивала.
P/S Не увидел упоминания о SQL. 1С без него работает, в файловом режиме?evgeniusu
21.01.2017 14:45+1. Интересно. У нас пока опыт не очень. Hetzner + Proxmox (W2k8 (терминальный) + AD SMB файловый сервер с LUKS) + OpenVPN (пинг 30-40мс). Парочка файлових баз, 2 юзера. Жалуются, что тормозит.
malbaron
22.01.2017 02:14Парочка файлових баз, 2 юзера.
Терминальный сервер Windows и файловую базу данных нужно ставить одну и ту же машину
Или посмотреть что там со скоростью между файловым сервером и терминальным.
Файловые БД очень требовательны к сети.
Еще может быть все плохо из-за медленного интернета на клиентских машинах.
P.S.:
На двух пользователях не должно тормозить.
=============================================
Короче:
Локализовать проблему:
1. Файловый сервер и терминальный сервер?
2. Терминальный сервер и клиенты?
3. Возможно, слишком дешевый тарифный план?
rPman
20.01.2017 18:28Пробовал ли кто-нибудь поднимать локальное read/lazy write кеширование для сетевого диска, расположенного за большими пингами, в реальной рабочей обстановке?
в конце концов, даже если необходимость сохранения консистентности базы после внезапного отключения интернета, потребует сохранение локального кеша (например в карманном сервере на базе смартфона), это лучше чем получить жестокие тормоза во время формирования отчетов.
speaktr
20.01.2017 22:01У меня так: на российском конце ZyXEL ZyWALL USG 50, на европейском конце: арендованный физический сервер, на котором установлен VMWare ESXi, в котором три виртуалки: Mikritik RouterOS как шлюз и второй край VPN, сервер 1С: Предприятие (на ubuntu), apache (там же), PostgreSQL (там же), и еще я туда их почтовик на zimbra засунул. 1С опубликована как WEB-приложение.
В таком режиме работает 25 человек.
Если уж говорить про немецкий ДЦ то это, скорее всего, Hetzner. С ним есть некоторые трудности:
1) Чтобы поставить VMWare — надо заказывать LARA-консоль за отдельные 21 евро.
2) Если что-то с железом — надо опять же заказывать LARA-консоль за те же деньги.
3) Я брал сервер с 2-мя SSD по 600Gb и RAID-контроллером. Они НЕ гарантируют новых дисков (даже скорее всего — они будут не новые), в результате через 8 месяцев у меня сдохли SSD, при чем с разницей в 24 часа, едва успел содрать образ виртуалки с 1С. Сохранность данных никто не гарантирует, бесплатно они могут только заменить диск. При этом они меняют диск не на новый, а на б/у. За отдельные деньги они меняют диск на «диск с гарантированным временем работы не более 10 000 часов», что-то вроде 30 евро за диск, или 15, не помню уже. Так что, если нет бэкапов образов операционок — то это к скорой переустановке всех осей.
cbone
20.01.2017 22:43+2Проблему с тормозами решит только RDP, если используется толстый клиент. Хоть 10 ГБит канал будет, если таймауат пинга высокий — не решит проблем.
Как-то раз с коллегами дебажили медленную работу толстого клиента 1С, запущенного в Москве, а сервер находился в Челябинске (около 2000 км). Провайдерский L2VPN с гарантированными 100 МБит/c. Таймаут пинга из Чел до Мск в районе 23-28 мс. Локально — 1 мс. В итоге проведение одной и той же операции из разных локаций отличалось ровно во столько раз, во сколько отличается таймаут. Дальнейший анализ трафика WireShark'ом показал, что толстый клиент отправляет пакет -> ждёт -> получает ответ -> отправляет следующий пакет -> и так далее…
Тестировани на 8 версии 1С.
beho1der
21.01.2017 08:30Да все правильно, толщина канала никак не поможет, автору надо снять загрузку полосу, смысла расширять полосу если она не загружена на 90% нету. Для ускорения работы 1С два варианта или терминальный сервер или максимальное использование тонкого клиента 1С.
ondys
21.01.2017 09:20Делали такое недавно для своего клиента, только он перенес ВСЮ свою серверную инфраструктуру к нам в ДЦ + арендовал несколько серверов
туннели держат пара Cisco 2921, для пользователей переезд незаметно прошел (переносили в выходные)
AndreyUA
21.01.2017 11:05Не поймите неправильно, но намеренно покупать DFL — это такой способ мазохизма? Мне достался по наследству 260E и все прелести владения и управления dfl я прочувствовал всем телом. И уж точно не купил железку для увеличения производительности. Посмотрите в сторону Mikrotik, если бюджет ограничен.
dimskiy
21.01.2017 11:05DFL там уже был изначально. Исторически )
Pirosmani
22.01.2017 23:09Дело тут не DFL — можете даже не пробовать. У меня точно такая же ситуация — 1С, немецкий серверораздаватель (тот же самый скорее всего на букву Хе), VPN. В аренде пару серверов, есть и DFL и микротик. Есть несколько мест (территориально) с различными точками входа каналов из Германии в Россию. Если коротко — канал для моих серверов обрезан до 10Мбит на поток именно в Россию, ну или в те места где я могу тесты проводить. Проверяется все просто — iperf или подобное, если есть физический доступ к серверам на обоих концах. Как понял что обрезается именно только в мою сторону — брал браузерные измерители скорости с возможностью выбора сервера, они есть и многопоточные и однопоточные. Я про это на форуме Гилева подробно все описывал. Общался по этому поводу с техподдержкой и немецкой и русской (один из серверов куплен у реселлера) — броня железобетонная, «у нас все ок». Смысл в этом ограничении я не вижу — возможно забыли снять когда с чем-то боролись. Дело не в этом — 10 Мбит тоже не мало — почему 1С не хватает. Причем есть базы самописные и легкие — там вобщем терпимо (грешили на впн, купили микротик)), но если работать со старыми стандартными конфигурациями 1С типа Бух2 или Торг10 — то совсем плохо. У меня ничего не получись поправить — потихоньку переезжаю обратно в Россию, тем более что цены уже сопоставимы.
avelor
23.01.2017 12:41сталкивался с похожей байдой, тоже грешил на хе и на провайдеров… оказалось проблема в виндовом стеке.
если вы вдруг на серверах под управлением вин2008+ сделали netsh int tcp set global autotuninglevel=disabled, они радостно считают, что у них гигабит и через ван работают паршиво (около 10мегабит как раз выходит). ставим netsh int tcp set global autotuninglevel=enabled (если у вас в инфраструктуре нет 2003 винды) — получаете нормальную скорость (на канале сто мегабит — сто мегабит). если есть 2003-е вёнды — netsh int tcp set global autotuninglevel=highlyrestricted — тогда будет чуть меньше, но всё равно приемлемо (где-то около 80 мегабит).
ну и помните, что микротики без криптомодулей в впн-е не особо производительны.Pirosmani
25.01.2017 13:02Спасибо за совет, действительно — стало намного лучше (до почти предела офисного канала 30 м/бит). Странно, что тормоза остались — на глаз заметно, но проблему не решает… Осталось так попробовать — зажать где-то на близком сервере сетевую до 10м/бит и посмотреть результат… Микротики с модулем конечно…
avelor
25.01.2017 13:06проглядел про бух2 и торг10.
в режиме толстого клиента будет тормозить ещё и из-за пинга, как уже писали. только в режиме тонкого клиента, ну или доставлять приложение любым удобным способом (remoteapp, xenapp, ulteo, etc)Spalf
26.01.2017 18:59БП 2.0 и УТ 10.3 не поддерживают управляемые формы и следовательно работу в тонком клиенте.
Кроме того я бы не сказал что тонкий клиент в обычном режим (не через HTTP) менее требовательный к соединению чем толстый.
Так что RemApp и аналоги это единственный приемлемый вариант.avelor
26.01.2017 19:55БП 2.0 и УТ 10.3 не поддерживают управляемые формы и следовательно работу в тонком клиенте.
именно про это я и написал)
Кроме того я бы не сказал что тонкий клиент в обычном режим (не через HTTP) менее требовательный к соединению чем толстый.
ощутимо менее требовательный, особенно к latency. ну по крайней мере, в моей практике на относительно тонких каналах с относительно высоким пингом тонкий клиент в обычном режиме выручал.
а вот если нужен именно толстый, тут да, или доставлять приложение, так или иначе (remoteapp, ulteo, xenapp, etc), или пускать на полноценный терминал.
malbaron
25.01.2017 12:23Дело не в этом — 10 Мбит тоже не мало — почему 1С не хватает
Терминальному серверу хватает. При чем здесь 1С?
Или вы базу по сети гоняете????????
10 мегабит по сети 1С — мало.Pirosmani
25.01.2017 12:57Базу по сети гоняем. Понятно что мало — не понятно почему… Медленная работа она выражается в не том, что отчеты долго формируются или какие-то большие выборки передаются, а в банальном открытии формы. Т.е. выглядит это так — тык на документ, 2-3 сек паузы, Открывается форма документа с пустыми табличными частями, 1-2 сек пауза — заполняются табличные части. Ок, может быть там последовательные запросы, вопрос-ответ и т.д., но почему когда в базу удаленно заходим конфигуратором, когда просто читается конфигурация, утилизация канала 1 процент. Где 10 м/бит?
malbaron
25.01.2017 16:22Так ведь там не только скорость, там еще и задержки сети и пр. и пр.
Почему мало — понятно — почти каждое действие подразумевает не просто линейное чтение, а, напротив, множественные чтения из совсем разных мест, а также и многочисленные блокировки таблиц с данными, которые только уменьшают скорость.
10 мегабит было мало даже 3 пользователям на старой версии 1С V7
Что уж про сейчас говорить.avelor
25.01.2017 17:241с 7.7 была более требовательна к каналу и к железу всех участников работы.
а в 8.х уже придумали тонкий клиент\веб клиент для работы в том числе и через WAN.
одна проблема — в 11 торговле нет порционного учета, а от бух-ии 3.0 бухи сходят с умаmalbaron
25.01.2017 17:271с 7.7 была более требовательна к каналу и к железу всех участников работы.
а в 8.х уже придумали тонкий клиент\веб клиент для работы в том числе и через WAN.
Уж что что, а к железу V8 ничуть не менее требовательная.
К оперативке и процессору. Хотя бы за счет более навороченного интерфейса.
Насчет тонкого клиента — эта возможность не включается автоматически и возможен не на всех конфигурациях.
Но в обсуждаемой проблеме да, стоило бы попробовать как будет с тонким клиентом.
а от бух-ии 3.0 бухи сходят с ума
Исключительно дело привычки.
Функционал там весь тот же есть.avelor
25.01.2017 17:35у 7.7 была такая фишка — что если хоть один из компов клиентов тугой, тупить начинают все. в 8ке этого нет (ну если не свалится в блокировки конечно).
Исключительно дело привычки.
согласен. ну уже не раз и не два звонили люди в ужасе, обновив случайно до 3.0. впрочем, кому-то даже нравится, но их, по крайней мере у меня, меньшинство:)malbaron
25.01.2017 19:22у 7.7 была такая фишка — что если хоть один из компов клиентов тугой, тупить начинают все. в 8ке этого нет (ну если не свалится в блокировки конечно).
В любом случае — я бы не стал ставить сервер за несколько тысяч километров и гонять туда-сюда файлами.
Есть терминальный сервер Windows, есть веб-клиент 1С.
Они прекрасно решают в данном случае проблему с производительностью.
avelor
21.01.2017 18:52если не секрет, в чем у вас возникли сложности с DFL?
AndreyUA
21.01.2017 19:47Нестабильная работа pptp сервера, часто клиенты отваливаются и подключаются не сразу. Своеобразный интерфейс управления, который выносит мозг. Нормально логи не посмотреть. Периодически его нужно перезагружать, а это железка корпоративного уровня!
avelor
21.01.2017 20:09да, интерфейс непривычный. особенно тяжко переходить со старой прошивки на свежие (или WW) где его перерисовали. зато добавили очень много вкусного, вроде сниффера (раньше был только в консоли) и всяких SSL-VPN.
а вот с остальным не соглашусь, с микротиками я больше глюков ловил, впрочем от софтварного роутера много и не требуется:)
к слову, если освоить консоль DFL, всё становится проще и логичнее, в том числе и веб-интерфейс.
n1mda
21.01.2017 11:05Уважаемый ТС, я бы рекомендовал Вам немного другой путь. «Мой друг» сделал так:
купил б\у сервер с двумя ксеонами на 2.4 по 8 ядер и 64 Gb RAM и с дисками в raid10, такими, что бы хранилище было 2-4 Тб. Он ставится в ДЦ и он является шлюзом для уже существующего сервера 1с, точнее гипервизора, внутри которого первая ВМ это терминальный сервер, а вторая уже сама 1с с SQL базами. Между собой у них простой аплинк витой пары. Заказал VPS за меньше 1тр. В\на ближайшей к нам стране и поднял там OpenVPN сервер. Б\у сервер из ДЦ и сервер из офиса подключаются как клиенты на сервер, 1c запускаетс как ремоутапп. Тем кому надо с ноутов заходить, у тех приложение openvpn для Windows. И еще пару моментов:
1. Сервера в ДЦ на одно доверенное лицо, в\на другой стране, на второе лицо.
2. В настройках подключения ремоутапа стоит адрес из ИХ локальной сети, но этот адрес весит на шлюзе альясом и просто днатится в нужном направлении.
PS В последнее время, ребята которые приходят по таким делаем, стали намного умнее.
VahMaster
21.01.2017 20:26для уверенности, что на удаленной площадке никто не заберет данные можно настроить Shielded VM а HGS сервер у клиента в офисе расположить
malbaron
22.01.2017 02:08Технически все просто с этим — о чем тут писать-то?
Перенесли базы данных на другой сервер? Типовая задача.
На моей практике, многие хотят, но опробовав скорости — возвращаются.
Хотя, может в вашем случае очень хороший канал и повезло.
Не совсем понимаю — зачем так?
Вполне можно и локально хранить и шифровать.
А сохранность баз данных обеспечивают ровно те же меры, которые используются для противостояния пожарам и т.п. — бэкапы и резервные сервера на другой площадке.
В добыстроинтернетную эпоху дешевого хостинга еще бытовали методы: «замуровать сервер в месте, которое неизвестно даже админу». По кабелям же — хрен найдешь.DrPass
22.01.2017 02:19Не совсем понимаю — зачем так?
Вполне можно и локально хранить и шифровать.
А сохранность баз данных обеспечивают ровно те же меры, которые используются для противостояния пожарам и т.п. — бэкапы и резервные сервера на другой площадке.
Ну да, только надо все мощности задублировать. А кроме того, и на другой площадке в этой же стране они тоже могут уехать в безоблачные дали на машине с мигалкой. Вы думаете, полицаи, приехав к вам с проверкой, не в состоянии посмотреть ваши договора аренды?
А если резервная площадка как положено, за границей, то вполне логичный вопрос, зачем вам тогда вообще иметь серверное хозяйство локально?
Да и шифрование, штука так себе. Я не уверен, что ваш админ откажет в удовольствии товарищу майору расшифровать данные, в ответ на предложение посидеть в обезьяннике с уголовниками. Прелесть хранения серверов за границей как раз в том, что при проверке вашего предприятия никто не догадается, что они у вас вообще есть.malbaron
22.01.2017 03:23Вы думаете, полицаи, приехав к вам с проверкой, не в состоянии посмотреть ваши договора аренды?
В чем проблема оформлять аренду на других, если уж вы занимаетесь настолько рисковым бизнесом?
Даже целые предприятия и банковские счета оформляют на других для «оптимизации налогов» — это сплошь и рядом.
Размещение серверов локально в большинстве случаев дешевле и быстрее оно работает.
Я не уверен, что ваш админ откажет в удовольствии товарищу майору расшифровать данные, в ответ на предложение посидеть в обезьяннике с уголовниками.
Какая разница — рассказать пароль к ключу шифрования или рассказать пароль к хостингу?
Прелесть хранения серверов за границей как раз в том, что при проверке вашего предприятия никто не догадается, что они у вас вообще есть.
Правда?
Вы считаете других людей настолько тупыми, что они поверят, что у вас вообще нет данных?
А когда обнаружится, что данных нет — все так же предложат посидеть в обезъяннике вполне известным должностным лицам — админу, гл. буху, зам.дира, директору.
DrPass
22.01.2017 17:49В чем проблема оформлять аренду на других
В том, что этим другим надо платить как минимум «чёрным налом», и иметь какие-то гарантии, что их с такой стрёмной деятельностью не накроют ещё раньше, чем вас.
если уж вы занимаетесь настолько рисковым бизнесом?
Что значит «настолько рисковым»? Это касается любого бизнеса, даже с абсолютно белой и чистой деятельностью. Проверять законность вашей деятельности контролирующие органы будут после конфискации оборудования, а не до неё. А вам, если вы бизнесмен, нужно предотвращать простой предприятия, а не устранять его последствия.
Даже целые предприятия и банковские счета оформляют на других для «оптимизации налогов»
То, что вы назвали — это уже экономические преступления, а не оптимизация налогов. Это немного несравнимые вещи с арендой серверов в Германии.
Какая разница — рассказать пароль к ключу шифрования или рассказать пароль к хостингу?
Вы всерьёз не понимаете элементарных вещей?
а) Пароль к хостингу можно десять раз поменять, в отличие от ключей к компьютеру, который лежит опечатанный на полицейском складе.
б) Любые данные с хостинга можно удалить, или вообще временно погасить удаленные серверы.
в) Наконец, о существовании какого-то хостинга с бизнесовыми базами данных вообще можно не рассказывать.
Правда?
Вы считаете других людей настолько тупыми, что они поверят, что у вас вообще нет данных?
Ну вот вы хотя бы себя возьмите в качестве примера. Вы взрослый человек, и специалист в какой-то сфере, наверняка не глупый. Но вам даже в голову не пришло, что можно поставить сервер-болванку для отвода глаз, и даже скопировать туда копию «белой» 1С-бухгалтерии, это простое и копеечное решение. Почему вы думаете, что оперативники будут умнее, особенно если учитывать, что зарплаты ИТшников не в органах намного выше, и хорошие спецы идут в другие организации?
Я меньше года назад пережил маски-шоу в своей компании. Я ещё долго буду вспоминать бригаду полицейских ИТ-специалистов. Один из них сел за мой компьютер, и глядя на приглашение ввода пароля, изрёк: «У них все компьютеры соединены в одну сеть, как у нас. База может быть где угодно!»
А вы говорите, не тупые.
Сняли у нас винты в бухгалтерии, забрали тестовый сервер. Через месяц вернули, в той же упаковке. Т.е. даже не притрагивались. И что бы мы месяц делали, не будь у нас продакшена на серверах за границей?F1RST
23.01.2017 09:43Тут вопрос частности. Это к вам такие специалисты приходили. Я работал с другими, особенно хорошее мнение сложилось о сотрудниках ФСБ, курирующих защищенную часть сети.
Sergey-S-Kovalev
24.01.2017 08:26Почему вы думаете, что оперативники будут умнее, особенно если учитывать, что зарплаты ИТшников не в органах намного выше, и хорошие спецы идут в другие организации?
Я меньше года назад пережил маски-шоу в своей компании. Я ещё долго буду вспоминать бригаду полицейских ИТ-специалистов. Один из них сел за мой компьютер, и глядя на приглашение ввода пароля, изрёк: «У них все компьютеры соединены в одну сеть, как у нас. База может быть где угодно!»
А вы говорите, не тупые.
Частности. Везде частности. К сожалению, большинство случаев с изыманием техники это когда приезжают с деструктивной целью остановить процессы. Почти всегда это делается конечными исполнителями на от##ись. Изъяли, но не нашли, не обнаружили, руководству доложили и все. Без заморочек. Месяц постояло это в углу, потом вернули.
Однако у каждого такого подразделения, есть связи с тем или иным аутсорсером, который предоставляет экспертизу, это афишируется почти никогда. Когда реально нужно найти — их приглашают осмотреть и сделать заключение. Если те находят малейшие намеки на удаленные сервисы или то что нужно, то все сотрудники организации берутся в разработку, и как следствие так или иначе находят.
Стоит одному сказать, что база где то там и кто именно в реальности ИТшник, то ИТшник тут же попадает в такие клещи, что через некоторое время нервы кончаются и приоритет ценностей меняется. Свой попец всегда дороже и присесть вместо своего работодателя никто не хочет. Причем причиной могут быть не только «рабочие» вопросы, обыск дома по доносу от бабушки живущей через два дома вполне себе причина. Был бы человек в разработке, а статья найдется.DrPass
24.01.2017 11:54Частности. Везде частности. К сожалению, большинство случаев с изыманием техники это когда приезжают с деструктивной целью остановить процессы.
Естественно, частности. Серебряную пулю от всех демонов никто не предлагает. Но в подавляющем большинстве случаев всё именно так. И если мы говорим об общей ситуации, т.е. когда компания находится не глубокой криминальной проработке, а является обычным бизнесом без серьёзных нарушений, куда приехали, просто проходясь по цепочке контрагентов, или по заказу конкурентов, то такие механизмы защиты вполне сработают. Никто не будет бить резиновой дубинкой админа в карцере, выпытывая у него неизвестные технические подробности.Sergey-S-Kovalev
24.01.2017 12:50Тогда нет смысла ехать сразу в Германию, поднять инфраструктуру на площадке в ближайшем и удобнейшем ЦОДе, и бэкапить ее на внешнюю площадку в Германии. Если начался прям ахтунговый ахтунг, когда насели даже на провайдера услуг ЦОД — то развернуть площадку из бэкапов при грамотном планировании — пара часов делов.
DrPass
24.01.2017 12:58Можно и так, абсолютно нормальный вариант. Вопрос в том, что дешевле — держать все мощности тут и что-то резервное там, вместе с планом аварийного подъема на новой площадке, или сразу туда всё отправить. В плане удобства, честно говоря, обычно нет разницы между администрированием виртуальной машины на расстоянии пяти километров или на расстоянии пяти тысяч километров.
С другой стороны,насели даже на провайдера услуг ЦОД
— тоже немалый и лишний риск. У меня в 2009-м году был случай, когда из местного ЦОД утащили мой сервер, просто потому, что изымали оборудование одной фирмы, а попутно вынесли всё, что было в ЦОДе.Sergey-S-Kovalev
25.01.2017 08:39Встречный, вполне резонный, вопрос: вот вы держите инфраструктуру в одном ЦОДе и живете в полной уверенности, что этот ЦОД обеспечит Вам 100% доступность всегда навсегда? Или таки бэкапы территориально распределенные таки должны существовать? Ну а дальше все прыгают от RPO/RTO — чем меньше нужно потерять и чем быстрее оживить — тем бОльшая обоснованность держать холодный резерв инфраструктуры в другом ЦОД.
DrPass
25.01.2017 11:15Встречный, вполне резонный, вопрос: вот вы держите инфраструктуру в одном ЦОДе и живете в полной уверенности, что этот ЦОД обеспечит Вам 100% доступность всегда навсегда?
Я держу в одном ЦОД, я не жду от него 100% доступности, т.к. это не требуется для нашего бизнеса, ибо восстановление основных сервисов в течении нескольких часов — для нас вполне достаточный SLA. В принципе, подобная же схема подходит для подавляющего большинства предприятий. А так, что бэкап не нужно держать там же, где и резервируемые данные, это прописная истина :)
malbaron
25.01.2017 12:37Сняли у нас винты в бухгалтерии, забрали тестовый сервер. Через месяц вернули, в той же упаковке. Т.е. даже не притрагивались. И что бы мы месяц делали, не будь у нас продакшена на серверах за границей?
А если бы у вас пожар был бы?
Или сервер сдох бы, а место на бэкапном томе закончилось в прошлом месяце?
Или RAID-контроллер сдох бы, а заказывать такую модель нужно и ждать его неделю?
;)
Маски-шоу вот ничем не отличается от других сбоев.
И методы защиты — все те же.
Второй сервер в другом месте, репликация, свежие бэкапы и т.п.
P.S.:
Выход из строя серверов (настоящее серверное железо, как положено) в моей практики встречался куда как чаще, чем маски-шоу.
И RAID-массивы разваливались и вирусы-шифровальщики встречались и пр.
А маски-шоу — на фоне этого большая редкость.
malbaron
25.01.2017 16:58В том, что этим другим надо платить как минимум «чёрным налом», и иметь какие-то гарантии, что их с такой стрёмной деятельностью не накроют ещё раньше, чем вас
Не выдумывайте ерунды.
Уж на аренду-то черного нала найти несложно.
Хоть из белой зарплаты директора, когда он её на руки получил.
Что значит «настолько рисковым»? Это касается любого бизнеса, даже с абсолютно белой и чистой деятельностью. Проверять законность вашей деятельности контролирующие органы будут после конфискации оборудования, а не до неё. А вам, если вы бизнесмен, нужно предотвращать простой предприятия, а не устранять его последствия.
Вы нам из каких годов пишете, из какой страны пишете?
Прежде всего начинают проверку с вежливого запрашивания бумажных документов.
В серьезных случаях — возможен приход маски-шоу с изъятием бумажных же документов.
Содержимое серверов — если конечно вы не порнобизнесом занимаетесь — не являются доказательствами.
Посему изъятие серверов в РФ в последние годы делают крайне редко…
Что значит «настолько рисковым»? Это касается любого бизнеса, даже с абсолютно белой и чистой деятельностью
Пожар, выход из строя железа сервера — относятся к ровно таким же проблемам.
И меры противодействия — примерно одинаковы — второй сервер на другой площадке, репликация, бэкапы.
То, что вы назвали — это уже экономические преступления, а не оптимизация налогов. Это немного несравнимые вещи с арендой серверов в Германии.
Отнюдь.
Если у меня 2 вида покупателей — с НДС и без НДС, то, вполне возможно, что мне удобнее иметь 2 разных юр. лица. С НДС же и без НДС.
И это законно.
Незаконно с этим перебарщивать.
а) Пароль к хостингу можно десять раз поменять, в отличие от ключей к компьютеру, который лежит опечатанный на полицейском складе.
Да напротив же.
Уничтожение ключей даже интернета не требует.
Это намного надежнее.
б) Любые данные с хостинга можно удалить, или вообще временно погасить удаленные серверы.
Современные методы шифрования таковы, что можно ничего не удалять — все равно вскроют через пару тысяч лет, когда лично вас это интересовать не будет.
Про «временно погасить»:
По этому поводу есть одна байка:
Как замурованный в стену сервер работал десятилетия…
;)
Для погашенного сервера остаются ярлыки, история подключений (в зависимости от типа подключения) и т.п. на клиентских компьютерах. После чего я бы начал с пристрастием задавать вопросы админу — а что это за странные IP-адреса.
Да и постоянный трафик на сервера за границу можно легко отследить.
в) Наконец, о существовании какого-то хостинга с бизнесовыми базами данных вообще можно не рассказывать.
Пока вас не начали спрашивать с пристрастием.
На самом деле — слабое место в любой системе защиты — это люди.
Но вам даже в голову не пришло, что можно поставить сервер-болванку для отвода глаз, и даже скопировать туда копию «белой» 1С-бухгалтерии, это простое и копеечное решение.
Обижаете. Это общеизвестный метод. Известный, думаю, и проверяющим.
Я даже знаю почему это не прокатывает. Проходили на практике. На актуализацию болванки очень быстро забивают. И когда приходит проверка, а вы демонстрируете «белую базу» полугодовой давности (при том, что работаете ежедневно).
А вы говорите, не тупые.
Сняли у нас винты в бухгалтерии, забрали тестовый сервер. Через месяц вернули, в той же упаковке. Т.е. даже не притрагивались. И что бы мы месяц делали, не будь у нас продакшена на серверах за границей?
У вас никто ничего не искал.
Это было «для галочки».
По настоящему ищут они по другому — повторюсь, просто разговаривают с пристрастием с админом, гл. бухом, зам. диром — всеми теми, кто может быть в курсе, но не является собственником.
И что бы мы месяц делали, не будь у нас продакшена на серверах за границей?
Вы уж извините, но… поскольку вы были настолько готовы, то не все чисто у вас.
Ну или явно это не РФ.
ОБЭПу по башке настучало правительство еще несколько лет назад — и все притихло. В РФ в последние годы нужно очень постараться, чтобы попасть на изъятие серверов (если речь идет о бухгалтерии).
Изымают прежде всего бумажные документы — так как именно они и являются доказательствами.DrPass
25.01.2017 20:58Не выдумывайте ерунды.
Уж на аренду-то черного нала найти несложно.
Его несложно найти в любом количестве. Но вы не слышали такой термин как «стоимость обналички». Чёрный нал не бесплатен. Даже если вы будете выводить его через зарплату директора, вы с него будете платить неслабые налоги. Поэтому на кой ляд предприятию такое удовольствие при наличии иных вариантов, вы все равно ответ дать не сможете.
Прежде всего начинают проверку с вежливого запрашивания бумажных документов.
Да? Где ж вы раньше были, я бы так и спросил у полиции: «Хде ваше вежливое запрашивание бумажных документов».
Содержимое серверов — если конечно вы не порнобизнесом занимаетесь — не являются доказательствами.
С чего это вдруг? Все материалы являются доказательствами. А по-вашему получается, что если контора работает вообще за чёрный нал без документов, то всё, она белая и пушистая. Ведь бумажных доказательств-то нет.
Уничтожение ключей даже интернета не требует.
Это намного надежнее
Конечно, не требует. Только они для этого должны быть где-то на каком-то носителе за пределами офиса, в котором они используются. Неожиданно как-то.
Я даже знаю почему это не прокатывает. Проходили на практике. На актуализацию болванки очень быстро забивают.
Да не надо на неё забивать, у любой конторы есть чистая белая бухгалтерия, с которой ведётся расчет с фискалами. Вот она и должна быть в офисе. Делать ежедневную реплику по расписанию как бы не есть проблема.
У вас никто ничего не искал.
Это было «для галочки».
По настоящему ищут они по другому
Я не говорю про «по-настоящему». Я говорю про простой предприятия при подобных прецедентах. Я подозреваю, что большинство подобных проверок делаются для галочки ради выполнения плана по оперативной проработке. Но это же не означает, что от них не надо застраховываться.
Вы уж извините, но… поскольку вы были настолько готовы, то не все чисто у вас.
Ничего крамольного, чего бы не было у всех других обычных предприятий. Ну т.е. если копнуть с пристрастием, можно найти какие-то проблемы с отчетностью и штрафануть на какую-то сумму, но оружием и наркотиками не торгуем.
Я просто не понимаю, зачем вы предлагаете всякие обходные варианты, если есть прямой и простой путь, который пока что является панацеей — держать серверы за границейmalbaron
25.01.2017 22:48Его несложно найти в любом количестве. Но вы не слышали такой термин как «стоимость обналички». Чёрный нал не бесплатен. Даже если вы будете выводить его через зарплату директора, вы с него будете платить неслабые налоги. Поэтому на кой ляд предприятию такое удовольствие при наличии иных вариантов, вы все равно ответ дать не сможете.
Для того, чтобы арендовать комнатку под второй сервер и оплатить там интернет?
Ну да, бешенные бабки.DrPass
26.01.2017 01:24Мы говорим о комнатке с сервером или о переносе серверной на другую площадку? Если у вас всего один сервер, арендовать его в стойке в любом датацентре всяко будет дешевле, чем арендовать под него комнату где-то.
malbaron
25.01.2017 22:55Я просто не понимаю, зачем вы предлагаете всякие обходные варианты, если есть прямой и простой путь, который пока что является панацеей — держать серверы за границей
Находится легко через ответственных людей (админ и пр.).
Через задушевный разговор с админом.
Если конторе простой действительно критичен, то ей нужен второй сервер с репликацией.
При этом чем он ближе находится, тем быстрее репликация.
Если устраивает скорость доступа и цена в датацентре Хетцнере — значит ставить у них, а не на соседней улице.
Реальную защиту или не защиту это не дает не больше и не меньше, чем сервер на соседней улице.
Слабина проявляется в людях. То есть ровно до тех пор пока админу не начали ломать пальцы.
Конечно, не требует. Только они для этого должны быть где-то на каком-то носителе за пределами офиса, в котором они используются. Неожиданно как-то
Его можно хоть в интернете хранить, если вы параноик настолько.
Он малюсенький.
malbaron
25.01.2017 17:07а) Пароль к хостингу можно десять раз поменять, в отличие от ключей к компьютеру, который лежит опечатанный на полицейском складе.
Что????????????????
А что они там делают?
Кто хранит ключ рядом с самими зашифрованными данными?
DrPass
25.01.2017 21:04Кто хранит ключ рядом с самими зашифрованными данными?
Ключ так или иначе будет где-то там, где его используют. И если у вас вся инфраструктура находится в офисе, то и ключи уедут на тот же склад вместе с хранилищем. Логично? Или вы ещё и е-токены предлагаете сотрудникам раздать?
bruges
22.01.2017 11:11Мой опыт такой. Физический сервер в Германии, во главу угла поставлена надежность, скорость на 2-м месте. Сервер софтрейдом 10 из SATA3 дисков, Centos установлен сотрудниками ДЦ. Виртуализация — KVM, под ней 2 виндовые вируталки: терминальные серверы в кластере. Роутером работает сам физический сервер. Каждый российский офис (12 шт.) имеет шлюзом локальный сервак, который коннектится через к немецкому openvpn-серверу. 1c 7.7 кастомная конфа, файловый вариант, 70 пользователей. Все работает быстро. Сейчас переползаем на 8ку с sql, думаю над апгрейдом железа.
Spalf
22.01.2017 11:11dimskiy кроме тормозов в 1С вы имеете реальную возможность получить битую 1С базу, даже с учетом того что используете клиент-серверный режим. Исходя из моего опыта 1С крайне плохо отрабатывает потери пакетов между клиентом и сервером.
А современные принтеры и МФУ на 2012R2 без всяких проблем пробрасываются RDP <— RDP <— клиент.
На 2008R2 не помню работало ли, сейчас нет возможности проверить.
Так что присоединяюсь к комментариям выше: настройте RDP на удаленном сервере, с RD-Gateway или через VPN. Но не гоняйте по сети между ДЦ данные 1С.
grumbler66rus
25.01.2017 11:47Скрипт с периодичностью запуска 5 минут — серьёзный костыль.
OpenVPN в режиме клиента умеет переключаться на любое количество резервных серверов (каналов) «из коробки». Таймауты настраиваются, пример из документации — одна минута. Что при этом важно — TCP внутри туннеля не рвётся.
Одна из причин, почему я не люблю IPSEC — я его настраивал для связки 2x2rPman
25.01.2017 23:45а как нужно настроить резервные сервера чтобы соединение клиента не рвалось? такое возможно только если у этих серверов шлюз один и тот же?
grumbler66rus
27.01.2017 01:39Самое простое — демон OpenVPN в режиме сервера на сервере с несколькими внешними интерфейсами слушaет все эти интерфейсы. В его конфиге задан ifconfig-pool-persist и каждый клиент получает постоянный IP.
У клиента несколько строк remote и настроены ping и ping-restart. Когда один канал падает, клиент подключается к следующему в списке remote и получает тот же самый адрес.
Пока идёт пересоединение, и клиент, и сервер не отвергают пакеты TCP. Только нужно настроить ping и ping-restart или keepalive на сервере и на клиенте так, чтобы TCP не успевало оборваться по таймауту, но не было ложных срабатываний, например:
keepalive 5 15 со стороны сервера.rPman
27.01.2017 10:47эхх, это очевидная реализация, к сожалению мало полезная. нужно дистанционно разделять сервера (разные провайдеры) иначе резервировать проблемы провайдеров не получается.
но логично что альтернатива — каждый сервер, должен быть отдельно быть подключен в общую сеть, а шлюз выхода либо один из них либо меняется но уже влияя на соединения клиентов.grumbler66rus
27.01.2017 11:22«дистанционно разделять сервера» — это территориально разнесённые площадки и означает, что клиент подключается к службам на разных серверах, тогда нет речи о сохранении соединения!
Если эти две площадки соединены линком, всё равно можно сделать один VPN-концентратор.
И всё же, IMHO нет проблем одну площадку подключить к разным операторам (каналам). У клиента тоже может быть несколько каналов, например, наземный и мобильный(е).
Если требуется сделать разные VPN-концентраторы для доступа к одному серверу, это тоже решается, но сильно костыльно:
— настраиваем у каждого VPN-концентратора так, что при задержках или пропадании связи с клиентом и/или падении канала файрвол блокировал ICMP с информацией о падении канала
— при подключении клиента на сервере изменяем маршрут к нему на ныне актуальный
— при отсутствии повторного подключения клиента в разумный срок генерируем пакет обрыва соединения TCP в сторону сервера.
IMHO проще настроить OpenVPN на самом сервере. Hint: OpenVPN нормально проходит через любое количество NAT.
grumbler66rus
27.01.2017 11:26но логично что альтернатива — каждый сервер, должен быть отдельно быть подключен в общую сеть, а шлюз выхода либо один из них либо меняется но уже влияя на соединения клиентов.
??? Не вижу логики.
Если серверы не связаны между собой сиречь независимы, это совсем другой случай.
Если серверы связаны, топологически нет никакой разницы, где они расположены территориально. Пока между ними работает связь, они могут быть хоть в одной стойке, хоть на разных континентах.rPman
27.01.2017 12:02Попробую разъяснить мою логику и кейс использования openvpn с несколькими серверами.
Провайдеры последней мили для частников да и для юриков по качеству связи на порядок отличаются от того интернета, что работает в датацентрах — это факт, доказанный практикой (по крайней мере в регионах)
Речь идет о подключении к vpn-серверам, по разным маршрутам, таким образом, чтобы при появлении проблемы на одном канале провайдера автоматически переключиться на другой (при необходимости можно точно так же использовать и на клиенте подключение к разным провайдерам).
p.s. последние три года с интернетом в России, по нарастающей, происходят просто катастрофические вещи, полагаю из-за неуклюжих попыток провайдеров исполнять указания по блокированию.
Я не говорю про доступ к заблокированному контенту, тут речь идет о периодических потерях связи до легитимных сайтов…
У меня уже стало нормой получить случайную ошибку например при чтении документации по tensorflow или открытии ролика youtube, провайдер в курсе но судя по реакции — поделать ничего не может (в общем у меня тариф дает хорошую связь томск -> москва, спидтест: 54 ms Download, 22.39 Mbps Upload, 91.26 Mbps и сотня гигабайт трафика лимиты в месяц плюс региональный безлимит), речь идет исключительно о связности, полагаю связь с популярными cdn серверами сломанаgrumbler66rus
27.01.2017 12:26Теперь понятно.
Если действительно нужна непрерывность соединения, делаем так:
Сервер 1 — VPNконцентратор
Серверы 2… осуществляют NAT на сервер1.
Получаем топологический аналог многоголового сервера.
inook
По голове получить не боитесь от государства?
iborzenkov
Ну так в частности поэтому и переносит :)
Один из пунктов ведения бизнеса в России кстати.
Lamaster
Пускай ссылка тут полежит, может кому-то пригодится
9,5 правил ведения безопасного IT-бизнеса в России
dimskiy
Ссылка, конечно, интересная, но и заграница не панацея. Например, вспомните проблемы из-за санкций.
Так-то ту статью можно описать одной фразой «не ведите бизнес в России», что несколько утрировано.
dimskiy
Заказчик явно знал что делает, да и было все это до обязанности хранить данные в РФ.
BigD
Да нет такой обязанности хранить данные «только» в РФ. А без слова «только» столько вариантов появляется…
BigD
За что именно?!