Pull to refresh

Comments 90

По голове получить не боитесь от государства?
Ну так в частности поэтому и переносит :)
Один из пунктов ведения бизнеса в России кстати.
Ссылка, конечно, интересная, но и заграница не панацея. Например, вспомните проблемы из-за санкций.
Так-то ту статью можно описать одной фразой «не ведите бизнес в России», что несколько утрировано.
Заказчик явно знал что делает, да и было все это до обязанности хранить данные в РФ.
Да нет такой обязанности хранить данные «только» в РФ. А без слова «только» столько вариантов появляется…
1Ска, в обертке RdpApp, прекрасно работает, я бы сказал — летает, на 10-15 юзерах на 1 тунель, при 10-15мбитах в тунеле (ipsec). Т.е — примерно по 1мбиту на юзера, основная нагрузка только при отправке на локальную печать. Остальная «неторпливость» — зависит уже от платформы, тюнинга субд, сервера, и прочих mtu :)
Неторопливая работа 1С из-за недостаточно производительного VPN, конечно, раздражает.

Пересадите их на терминальный сервер, который стоит в том же датацентре. Это решит все проблемы с производительностью интерфейса. Правда, добавит проблем тем клиентам, которые используют подключенное к 1С торговое оборудование, всякие ТСД, сканеры штрих-кодов и карт и т.д. Если они, конечно, есть.
можете написать значения ping до сервера через тунель (по внутреннему каналу) до него же только без туннеля?
Если не изменяет склерз, то задержки были в районе 30-40 мс
размер может оказаться не главное. 30-40 мс, до Германии это может быть напрямую. А добавляет ли канал свои задержки и какие? если будет возможность, посмотрите
Мне вот интересно, где вы такие мифы читаете, что туннель добавляет большие задержки? Современный софт на современном железе добавит максимум несколько мс при большой нагрузке и всё.

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 ms
причем здесь мифы?
есть решение, хочется узнать всесторонние подробности. Простое любопытство.
Пинг по тунелям: 109мс — из Владика, 10мс — Воронеж, 20мс — Краснодар (это разбросанные, дальние, от сервера города).
Пинг по их внешним адресам (города в том же порядке): 112мс, 10мс, 23мс
До 100мс — норм. Открытие диалогов, новых окон документов — происходит в ту же секунду, когда произошел клик, печать — к сожалению идёт с задержкой — до 5 секунд. У нас основной критерий — есть среднепаршивые нагруженные отчеты по базе (базы в районе 200гб) — их построение и вывод не должен занимать 5 сек. Для самых тяжелых — 15. Но это действительно тяжёлые отчеты. :)
Периодически у нас бываю жалобы, начинается тупняк в работе — решается чаще всего передергиванием туннеля, или игрой с mtu.
Но так, чтобы прямо на глаз было заметна разница между работой с базой локально и удалённо — заметно только на пингах выше 100.
Дело, я думаю, не в ширине канала, а в задержках до Германии. Так что смена VPN на гигабит с большой долей вероятности скорости не добавит.
Насколько я помню, начиная с версии 8.2 можно у пользователей прописать ссылку на файл ibases.v8i ведущую не в appdata, а на сервер. Мы делали на DFS шаре netlogon, все замечательно работало, файл хранился в 1 месте и читался при запуске 1cstart.exe (вроде так называется).
Да, так и делали только еще в 2014 году, была тоже похожая тема. Нам было проще — не требовалось прятать базы. Очень прикольно, что можно добавлять базы руками персонально. (для разрабов было полезно)
UFO just landed and posted this here
у 860e согласно офф.сайту 60 мегабит максималка в впн-е. с дуплексом — пополам.
а вот 870й интереснее, читаю про него.
UFO just landed and posted this here
недавно вышла, 860 с производства сняли. якобы зверь-машина:) пока вопрос насколько стабильно там работает WW-прошивка с нормальным шифрованием…
UFO just landed and posted this here
А не проще ли было вместо выноса баз на далекий забугорный сервер вынести их на обычный сервер, с зашифрованными дисками?
если мне не изменяет память, то eoip идет в открытую…
Да, тем более есть удобное решение https://wiki.recompile.se/wiki/Mandos
Делал подобное пару лет назад. Mikrotik + EoIP + RemoteApp для решения проблем со скоростью работы толстого клиента. Никаких костылей и танцев с бубнами.
Я для таких целей поднимаю OpenVpn. Железки стОят в несколько раз дешевле, под любые платформы. Хоть роутинг, хоть bridge…
Производительность устраивала.

P/S Не увидел упоминания о SQL. 1С без него работает, в файловом режиме?
+1. Интересно. У нас пока опыт не очень. Hetzner + Proxmox (W2k8 (терминальный) + AD SMB файловый сервер с LUKS) + OpenVPN (пинг 30-40мс). Парочка файлових баз, 2 юзера. Жалуются, что тормозит.
Парочка файлових баз, 2 юзера.


Терминальный сервер Windows и файловую базу данных нужно ставить одну и ту же машину
Или посмотреть что там со скоростью между файловым сервером и терминальным.
Файловые БД очень требовательны к сети.

Еще может быть все плохо из-за медленного интернета на клиентских машинах.

P.S.:
На двух пользователях не должно тормозить.

=============================================

Короче:

Локализовать проблему:

1. Файловый сервер и терминальный сервер?
2. Терминальный сервер и клиенты?
3. Возможно, слишком дешевый тарифный план?
Пробовал ли кто-нибудь поднимать локальное read/lazy write кеширование для сетевого диска, расположенного за большими пингами, в реальной рабочей обстановке?

в конце концов, даже если необходимость сохранения консистентности базы после внезапного отключения интернета, потребует сохранение локального кеша (например в карманном сервере на базе смартфона), это лучше чем получить жестокие тормоза во время формирования отчетов.
У меня так: на российском конце 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, не помню уже. Так что, если нет бэкапов образов операционок — то это к скорой переустановке всех осей.
Проблему с тормозами решит только RDP, если используется толстый клиент. Хоть 10 ГБит канал будет, если таймауат пинга высокий — не решит проблем.
Как-то раз с коллегами дебажили медленную работу толстого клиента 1С, запущенного в Москве, а сервер находился в Челябинске (около 2000 км). Провайдерский L2VPN с гарантированными 100 МБит/c. Таймаут пинга из Чел до Мск в районе 23-28 мс. Локально — 1 мс. В итоге проведение одной и той же операции из разных локаций отличалось ровно во столько раз, во сколько отличается таймаут. Дальнейший анализ трафика WireShark'ом показал, что толстый клиент отправляет пакет -> ждёт -> получает ответ -> отправляет следующий пакет -> и так далее…
Тестировани на 8 версии 1С.
Да все правильно, толщина канала никак не поможет, автору надо снять загрузку полосу, смысла расширять полосу если она не загружена на 90% нету. Для ускорения работы 1С два варианта или терминальный сервер или максимальное использование тонкого клиента 1С.
Делали такое недавно для своего клиента, только он перенес ВСЮ свою серверную инфраструктуру к нам в ДЦ + арендовал несколько серверов
туннели держат пара Cisco 2921, для пользователей переезд незаметно прошел (переносили в выходные)
Не поймите неправильно, но намеренно покупать DFL — это такой способ мазохизма? Мне достался по наследству 260E и все прелести владения и управления dfl я прочувствовал всем телом. И уж точно не купил железку для увеличения производительности. Посмотрите в сторону Mikrotik, если бюджет ограничен.
DFL там уже был изначально. Исторически )
И планируете купить тот же DFL?
Дело тут не DFL — можете даже не пробовать. У меня точно такая же ситуация — 1С, немецкий серверораздаватель (тот же самый скорее всего на букву Хе), VPN. В аренде пару серверов, есть и DFL и микротик. Есть несколько мест (территориально) с различными точками входа каналов из Германии в Россию. Если коротко — канал для моих серверов обрезан до 10Мбит на поток именно в Россию, ну или в те места где я могу тесты проводить. Проверяется все просто — iperf или подобное, если есть физический доступ к серверам на обоих концах. Как понял что обрезается именно только в мою сторону — брал браузерные измерители скорости с возможностью выбора сервера, они есть и многопоточные и однопоточные. Я про это на форуме Гилева подробно все описывал. Общался по этому поводу с техподдержкой и немецкой и русской (один из серверов куплен у реселлера) — броня железобетонная, «у нас все ок». Смысл в этом ограничении я не вижу — возможно забыли снять когда с чем-то боролись. Дело не в этом — 10 Мбит тоже не мало — почему 1С не хватает. Причем есть базы самописные и легкие — там вобщем терпимо (грешили на впн, купили микротик)), но если работать со старыми стандартными конфигурациями 1С типа Бух2 или Торг10 — то совсем плохо. У меня ничего не получись поправить — потихоньку переезжаю обратно в Россию, тем более что цены уже сопоставимы.
сталкивался с похожей байдой, тоже грешил на хе и на провайдеров… оказалось проблема в виндовом стеке.
если вы вдруг на серверах под управлением вин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 мегабит).

ну и помните, что микротики без криптомодулей в впн-е не особо производительны.
Спасибо за совет, действительно — стало намного лучше (до почти предела офисного канала 30 м/бит). Странно, что тормоза остались — на глаз заметно, но проблему не решает… Осталось так попробовать — зажать где-то на близком сервере сетевую до 10м/бит и посмотреть результат… Микротики с модулем конечно…
проглядел про бух2 и торг10.
в режиме толстого клиента будет тормозить ещё и из-за пинга, как уже писали. только в режиме тонкого клиента, ну или доставлять приложение любым удобным способом (remoteapp, xenapp, ulteo, etc)
БП 2.0 и УТ 10.3 не поддерживают управляемые формы и следовательно работу в тонком клиенте.
Кроме того я бы не сказал что тонкий клиент в обычном режим (не через HTTP) менее требовательный к соединению чем толстый.
Так что RemApp и аналоги это единственный приемлемый вариант.
БП 2.0 и УТ 10.3 не поддерживают управляемые формы и следовательно работу в тонком клиенте.

именно про это я и написал)
Кроме того я бы не сказал что тонкий клиент в обычном режим (не через HTTP) менее требовательный к соединению чем толстый.

ощутимо менее требовательный, особенно к latency. ну по крайней мере, в моей практике на относительно тонких каналах с относительно высоким пингом тонкий клиент в обычном режиме выручал.
а вот если нужен именно толстый, тут да, или доставлять приложение, так или иначе (remoteapp, ulteo, xenapp, etc), или пускать на полноценный терминал.
Дело не в этом — 10 Мбит тоже не мало — почему 1С не хватает


Терминальному серверу хватает. При чем здесь 1С?
Или вы базу по сети гоняете????????
10 мегабит по сети 1С — мало.
Базу по сети гоняем. Понятно что мало — не понятно почему… Медленная работа она выражается в не том, что отчеты долго формируются или какие-то большие выборки передаются, а в банальном открытии формы. Т.е. выглядит это так — тык на документ, 2-3 сек паузы, Открывается форма документа с пустыми табличными частями, 1-2 сек пауза — заполняются табличные части. Ок, может быть там последовательные запросы, вопрос-ответ и т.д., но почему когда в базу удаленно заходим конфигуратором, когда просто читается конфигурация, утилизация канала 1 процент. Где 10 м/бит?
Так ведь там не только скорость, там еще и задержки сети и пр. и пр.

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

10 мегабит было мало даже 3 пользователям на старой версии 1С V7
Что уж про сейчас говорить.
1с 7.7 была более требовательна к каналу и к железу всех участников работы.
а в 8.х уже придумали тонкий клиент\веб клиент для работы в том числе и через WAN.

одна проблема — в 11 торговле нет порционного учета, а от бух-ии 3.0 бухи сходят с ума
1с 7.7 была более требовательна к каналу и к железу всех участников работы.
а в 8.х уже придумали тонкий клиент\веб клиент для работы в том числе и через WAN.


Уж что что, а к железу V8 ничуть не менее требовательная.
К оперативке и процессору. Хотя бы за счет более навороченного интерфейса.

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

а от бух-ии 3.0 бухи сходят с ума

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

Исключительно дело привычки.

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


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

Есть терминальный сервер Windows, есть веб-клиент 1С.
Они прекрасно решают в данном случае проблему с производительностью.
если не секрет, в чем у вас возникли сложности с DFL?
Нестабильная работа pptp сервера, часто клиенты отваливаются и подключаются не сразу. Своеобразный интерфейс управления, который выносит мозг. Нормально логи не посмотреть. Периодически его нужно перезагружать, а это железка корпоративного уровня!
да, интерфейс непривычный. особенно тяжко переходить со старой прошивки на свежие (или WW) где его перерисовали. зато добавили очень много вкусного, вроде сниффера (раньше был только в консоли) и всяких SSL-VPN.
а вот с остальным не соглашусь, с микротиками я больше глюков ловил, впрочем от софтварного роутера много и не требуется:)
к слову, если освоить консоль DFL, всё становится проще и логичнее, в том числе и веб-интерфейс.
Уважаемый ТС, я бы рекомендовал Вам немного другой путь. «Мой друг» сделал так:
купил б\у сервер с двумя ксеонами на 2.4 по 8 ядер и 64 Gb RAM и с дисками в raid10, такими, что бы хранилище было 2-4 Тб. Он ставится в ДЦ и он является шлюзом для уже существующего сервера 1с, точнее гипервизора, внутри которого первая ВМ это терминальный сервер, а вторая уже сама 1с с SQL базами. Между собой у них простой аплинк витой пары. Заказал VPS за меньше 1тр. В\на ближайшей к нам стране и поднял там OpenVPN сервер. Б\у сервер из ДЦ и сервер из офиса подключаются как клиенты на сервер, 1c запускаетс как ремоутапп. Тем кому надо с ноутов заходить, у тех приложение openvpn для Windows. И еще пару моментов:
1. Сервера в ДЦ на одно доверенное лицо, в\на другой стране, на второе лицо.
2. В настройках подключения ремоутапа стоит адрес из ИХ локальной сети, но этот адрес весит на шлюзе альясом и просто днатится в нужном направлении.
PS В последнее время, ребята которые приходят по таким делаем, стали намного умнее.
Вообще вести бизнес на россии крайне глупо.
для уверенности, что на удаленной площадке никто не заберет данные можно настроить Shielded VM а HGS сервер у клиента в офисе расположить
Технически все просто с этим — о чем тут писать-то?
Перенесли базы данных на другой сервер? Типовая задача.

На моей практике, многие хотят, но опробовав скорости — возвращаются.
Хотя, может в вашем случае очень хороший канал и повезло.

Не совсем понимаю — зачем так?
Вполне можно и локально хранить и шифровать.

А сохранность баз данных обеспечивают ровно те же меры, которые используются для противостояния пожарам и т.п. — бэкапы и резервные сервера на другой площадке.

В добыстроинтернетную эпоху дешевого хостинга еще бытовали методы: «замуровать сервер в месте, которое неизвестно даже админу». По кабелям же — хрен найдешь.
Не совсем понимаю — зачем так?
Вполне можно и локально хранить и шифровать.

А сохранность баз данных обеспечивают ровно те же меры, которые используются для противостояния пожарам и т.п. — бэкапы и резервные сервера на другой площадке.

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


В чем проблема оформлять аренду на других, если уж вы занимаетесь настолько рисковым бизнесом?
Даже целые предприятия и банковские счета оформляют на других для «оптимизации налогов» — это сплошь и рядом.

Размещение серверов локально в большинстве случаев дешевле и быстрее оно работает.

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


Какая разница — рассказать пароль к ключу шифрования или рассказать пароль к хостингу?

Прелесть хранения серверов за границей как раз в том, что при проверке вашего предприятия никто не догадается, что они у вас вообще есть.


Правда?
Вы считаете других людей настолько тупыми, что они поверят, что у вас вообще нет данных?

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

В чем проблема оформлять аренду на других

В том, что этим другим надо платить как минимум «чёрным налом», и иметь какие-то гарантии, что их с такой стрёмной деятельностью не накроют ещё раньше, чем вас.
если уж вы занимаетесь настолько рисковым бизнесом?

Что значит «настолько рисковым»? Это касается любого бизнеса, даже с абсолютно белой и чистой деятельностью. Проверять законность вашей деятельности контролирующие органы будут после конфискации оборудования, а не до неё. А вам, если вы бизнесмен, нужно предотвращать простой предприятия, а не устранять его последствия.
Даже целые предприятия и банковские счета оформляют на других для «оптимизации налогов»

То, что вы назвали — это уже экономические преступления, а не оптимизация налогов. Это немного несравнимые вещи с арендой серверов в Германии.
Какая разница — рассказать пароль к ключу шифрования или рассказать пароль к хостингу?

Вы всерьёз не понимаете элементарных вещей?
а) Пароль к хостингу можно десять раз поменять, в отличие от ключей к компьютеру, который лежит опечатанный на полицейском складе.
б) Любые данные с хостинга можно удалить, или вообще временно погасить удаленные серверы.
в) Наконец, о существовании какого-то хостинга с бизнесовыми базами данных вообще можно не рассказывать.
Правда?
Вы считаете других людей настолько тупыми, что они поверят, что у вас вообще нет данных?

Ну вот вы хотя бы себя возьмите в качестве примера. Вы взрослый человек, и специалист в какой-то сфере, наверняка не глупый. Но вам даже в голову не пришло, что можно поставить сервер-болванку для отвода глаз, и даже скопировать туда копию «белой» 1С-бухгалтерии, это простое и копеечное решение. Почему вы думаете, что оперативники будут умнее, особенно если учитывать, что зарплаты ИТшников не в органах намного выше, и хорошие спецы идут в другие организации?
Я меньше года назад пережил маски-шоу в своей компании. Я ещё долго буду вспоминать бригаду полицейских ИТ-специалистов. Один из них сел за мой компьютер, и глядя на приглашение ввода пароля, изрёк: «У них все компьютеры соединены в одну сеть, как у нас. База может быть где угодно!»
А вы говорите, не тупые.
Сняли у нас винты в бухгалтерии, забрали тестовый сервер. Через месяц вернули, в той же упаковке. Т.е. даже не притрагивались. И что бы мы месяц делали, не будь у нас продакшена на серверах за границей?
Тут вопрос частности. Это к вам такие специалисты приходили. Я работал с другими, особенно хорошее мнение сложилось о сотрудниках ФСБ, курирующих защищенную часть сети.
Почему вы думаете, что оперативники будут умнее, особенно если учитывать, что зарплаты ИТшников не в органах намного выше, и хорошие спецы идут в другие организации?
Я меньше года назад пережил маски-шоу в своей компании. Я ещё долго буду вспоминать бригаду полицейских ИТ-специалистов. Один из них сел за мой компьютер, и глядя на приглашение ввода пароля, изрёк: «У них все компьютеры соединены в одну сеть, как у нас. База может быть где угодно!»
А вы говорите, не тупые.

Частности. Везде частности. К сожалению, большинство случаев с изыманием техники это когда приезжают с деструктивной целью остановить процессы. Почти всегда это делается конечными исполнителями на от##ись. Изъяли, но не нашли, не обнаружили, руководству доложили и все. Без заморочек. Месяц постояло это в углу, потом вернули.
Однако у каждого такого подразделения, есть связи с тем или иным аутсорсером, который предоставляет экспертизу, это афишируется почти никогда. Когда реально нужно найти — их приглашают осмотреть и сделать заключение. Если те находят малейшие намеки на удаленные сервисы или то что нужно, то все сотрудники организации берутся в разработку, и как следствие так или иначе находят.
Стоит одному сказать, что база где то там и кто именно в реальности ИТшник, то ИТшник тут же попадает в такие клещи, что через некоторое время нервы кончаются и приоритет ценностей меняется. Свой попец всегда дороже и присесть вместо своего работодателя никто не хочет. Причем причиной могут быть не только «рабочие» вопросы, обыск дома по доносу от бабушки живущей через два дома вполне себе причина. Был бы человек в разработке, а статья найдется.
Частности. Везде частности. К сожалению, большинство случаев с изыманием техники это когда приезжают с деструктивной целью остановить процессы.

Естественно, частности. Серебряную пулю от всех демонов никто не предлагает. Но в подавляющем большинстве случаев всё именно так. И если мы говорим об общей ситуации, т.е. когда компания находится не глубокой криминальной проработке, а является обычным бизнесом без серьёзных нарушений, куда приехали, просто проходясь по цепочке контрагентов, или по заказу конкурентов, то такие механизмы защиты вполне сработают. Никто не будет бить резиновой дубинкой админа в карцере, выпытывая у него неизвестные технические подробности.
Тогда нет смысла ехать сразу в Германию, поднять инфраструктуру на площадке в ближайшем и удобнейшем ЦОДе, и бэкапить ее на внешнюю площадку в Германии. Если начался прям ахтунговый ахтунг, когда насели даже на провайдера услуг ЦОД — то развернуть площадку из бэкапов при грамотном планировании — пара часов делов.
Можно и так, абсолютно нормальный вариант. Вопрос в том, что дешевле — держать все мощности тут и что-то резервное там, вместе с планом аварийного подъема на новой площадке, или сразу туда всё отправить. В плане удобства, честно говоря, обычно нет разницы между администрированием виртуальной машины на расстоянии пяти километров или на расстоянии пяти тысяч километров.
С другой стороны,
насели даже на провайдера услуг ЦОД
— тоже немалый и лишний риск. У меня в 2009-м году был случай, когда из местного ЦОД утащили мой сервер, просто потому, что изымали оборудование одной фирмы, а попутно вынесли всё, что было в ЦОДе.
Встречный, вполне резонный, вопрос: вот вы держите инфраструктуру в одном ЦОДе и живете в полной уверенности, что этот ЦОД обеспечит Вам 100% доступность всегда навсегда? Или таки бэкапы территориально распределенные таки должны существовать? Ну а дальше все прыгают от RPO/RTO — чем меньше нужно потерять и чем быстрее оживить — тем бОльшая обоснованность держать холодный резерв инфраструктуры в другом ЦОД.
Встречный, вполне резонный, вопрос: вот вы держите инфраструктуру в одном ЦОДе и живете в полной уверенности, что этот ЦОД обеспечит Вам 100% доступность всегда навсегда?

Я держу в одном ЦОД, я не жду от него 100% доступности, т.к. это не требуется для нашего бизнеса, ибо восстановление основных сервисов в течении нескольких часов — для нас вполне достаточный SLA. В принципе, подобная же схема подходит для подавляющего большинства предприятий. А так, что бэкап не нужно держать там же, где и резервируемые данные, это прописная истина :)
Сняли у нас винты в бухгалтерии, забрали тестовый сервер. Через месяц вернули, в той же упаковке. Т.е. даже не притрагивались. И что бы мы месяц делали, не будь у нас продакшена на серверах за границей?


А если бы у вас пожар был бы?
Или сервер сдох бы, а место на бэкапном томе закончилось в прошлом месяце?
Или RAID-контроллер сдох бы, а заказывать такую модель нужно и ждать его неделю?
;)

Маски-шоу вот ничем не отличается от других сбоев.
И методы защиты — все те же.
Второй сервер в другом месте, репликация, свежие бэкапы и т.п.

P.S.:
Выход из строя серверов (настоящее серверное железо, как положено) в моей практики встречался куда как чаще, чем маски-шоу.
И RAID-массивы разваливались и вирусы-шифровальщики встречались и пр.
А маски-шоу — на фоне этого большая редкость.
В том, что этим другим надо платить как минимум «чёрным налом», и иметь какие-то гарантии, что их с такой стрёмной деятельностью не накроют ещё раньше, чем вас


Не выдумывайте ерунды.
Уж на аренду-то черного нала найти несложно.
Хоть из белой зарплаты директора, когда он её на руки получил.

Что значит «настолько рисковым»? Это касается любого бизнеса, даже с абсолютно белой и чистой деятельностью. Проверять законность вашей деятельности контролирующие органы будут после конфискации оборудования, а не до неё. А вам, если вы бизнесмен, нужно предотвращать простой предприятия, а не устранять его последствия.


Вы нам из каких годов пишете, из какой страны пишете?

Прежде всего начинают проверку с вежливого запрашивания бумажных документов.
В серьезных случаях — возможен приход маски-шоу с изъятием бумажных же документов.
Содержимое серверов — если конечно вы не порнобизнесом занимаетесь — не являются доказательствами.

Посему изъятие серверов в РФ в последние годы делают крайне редко…

Что значит «настолько рисковым»? Это касается любого бизнеса, даже с абсолютно белой и чистой деятельностью


Пожар, выход из строя железа сервера — относятся к ровно таким же проблемам.
И меры противодействия — примерно одинаковы — второй сервер на другой площадке, репликация, бэкапы.

То, что вы назвали — это уже экономические преступления, а не оптимизация налогов. Это немного несравнимые вещи с арендой серверов в Германии.


Отнюдь.
Если у меня 2 вида покупателей — с НДС и без НДС, то, вполне возможно, что мне удобнее иметь 2 разных юр. лица. С НДС же и без НДС.
И это законно.
Незаконно с этим перебарщивать.

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


Да напротив же.
Уничтожение ключей даже интернета не требует.
Это намного надежнее.

б) Любые данные с хостинга можно удалить, или вообще временно погасить удаленные серверы.


Современные методы шифрования таковы, что можно ничего не удалять — все равно вскроют через пару тысяч лет, когда лично вас это интересовать не будет.

Про «временно погасить»:

По этому поводу есть одна байка:
Как замурованный в стену сервер работал десятилетия…
;)

Для погашенного сервера остаются ярлыки, история подключений (в зависимости от типа подключения) и т.п. на клиентских компьютерах. После чего я бы начал с пристрастием задавать вопросы админу — а что это за странные IP-адреса.

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

в) Наконец, о существовании какого-то хостинга с бизнесовыми базами данных вообще можно не рассказывать.


Пока вас не начали спрашивать с пристрастием.
На самом деле — слабое место в любой системе защиты — это люди.

Но вам даже в голову не пришло, что можно поставить сервер-болванку для отвода глаз, и даже скопировать туда копию «белой» 1С-бухгалтерии, это простое и копеечное решение.


Обижаете. Это общеизвестный метод. Известный, думаю, и проверяющим.

Я даже знаю почему это не прокатывает. Проходили на практике. На актуализацию болванки очень быстро забивают. И когда приходит проверка, а вы демонстрируете «белую базу» полугодовой давности (при том, что работаете ежедневно).

А вы говорите, не тупые.
Сняли у нас винты в бухгалтерии, забрали тестовый сервер. Через месяц вернули, в той же упаковке. Т.е. даже не притрагивались. И что бы мы месяц делали, не будь у нас продакшена на серверах за границей?


У вас никто ничего не искал.
Это было «для галочки».
По настоящему ищут они по другому — повторюсь, просто разговаривают с пристрастием с админом, гл. бухом, зам. диром — всеми теми, кто может быть в курсе, но не является собственником.

И что бы мы месяц делали, не будь у нас продакшена на серверах за границей?


Вы уж извините, но… поскольку вы были настолько готовы, то не все чисто у вас.
Ну или явно это не РФ.
ОБЭПу по башке настучало правительство еще несколько лет назад — и все притихло. В РФ в последние годы нужно очень постараться, чтобы попасть на изъятие серверов (если речь идет о бухгалтерии).
Изымают прежде всего бумажные документы — так как именно они и являются доказательствами.
Не выдумывайте ерунды.
Уж на аренду-то черного нала найти несложно.

Его несложно найти в любом количестве. Но вы не слышали такой термин как «стоимость обналички». Чёрный нал не бесплатен. Даже если вы будете выводить его через зарплату директора, вы с него будете платить неслабые налоги. Поэтому на кой ляд предприятию такое удовольствие при наличии иных вариантов, вы все равно ответ дать не сможете.

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

Да? Где ж вы раньше были, я бы так и спросил у полиции: «Хде ваше вежливое запрашивание бумажных документов».
Содержимое серверов — если конечно вы не порнобизнесом занимаетесь — не являются доказательствами.

С чего это вдруг? Все материалы являются доказательствами. А по-вашему получается, что если контора работает вообще за чёрный нал без документов, то всё, она белая и пушистая. Ведь бумажных доказательств-то нет.
Уничтожение ключей даже интернета не требует.
Это намного надежнее

Конечно, не требует. Только они для этого должны быть где-то на каком-то носителе за пределами офиса, в котором они используются. Неожиданно как-то.
Я даже знаю почему это не прокатывает. Проходили на практике. На актуализацию болванки очень быстро забивают.

Да не надо на неё забивать, у любой конторы есть чистая белая бухгалтерия, с которой ведётся расчет с фискалами. Вот она и должна быть в офисе. Делать ежедневную реплику по расписанию как бы не есть проблема.
У вас никто ничего не искал.
Это было «для галочки».
По настоящему ищут они по другому

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

Ничего крамольного, чего бы не было у всех других обычных предприятий. Ну т.е. если копнуть с пристрастием, можно найти какие-то проблемы с отчетностью и штрафануть на какую-то сумму, но оружием и наркотиками не торгуем.
Я просто не понимаю, зачем вы предлагаете всякие обходные варианты, если есть прямой и простой путь, который пока что является панацеей — держать серверы за границей
Его несложно найти в любом количестве. Но вы не слышали такой термин как «стоимость обналички». Чёрный нал не бесплатен. Даже если вы будете выводить его через зарплату директора, вы с него будете платить неслабые налоги. Поэтому на кой ляд предприятию такое удовольствие при наличии иных вариантов, вы все равно ответ дать не сможете.


Для того, чтобы арендовать комнатку под второй сервер и оплатить там интернет?
Ну да, бешенные бабки.
Мы говорим о комнатке с сервером или о переносе серверной на другую площадку? Если у вас всего один сервер, арендовать его в стойке в любом датацентре всяко будет дешевле, чем арендовать под него комнату где-то.
Я просто не понимаю, зачем вы предлагаете всякие обходные варианты, если есть прямой и простой путь, который пока что является панацеей — держать серверы за границей


Находится легко через ответственных людей (админ и пр.).
Через задушевный разговор с админом.

Если конторе простой действительно критичен, то ей нужен второй сервер с репликацией.
При этом чем он ближе находится, тем быстрее репликация.

Если устраивает скорость доступа и цена в датацентре Хетцнере — значит ставить у них, а не на соседней улице.
Реальную защиту или не защиту это не дает не больше и не меньше, чем сервер на соседней улице.

Слабина проявляется в людях. То есть ровно до тех пор пока админу не начали ломать пальцы.

Конечно, не требует. Только они для этого должны быть где-то на каком-то носителе за пределами офиса, в котором они используются. Неожиданно как-то


Его можно хоть в интернете хранить, если вы параноик настолько.
Он малюсенький.
а) Пароль к хостингу можно десять раз поменять, в отличие от ключей к компьютеру, который лежит опечатанный на полицейском складе.


Что????????????????
А что они там делают?
Кто хранит ключ рядом с самими зашифрованными данными?

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

Ключ так или иначе будет где-то там, где его используют. И если у вас вся инфраструктура находится в офисе, то и ключи уедут на тот же склад вместе с хранилищем. Логично? Или вы ещё и е-токены предлагаете сотрудникам раздать?
Мой опыт такой. Физический сервер в Германии, во главу угла поставлена надежность, скорость на 2-м месте. Сервер софтрейдом 10 из SATA3 дисков, Centos установлен сотрудниками ДЦ. Виртуализация — KVM, под ней 2 виндовые вируталки: терминальные серверы в кластере. Роутером работает сам физический сервер. Каждый российский офис (12 шт.) имеет шлюзом локальный сервак, который коннектится через к немецкому openvpn-серверу. 1c 7.7 кастомная конфа, файловый вариант, 70 пользователей. Все работает быстро. Сейчас переползаем на 8ку с sql, думаю над апгрейдом железа.
dimskiy кроме тормозов в 1С вы имеете реальную возможность получить битую 1С базу, даже с учетом того что используете клиент-серверный режим. Исходя из моего опыта 1С крайне плохо отрабатывает потери пакетов между клиентом и сервером.
А современные принтеры и МФУ на 2012R2 без всяких проблем пробрасываются RDP <— RDP <— клиент.
На 2008R2 не помню работало ли, сейчас нет возможности проверить.
Так что присоединяюсь к комментариям выше: настройте RDP на удаленном сервере, с RD-Gateway или через VPN. Но не гоняйте по сети между ДЦ данные 1С.
Скрипт с периодичностью запуска 5 минут — серьёзный костыль.
OpenVPN в режиме клиента умеет переключаться на любое количество резервных серверов (каналов) «из коробки». Таймауты настраиваются, пример из документации — одна минута. Что при этом важно — TCP внутри туннеля не рвётся.

Одна из причин, почему я не люблю IPSEC — я его настраивал для связки 2x2
а как нужно настроить резервные сервера чтобы соединение клиента не рвалось? такое возможно только если у этих серверов шлюз один и тот же?
Самое простое — демон OpenVPN в режиме сервера на сервере с несколькими внешними интерфейсами слушaет все эти интерфейсы. В его конфиге задан ifconfig-pool-persist и каждый клиент получает постоянный IP.
У клиента несколько строк remote и настроены ping и ping-restart. Когда один канал падает, клиент подключается к следующему в списке remote и получает тот же самый адрес.
Пока идёт пересоединение, и клиент, и сервер не отвергают пакеты TCP. Только нужно настроить ping и ping-restart или keepalive на сервере и на клиенте так, чтобы TCP не успевало оборваться по таймауту, но не было ложных срабатываний, например:
keepalive 5 15 со стороны сервера.
эхх, это очевидная реализация, к сожалению мало полезная. нужно дистанционно разделять сервера (разные провайдеры) иначе резервировать проблемы провайдеров не получается.

но логично что альтернатива — каждый сервер, должен быть отдельно быть подключен в общую сеть, а шлюз выхода либо один из них либо меняется но уже влияя на соединения клиентов.
«дистанционно разделять сервера» — это территориально разнесённые площадки и означает, что клиент подключается к службам на разных серверах, тогда нет речи о сохранении соединения!
Если эти две площадки соединены линком, всё равно можно сделать один VPN-концентратор.

И всё же, IMHO нет проблем одну площадку подключить к разным операторам (каналам). У клиента тоже может быть несколько каналов, например, наземный и мобильный(е).

Если требуется сделать разные VPN-концентраторы для доступа к одному серверу, это тоже решается, но сильно костыльно:
— настраиваем у каждого VPN-концентратора так, что при задержках или пропадании связи с клиентом и/или падении канала файрвол блокировал ICMP с информацией о падении канала
— при подключении клиента на сервере изменяем маршрут к нему на ныне актуальный
— при отсутствии повторного подключения клиента в разумный срок генерируем пакет обрыва соединения TCP в сторону сервера.
IMHO проще настроить OpenVPN на самом сервере. Hint: OpenVPN нормально проходит через любое количество NAT.
но логично что альтернатива — каждый сервер, должен быть отдельно быть подключен в общую сеть, а шлюз выхода либо один из них либо меняется но уже влияя на соединения клиентов.


??? Не вижу логики.
Если серверы не связаны между собой сиречь независимы, это совсем другой случай.
Если серверы связаны, топологически нет никакой разницы, где они расположены территориально. Пока между ними работает связь, они могут быть хоть в одной стойке, хоть на разных континентах.
Попробую разъяснить мою логику и кейс использования openvpn с несколькими серверами.

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

Речь идет о подключении к vpn-серверам, по разным маршрутам, таким образом, чтобы при появлении проблемы на одном канале провайдера автоматически переключиться на другой (при необходимости можно точно так же использовать и на клиенте подключение к разным провайдерам).

p.s. последние три года с интернетом в России, по нарастающей, происходят просто катастрофические вещи, полагаю из-за неуклюжих попыток провайдеров исполнять указания по блокированию.
Я не говорю про доступ к заблокированному контенту, тут речь идет о периодических потерях связи до легитимных сайтов…

У меня уже стало нормой получить случайную ошибку например при чтении документации по tensorflow или открытии ролика youtube, провайдер в курсе но судя по реакции — поделать ничего не может (в общем у меня тариф дает хорошую связь томск -> москва, спидтест: 54 ms Download, 22.39 Mbps Upload, 91.26 Mbps и сотня гигабайт трафика лимиты в месяц плюс региональный безлимит), речь идет исключительно о связности, полагаю связь с популярными cdn серверами сломана
Теперь понятно.
Если действительно нужна непрерывность соединения, делаем так:
Сервер 1 — VPNконцентратор
Серверы 2… осуществляют NAT на сервер1.
Получаем топологический аналог многоголового сервера.
Sign up to leave a comment.