Системы хранения и обработки данных являются фундаментальными компонентами современной инфраструктуры информационных технологий в бизнесе. По мере интенсивного технологического развития и масштабирования предприятия сталкиваются с неизбежным увеличением потока данных – если раньше с ними можно было справиться силами обычных серверов, то сейчас некоторым компаниям приходится обращаться к помощи программных комплексов и систем с большей ёмкостью.
Системы хранения и обработки данных или СХД отлично справляются не только с огромными объёмами данных, но и позволяют предприятию управлять ими – практически в любой нише, будь то интернет магазин или промышленное производство.
Долгое время на рынке большой популярностью пользовались продукты зарубежных разработчиков. Но после 2022 года российские предприниматели лишились многих востребованных СХД – HPE, DELLEMC, Fujitsu, HGST. Со временем и в этом секторе удалось наладить параллельный импорт – но это практически никак не решило проблему, поскольку поставляемая продукция до сих пор лишена критичных для бизнеса сервиса и технической поддержки.
Поэтому в этой статье мы поговорим об альтернативах отечественных производителей – достойных системах хранения и обработки данных, сертифицированных, безопасных и предоставляющих все необходимые гарантии своим клиентам.
Привет, меня зовут Александр, я руковожу Управлением исследований и разработки новых решений в «Ростелеком-ЦОД», если коротко — лабораторией R&D.
Сейчас лаборатория хорошо прокачана и продуктивна, но так было не всегда. В этой статье я расскажу, как мы ее создавали, к чему пришли и как тестируем оборудование, ПАК и ПО.
Кто изобрел USB-накопитель? Однозначно приписать эту заслугу кому-то конкретному нельзя — на авторство претендуют сразу несколько людей и компаний.
Во многом появлению этого изобретения поспособствовала технологическая среда того времени. Флэшка сочетала в себе флеш-память и интерфейс USB в удобном корпусе, который заменил дискеты.
В этой статье кратко расскажем об основных вехах создания флешки и приведем историю сингапурца Хенна Тана, который один из первых вывел флешку на коммерческий рынок и способствовал ее распространению. Тан вел множество судебных споров о нарушении патентов, но в конечном счете ему удалось добиться лишь ограниченного успеха в борьбе с распространением дизайна флешки.
Выбор надежного поставщика систем хранения данных (СХД) является важным шагом для организации, которая стремится обеспечить успешную работу своих инфраструктурных решений. В мире информационных технологий, где объемы данных растут экспоненциально, а потребности клиентов постоянно меняются, надежный поставщик оборудования играет важную роль в обеспечении стабильного функционирования системы.
В прошлом материале мы рассказали о типах файловых систем и подробно остановились на системе ZFS. В второй части подробно разберем BTRFS — файловую систему для Unix-подобных ОС.
Привет, привет!
Представлюсь: меня зовут Тамара, и я являюсь ведущим инженером по нормативно-справочной информации в компании Bimeister.
Начну с того, что это лишь малая часть той большой истории, которую я хочу вам рассказать.
Будет много вопросов типа «Что это?», «Для чего нужен?» и тд. Ищите ответы на эти вопросы ниже, я вам все объясню)
Чем же занимаемся мы, ребята из отдела разработки НСИ? Давайте попробую вам кратко рассказать:
Промышленные предприятия сталкиваются с проблемой создания единой системы нормативно-справочной информации. Возникают трудности с созданием и внедрением общих правил именования оборудования, систем, материалов, товаров, контрагентов, и пр. Предприятиям необходим единый инструмент и общая методология ведения НСИ.
Нормативно-справочная информация – условно постоянный компонент корпоративной информации, являющийся основой для унификации и нормализации данных, сопровождающих протекающие бизнес-процессы, а также регламентацию деятельности организации.
Качественная база данных оборудования (БДО) является основой для построения системы автоматизации/цифровизации процессов Управления техническим обслуживанием и ремонтами (ТОиР). В процессе эксплуатации системы Управления ТОиР предприятиям постоянно требуется актуализация существующих аналитических справочников, составляющих БДО. Чтобы иметь возможность планировать ремонт или техническое обслуживание (ТО) любой конкретной обслуживаемой единицы оборудования, а также вести учет истории ремонтов и отказов (дефекты, параметры состояния, наработка, отказы), необходимо, чтобы эта единица была описана в информационной системе (паспортизирована).
Технология NVMe через различные фабрики (далее NVMeOF) оформлена в качестве стандарта летом 2016 года, она была встроена в пятую ветку ядра Linux.
Поэтому, когда было решено мигрировать объемные базы данных с легаси-решений на общедоступные платформы, возник вопрос — можно ли применить эту технологию для увеличения дискового пространства для создания зеркал локальных дисков?
Чтобы все зеркала не вышли из строя сразу, принимать такие диски надо бы небольшими группами с нескольких машин из разных стоек. Идея показалась достойной рассмотрения, поэтому создали небольшой стенд.
Меня зовут Алексей Дрожжов, я старший инженер в билайне, и в этом посте расскажу, как мы решали эту задачу.
Задача: подключить много дисков с нескольких серверов
Год назад мы выпустили «Маскировщик» — промышленный софт, который обезличивает персональные данные, сохраняя их качество и смысл. То есть гендерный баланс; социально‑демографическую структуру; родственные связи; страну и оператора в телефоне; валидность паспортов, ИНН, СНИЛС. В общем, «Маскировщик» делает так, чтобы вы тестировали продукты и обучали ML‑модели будто бы на «живых» ПД.
В этой статье пролью свет на методы изменения состава и семантики, которые использует продукт. Для простоты буду называть их «алгоритмами маскирования». Расскажу, по какой логике меняем одни данные другими, какие ограничения и как учитываем.
Да, N это очень круто, не спорю, но однажды у меня в N закончилось место в 1000 блоков (в A пространство так же ограничено 1Гб, но об этом позже) и дальше заметки вести невозможно, и N предлагает апгрейд
Привет! Я Александр Пищулин, перфоманс-инженер в компании YADRO. Сегодня расскажу об одном интересном случае траблшутинга в работе с системой хранения данных — он касается выброса времени отклика. Поиск причин сбоев, наверное, одно из самых увлекательных занятий в моей работе. Зачастую у подобных задач минимальная формализация подхода к решению, каждый раз может быть своего рода открытием или, если угодно, челленджем.
Так произошло и в случае, который я описываю под катом. Путь решения задачи может показаться не оптимальным, но в итоге именно он привел к неожиданной разгадке всей проблемы. Возможно, вы бы начали искать проблему иначе — предлагаю поделиться вашими соображениями или опытом в комментариях.
Про restic я уже рассказывал в статье Бэкап-хранилище для тысяч виртуальных машин свободными инструментами, с тех пор он остаётся моим любимым инструментом для бэкапа.
Сегодня я опишу вам готовый рецепт того как настроить эффективное бэкапирование чего угодно прямо из stdin, с дедупликацией и автоматической очисткой репозитория от старых копий.
Несмотря на то, что restic отлично подходит для сохранения целых каталогов с данными в этой статье мне хотелось бы сделать упор на сохранении резервных копий на лету прямо из Stdin.
Как правило это бывает актуально для сохранения бэкапов виртуальных машин, баз данных и других, представленных одним большим файлом, данных, которые можно последовательно вычитывать и сразу отправлять в систему бэкапирования.
Когда Большой адронный коллайдер запущен — как например, во время своего второго цикла, с начала 2015 года по 2018 год, — он обрабатывает события на частоте 40 МГц. Другими словами, он учитывает 40 миллионов событий в секунду. Это необходимо, чтобы отслеживать столкновения между частицами, длящиеся менее 25 наносекунд.
Каждое событие содержит в себе примерно 1 мегабайт данных. Это значит, что в систему во время работы коллайдера входит примерно 40 терабайт данных. В секунду! Абсолютно фантастический объем информации, ведь петабайт набирается примерно за полминуты. Около 72 000 средних жестких дисков заполнялись бы каждый час.
Обрабатывать всё это на такой же скорости не представляется возможным; для анализа подобных объемов данных после окончания работы установки требуются годы. Значительная часть отфильтровывается еще на этапе сбора, на что тоже уходят огромные вычислительные ресурсы. Но всё‑таки остальную часть информации нужно где‑то хранить. Для этого европейская организация по ядерным исследованиям (ЦЕРН) содержит самый большой ЦОД в мире.
TON Storage - это часть экосистемы TON, изначально спроектированной командой Telegram, во главе с Павлом Дуровым. Она предоставляет возможность хранить, скачивать и делиться файлами децентрализованным способом.
Напомню, что работа TON (Telegram Open Network) на несколько лет была запрещена американским, а проект был передан сообществу и переименован в The Open Network.
TON Storage необходим в блокчейн-экосистеме как дешевый способ хранения больших файлов. Хранение файлов непосредственно в блокчейне будет очень дорогим, а потребность в обмене большими файлами между пользователями блокчейна существует. Например, NFT создаются не только на основе изображений, но и музыки и видео. И все эти данные нужно где-то хранить.
