DATABASE DESIGN

Почему фотография Скарлетт Йоханссон заставила PostgresSQL майнить Monero В рамках кампании по защите данных наших клиентов мы в Imperva рассказываем о разных методах атак на БД. Если вы не знакомы с нашим исследовательским проектом StickyDB, почитайте прошлые статьи: часть I и часть II. Там описано устройство сети ханипотов (рис. 1), которая заманивает злоумышленников атаковать наши БД, чтобы мы изучали их методы и улучшали защиту. Рис. 1. Сетевое окружение ханипота StickyDB Недавно мы обнаружили интересную технику в ходе атаки одного из серверов PostgreSQL. После входа в БД злоумышленник продолжал создавать полезные нагрузки из встроенных бинарников в скачанных картинках, сохранять полезные нагрузки на диск и запускать их. Как часто бывает в последнее время, злоумышленник захватил ресурсы сервера для майнинга Monero. Как будто этого мало, вектором атаки была фотография Скарлетт Йоханссон. Ну тогда ладно. Разберёмся, как это работает! Читать: https://habr.com/ru/articles/351452/ #ru @database_design | Другие наши каналы

Исследование БД и СУБД с помощью T-SQL Предисловие Приветствую вновь тебя, уважаемый читатель Хабра! Когда свои реализованные идеи, опыт, а также всю ту информацию, что не дает покоя, оформляешь в публикации, рано или поздно приходит логическая точка всему ранее написанному потоку информации. Эта статья будет отличаться от всех ранее опубликованных мною своей нестрогостью и более свободным стилем изложения текста, а также она завершит изложение всего моего накопленного опыта по MS SQL Server. Данная статья является дополнением к статье Исследуем базы данных с помощью T-SQL, а также вкратце рассказывает о созданной базе данных по администрированию SRV и о проектах-утилитах, которые предназначены помочь в работе DBA MS SQL Server. Читать: https://habr.com/ru/articles/350388/ #ru @database_design | Другие наши каналы

DICOM: цифровые снимки в медицине — ликбез для системного администратора Одним из самых компьютеризированных разделов медицины является радиодиагностика. Медицинские исследования генерируют большое количество данных, которые затем обрабатываются передовыми методами визуализации, 3D-реконструкции по срезам и даже машинного обучения. Этот топик призван помочь системным администраторам погрузиться в тематику передачи и хранения медицинских изображений. Фото автора Читать: https://habr.com/ru/articles/217761/ #ru @database_design | Другие наши каналы

Агрегация каналов и балансировка трафика по IP для СХД Для небольших компаний нередко применение всего двух-четырех серверов с виртуализацией, два Ethernet свитча порой даже с возможностью стекирования и Multi-chassis EtherChannel плюс СХД младшей серии — это вполне стандартная конфигурация инфраструктуры среднего бизнеса. Таким предприятиям очень важно максимально задействовать все доступные технологии, чтобы максимально утилизировать своё оборудование и в этой статье пойдёт речь как этого добиться. В большинстве современных серверов на борту как правило присутствует минимум два 1Gb интерфейса под данные и один 100Mb для менеджмента. На СХД младшей серии NetApp FAS2240/FAS2220 на борту каждого контроллера помимо прочего присутствует 4х 1Gb порта. Т.е. вполне логично использовать схему, где два свича в стеке используют Multi-chassis EtherChannel агрегируя линки идущие от каждого контроллера в каждый свитч для получения как отказоустойчивости так и утилизации пропускной способности всех этих линков. Такая-себе архитектура по образу и подобию FlexPod Express, но без модно-дорогой фичи vPC как у свитчей компании Cisco серии Nexus, в таком случае вместо интерлинков просто будет использован стек свичей. Да и вообще сервера и свитчи в такой схеме могут быть любого производителя. А если совсем всё туго с бюджетом, то можно использовать прямое включение в сервера, так если у сервера 2 порта на борту, можно будет подключить 4-ре сервера, а когда нужно будет добавить 5-й сервер, тут уж прийдётся покупать свитчи. Схема подключения FlexPod Express. Читать: https://habr.com/ru/articles/215351/ #ru @database_design | Другие наши каналы

Поддержка аппаратных снапшотов СХД NetApp в Veeam Backup & Replication v8 Одним из главных приоритетов современного резервного копирования, особенно в системах 24x7, является минимизация воздействия на производительность продуктивной сети. Хорошим вариантом решения, отвечающего этому приоритету, является создание дисковых снапшотов СХД на аппаратном уровне, так как оно не требуют вовлечения в этот процесс гипервизора, а алгоритм создания самих снапшотов оптимизирован разработчиками СХД на уровне аппаратуры. NetApp — компания, относящаяся к лидерам на рынке СХД, обладает одной из самых передовых технологий в области дисковых снапшотов. Эта технология позволяет NetApp предоставлять пользователям своих СХД эффективную, экономичную по ресурсам хранения и, в общем случае, незначительно влияющую на производительность продуктивной системы технологию защиты данных от сбоев. Особая сила NetApp всегда заключалась в программной части СХД — операционной системе ONTAP, которая предлагает пользователям полнофункциональную платформу хранения данных, а также в технологии создания снапшотов, на которой базируются хорошо масштабируемые технологии защиты данных, такие как SnapMirror (репликация между NetApp СХД) и SnapVault (резервное копирование данных). Читать: https://habr.com/ru/companies/veeam/articles/222147/ #ru @database_design | Другие наши каналы

Трансформация технологий хранения резервных копий: программные продукты и устройства дедупликации данных Рынок ориентированных на хранение резервных копий дисковых СХД измеряется миллиардами долларов. На этом рынке работает довольно много известных компаний, выпускающих продукты, которые уже стали хорошо известны во всем мире: EMC DataDomain, Symantec NetBackup, HP StoreOnce, IBM ProtectTier, ExaGrid и другие. C чего начинался этот рынок, и в каком технологическом направлении он развивается сейчас, как сравнивать разные программные продукты и устройства дедупликации между собой? Первые СХД с дедупликацией появились в начале 2000-х. Они были созданы для решения проблемы резервного копирования экспоненциально растущих данных. Рост данных в продуктивных системах компаний приводил к тому, что продолжительность резервного копирования на ленты увеличивалась настолько сильно, что полные резервные копии уже не «помещались» в окно резервного копирования, а применение в качестве бэкап-хранилища существовавших в то время дисковых СХД было затруднено из-за их недостаточной емкости. В результате бэкапы могли «обрываться» либо из-за недостатка времени (для случая лент), либо из-за недостатка места (для случая дисков). Проблему места на диске можно было решить покупкой СХД большой емкости, однако в этом случае возникала проблема высокой стоимости хранения. Читать: https://habr.com/ru/companies/veeam/articles/216753/ #ru @database_design | Другие наши каналы

Создание надёжного iSCSI-хранилища на Linux, часть 2 Часть первая Продолжаем Продолжаем создание кластера, начатое первой части. На этот раз я расскажу про настройку кластера. В прошлый раз мы закончили на том, что началась синхронизация DRBD. Если мы в качестве Primary сервера для обоих ресурсов выбрали один и тот же сервер, то после завершения синхронизации должны в /proc/drbd увидеть примерно такую картину: # cat /proc/drbd version: 8.4.3 (api:1/proto:86-101) GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by root@debian-service, 2013-04-30 07:43:49 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r----- ns:0 nr:190397036 dw:190397036 dr:1400144904 al:0 bm:4942 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0 1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r----- ns:0 nr:720487828 dw:720485956 dr:34275816 al:0 bm:3749 lo:468 pe:0 ua:0 ap:0 ep:1 wo:d oos:0 Самое интересное поле тут ds:UpToDate/UpToDate, означающее что и локальная и удаленная копия актуальны. После этого переведем ресурсы в secondary режим — дальше ими будет управлять кластер: # drbdadm secondary VM_STORAGE_1 # drbdadm secondary VM_STORAGE_2 Pacemaker Итак, менеджер кластера. Читать: https://habr.com/ru/articles/209666/ #ru @database_design | Другие наши каналы

Создание надёжного iSCSI-хранилища на Linux, часть 1 Часть вторая Прелюдия Сегодня я расскажу вам как я создавал бюджетное отказоустойчивое iSCSI хранилище из двух серверов на базе Linux для обслуживания нужд кластера VMWare vSphere. Были похожие статьи (например), но мой подход несколько отличается, да и решения (тот же heartbeat и iscsitarget), используемые там, уже устарели. Статья предназначена для достаточно опытных администраторов, не боящихся фразы «патчить и компилировать ядро», хотя какие-то части можно было упростить и обойтись вовсе без компиляции, но я напишу как делал сам. Некоторые простые вещи я буду пропускать, чтобы не раздувать материал. Цель этой статьи скорее показать общие принципы, а не расписать всё по шагам. Вводные Требования у меня были простые: создать кластер для работы виртуальных машин, не имеющий единой точки отказа. А в качестве бонуса — хранилище должно было уметь шифровать данные, чтобы враги, утащив сервер, до них не добрались. В качестве гипервизора был выбран vSphere, как наиболее устоявшийся и законченый продукт, а в качестве протокола — iSCSI, как не требующий дополнительных финансовых вливаний в виде коммутаторов FC или FCoE. С опенсурсными SAS таргетами довольно туго, если не сказать хуже, так что этот вариант тоже был отвергнут. Осталось хранилище. Разные брендовые решения от ведущих вендоров были отброшены по причине большой стоимости как их самих по себе, так и лицензий на синхронную репликацию. Значит будем делать сами, заодно и поучимся. В качестве софта было выбрано: * Debian Wheezy + LTS ядро 3.10 * iSCSI-таргет SCST * DRBD для репликации * Pacemaker для управления ресурсами кластера и мониторинга * Подсистема ядра DM-Crypt для шифрования (инструкции AES-NI в процессоре нам очень помогут) В итоге, в недолгих муках была рождена такая несложная схема: Читать: https://habr.com/ru/articles/209460/ #ru @database_design | Другие наши каналы

Оптимальная архитектура хранения резервных копий виртуальной инфраструктуры Как правильно спроектировать архитектуру хранилища резервного копирования виртуальной инфраструктуры? Прежде всего, нужно ответить на ключевой вопрос: “Что является главным приоритетом: минимизация использования дискового пространства, производительность или стоимость?” Ответ на этот вопрос определяет всю дальнейшую стратегию инвестирования в бэкап-инфраструктуру. На рисунке изображен один из оптимальных вариантов архитектуры инфраструктуры резервного копирования. СХД «первой линии» (на рисунке — это Backup Storage, изображенный слева от линии передачи данных), расположенное в непосредственной близости от оригинальных данных продуктивной сети, должно быть максимально быстрым (например, оно может быть построено на SSD дисках), но оставаясь при этом разумным по цене. Чтобы достичь такой цели, это хранилище должно иметь размер, достаточный для хранения только тех данных, которые с наибольшей вероятностью могут быть истребованы для восстановления при системном сбое или по запросу пользователей продуктивной сети. Например, если по вашей статистике до 80% запросов на восстановление приходятся на данные, созданные, модифицированные или удаленные за последние 30 дней, то только эти данные и нужно хранить на СХД «первой линии». При выборе этого СХД нужно учитывать следующие рекомендуемые свойства: Читать: https://habr.com/ru/companies/veeam/articles/206170/ #ru @database_design | Другие наши каналы

Введение в дедупликацию данных Введение В области обеспечения непрерывности бизнеса существует много различных проблем, связанных с быстрым ростом данных в современных IT инфраструктурах. На мой взгляд, можно выделить две основные: 1. Как запланировать место для хранения большого объема данных 2. Как сделать резервную копию этих данных Действительно, рост объема данных на терабайты в год у какой-нибудь крупной организации – сегодня вполне реальный сценарий. Но как быть с эффективным хранением и резервным копированием? Ведь в сутках есть максимум 24 часа и окно резервного копирования не может расти бесконечно (в отличие от самих данных). Сегодня я хочу рассказать, как дедупликация может помочь уменьшить остроту этой проблемы. Читать: https://habr.com/ru/companies/veeam/articles/203614/ #ru @database_design | Другие наши каналы

NetApp: Матрица совместимости Совместимость Не секрет, что далеко не всё всегда 100% совместимо, хотя казалось бы все протоколы, разъёмы, API приложений стандартизированы, что ещё нужно для нормальной работы инфраструктуры ЦОД? Даже если иметь два компонента взаимодействующих друг с другом, произведённых одним производителем само по себе работать оно не обязано, если туда не залить точно проверенные именно для вашего случая прошивки и конфигурации. Все производители имеют матрицу совместимости, где собрано множество оттестированных комбинаций оборудования, их прошивок, подключений и приложений. Настройка ЦОД'ов далеко не тривиальный процесс и для его упрощения рекомендуется во-первых следовать лучшим практикам, во-вторых пользоваться матрицей совместимости, которые уменьшают количество потенциально проблемных мест. Так использование проверенных и оттестированых конфигураций упрощает и ускоряет процесс запуска и эксплуатации ЦОД, уменьшает фактор человеческой ошибки. Широко применяйте этот подход в вашей практике для уменьшения потенциальных проблем в инфрастурктуре ЦОД. Читать: https://habr.com/ru/articles/154205/ #ru @database_design | Другие наши каналы

Dropbox — получаем дополнительные 9 Гб за один день Сервис Dropbox я начал использовать совсем недавно. Кстати, когда попробовал, долго недоумевал, почему я начал использовать его только сейчас, хотя слышал о нем давно — уж очень удобно все. Как известно, после регистрации для бесплатного аккаунта доступно пространство в 2 Гб. Это пространство можно увеличить до 11 Гб различными способами. Далее я расскажу несколько подробнее обо всех известных способах, а так же будет небольшой лайфхак. Читать: https://habr.com/ru/articles/120378/ #ru @database_design | Другие наши каналы

Amazon запускает бесплатное хранилище файлов и музыки Новый сервис Amazon Cloud Drive позволит пользователям бесплатно хранить 5 Гб данных, которые можно будет загружать через браузер или через stand-alone клиент для Maca и Windows. Основным сценарием использования Amazon считает хранение музыки, поэтому в дополнение выпущен Amazon Cloud Player (встроен в приложение Amazon MP3, пока доступен только на Android). Единственное огорчение — на данный момент сервис не работает в Opera. Еще подробности: — Хранить можно не только mp3 или aac (DRM-файлы не загрузятся), но и видео, картинки и любые документы. — Если вы покупали mp3 у Amazon — они не будут учитываться в размере хранимых файлов — Если вы покупали альбомы у Amazon — вам накинут еще 20 GB на 1 год — Пространство сверх 5 Гб можно будет докупать ($20 за 20Гб, $50 за 50 и $100 за 100, а еще $1000 за терабайт :) Читать: https://habr.com/ru/articles/116420/ #ru @database_design | Другие наши каналы

Цифровая вселенная выросла до 1,2 зеттабайта Информационные потоки продолжает нарастать в геометрической прогрессии (впрочем, кто бы сомневался). Согласно последним оценкам IDC, в 2010 году объём цифровой информации, создаваемой и копируемой, достигнет 1,2 зеттабайта (то есть 1,2 миллиарда терабайтов). Масштаб этой цифры можно оценивать по-разному. Например, это 109 библиотек Конгресса или стопка DVD-дисков высотой до Луны1. Примерно 75% созданной в мире информации — копии, и только 25% является оригинальными данными (домашнее HD-видео, фотографии, научные данные и т.д.). Читать: https://habr.com/ru/articles/92831/ #ru @database_design | Другие наши каналы

Lose/Lose — поиграй и потеряй все файлы на винчестере Время скролл-шутеров давно и безвозвратно ушло. Чтобы сегодня игра в этом жанре заинтересовала хоть кого-то, это должно быть либо Touhou, либо что-то действительно неожиданное и необычное. Парень с ником Zach сделал в своей игре Lose/Lose потрясающую фичу: при уничтожении каждый кораблик противника стирает случайный файл на винчестере. Больше описывать нечего, можете посмотреть видео и даже скачать. Но я бы на его месте пошел еще дальше. Представьте, что проигрыш или выход из игры вызывал бы форматирование диска! Причем об этом сообщалось бы уже после запуска. О-о-о, это был бы хит. Сделайте кто-нибудь, а? источник Читать: https://habr.com/ru/articles/71111/ #ru @database_design | Другие наши каналы

Файловые системы — отстой Компьютеры пришли в народ из мира инженеров. А в мире инженеров реализация всегда превалирует над интерфейсом. Вот и с файловой системой так. Несмотря на на колоссальный скачок от перфокарт к EXT3 или NTFS, интерфейс файловой системы остается таким Каким? Читать: https://habr.com/ru/articles/68092/ #ru @database_design | Другие наши каналы

Сказ о том, как поднимался упавший fake RAID 0 … или, точнее говоря, — как я восстанавливал данные с положеного мною nVidia RAID 0. Завязка Собственно, прелюдия. Живёт у меня дома комп, контроллер IDE у него реализован в nVidia MCP65. У данного контроллера есть опция, превращающая его в RAID-контроллер с поддержкой RAID 0 и RAID 1. В моём случае — RAID 0 из двух Samsung'ов по 250 Гб каждый. Вобщем, ничего сверхестественного, набортным RAID'ом удивить сложно было уже 5 лет назад, не то что в наше время. Если кого-то заинтересовала приставка «fake» — так принято называть полуаппаратные реализации RAID. Разберём на пальцах. Читать: https://habr.com/ru/articles/67229/ #ru @database_design | Другие наши каналы

Настройка HADR на серверах DB2 и Настройка ACR на серверах Websphere HADR инструмент DB2, реализующий зеркалирование баз данных. ACR механизм в Websphere позволяющий в случае падения базы, автоматически переключать клиентов на резервный сервер. Ниже расскажу как настраивал обе эти штуки 8-) Читать: https://habr.com/ru/articles/219053/ #ru @database_design | Другие наши каналы

Статистика ожиданий SQL Server'а или пожалуйста, скажите мне, где болит Сколько раз вы испытывали проблемы с производительностью SQL Server'а и решали, куда именно смотреть? Одна из самых редко используемых методологий устранения проблем с производительностью SQL Server'а называется «Ожидания и очереди» (также известная как «статистика ожиданий»). Основная предпосылка методологии состоит в том, что SQL Server постоянно отслеживает, какие потоки выполнения должны ждать. Вы можете запросить у SQL Server'а эту информацию для того чтобы сократить перечень возможных причин проблем с производительностью. «Ожидания» — это то, что отслеживает SQL Server. «Очереди» — это ресурсы, доступ к которым ожидают потоки. Система обычно фиксирует огромное количество ожиданий, и все они означают ожидание доступа к различным ресурсам. Для примера, ожидание PAGEIOLATCH_EX означает, что поток ожидает чтения страницы данных с диска в буферный пул. Ожидание LCK_M_X означает, что поток ожидает возможности наложить эксклюзивную блокировку на что-то. Отличная новость состоит в том, что SQL Server знает, в чем именно заключаются проблемы с производительностью, и все что вам нужно — это спросить у него… и потом правильно интерпретировать то, что он скажет, что может быть немного сложнее. Читать: https://habr.com/ru/articles/216309/ #ru @database_design | Другие наши каналы

Ускоряем базу данных. Bcache Для работы мы используем postgresql + postgis базу данных с данными для всей планеты от osm.org. На диске она занимает около 350 Gb и работает не быстро, да и хранится на обычном винчестере 2Tb 7200rpm, без RAID-a. Т.к. нагрузка на базу данных постепенно растет, было решено ускорить дисковую подсистему, потратив при этом минимум денег. Вариантов было не много: * купить еще один такой же винчестер и объединить их в raid-0. * купить небольшой SSD и организовать на нем быстрый кэш: * dm-cache. Был добавлен в ядро 3.9, ставится просто. * bcache. Судя по обзорам самый быстрый. Основной минус — надо форматировать диски перед началом использования. Официально добавлен в ядро 3.10, распространяется как пропатченое ядро 3.9. * EnhanceIO. В обзорах я встретил упоминание его, как самого медленного, но простого в использовании. Взвесив плюсы и минусы, а так же спросив отзывы знакомых, я решил остановиться на bcache. О нем и расскажу подробнее. Читать: https://habr.com/ru/articles/182372/ #ru @database_design | Другие наши каналы