Comments 16
А можно ли здесь вместо обсуждения статьи задать вопрос про выбор облачного хранилища? Дело в том, что мы начали использовать для определенных задач Яндекс-диск, но он не обеспечивает некоторые наши потребности (впрочем, не факт, что их вообще можно обеспечить каким-то "дешевым" способом). Чтобы не мешать обсуждению статьи (если такой вопрос тут все же офтопик)
сам длинный-предлинный вопрос убран под кат
Ситуация следующая. У нас есть самодельная программа, работающая с временными рядами. Она была написана очень давно, и в силу исторических причин представляет собой конгломерат из
СУБД временных рядов и пакета процедур анализа рядов данных, обернутых в проблемно-ориентированный интерфейс
Причем, кардинально в ней что-то менять у нас нет ни возможности, ни потребности, так как со своими функциями система справляется, а реализовать их на базе какой-то современной среды не так-то просто ввиду очень большого количества специфических опций. Да и не факт, что эта среда не вымрет через несколько лет, и нам не придется все заново переписывать. А фортран, хотя и неудобен в некоторых отношениях, но весьма эффективен в вычислительном плане и, по сравнению с большинством других сред, практически вечен ;-)
Изначально встроенная СУБД временных рядов была однопользовательской, так как все работало на самых первых персональных компьютерах, а о таких штуках, как будущий интернет, большинство советских программистов попросту еще не догадывалось (хотя сеть NSFNet в тот момент уже появилась).
Спустя некоторое время в наших институтах появились локальные сети. После чего авторы программы с удивлением обнаружили, что эту нашу персональную базу данных можно записать на один компьютер, а подключаться к ней совсем из другого места. Так как с точки зрения программы, она просто открывает файл на каком-то диске, и при этом совершенно не важно - локальный он или же сетевой.
Чтобы предотвратить конфликты, в БД был добавлен флаг "база занята", который проверяется/устанавливается при подключении юзера и снимается при его отключении. Сама база при этом по сути осталась однопользовательской, но работе это совсем не мешало, так как из-за специфики задач количество пользователей у каждой БД не превышало (и не превышает) нескольких человек, а непосредственный доступ к базе им нужен достаточно редко: только при обновлении/модификации данных либо при их загрузке в личное рабочее пространство (где и идут все расчеты).
Однако жизнь - штука непредсказуемая. И спустя еще какое-то время в дополнение к локальным сетям появились облачные сервисы. После чего авторы программы с удивлением обнаружили, что если эту персональную базу данных записать на Я-диск, то подключаться к ней можно будет с
любого компьютера в мире
Например, я живу в Подмосковье, и использую некоторые БД совместно с коллегами на Камчатке.
Так как с точки зрения программы, она просто открывает файл на каком-то диске, и при этом совершенно не важно - локальный он или же облачный.
И все было бы хорошо, если бы бензопила в этот момент не сказала "КРЯК" не задержки синхронизации. Де-факто во время работы с "облаком" программа открывает не файл в облачном хранилище Я-диска, а его локальную копию. Которая может
обновляться с задержкой
Флаг, естественно, ставится не в файлах с данными, а в специальном заголовочном файле небольшого размера. Обычно там 10-20Кб. Т.е. он вроде бы должен синхронизироваться мгновенно. Но по факту иногда это может занимать даже не секунды, а чуть ли не минуту. Делать такую паузу при каждом подключении к БД невозможно: это уже не работа...
Поэтому вполне возможна ситуация, когда два юзера на своих компах открывают свою локальную копию базы одновременно. А в ней факт подключения второго юзера еще не отражен (флаг "занято" не установлен). После чего начинается синхронизация... облако обнаруживает, что файл изменен двумя клиентами сразу, в результате у каждого из них появляются сразу две версии открытого файла с пометкой (1), (2) и т.д.
Да, наша программа это почти сразу же замечает и спрашивает "Парни, че делать-то будем?". Даже пытается как-то этот конфликт разрешить. Но это борьба со следствиями, а не с причинами.
На самом деле, все, что мне нужно - это возможность задать вопрос облаку:
А не идет ли в данный момент синхронизация вот этого файла с каким-то другим юзером?
После чего я готов подождать ровно столько времени, сколько нужно облачному хранилищу для проверки этого факта. То есть, при получении моего запроса облако должно проставить у облачной (а не моей локальной) копии файла ключ блокировки (если он еще не стоит), а затем вернуть мне ответ: файл твой, работай!
Как правило, связь хорошая, поэтому есть надежда, что облако ответит быстро (незаметно для юзера). Если же со связью проблемы, то можно и подождать - это лучше, чем разбираться потом с дубликатами файла.
Да, в этом случае остается вопрос про компы, которые не в сети, или где синхронизация с облаком временно выключена. Там ведь никто (кроме моей программы) не может запретить юзеру редактировать тот же файл в автономном режиме. Но это уже будет не проблема облака, а моя.
Но насколько я понял, сейчас задать такой вопрос облаку Я-диска нельзя.
Или все-таки можно?
Или для этого нужны другие сервисы, а не Яндекс-диск?
Для меня тут критично, что с точки зрения моей программы,
она должна просто открывать файл
точно так же, как если бы он лежал на локальном диске. Чтобы не делать какую-то особую систему для работы с облачными БД, а просто работать со всеми базами через одинаковый интерфейс. Я же основную часть времени не программированием занимаюсь, а работаю с данными. Поэтому на поддержку и развитие программы ресурс времени ограничен...
Или я вообще какую-то ерунду спрашиваю, и на самом деле все делается совсем по-другому? Честно скажу, что я с многопользовательскими СУБД никогда не работал. Вполне возможно, что я поэтому в каких-то азбучных истинах плаваю, и вообще мне хочется странного...
Буду благодарен за любые советы. Даже если в моей ситуации реализовать их заведомо нереально, то хотя бы пойму, что к чему...
Можете попробовать подключить сетевой диск по протоколу WebDAV, но Яндекс как-то ограничил этот протокол и возможно с Яндекс-диском не получится. Как альтернативу можете сделать собственный сервер с Nextcloud который поддерживает WebDAV.
...попробовать подключить сетевой диск по протоколу WebDAV
Спасибо за наводку! Но к сожалению, я никогда про такой протокол не слышал, и вообще с сетями "на Вы". Поэтому из беглого чтения вики и еще пары сайтов не смог понять, как это может работать на практике. Мы ведь не работаем с облачными файлами через браузер. Никто не копирует файлы вручную в облако и обратно. Удобство работы заключается именно в том, что слой интерфейса к облачному хранилищу полностью прозрачен как для прикладной программы, так и для юзера.
Для нас это выглядит так:
- на локальном компе установлен клиент Я-диска. Он создает на локальном компе точную копию облачной папки с данными.
- прикладная программа фактически и работает с этой локальной папкой (= копией облачной папки). Для программы-клиента эта папка ничем не отличается от других папок на компьютере. Для нее это просто обычные файлы.
- Я-клиент "на лету" синхронизирует локальные файлы с облаком
А как на практике может выглядеть использование протокола WebDAV в этой схеме?
В идеале, я бы хотел послать Я-диску запрос на блокировку облачного файла (локальную копию которого открывает прикладная программа) перед его открытием, и запрос на разблокировку после того, как работа с файлом и его синхронизация закончена.
Но я подозреваю, что исполнение такого запроса - это все равно компетенция облака. Ведь ему одновременно надо проверять статус синхронизации файла?
Я правильно понял, что Я-диск умеет выполнять такие запросы, но обычный яндекс-клиент не поддерживает их отправку? И что поэтому нужно установить какой-то альтернативный клиент (надстройку над Я-клиентом?), который будет работать с облачным хранилищем Я-диска по протоколу WebDAV?
В диалоге подключения сетевого диска указываете https://webdav.yandex.ru
Скриншот
Далее будет запрос логина и пароля, в качестве пароля надо будет использовать "пароль приложения", он создается в разделе безопасности с типом "WebDav Файлы".
В итоге вы получаете сетевой диск средствами системы. В этом случае по идее изменения сразу должны будут сохраняться на сетевой диск.
@darkxanter, спасибо за подробный совет! Но у меня все именно так и подключено изначально. Я задал вопрос в поддержку Я-диска... но суть ответа сводится к тому, что Я-диск сейчас не позволяет "...отслеживать состояние синхронизации файла вне интерфейса программы или папки синхронизации в Проводнике".
Если бы я был крутым программистом
то наверное научился бы из программы открывать окно клиента Я-диска, искать там (в этом окне) в нужной папке нужный мне файл, и проверять цвет значка слева от имени файла.
Кстати, один мой коллега
когда-то давно проделал такой трюк с моей собственной программой, которая активно используется в их лаборатории. Он встроил в свою программу хакинг-блок, который анализировал окно моей программы и выводимые туда сообщения, и посылал этому окну свои команды, чтобы автоматизировать взаимодействие двух программ. А на мой вопрос, почему бы не сделать прямую отправку нужной информации из моей программы в его программу (мне для этого потребовалось бы добавить несколько операторов) сказал, что так интереснее ;-)
Но я пока не достиг такого уровня мастерства и занудства, чтобы копаться в чужих экранах, распознавая напечатанный текст и изображение (не говоря уже о том, что их оформление может без предупреждения поменяться). А главное, даже если я это сделаю, то смогу отслеживать только синхронизацию своего локального файла с облаком. А вовсе не синхронизацию облачного файла с другими клиентами. А уж про блокировку облачного файла таким способом не приходится даже мечтать...
Еще поддержка посоветовала мне покопаться в API Яндекс-диска. WebDav там есть, он поддерживается (правда, без каких-либо гарантий со стороны разработчика). Но работа через API - это совсем другой стиль. Все операции по закачке и скачиванию файлов в этом случае придется
выполнять самому
т.е. дополнить свою программу собственным полноценным клиентом взамен стандартного. Да еще и висящим постоянно в фоне, т.к. я после запуска своей проги я хочу сразу же начинать работу с данными, а не ждать синхронизации файлов...
В общем, покурив документацию, я так и не смог понять, как все это приспособить к нашим задачам
задешево
У нас ведь очень узконишевая некоммерческая программа, а пользователей у нее меньше полста. Поэтому бюджет времени на поддержку и развитие проекта - это 30% рабочего времени одного человека (причем не совсем программиста). Включая задачи по отлову и правке багов, реализации разных специфических алгоритмов и методов (примерно по паре штук в год), а также регулярный рефакторинг, без которого первые два пункта реализовать бы просто не получилось. Так что на какую-то капитальную переделку ресурсов попросту нет :-(
Поэтому я бы не хотел менять существующую технологию и отказываться от стандартного Яндекс-клиента. В идеале, надо добавить к нему какую-то надстройку (плагин), которая позволяла бы разным клиентам поочередно блокировать/разблокировать один и тот же облачный файл.
Вообще, у нас архитектура СУБД достаточно странная
Де-факто это однопользовательская СУБД, но данные общие, и с ними поочередно может работать много клиентов. При этом серверной части у СУБД нет вообще. Вместо этого есть общий для всех заголовок базы, в котором подключающиеся клиенты ставят и сбрасывают разные флаги.
Для локальной сети с быстрым трафиком это все как-то работает:
удобств гораздо больше, чем рисков
В локальной сети подключиться к базе одновременно вдвоем практически невозможно. В худшем случае форсмажора (отпала связь, погас свет) будет потеряна только одна транзакция, причем известно, какая. При подключении к базе следующего пользователя он просто сбросит базу к исходному (до начала транзакции) состоянию.
А вот в случае с облаком к базе можно подключиться сразу вдвоем. При тестах нам удавалось это сделать в 90% случаев, просто созваниваясь онлайн и нажимая одну и ту же кнопку на "раз-два-три". И вот в этом случае две транзакции перемешиваются, так что может быть нарушена целостность данных. В худшем случае может потребоваться откат базы к состоянию "до подключения", то есть на ровном месте будут потеряны действия сразу двух человек. В общем,
если (же) данные лежат в облаке, то контролировать доступ к ним должен все-таки сервер...
Однако я пока что так и не смог понять, есть ли вообще в API Яндекс-диска команда блокировки/разблокировки файла. А если ее там действительно нет, то вопрос об одновременном использовании стандартного клиента и Я-Д-API можно даже не задавать...
Сталкивался в своей деятельности с WebDav от Яндекса.
Могли и поменять, но тогда этот интерфейс внезапно стал платным, доступным только на коммерчесских тарифах с совершенно непонятной моделью оплаты. Думаю сейчас, с появлением Яндекс360 это устаканилось в понятные расценки, но это только предположение. Не проверял, но отказались даже не поэтому, а п.2
Многие программы, имеющие конрни из 90х и ранее в упор не видят веб-диски, в т.ч. от яндекса. Т.е. надо перепиливать клиента в современные реалии. Но если я правильно понял @adeshere, то у них эдакий монолит из прошлого без разделения на клиентскую и серверную части, что и вызывает огневой эпизод.
Многие программы, имеющие конрни из 90х и ранее в упор не видят веб-диски, в т.ч. от яндекса. Т.е. надо перепиливать клиента в современные реалии.
Именно эта проблема как раз и решается стандартным клиентом Я-диска. Он создает на локальном компе точную копию веб-диска, которая на лету (ну, почти) синхронизируется с облаком. Соответственно, для локальной программы (будь она хоть из DOS-а) такой веб-диск неотличим от локального. Все, что требуется от программы - чтобы она понимала еще какие-то буквы, помимо "A:", "B:" и "C:" ;-)
Но если я правильно понял @adeshere, то у них эдакий монолит из прошлого без разделения на клиентскую и серверную части, что и вызывает огневой эпизод.
Да, именно так. Даже еще чуть-чуть веселее: серверная часть отсутствует вовсе ;-) Функции сервера у нас исполняет небольшой файлик с набором флагов. Клиент должен первым делом открыть этот файл, и, изучив эти флаги, принять решение: что ему можно делать, а что нельзя.
Вот именно этот файлик мне и нужно синхронизировать с облаком "мгновенно". То есть настолько быстро, чтобы вероятность для двух клиентов одновременно открыть этот файл (до того, как синхронизация завершилась), стремилась к нулю. На практике (учитывая реальное число пользователей и число подключений к БД) меня бы вполне устроило, чтобы время синхронизации не превышало пары секунд. Одна секунда и меньше - вообще идеально: такую задержку можно обработать дополнительной микропаузой при открытии БД (при этом ведь все равно проверяется целостность базы и др.).
Но де-факто даже при устойчивом интернете его синхронизация может иногда занимать до минуты, особенно если параллельно идет другой трафикоемкий процесс.. Это означает, что при активной работе с БД мы будем необратимо терять транзакцию несколько раз в год
Да, в СУБД есть журнал
куда пишется статус всех операций (включая незавершенные). Но он сейчас предназначен скорее для копирования результатов выполненных расчетов из нашего пакета в другие программы, а также для всякой отладки. Автоматическое восстановление при аварийном завершении всяких транзакций реализовано только для самых критических случаев, причем обрабатываются только однопользовательские сбои. Возиться с добавлением автомата, который бы разбирался с многопользовательскими конфликтами, мне очень не хочется, так как в этом случае возникает проблема рекурсии аварий, обработать которую гораздо сложнее. Понятно, что всегда можно заставить принимать решение пользователя (что сейчас и реализовано в качестве временной меры), но дружественным я бы такой подход не назвал...
UPD: пока я все это рассказывал, появилась еще одна идея: возможно, моя проблема решится, если Я-диск разрешит юзерам настраивать приоритеты синхронизации? Чтобы я мог пометить какой-то файл в своем облаке и сказать Я-диску: пожалуйста, всегда синхронизируй его в первую очередь. Пожалуй, сейчас подкину такой вопрос в службу поддержки. Там ведь наверняка в алгоритме синхронизации и так есть какие-то приоритеты. А вдруг такой апгрейд будет очень "дешев" в плане реализации? Для пользователей типа нас он бы добавил огромную кучу выгод!
Как вариант, мы используем syncthing.
Мы отказались от Я-диска как-раз из-за пауз синхронизации, а вебдав-диски просто не виделись программами. "СиняяИзолента" позволяет установить флаг синхронизации начать синхронизацию по факту изменения в файле. Так же есть возможность поднять собственный сервер синхронизации, а не пользоваться публичным.
У синейИзоленты есть Онтрэй-клиент "SyncTraizor".
Этой системой мы, в том числе, ведем разработку мелких конфигураций файловых 1с, что довольно похоже на Ваш кейс. У Вас даже лучше, база сама сообщает о занятости. Надо будет нам такое себе прикрутить :).
Если исходные файлы централизованы и не обновляются пользователями, вы можете использовать простой веб-хостинг для хранения файлов.
Если ваши файлы обновляются пользователями, можно использовать какой-то вид системы контроля версий (например, git).
Если ваши файлы обновляются пользователями, можно использовать какой-то вид системы контроля версий (например, git).
Файлы обновляются при каждом сеансе работы. Контроль версий не поможет, так как задача в том, чтобы вообще избежать проблемы слияния веток (когда файл правили два пользователя сразу, и затем надо сохранить и те, и другие правки. А они могут быть взаимоисключающими).
В общем, нужен не контроль версий, а гарантия поочередного доступа к файлу.
Все изначально неправильно сделано, но учитывая ограничения того времени, вариантов не было. Все это надо переделать, причем вчера. Да, оно вымрет и придется переписывать. Лучше уже сейчас начать.
Главное что бы облако находилось в отдельном здании от бэкапа. На случай пожара.
Конечно, какой бы надежной ни была инфраструктура, всегда есть вероятность возникновения нештатных ситуаций, способных негативно повлиять на работу компании в целом. Но дата-центры как раз и служат решением, которое закрывает потребность в отказоустойчивости и надежности.
Например, для защиты серверных и технологических помещений в своих дата-центрах мы используем самые проверенные средства пожарной защиты, не экономя на надежности инфраструктуры и качества ОТВ. Высокий уровень защиты достигается за счет использования автономных центральных станций газового пожаротушения с веществом Хладон 125. И это только про системы пожаротушения.
Если говорить про объектное хранилище, которое описано в статье, то все объекты (данные) хранятся в трех копиях — на разных серверах в разных стойках. Это гарантирует надежность хранения: если что-то произойдет с сервером или даже со стойкой, с данными все будет в порядке.
А меня как обычно интересует другой вопрос ))!
Имеет ли возможность держатель облака посмотреть содержимое того, что я туда положил))?
Далеко не каждую информацию следует хранить отдельно от себя, а некоторую даже совсем не надо хранить где либо))
Добрый день! Мы бережно храним данные наших клиентов по 152-ФЗ, поэтому другие люди не могут получить к ним доступ.
Да, имеет.
Используйте шифрование, например, cryptomator
Как хранить данные в облаке? Краткий экскурс по технологиям