Comments 246
Спасибо за ваш отзыв. Я понимаю, что несмотря на доступность списка служебных контейнеров и управления ими в API S3, наш продукт имеет потенциал для дальнейшего развития. Мы обязательно учтем ваше замечание и добавим соответствующую функциональность в нашу Панель Управления в ближайшее время.
Что касается обработки «абортов» и управления оставшимися сегментами. Я уверен, что мы не имеем права самостоятельно, на своей стороне, решать, удалять нам или нет часть вашей информации (даже если она служебная). Дело в том, что со стороны продукта мы никогда достоверно не знаем, как поведет себя ваше ПО: начнет загружать объект снова или вызовет «комплит мультипарт аплоад» и дозагрузит недостающую часть.
Мы изучим логи и внимательно разберем вашу ситуацию. Спасибо, что помогаете нам делать сервис лучше!
То есть всё ранее
https://habr.com/ru/articles/796393/
https://habr.com/ru/articles/734854/
оказалось, простите, "лажей"?
Я бы поменял название статьи в целом
Держитесь подальше от Selectel
Ну не знаю, один клиент их виртуальный сервер нормально использует.
Как источник виртуальных данных обо всех клиентах компании?))
нет, там у него развернуты какие-то программы.
а что Вы имеете в виду, подскажите, пожалуйста?
Я имею в виду, что Selectel как российская компания обязан участвовать во всяких СОРМах
привыкайте. мы живем в эпоху утраты приватности. селяви
В современных реалиях эта статья является максимально неактуальной, а в местах сильным навалом кринжа. По факту из реально полезного только пункт 8 применимый к любому среднему-крупному бизнесу. А по статье автора можно нарисовать картину как технически неграмотный человек (в этом моменте) рассказывает ТП как должен работать их сервис. Но вы вроде платили за "хранение" файлов, а не за администрирование хранилища. Вы сами выбрали S3 API для загрузки данных недоконца разобравшись в тонкостях и перекладываете ответственность на сервис. Как-то не ice получается(
С подключением, теперь вы знаете, что S3-хранилища - это не бесконечная сетевая шара и требует вдумчивого подхода.
Это недостатки исполнителя. Ничто не мешает сделать транзакционно законченный синхронизатор. Не вижу технических сложностей.
Только это надо делать уже не на прикладном уровне, на прикладном надо сесть и поехать.
Это не недостатки исполнителя, это непонимание концепции multipart в контексте концепции облачного хранилища.
Вот статья от AWS, где все та же "проблема" описана в деталях. Допиливать реализацию CEPH (подозреваю, на нем все) можно конечно, но, кажется мне, нецелесообразно: если клиент оборвал соединение, стоит удалять остатки мультипарта? А через какое время?
Про "техническую сложность транзакций" — улыбнуло.
Название статьи лучше бы переименовать в "Держитесь подальше от 1С, если у вас нет своего штата разработчиков" или "Контроллируйте работу своего клиента при работе с облаком".
Т.е. ситуация, когда есть некий "служебный контейнер" который не отображается но тарифицируется это норм? Ясненько, понятненько.
Соответствует спеке S3? Вполне. Остальное на усмотрение разработчика клиента и хостинг-провайдера.
Раз товарищ не осилил почитать документацию того, чем пользуется и где-то у себя в голове самостоятельно решил "как это должно работать" - имхо, ССЗБ.
А в спеке написано что он входит в тариф? Спека это только техническая часть. А клиент возмущен тем что с него денег хотят больше чем в тарифе указано. Проблема не в незнании клиентом спеки S3, а в организации прозрачности процесса продажи клиенту услуги. То есть отсутствии этой самой прозрачности и наличии скрытых факторов.
Соответствует спеке S3? Вполне.
Вас не затруднит привести цитату из спеки где написано что в личном кабинете надо объем услуг отображать без учета служебного контейнера, а счет выставлять исходя из полного объема?
Заказываешь килограмм колбасы в интернет-магазине за 500 рублей, тебе привозят килограмм колбасы и счет на 50 000 рублей. А на вопрос "какого хрена?" выясняется что в счет входит вес курьера с электросамокатом потому что вы ему "до свидания" не сказали и он вас на лестничной площадке неделю ждал.
S3 к личному кабинету никакого отношения не имеет.
Что Селектел учитывает недокачанное в общем объёме и не даёт никак легко это почистить - недостаток их сервиса, но и только. Это не повод ныть, как автор поста, насчёт того, что "S3-хранилища совершенно не подходят для бэкапов".
я "ною" конкретно про Selectel. И точнее - для простой организации бэкапов. Если вы знаете, как бэкапить через коммандную строку без лишних геморроев, Welcome. Пока что тут не озвучен метод.
S3 хранилища совершенно не подходят для бекапов. CEPH. Более того, строго противопоказано осуществлять резервирование на S3. В стране в лучшем случае дюжина человек умеет правильно обращаться с этими хранилищами. Какова вероятность, что у селектела такой человек имеется? веротностная выборка говорит, что эта фишка у них на аутсорсе;)))
Если вы используете или планируете использовать холодное хранилище Selectel для бэкапа
Задача решается готовым VDS с большим диском. Разумеется, помимо облачного бэкапа, должен быть ещё и бэкап на физическом NAS, а ещё, желательно, офлайновый бэкап на физическом диске в несгораемом сейфе.
А подобные "холодные хранилища" - это инфраструктурные продукты для более сложных (и дорогих в разработке) вещей.
нужно просто допилить нормальную транзакционную передачу. Если этого нет то да, для бэкапа это бесполезно.
В случае с мультипартом селектел действует абсолютно правильно. Если вы решили отменить мультипартовую загрузку - для этого в API S3 есть соответствующая функция.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/abort-mpu.html
То, что вы не знаете этого, это ваша проблема а не селектела.
и как же мне вызвать это API и главное - зачем?
я покупаю хранилище у Селектела, а не у Амазона.
Рассчитываю на хранение данных, тестирую - вроде все ок. А потом вскрываются подводные камни.
Попробуйте готовое облако 1С. Не придется настраивать бекапы через bat файлы.
это облако для 1С, которых пруд-пруди. У клиентов 1С локально установленная, поэтому и возникла задача архивации. Вы предлагаете лечить головную боль гильотиной.
Я не понимаю все же плюсов от таких хранилищ, неужели это гораздо дешевле и удобнее чем просто пару пк с пачкой дисков и ибп. Ну или вообще просто 1с фреш?
а если случится пожар или маски-шоу и т.п?
если будут маски-шоу, вы сами им все отдадите, и не важно где это находится, вот вообще не аргумент
Мой дед был партизаном. а я что, паяльника убоюсь?
От организации процесса зависит.
Можно сделать всё так, что ни кто из участников маски-шоу просто не будет иметь пароля от системы и даже не будет знать, где этот пароль взять. А пока следователь выполнит квест по поиску пароля, оставшиеся соучастники удалят пароль из места хранения.
Вопрос лишь в том, что будет если пароль "случайно потеряется"...
если будут маски-шоу, вы сами им все отдадите
Так проблема то не в этом. У вас могут изъять сервер, порыть его месяц, ничего не найти, извиниться и вернуть... не весь. Вот тут то и неплохо иметь бэкапы где-то, откуда оборудование не вынесут и из него случайно что-нибудь не пропадет.
роют не идиоты, они увидят куда делались бакапы, далее запрос в ЦОД и ЦОД все отдает ) а еще проще устроят допрос с пристрастием админу, он сам все и выдаст, тут решают не технологии, а человеческий фактор, человек тут слабое звено
Отдаст-то отдаст, главное что не удалит.
Я сразу в сообщении написал, что проблема не в том что отдаст, а в том, что сотрудники полиции могут данные просто потерять, и у вас будут лишние проблемы, даже если в итоге дело закроют, а в ЦОДе они останутся. Знаю историю, где именно так и было -- просто вернули сервер без дисков.
А по-моему классная у них поддержка, судя по выложенному диалогу.
Возможно, но проблему не решила и с менеджером не связала. Пришлось выносить этот сор на публику. Увы. Да и мне не особо улыбается сейчас у трех клиентов менять схему бэкапа.
Доброй ночи! На самом деле, с менеджерами можно легко связаться с помощью нашего Telegram-чата Selectel Community: https://t.me/SelectelCommunity
Достаточно задать вопрос по интересующему продукту. Как показывает практика, коллеги там отвечают довольно оперативно.
Спасибо за ваш отзыв. Я понимаю, что несмотря на доступность списка служебных контейнеров и управления ими в API S3, наш продукт имеет потенциал для дальнейшего развития. Мы обязательно учтем ваше замечание и добавим соответствующую функциональность в нашу Панель Управления в ближайшее время.
Что касается обработки «абортов» и управления оставшимися сегментами. Я уверен, что мы не имеем права самостоятельно, на своей стороне, решать, удалять нам или нет часть вашей информации (даже если она служебная). Дело в том, что со стороны продукта мы никогда достоверно не знаем, как поведет себя ваше ПО: начнет загружать объект снова или вызовет «комплит мультипарт аплоад» и дозагрузит недостающую часть.
Мы изучим логи и внимательно разберем вашу ситуацию. Спасибо, что помогаете нам делать сервис лучше!
ну ретеншен поличи можно же сделать, чтобы не вечно эти остатки болтались, а какое-то желательно настраеваемое время
сделайте нормальный синхронизатор, чтобы откатывал файлы в случае обрыва. Сейчас пользоваться Rclone невозможно. У одного клиента даже лимит превышен был контейнера (но там обещали вернуть деньги за превышение). Другие платят больше чем должны из-за служебных фрагментов. А как это чистить непонятно. и главное - зачем, ведь потом опять появятся эти обрывки.
Скажите, а Rclone -чей продукт? Почему Selectel вдруг вообще стали виноваты в том, что Rclone оставляет за собой "мусор"?
Радик неувиновен, спору нет.
Но Selectle рекомендует Rclone.
Если бы он честно и прямо написал, что Amazon S3 - это только для большого IT, а для простой архивации не годно, т.к. кривое, косое и сложное, я бы его и не использовал.
А в итоге получается, что мы с поддержкой пришли к выводу, что у них нет простого сценария для архивации. Импотенция, так сказать - отсутствие возможности.
Это не для большого IT, а для тех кто знает за что держать, куда смотреть и на что нажимать. Или, хотя бы, имеет привычку изучать документацию.
Если вы не владеете такими навыками, то, например, можно просто посмотреть видео в отпуске на десятки тысяч долларов, получить хук перфоратором и перелом шеи со смещением, или просто получить в бочину поездом.
обычно есть вещи, которые ожидаешь от сервиса.
т.е. заселяясь в отель, не будешь подозревать, что нельзя садиться на унитаз, предварительно не нажав красную кнопку.
скажем так, общепринятые практики облачных хранилищ данных
Если уж проводить аналогию с унитазом — так с ним надо время от времени использовать ершик и спецсредство.
какой именно. Как отделить битые фрагменты от небитых? Я бы перед началом каждого бэкапа без проблем чистил бы служебный контейнер, но говорят что нельзя - удалятся сегменты файлов из основного контейнера.
Выкачать файло, прохешировать поблочно на манер торрента, грохнуть всех, выкачать повторно и посмотреть, что выживет.
Данных у вас там не петабайты, идея вполне реализуемая. Тем более, что вы где-то в сиблингах рапортовали, что ничего не поменялось с конечным сальдо в 300ГБ или около того
Только вот прикол в том, что S3 - это и есть общепринятая практика облачных хранилищ данных...
на яндекс-диске я подобного беспредела не встречал. Видимо, вы говорите о холодных хранилищах, а не об обычных?
Ну что вы "грузите" то? Это элементарная "галочка" в настройках. Что-то типа "удалять недозагруженные файлы через Х часов". Делается элементарно через крон (да, я намеренно утрирую, но вас толпа народа, вы в состоянии сделать как вам нужно). Просто скажите прямо: "Менеджмент нам запретил это делать, т к это нам не выгодно". Зачем врать то?
ПС: внизу вон пишут, что у амазона это сделано.
У Амазона сделана не "галочка", а возможность управления политиками жизненного цикла. Сами политики ещё кто-то должен написать, и если использовать подход "я думал это просто сетевой диск" - проблема будет ровно та же самая.
вот именно. если Амазон - настолько кривая система для архивации, то проще все же поискать другое холодное хранилище или использовать не холодное.
вот именно. если Амазон - настолько кривая система для архивации
Я честно вас не понимаю, вы просто выбрали инструмент не подходящий под ваши задачи. Стоило просто разобраться как работает S3 прежде чем использовать. Если работать используя "метод тыка", можно куда больше денег потерять, и данные в придачу.
А что мешает с юридической точки зрения добавить в личный кабинет функцию "Очистить недогруженные фрагменты файлов", и подтверждение с описанием возможного риска и галочкой "я понимаю риск, продолжить". Если клиент (юзер) поставил галочку и удалил хвосты, то дальше на его совести, как поведёт себя клиент (ПО).
Меня в гуглодиске это дико бесило, что загруженные через API, но удалённые в дальнейшем через веб-интерфейс файлы могут стать orphaned и занимать при этом место, но никакого внятного интерфейса для их очистки не было (т.к. в папке они не отображались, но продолжали существовать), приходилось скрипт писать, который через API вынимал список всех файлов и удалял те, на которых нет ни одной ссылки в папках. Как сейчас там с этим делом, не в курсе.
Спустя квартал от службы поддержке получен такой ответ:
Для доработки функции профильным отделом проводится предварительный анализ частоты воспроизведения проблемы, ее критичности и последующий анализ трудозатрат.
По результатам проведенных работ назначается ориентировочный срок введения и по результатам мы передаем обратную связь конечному пользователю.
Ввиду вышеперечисленных факторов, назвать ориентировочные сроки несколько затруднительно, однако по факту появления дополнительной информации мы свяжемся с вами в рамках тикет системы.
Бюрократия победила. Жаль, что Selectel так и не стал надежным хранилищем для бэкапов из-за того, что не может разделить клиентов на тех, которым нужен чистый Amazon S3 и которым нужно просто прозрачное холодное хранилище данных.
Цитирую ответ поддержки. По-прежнему не могут определить лишние сегменты, но деньги за них берут.
Благодарим за длительное ожидание.
Перемещение можно выполнить средствами API. Подробнее можно ознакомиться в документации
Вы копируете данные с одного контейнера и загружаете сразу в новый, минуя скачивание. Как вариант использовать 2 учетные записи rclone. Или другого программного обеспечения.
Именно скачивать данные ненужно, но перенести объекты средствами панели управления также не получится.
К сожалению, у нас нет возможности определить какие именно объекты и в каком контейнере являются лишними.
Рекомендуем самостоятельно провезти анализ наиболее важных данных в контейнере и перенести.
Для объективности было бы неплохо изучить как обстоят дела с этим в других Amazon S3 совместимых облаках. Например у яндекса или у самого амазона. Пока выглядит как недостаток архитектуры by-design а не как косяк селектела.
Я их не защищаю, сам от них съехал после грандиозного факапа лет пять назад, когда у них несколько дата-центров лежала. Но по приложенной переписке работа поддержки приятно удивила)
Посмотрите на syncthing для резервного копирования. Просто работает, я доволен как слон.
я другие не щупал. Но если это так, что весь Amazon S3 не годен для простого бэкапа. И это то, что при входе и не заметишь. Вроде бэкапит, вроде все хорошо, а потом вскрывается, что пользоваться этим совершенно невозможно...
syncthing - это я так понял софт, а не облако? или вы имеете ввиду, что он может обходить описанный косяк Amzon S3?
syncthing – это софт, который настраивается на двух машинах (на тачке, имеющей доступ к файлам БД жопы одина, и на машине, куда вы будете делать бэкап). Транзакционность, докачка, восстановление с середины – всё есть
на мой взгляд, чрезмерно усложнено.
ничего подобного - там наоборот, рассчитано на уровень "чуть выше домохозяйки"
Он решает задачу "синхронизировать два каталога".
Как Dropbox/Drive (любой)/Box, но вместо облака – другая машина.
Настраивать сеть, ставить демона, заставлять машины видеть друг друга не нужно, там DHT-сеть от BitTorrent.
Но да, он решает задачу синхронизации двух каталогов (включая, например, телефон), а не бэкапа.
Но да, он решает задачу синхронизации двух каталогов (включая, например, телефон), а не бэкапа.
Ну там и слепки есть, и синхронизация в одну сторону.
Да я oldscool, мне robocopy было достаточно всегда. ;-)
Я на CMD напишу нужный архиватор. Но мне нужна утилита командной строки для Amazon S3 вроде rclone, но не засоряющая диск.
При всей любви к Syncthing - он не решает проблему bitrot, например.
Syncthing шикарная штука, но я бы не рекомендовал её как средство для коммерческого бекапа. Там нет снепшотов и полных версий. Если версию последнюю восстановить ещё можно, то с восстановлением версии "месяц назад" могут возникнуть проблемы.
Там есть история версий с настройкой по числу копий или по времени. Хотя лично я Syncthing не для бекапа использую, а по назначению - для синхронизации.
Для бекапа у меня rdiff-backup (и ещё кое где tar). Ну его-то данные в S3 не положишь, нужна нормальная ФС.
Оно применяется к файлу, полного состояния на какое-то время не получить без разбора потенциально сложной структуры разных версий.
Именно так, там есть версионность. Но не очень удобная, если нужно восстановить много файлов то лучше выбрать что то другое.
Но я рассматриваю Syncthing как средство гарантированной доставки дампов баз или локального состояния файлового хранилища до сервера бэкапов. А там уже локально оно хранится с той глубиной которая мне нужна.
То есть в случае с 1с снимаю дампы sql или выгружаю файловую версию, на месте ее шифрую, а потом отдаю Syncthing, который сквозь все NATы доставляет ее до одного или даже нескольких в критических случаях хранилищ. И там раскладываю.
В Amazon S3 недозагруженные объекты (файлы) хранятся в той же корзине (bucket). Можно создать правило (lifecycle rule), которое их чистит.
Можно. Но это все сложно. Я думал, что контейнер - это обычный диск, который можно синхронизировать через Rclone. А тут вскрылся такой геморрой, что ну его, получать такие проблемы на ровном месте. Не хочется костыли прикладывать.
А чем вы его монтируете, кстати? s3fs?
я не монтирую. я тупо использую rclone для синхронизации файлов, рассматривая при этом контейнер как диск. даже не думал, что там такие заморочки.
Я вполне поверю, что проблема в реализации временных файлов у rclone, а не у селектела. Впрочем, спеку на S3 не читал, особенно на серверную часть (с клиентской хотя бы работал через s3fs и boto@python)
но в итоге у S3 нет никаких вменяемых инструментов командной строки для синхронизации.
Есть s3cmd, minio-client как минимум. При этом они же позволяют настроить удаление лишнего.
каким образом позволяют?
Через ключи или через установку политик life circle
а по-подробнее.хотя можете и не объяснять. Это чрезмерное усложнение для сервиса, где должно все просто копироваться.Прервалась связь с источником - все, фрагменты будьте добры удалитесь.
... и копируйтесь 100 терабайт снова с нуля ? денег не жалко ?
фрагменты на то и фрагменты, что заливаются независимо и "собираются" в один файл отдельным вызовом апи.
мало того, при желании можно заливать по кусочку в день, а собирать раз в месяц.
а вот отсутствие lifecycle у селектела при "совместимости с S3" - это да, косяк
Welcome to real world.
Облачные технологии это не отсутствие компьютера/сервера. Это компьютер/сервер у кого-то Другово.
Сетевой диск это не «как обычный диск только побольше» это другая система и другой уровень проблем.
Только сетевой диск в NFS работает на основе кода, который вы можете скачать, прочесть и собрать; сетевой диск в CIFS (SMB) работает на основе кода, который используют тридцать лет, его можно дизассемблировать, к нему есть вылизанный тысячами пользователей и разработчиков MSDN; а сетевой диск в S3 работает как-то, к нему написано руководство, которое, может быть, соответствует реальности. Или не полностью.
С Яндекс-диском у меня никогда таких проблем не было. Пока они не стали перекрывать кислород маркетинговыми уловками и не задушили WedDav
Если вам нужен аналог Яндекс-диска, посмотрите на Nextcloud как прослойку между вами и s3. Только нужно будет иметь в виду необходимость бэкапов самого Nextcloud...
Кстати, вернулся к яндекс-диску, когда опытным путём заметил, что скорость режется только для некоторых типов файлов, в основном архивов. Поменял расширение всех архивов на .bin и скорость через rclone чудесным образом взлетела. Понятно, что в любой момент могут снова что-то ограничить, но в некоторых случаях полезно.
Селектел скатился в последний год, видимо нормальные админы разбежались после начала чего-то-там. Но цены для РФ всё равно "лучше всех" если ловить дедики на аукционе со скидкой 30-35%
Тут говорят, проблема не в Селектел, а в протколе S3 Amazon.
конечно же проблема и в selectel, и в протоколе s3. но уж точно не в том, каким образом вы его стали использовать :))
а чем плохо такое использование. Разве холодное хранилище не идеально для бэкапа?
Концептуально - идеально, но нужен ещё и клиент, который умеет с ним работать не оставляя мусора.
да. а клиента то нетуть...
Клиент есть, только к нему, как подсказывают ниже, тоже надо документацию читать. Хоть и запрятали там её в довольно неочевидное место.
оно очень удобно. да. но, как и со всем остальным, иногда надо поизучать вопросы "а как эта штука работает", "а как ей правильно пользоваться" итд.
а то это получается как с бензопилой. ей пользоваться очень удобно, она эффективно валит деревья, делает это быстро, но если ее неправильно держать и прилагать усилия не в том месте может отпилить руку. и чаще всего это не проблема бензопилы.
я с таким сталкивался у других провайдеров. Это не (только) селектел.
Краткий вывод - использовали инструмент, функционал которого не изучили.
вы еще скажите это фича
Это определённо баг, но не в s3. Это баг в Rclone.
Других инструментов командной строки для S3 нет. Значит S3 в целом бесполезна для простой архивации.
эм... их вагон и маленькая тележка включая официальный от амазона
например? (мы про утилиты командной строки для синхронизации данных)
зачем нужен Rclone если есть s3cmd, да?
и что я должен оттуда понять?
насколько я понял читать вы не хотите, поэтому вот вам готовая инструкция на русском от chatgpt
@echo off
REM Получить список всех незавершенных multipart загрузок и сохранить в temp файл
aws s3api list-multipart-uploads --bucket your-bucket-name --profile your-s3-compatible-service --query "Uploads[*].[UploadId, Key]" --output text > uploads.txt
REM Прочитать temp файл и удалить каждую незавершенную загрузку
for /F "tokens=1,2" %%A in (uploads.txt) do (
echo Aborting upload ID %%A for key %%B
aws s3api abort-multipart-upload --bucket your-bucket-name --key %%B --upload-id %%A --profile your-s3-compatible-service
)
REM Удалить temp файл
del uploads.txt
pausebat скрипт для удаления старых multipart загрузок
мимо кассы. Я уже писал, что незавершенные загрузки rclone не удаляет.
Kopia, duplicati и т.д.
Спасибо кэп. Только эта фишка не на поверхности, а глубоко под капотом.
600 рублей..
Кажется, что многие, кто сегодня открыл эту статью сильно больше зарабатывают в час..
Не спорю, любая должна быть озвучена, только так ее будут решать, но непонятно наличие проблемы.. Но тут ведь даже не случай проблемы, кажется автор решил не читать инструкцию, но время на написание гневного отзыва - это всегда пожалуйста.
Никогда не использовал селектел, и скорее всего никогда не буду. Но 600 рублей - это конечно сильно, особенно для заголовка - "Держитесь подальше от холодных хранилищ Selectel".
Почитал как отвечает поддержка селектела и мне наоборот захотелось к ним перейти?♂️
Там накопительный эффект. За год уже 6.000. Да и в конечном итоге яндекс-диск дешевле.
но проблема даже не в деньгах, а в том что диск засоряется и новые данные уже не принимает. Да и расходы растут в геометрической прогрессии из за обрывков.
Я посчитал за свою жизнь, получилось 240.000. Так как нельзя брать последнее для подсчёта среднего, взял курс доллара на середину жизни (~28.5) получилось чуть больше 8421, но т.к. мы живём сегодня и в России и сегодня, я посчитал обратно на сейчас по текущему курсе и получилось 757.900. Накопительный эффект решает. А если ещё добавить инфляцию, думаю на двушку около ТТК хватит.
Это же фиксон, широко известный в узких кругах трол
... получается 600 рублей в месяц, это 6.000 в год ...
Мне одному эта фраза кажется странной? )) Вроде 600 x 12 = 7.200, не?
А вообще да, если у какой-либо конторы 600 рублей в месяц это проблема, то вряд ли она решится экономией этих самых шести сотен
в пределе потом это все выливается вот в такие случаи:
https://habr.com/ru/companies/ncloudtech/articles/783564/
"как съэкономить поллимона $ в год, изменением одной дефолтной настройки"
да. вы буквоед.
проблема решится, тем более что таких конторы три.
суммарно уже эффект получше.
а если умножить на пятилетку, сами понимаете.
Копейка рубль бережет.
Перед тем как писать статью или даже в поддержку стоило бы разобраться с используемой технологией. S3 именно так и работает, это правильная реализация. Настройка TTL для недогруженных файлов есть, тут тоже все реализовано правильно.
Селектел красавцы, их поддержка просто лучшая. Они имели полное право грубо вас послать читать документацию.
Как через Rclone мне удалить данные в служебном контейнере?
Вопрос неправильный. У Yandex это делается через политику lifecycle для bucket. Кстати, на той же странице есть упоминание S3 API и XML, а здесь есть тоже упоминание S3 API... В общем, всё это вполне может быть и навешивание политик должно быть возможно автоматизировать через CI pipeline, даже если в веб-интерфейсе или стороннем инструменте этой настройки и нет.
Я вот так очищаю в s3 yandex в скрипте
# Cleanup incomplete multipart uploads
s3cmd -c .s3cfg multipart s3://$BUCKET_NAME | grep '-[0-9]{2}T[0-9]{2}:' | while read MULT_LINE
do
MULT_NAME=echo $MULT_LINE | cut -d' ' -f2
MULT_ID=echo $MULT_LINE | cut -d' ' -f3
s3cmd -c .s3cfg abortmp $MULT_NAME $MULT_ID
done
поддержка не ответила, как отличать используемые части от неиспользуемых...
так бы я уж удалил, наверное.
да я и не думаю, что это просто.
У меня просто только один скрипт делает синхронизацию раз в сутки. После его отработки можно считать что все недокаченное "не используется"
мне поддержка ответила, что нельзя просто очистить служебный контейнер, иначе будут удалены сегменты основного контейнера. я тоже так хотел, конечно же.
иначе будут удалены сегменты основного контейнера
Может быть под этим и подразумевались "текущие закачки" ?
Не могу придумать что это за сегменты такие.
без понятия. Поддержка изъясняется загадочно.
Ну надо было уточнить - если я точно знаю что в данный момент ничего не закачивается и удалю букет "*_s3multimartuploads" ничего страшного не случится ?
Но задавать правильные вопросы тоже искусство, да )
PS. Предназначение бакета можно понять по его названию
PPS. В селектеле кстати получается проще - можно просто бакет снести, а не искать "недокачки" как у меня в скрипте.
джва года ищу замену hetzner storagebox
ну нету ни у кого, в тп селектела сказали что "в разработке, а вы пока наше s3 юзайте"
а я не хочу s3, я хочу nfs/sftp...
NFS без Кербероса не шифруется - отличный вариант для передачи данных, да. А SSH есть примерно у всех, берёте жирный сервер и пользуетесь.
Видел на гитхабе конвертер sftp /s3 и ещё куча протоколов
Насыпьте плюсиков человеку. За то что свел переписку в виде таблицы текста, а не простыни скриншотов. Сейчас таких уже не осталось.
главное часть из это таблички можно в свое образный FAQ добавить для тех кто еще применяет этот сервис.... а статья вовремя попалась, чуть пару своих проектов на selectel не затянул.... может действительно облачные диски поисковиков применять
да, это было спонтанное решение. раньше никогда так не делал.
Что я понял из статьи (никогда ранее не использовав Selectel и Amazon S3):
1) Поддержка Селектела отвечает внятно
2) У любой технологии есть внутренние нюансы, поэтому применение любого решения "нужно уметь готовить правильно", хорошо если эти нюансы и способы описаны в документации у того, кто предоставляет доступ к этой технологии.
3) Жаловаться "я хочу чтобы всё работало по-простому, а у вас так не работает" - можно, но скорее всего это ничего не изменит, потому что в современном мире не технологии подстраиваются под людей, а люди из тысяч готовых технологий выбирают ту, которая подходит под их задачи.
4) Конкретно мысль о том, что селектел что-то там не удаляет, чтобы вытянуть побольше денег с клиентов - это самая бредовая мысль всей статьи. Как явно следует из ответов поддержки, технология загрузки больших объектов по умолчанию использует метод загрузки с возможностью докачки, поэтому для таких загрузок сейчас нет понятия "загрузилось полностью", любой загруженный кусок остаётся на сервере, т. к. после обрыва связи клиент может захотеть продолжить закачку (в данном случае клиент это не человек, а какое то умное ПО, поддерживающее докачку).
Думал чтобы сохранить инфраструктуру, разбивать файлы на части по 0.3 Гб, но ключ --disable-multipart есть только у s3cmd, у rclone его нет. Это надо переписывать код. Проще поискать другое хранилище.
Вы 20 раз написали, что используете rclone, но, похоже, так ни разу и не прочитали документацию. В доке явно сказано:
If you run
rclone cleanup s3:bucketthen it will remove all pending multipart uploads older than 24 hours.
https://rclone.org/s3/#cleanup
Думал чтобы сохранить инфраструктуру, разбивать файлы на части по 0.3 Гб, но ключ --disable-multipart есть только у s3cmd, у rclone его нет.
Буквально на том же экране:
Multipart uploads
rclone switches from single part uploads to multipart uploads at the point specified by
--s3-upload-cutoff. This can be a maximum of 5 GiB and a minimum of 0 (ie always upload multipart files).
Установите предел в 5Гб и закружайте одним куском. 5Гб - ограничение S3 для single part: https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html.
спасибо, проверю. попробую почистить s3:bucket. странно, что поддержка мне об этом не сказала. Попробую выполнить эту команду и посмотрю, уменьшится ли объем служебного контейнера. Тогда буду вызывать ее перед началом архивации.
про разбивку я у них тоже справшивал, есть ли ключ, ограничивающий мультипарт для rclone, не ответили.
Не работает cleanup:
Посчитаем размер основного контейнера 189 Гб:
rclone size backup:backup
Total objects: 60
Total size: 189.032 GiB (202971502109 Byte)Посчитаем размер служебного контейнера 557 Гб:
rclone size backup:backup_s3multipartuploads
Total objects: 111.661k (111661)
Total size: 557.222 GiB (598312185406 Byte)Попробуем очистить загрузки старше чем 24 часа, но размер хранилища не уменьшился:
rclone cleanup backup:backup_s3multipartuploads
rclone size backup:backup_s3multipartuploads
Total objects: 111.699k (111699)
Total size: 557.407 GiB (598511414846 Byte)Так чистить надо там, куда загружали. То есть backup:backup.
Увы, не помогло:
C:\rclone>rclone cleanup backup:backup
C:\rclone>rclone size backup:backup_s3multipartuploads
Total objects: 110.795k (110795)
Total size: 553.439 GiB (594250626612 Byte)
C:\rclone>rclone size backup:backup
Total objects: 60
Total size: 189.033 GiB (202972126739 Byte)
Поддержка пишет:
Что касается cleanup. Если мы правильно понимаем документацию, то эта команда отвечает за очистку объектов, которые ожидают загрузки, то есть есть сценарий, при котором загрузка остановилась и стоит на ожидание завершения. Скорее всего, это как раз тот сценарий при котором клиент загружает файл, сервер с Rclone теряет связь, далее остаются какие то сегменты с подобным флагом или что то подобное. У Вас таких объектов нет + у этих объектов есть лимит по времени, судя по документации это 24 часа. То есть сейчас действительно самым разумным вариантом будет перенести объекты в соседний контейнер, тем же rclone, проверить, что все завершилось исправно и удалить контейнеры с лишними сегментами. После вернуть все как было.
Syncthing шикарная штука
У нас похожая ситуация с CDN от Selectel. Соблазнились малой ценой за переданный гигабайт.
По факту пришлось платить за переданные гигабайты пользователям + служебный трафик между нодами, а это было 80%. Если честно первый раз явно столкнулись с такой тарификацией. Т. е. увеличение в стоимости в 5 раз. Ушли.
Те я правильно вижу, что это обсуждение из-за 600 р. Автор, доработайте заголовок Держитесь трали-вали, а ТО ПОТЕРЯЕТЕ 600 р!
Ттк я когда цифры увидел, честно подумал, что я без очков наверное там нулей не вижу, или запятая в другом месте и там 60К.
Поддерже селектела респект.
Никогда не использовал селектел, и скорее всего никогда не буду. Но 600 рублей - это конечно сильно, особенно для заголовка - "Держитесь подальше от холодных хранилищ Selectel".
Народ, вы кого слушаете?! простого 1Сника? наберите в инетернете кто такой Фиксин. Будите приятно удивлены. Он правильно написал, что он простой 1Сник. Дело было так - ему заказчик поставил задачу на реализацию облачного хранилища. Товарищ, т. к. у него ипотека и содержит кучу дармоедов, не детей уже, берется за любую работу. Заказчик попросит на С++ написать, он и за это возьмется. Так вот он нашел Селектел, установил, настроил его, т. е. втюхнул заказчику. Хотя мог бы отказаться, раз он простой программист 1С.
Тепереча работает все не так как надо, ему заказчки предъявил, мол что за фигня - ты же порекомендовал, установил, настроил, а теперь не работает. Чья это ответственность? Селектела разве? нет, того человека, кто устанавливал и настраивал все это. А именно Сергея Осипова. Который в силу своей недалекости и слабоумия не смог адекватно, обдуманно подойи к задаче. Теперь его заказчик схватил за одно место, но вместо этого он все валит на Селектел. Мол это они, а я то чего, я простой 1Сник, с меня и взятки глатки. Ничего не напоминает?! кто тут про олдскул чего то гворил.... Типа я простой слесарь, а это кран виноват.
Серень, ты накосячил, так признай это. А то вертишься как уж на сковороде. У мобильного телефона тоже есть кучв настроек под капотом, никто не жалуется. Если не устраивает - вон купи кнопочный телефон, для пенсионеров. Ишь ты, простой 1Сник.
вместо простого и понятного инструмента для бэкапа мы получаем какое-то устройство для гиков.
устройство для гиков выкачивания бабла.
ММмм multipart_upload, это ceph передает привет, если селектел обновит до 18 будет получше, но в целом реализовать diff между метрикой который ceph отдает по бакету и реальными объектами в бакете, несложно, но может быть ресурсно затратно, если объектов много...
Решал эту проблему с месяц назад. Тоже было не особо приятно удивлён этим косяком в UI.
Храню бэкапы gitlab, он штатно умеет в s3 отправлять их, очень удобно.
Обошёлся удалением через minio client. ansible task, может кому пригодиться заюзать:
- name: Install minio client from the internet
ansible.builtin.apt:
deb: https://dl.min.io/client/mc/release/linux-amd64/mcli_20240429095605.0.0_amd64.deb
- name: Set s3 alias for minio client - prepare creds
ansible.builtin.template:
src: ../templates/credentials.json
dest: /root/credentials.json
- name: Set s3 alias for minio client - import creds
ansible.builtin.command: mcli alias import selectel /root/credentials.json
- name: Clean up s3 backups
ansible.builtin.cron:
name: Cleanup s3multipartuploads
minute: 0
hour: 04
job: mcli rm -r --force --older-than 7d selectel/gitlab-backups_s3multipartuploads/// ../templates/credentials.json
{
"url": "{{ s3_garbage_collector.url }}",
"accessKey": "{{ s3_garbage_collector.aws_access_key_id }}",
"secretKey": "{{ s3_garbage_collector.aws_secret_access_key }}",
"api": "s3v4",
"path": "auto"
}не, я это не осилю.
А зря, там весь файл сводится к запуску команды mcli rm -r --force --older-than 7d selectel/gitlab-backups_s3multipartuploads/
Хотя я теперь не понимаю какие такие важные фрагменты файлов там у вас хранятся, если у других через 7 дней можно всё чистить...
mcli это уже другая утилита, не rclone?
и что делает этот замечательный код? Удаляет вообще все файлы старше 7 дней, а зачем? мне ведь надо хранить эти архивы.
Хотя если там всего 10 ежедневных архивов, конечно можно удалить файлы старше 10 дней, это как вариант, хотя бы и на том спасибо. А если бы я хранил еще ежемесячные копии, тогда бы не годилось.
Думаю Rclone тоже может удалять файлы старше определенной даты.
я выплачиваю 600 RUR в месяц
Простите, а сколько стоят ваши данные, что 600р/мес дорого для их сохранности?
а 6000 в месяц нормально или дорого? Ведь из-за обрывков объем будет расти геометрически. Я сравниваю с "горячим" яндекс-диском где за 6000 в год можно иметь 2 Тб.
Мне кажется, что с каждым ежемесячным счетом от селектела, который превышает стоимость видимых гигабайт, надо писать отдельное обращение в роспотребнадзор, прокуратуру и другие аналогичные конторы. Вам счет на 600р, им штрафы на миллионы. И так - каждый месяц, пока не найдут нормальных разрабов и не пофиксят проблему. А потом с ответом от этих контор идти в суд, который автоматически выигрышный. Требуешь с селектела миллион за аморальные страдания. Дадут тысяч 50, все равно отобьешь ежемесячную плату. Они явно расчитывали на крупный корпорат, который такие мелочи не замечает, платит молча и которому можно втюхивать счета в 10-20 раз больше реально используемых услуг. А на мелкой компании спалились и теперь ТП остается только переходить в режим чат-бота и писать шаблонные отмазки
Западные компании рассматриваются? Hetzner Storage Box - прекрасная вещь с доступом по множеству протоколов.
За 10 лет поел я всего чего только можно c этими incomplete uploads у десятка провайдеров.
Не буду вдаваться в подробности, но иногда s3 клиенты реализованы неполно и, к примеру, не поддерживают пагинацию в запросе ListMultipartUploads или что-то подобное. А там по умолчанию выдаётся 1000 и может так оказаться, что весь клинап касается только первой тысячи.
Попробуйте запустить cleanup у rclone (как написали выше у основной корзины) раз десять и посмотрите изменилось ли существенно что-то в служебной корзине количественно (если вдруг помогло, повторите еще 90 раз). Понимаю что это выглядит немного тупо, но аналогичные действия у меня решали аналогичную проблему в примерно 20% случаев.
Небольшое PS как пример кривых реализаций:
Если серверная часть s3 хранилища это minio (не вдавался что там у селектела, но вероятно не minio, а swift) то посмотреть что там зависло нельзя: https://github.com/minio/minio/issues/13246 "We do not implement full ListMultipartUploads API on purpose. "
Статья находится в невероятной суперпозиции - автор недосмотрел/недоизучил протокол S3, Selectel не сделал корректное лимитирование (уже который год, кстати)
не всегда ожидаешь подлянок от предсказуемого инструмента.
Так он так везде работает, инструмент этот. При этом с ним можно отлично жить, даже сайты статические на нем держу. И не утекает место, все замечательно.
HINT: лично для себя выработал правило - если беру новую технологию - то сразу ищу hacks and tips по ней. Экономит время и деньги это.
Хорошее правило.
но я не ожидал таких "детских болезней" утечки фрагментов от S3 и RCLONE. Все же есть некий ожидаемый уровень технологии.
Это как приходишь в офис, а там менеджеры в лаптях.
Привыкайте, современные облака из таких "детских болезней" и состоят.
Не усложняйте, тут мы не решаем бином ньютона, обычное копирование делаем.
Под "обычным" копированием скрывается пара десятков таких биномов, уложеных послойно.
обычный интернет не менее сложно устроен, но когда вы качаете приложение на телефон, вы об этом не думаете. вот и я не думаю - мне заявлено файловое хранилище, я использую его как хранилище.
Ха, черточка.
Очень даже наоборот — потому что ни в поезде, ни в подвале, ни в крупном ТЦ, ни на даче, ни еще в тысяче мест не то что скачать приложеньку в четверть гига, а даже получить sms бывает проблемно. А вы вот, похоже, не думаете в принципе — и теперь пытаетесь всем доказать, что это злобный линукс виноват в том что ненавидия перестала поддерживать семерку.
Херню порете, короче говоря.
Это не детская болезнь, а особенности реализации. Вы же когда выбираете инструмент проверите как он будет работать? Вот и тут так же - при загрузке больших файлов есть особенность.
Тут преступно только то, что квоты на тех бакет и на основной считаются раздельно. Но учитывая размеры - а вас точно не смущало, что многогигабайтный бэкап в 44 гига уместился?
у меня нет архивов на 44 гига, 8-12 Гб максимум, размеры контейнера я не смотрел общие, т.к. был спокоен, установив лимит.
А горизонт хранения то какой? Мы вроде бы про бэкап говорим - а значит он должен быть. Должны быть оповещения при неудачном бэкапе и вот это все.
А вообще, делюсь хорошим чеклистом по хранилкам:
Что мы решаем новой технологией? Что она представляет? Что есть наш файл?
Какие есть плагины - сжатие, шифрование, докачка, версии? Как реализовано?
Как файлы грузятся? 4, 5, 10мб, 1гб, 10, 100? А что если оборвать загрузку? Как докачать?
Как это лежит у хостера? Как чистится? Что показывает биллинг?
Стресс-тест хранилища. - заливает/удаляем 10000 разнокалиберных файлов
На такие тесты тратится пара суток, но в итоге все основные вопросы проверены. И вы точно увидели бы что хранится больше чем нужно.
Вообще, конечно, больше всего доставляет как автор сначала безопеляционно нахваливает S3 хранилище от Селектел, а потом столь же безопеляционно заявляет что вся технология S3 хранилищ никуда негодная шняга. При том что по факту он просто не удосужился разобраться как же она, эта технология, работает.
И отдельно радует это именно "холодное хранилище" везде, как будто это часть технологии S3 и "нехолодное" хранилище это уже что-то другое :)) вэ
Всё это, конечно, ничуть не меняет того что Селектел нехорошие ребята и пользуются ситуацией искусственно сниженной конкуренции. Ибо у того же Амазона, как уже здесь написали, есть инструмент для удаления недокаченных битых частей, а Селектелу это просто не надо - файлы лежать, денежки капают.
Как ни крути, а вот этот вот накопившийся служебный скрытый мусор, о котором selectel наверное даже Не предупреждал, и сожрал деньги юзера. Такого однозначно быть не должно.
да. но они считают, что мусор - это часть сервиса. Мол это проблемы Амазона, а не их.
Типа надо чистить на стороне пользователя. Вопрос - как? нет ответа.
Для начала надо понять откуда он берётся. Но у нас облака Селектела нет, а вы никаких подробностей не сообщаете, только запутываете. Конечно же ответа "как чистить" не будет.
Нет ответа Как - раз.
Нет предупреждения о накоплении служебной инфы размером с основную - два.
Вывод: пахнет мошенничеством, цена ведь от объёма зависит.
Я правильно понимаю, что убытки 600 рублей, а для решения проблемы достаточно разбивать бэкапы на части, а не грузить большими файлами?
Держитесь подальше от холодных хранилищ Selectel