Рубрика «хранение данных» - 100

Простые решения. Прокачиваем картинки - 1

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

Добрый день читатели!

Блог компании HGST после некоторого перерыва снова с вами. И сегодня мы хотели бы поговорить о преимуществах твердотельных накопителей SAS перед накопителями с интерфейсом SATA.

Интерфейс SAS, поддерживающий связь между устройствами, предназначен для использования на корпоративном уровне и обеспечивает масштабируемость, надежность работы и высокую доступность данных, в то время, как устройства с интерфейсом SATA оптимизированы для более дешевых пользовательских приложений.
Читать полностью »

В этой статье я хочу рассказать про ещё один этап развития DWH в Тинькофф Банке.

Ни для кого не секрет, что требования к наличию Disaster Recovery (далее DR) в современных бизнес информационных системах относятся к категории «must have». Так, чуть более года назад, команде, занимающейся развитием DWH в банке, была поставлена задача реализовать DR для DWH, на котором построены как offline, так и online процессы банка.

Проект Dual ETL или как мы строили Disaster Recovery для Greenplum - 1

Читать полностью »

Не спешите выкидывать старые серверы, из них можно собрать быструю Ethernet-СХД за час - 1

Однажды мы ставили новые дисковые полки для массива EMC у одного из наших крупных клиентов. Когда я уходил с объекта, то обратил внимание на людей в форме транспортной компании, которые вытаскивали из стоек и готовили к погрузке большое количество серверов. С сисадминами заказчиков общение идёт плотное, поэтому довольно быстро выяснилось, что это серверы — старые машинки, в которых мало памяти и процессорной мощности, хотя дисков стоит в избытке. Обновлять их не выгодно и железки будут отправлены на склад. И их спишут где-то через год, когда они покроются пылью.

Железо, в целом, неплохое, просто прошлого поколения. Выкидывать, естественно, было жалко. Тогда я и предложил протестировать EMС ScaleIO. Если коротко, работает это так:

Не спешите выкидывать старые серверы, из них можно собрать быструю Ethernet-СХД за час - 2

ScaleIO — это софт, который ставится на серверы поверх операционной системы. ScaleIO состоит из серверной части, клиентской части и нод управления. Дисковые ресурсы объединяются в одну виртуальную одноуровневую систему. Читать полностью »

В продолжение статьи о парадигме резервного копирования NetApp, хочу рассказать о недокументированной возможности преобразования «архивных копий» в «резервные» для серии FAS. Отличительной чертой СХД компании NetApp серии FAS является то, что они все унифицированы. Унифицированность не только в том, что одно устройство предоставляет доступ хостам как по блочным, так и по файловым протоколам, но и по способу применения. Системы FAS используются для виртуализации, для Data Compliance, для хранения архивных копий, для построения Disaster Recovery решений и т.д. Одна и та же СХД может выполнять сразу множество функций. Так для каждой функции не нужно держать одно «специализированное» устройство, а в случае если срочно понадобится «запасная» СХД, её всегда можно «перепрофилировать» из того что есть, к примеру из СХД для архивации данных. Благодаря этой универсальности нет необходимости переобучаться под каждую из этих задач ведь операционная система, командная строка и все принципы настройки одни и те же для всех FAS систем.

В этой статье я расскажу как построенное решение «Архивация данных на NetApp» переделать в решение «Disaster Recovery».

С точки зрения бизнеса Disaster Recovery и архивирование отличаются тем, что:

  • Архивирование (SnapVault) — решение предназначено для длительного хранения и защиты данных от изменений, для последующего восстановления их туда, откуда они были скопированы (или в другое место).
  • Disaster Recovery (SnapMirror) — хранение данных на резервном сайте, для переключения на него (и соответственно изменения данных), в случае катастрофы.

Поясню на примере: когда у вас есть хотя бы две СХД с настроенной репликацией SnapMirror, в такой схеме одна из них играет роль источника (primary), а вторая роль приемника (Secondary). В случае аварии, при разрыве репликации (командой break, а не просто разрыв линка), принимающая (Secondary) система переведёт реплицируемое зеркало из режима read-only в режим read-write. Т.е. это инструмент для создания решения «Переключение на запасную площадку в случае аварии» (Disaster Recovery). Логично, чтобы обе системы были плюс-минус одинаковой производительности, чтобы обеспечить все переключённые узлы с одного сайта на другой, должным уровнем производительности.

7-Mode: Недокументированные возможности или делаем DR из SnapVault - 1

В то время, как SnapVault предназначен для архивирования на резервную (Secondary) систему, чтобы потом из неё восстановить все данные обратно на первичную систему или вообще на третью систему. Стоит отметить, что для задач архивирования очень важно хранить данные в неизменённом состоянии все время. В данном случае вторичная система, куда складываются все архивы, может быть любой модели. Здесь логично иметь самую дешевую модель NetApp FAS с медленными и дешевыми дисками большего объема. К примеру, FAS2554 или FAS2520.
Читать полностью »

В наше время сооружение дата-центров стало весьма обыденным событием. К этому естественно привело то впечатляющее и все возрастающее на протяжении последнего десятилетия количество, такого рода, новых сооружений. Типовые проекты производственных зданий, совершенно безликих, как внутри так и снаружи, задвигают на второй план ту важную роль которую они осуществляют в современном мире. ЦОД о который далее пойдет речь – это скорее исключение из правил. Более необычной ИТ-инфратструктуры не стоит даже и искать. Этому есть целый ряд удивительных причин. Размещенный глубоко под землей, в недрах горы швейцарских Альп – Форт Кнокс (Fort Knox) – дата-центр, который стал обязан своему созданию компании SIAG. Осуществление проекта стало следствием понимания руководством компании тех простых вещей, что информация – это ценность сродни золоту. Даже само название ИТ-комплекса не случайно перекликается со всем известной военной базой в штате Кентукки, США, которая в свою очередь является одним из наиболее известных в мире хранилищ золота. Давайте же рассмотрим более детально на сколько тщательно «дух горы» бережет свои сокровища.

Горный ЦОД - 1Читать полностью »

Онлайн-конференция по серверам HP — всего 10 дней, чтобы выиграть 2 планшета - 1 Недавно мы подумали — а почему бы не сделать онлайн-конференцию по серверам HP? Как те, что мы регулярно проводим вживую для наших партнеров и заказчиков. И сделали, конечно на Хабре. Что у нас получилось вы можете видеть здесь: special.habrahabr.ru/hp/o/. И у нас там даже есть конкурс, где вы можете выиграть один из планшетов HP SlateBook x2!

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

Мы считаем, что оценивать сервер нужно сразу по нескольким критериям. И на первом плане — стоимость владения сервером на всем протяжении его жизни. Которая в среднем уже перевалила за 5 лет — и все это время сервер нужно будет обслуживать, вкладывая свое время и деньги.

В нескольких коротких докладах мы рассказали:
Читать полностью »

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

Р. Брэдбери

Введение

В статье описан Backend-as-a-Service подход к хранению и обработки данных. Рассказаны преимущества и недостатки представителя такого подхода — сервиса parse.com. Коротко представлен сервис аутентификации пользователей через соц. сети uLogin. Основное назначение — показать, как эти два сервиса могут взаимодействовать, чтобы проект не требовал регистрации пользователей по логину и паролю, но в то же время сохранилась возможность авторизации пользователей к действиям над объектами.

О BaaS и parse.com

Parse.com — один из самых популярных провайдеров backend-as-a-service (BaaS). BaaS подход позволяет не поднимать свой сервер для хранения и обработки данных приложения. Это используется в мобильных разработках и в обычном вебе. Parse.com имеет свои SDK под несколько платформ, в том числе серверных. Но я расскажу о javascript.

Возможность работать с базой данных через javascript, не поднимая свой сервер, открывает отличные возможности, например, для Single page application (SPA), которое можно хостить на Github Pages, Bitbucket и многих других бесплатных. Первый вопрос, который у меня возник, когда я услышал про работу с БД из клиентского кода — это разграничение прав доступа, так как ключи общеизвестны. Изучив документацию parse.com, я выяснил, что для этого используется авторизация пользователей. Каждый пользователь имеет свой логин и пароль. SDK имеет методы регистрации нового пользователя по логину и паролю, аутентификации по этим же данным. Можно добавить email, при этом сам parse.com умеет отправлять настраиваемые письма для верификации email.
Читать полностью »

В продолжение темы об оптимизации хоста с VMware ESXi, рассмотрим как поступать со Swap'ом в инфраструктуре живущей на СХД NetApp FAS. Хотя эта статья должна быть полезна и не только владельцам систем NetApp FAS.

Одна из важнейших возможностей виртуализации заключается в возможности более эффективно утилизировать серверное оборудование, что подразумевает Overcommit ресурсов. Если мы говорим об ОЗУ, это означает, что мы можем настроить каждой виртуальной машине больше памяти, чем есть на сервере на самом деле. А дальше мы полагаемся на ESXi, чтобы тот разрулил борьбу за ресурсы — забрал (такой процесс часто называют reclamation) не нужную память одной виртуальной машины и отдал той, которая в ней действительно нуждается. В тот момент когда не хватает памяти, начинается процесс свапинга памяти.

Начнём с того, что есть два типа свапинга которые могут происходить на ESXi хосте. Их очень часто путают, по-этому давайте условно будем называть их Тип 1 и Тип 2.

NetApp FAS и VMware ESXi: Swap - 1
Расположение данных VMware ESXi по-умолчанию
Читать полностью »

Вопросы про индексы, которые вам не надо будет задавать - 1

После ответов на 14 вопросов об индексах, которые вы стеснялись задать, у меня возникло гораздо больше комментариев, уточнений и исправлений. Скомпилировать из всего этого статью выглядело затеей с минимумом пользы. И это заставило меня призадумался, а почему вообще мы должны «стесняться задавать» подобные вопросы? Стыдно не знать? А есть ли способ разобраться, не вгоняя себя в краску? Есть. Причем он избавит от многочисленных неточностей, которыми изобилуют многие «ответы». Вы будете чувствовать буквально каждый байт вашей базы кончиками своих пальцев.

Для этого, я предлагаю «поднять капот» у SQL Server и окунуться в сладостный мир шестнадцатеричных дампов. Может статься, что внутри все гораздо проще, чем вам казалось.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js