Чи є хороший спосіб створити резервну копію петабайт даних і зберегти їх?

Я починаю бачити клієнтів із сотнями терабайт даних (в установках SQL Server). Оскільки загальний обсяг даних на деяких підприємствах наближається до значущих часток петабайт, я хотів би створити колективну базу знань там, щоб побачити, що люди роблять з такою величиною даних, щоб їх захистити.

Очевидна проблема полягає в тому, що зберігання декількох резервних копій такої кількості даних є надмірно дорогим, використовуючи сховище корпоративного класу, чортів, навіть просто RAID-5.

Я бачу такі варіанти:

1. Створіть дзеркальну копію даних в іншому центрі обробки даних і постійно надсилайте до неї відмінності (використовуючи будь-який механізм, доступний для вашого джерела даних - наприклад, доставка журналів або дзеркальне відображення бази даних за допомогою SQL Server)
2. Робіть регулярні резервні копії, використовуючи потужний алгоритм стиснення (мабуть, підходить лише тоді, коли дані добре піддаються сильному стисненню)
3. Візьміть поодинокі резервні копії критичних / мінливих частин даних.
4. Не створюйте резервні копії даних і не довіряйте корупціонерам.

Я бачу, що варіант №4 приймається за замовчуванням, і як експерт HA / DR це дуже страшно, але що я раджу як альтернативу? Я думаю, що №1 є найкращим підходом, але "я не думаю так" - це звичайна відповідь, коли пропонуються будь-які альтернативи, крім №4 та, можливо, №3.

Тепер, звичайно, це залежить від швидкості зміни та критичності даних. Не потрібно відповідати на це, оскільки я відповідав за всі функції HA на SQL Server, коли я працював у Microsoft, тому я добре розбираюся в аргументах "це залежить" - ось моя фраза :-)

Мені б дуже цікаво почути будь-які альтернативи, які я пропустив, або почути, що всі інші знаходяться в одному човні, і немає реальної альтернативи витрачати багато грошей на більше місця зберігання.

Заздалегідь дякую - всі належно продумані та висловлені відповіді будуть надані належним чином.

Ідея стіни - чи потрібна чи корисна вся збережена інформація?

Скільки коштує насправді інформація? Здається, очевидно смішно витрачати більше на обслуговування та управління, ніж варті дані.

Чи підходять дані в базі даних для зберігання в базі даних? Наприклад, чи дійсно зберігання стислих багатогігабайтних основних файлів у базі даних організації підтримки надає фактичну користь?

Чи є в базі даних багато дублюваних даних? Наприклад, чи тисяча людей зберігає по десять примірників кожного щомісячного інформаційного бюлетеня по 10 МБ?

Чи є у деяких даних "дата закінчення терміну придатності", після якого вони не надають ніякого значення? Повертаючись до прикладу організації підтримки, з різних причин практично немає користі зберігати основні файли клієнта більше ніж через кілька місяців після доставки виправлення.

Інша думка - зберегти стільки даних, що відкривають компанію зобов’язанням. Деякі дані потрібно, за законом, зберігати. Однак деякі дані слід "подрібнити" через ризики, якщо вони випадково або зловмисно передаються неналежним сторонам.

Так, інший варіант - віртуалізація пам’яті: пристрій, який сидить між вашими серверами та SAN, як IBM SVC. SVC керує копіями від SAN до SAN і може робити віддалену реплікацію (хоча це, очевидно, досить болісно на рівні петабайт, якщо у вас дійсно низькі показники зміни даних та дійсно висока пропускна здатність.)

Ефектна частина полягає в тому, що весь процес невидимий для залучених серверів. Якщо ви використовуєте SQL Server, ви створюєте свої файлові групи, щоб зберігати разом речі з низькою швидкістю зміни (наприклад, архіви продажів від> 3 роки тому), а також речі з високим коефіцієнтом зміни (наприклад, поточні продажі) в окремій групі файлів. Вони навіть не повинні бути повністю доступними лише для читання - ви просто хочете розробити це так, щоб ви могли використовувати різні методи реплікації для кожної групи файлів. Пристрій SAN може синхронізувати луна через мережу, стрічку або через SAN - це означає, що ви можете перевозити частини SAN назад і назад. Це ефективніше із передачами типу LeftHand's, де SAN складається з пулу учасників.

Тоді ви можете синхронізувати матеріал із низькою швидкістю зміни через провід і синхронізувати високу швидкість зміни за допомогою кросівок. (Здається, у мене це назад, але це правда - ви не можете синхронізувати інформацію про високу швидкість зміни по дроту через об'єм.) Навіть деякі передачі низького класу вміщують це зараз: LeftHand дозволяє вам реплікувати на інші Залиште одиниці LeftHand у вашому центрі обробки даних, а потім відправте їх у свій центр обробки даних. Підключіть їх, приєднайте їх до віддаленої сторони, змінивши IP-адреси та групи, і тепер вони є частиною вашого віддаленого резервного копіювання SAN. Крок продажів LeftHand у цьому просто чудовий: встановіть два ваших SAN в основному центрі обробки даних, синхронізуйте їх, потім ви зможете відправити їх частини у віддалений центр обробки даних, а деякі з них залишаться у вашому поточному центр обробки даних, який слід синхронізувати. Поступово рухайтеся '

Я ще цього не робив на рівні петабайт. Ви знаєте, що вони кажуть - теоретично, теоретично і на практиці одне і те ж. На практиці...

Варіант 1 - це дзеркальне відображення, що майже так само погано, як і №4: будь-яка помилка, яка пошкоджує дані, і не буде виявлена ​​негайно, зіпсує обидві копії.

Якщо дані є критичними, розгляньте спеціальні рішення; читайте, наприклад, про продукти Shark від IBM, або про конкурентоспроможні продукти від EMS тощо. Вони мають такі функції, як Flash-копія, що дозволяють миттєво створити логічну копію файлу без подвоєння вимог до диска; а потім ви можете створити резервну копію цієї копії на (наприклад) стрічці. Перегляньте також резервну копію робототехнічної стрічки.

Зверніть увагу на тих, хто хоче зберігати Petabyte даних, які зберігають недешево.

Мені так набридло людей, що стогнуть про те, що у вас немає додаткового терабайтного онлайн-сховища, тому що диск дешевий - диск може бути, але кероване сховище впевнене, що це не так.

Якщо зберігати резервні копії надмірно дорого, то зберігати дані надмірно дорого безпечно, тому запропоноване рішення не є життєздатним.

Однією з найважливіших причин створення резервних копій є захист від помилок користувача (більшість проблем з помилкою обладнання може бути вирішено апаратними рішеннями), але навіть дзеркальне відображення баз даних не є захистом від скинутої таблиці (ОК, ви можете захистити від цього, але все одно можна отримати непомітний guff у вашій БД - якщо тільки причина БД не така велика, це те, що вона видає лише вставки).

Як я бачу, стрічка вже не є життєздатним рішенням - тепер дешевше працювати з дисковими масивами (хоча фізичне зберігання може бути незручним). Тому я думаю, що ваш єдиний варіант - це певний метод розподілу даних на шматки, достатньо малий, щоб їх можна було відновити в розумний часовий період, а потім регулярно отримувати їх на сховищі дисків (і ось рішення типу EMS можуть допомогти, якщо у вас є готівкою).

Цікаве відео з деталізацією архітектури myspace.com (бекенд SQL2005). Не впевнений, чи є у них окремі петабайт-коди, оскільки вони масштабуються за допомогою декількох dbs. Вони використовують швидкі резервні копії SAN.

http://wtv.watchtechvideos.com/topic70.html

ZFS. Звичайно, це все ще тільки починається, але є ряд напрямків, де ZFS призначений для обробки саме таких речей. По-перше, це здатність обробляти велику кількість даних, а також безліч різних пристроїв зберігання даних (локальних, SAN, волокон тощо), при цьому зберігаючи дані в безпеці за допомогою контрольних сум і "шару, що порушує" обізнаність про стан пристрою і невдачі. Як же це допомагає вирішити резервну копію такої кількості даних?

Один із способів - використовувати знімки. Зробіть знімок, надішліть його на стрічку / диск / мережу для передачі на віддалений сайт. Подальші знімки надсилають лише надіслані дані, і ви можете зберігати живі дані на обох кінцях, якщо потрібно.

Інша полягає у використанні програмного забезпечення Solaris Cluster, де (доки у вас є достатня пропускна здатність мережі), ви можете мати дзеркальне відображення між двома серверами, і якщо один знизиться, другий може перейняти. Це більше для використання там, де важлива висока доступність (HA), але я б здогадався, що більшість місць з такою кількістю даних хочуть HA.

І ви кажете, що ZFS не підтримується в Windows, звичайне місце, де ви можете знайти sqlserver, можливо, ви запустите Sun / ZFS на бекенді та підключитесь через iSCSI. Можливо, це теж жахлива ідея, але, принаймні, варто задуматися, щоб ви знали, що не робити.

Ви розглядали льодовик Амазонка як варіант?

IMO, якщо у вас є якесь обладнання на рівні godzilla, якщо у вас є стільки даних, ви повинні використовувати технологію резервного стиснення. Я найбільше знайомий з LiteSpeed, але є подібні продукти інших постачальників і (звичайно) подібна функція вбудована в SQL2008. Ви можете не стиснути 10 на 1, але це зменшує вимоги до зберігання резервної копії, а також може зменшити вимоги до вікна резервного копіювання. Якщо ваша мета - зберегти декілька наборів резервних копій (вчора плюс день до цього, плюс один з минулого тижня і один з минулого місяця, або ряд диференціалів плюс цілі, які можуть отримати досить багато, якщо змінити багато даних у база даних), це просте питання простору зберігання.

Резервне копіювання на основі файлової групи (IOW, розміщуючи енергонезалежні дані на певних FG та на звороті вгору нечасто) ніколи не здається, тому що розробники чи користувачі не можуть чи не можуть вирішити, які дані є мінливими, а що ні, і в brownfield сценарії, за якими часто ви не можете ризикувати.

Якщо веб-сайт з відмовою є необхідністю, окрім роздумів про дзеркало баз даних), можливо, ви захочете поговорити з постачальником пам’яті своїх клієнтів, щоб дізнатися, чи пропонують вони щось на зразок SRDF, що є апаратною технологією реплікації даних. Звичайно, реплікація (будь-якого типу, але особливо в режимі реального часу чи майже в реальному часі) не є заміною резервного копіювання.

Я не думаю, що у вас тут великий вибір на стрічці V. Стрічка, ймовірно, не буде вирізати її у звичайному резервному вікні, якщо ви її не будете розкреслювати, і я не впевнений, що надійність є.

Таким чином, ви переходите до резервного копіювання диска. Ви версії? Значить Ви турбуєтесь про повернення до резервної копії 2 (поточний db мінус 2 резервних копій)? Або резервна копія 3? У цьому випадку у вас можуть виникнути проблеми, але ймовірно, що вам доведеться обробити резервні копії журналу, а не стільки резервного копіювання даних.

Якщо ви можете розділити деякі дані як лише для читання / не змінювання, можливо, у вас є керовані розміри резервного копіювання / windows. Або принаймні ви сподіваєтесь, що технологія резервного копіювання та пропускна здатність наздоганяють зростання даних.

Я не думаю, що ти створюєш резервну копію стільки, скільки ти зберігаєш другу копію, щоб відновитись після проблем із основним. Це означає апаратне забезпечення, корупцію тощо. Ви щодня молитеся, щоб помилки не надсилалися до другої копії. Копії, швидше за все, робляться SAN-SAN, з деякою технологією оснащення. хоча оригінальна копія може бути через Fed-Ex, а не через провід. Пропускну здатність для переміщення в 100 Тб не легко подолати для когось.

Я думаю, що вам потрібна комбінація 1, 2 і 3 (а не 4) з відмінним керуванням резервного копіювання журналу.

Насправді я думаю, що в будь-який момент часу ти справді переглядаєш 3 копії своїх даних. Запуск CHECKDB на 1 з копій, а другий примірник використовується для фактичного отримання змін. Потім ви знімаєте цю другу копію першої та продовжуєте. Маючи стільки даних, я думаю, що вам тут знадобиться певна ретельність. Пол, як працює checkdb на багатокористувацькому, 100TB db, який є в Інтернеті?

Як уже згадувалося, чи не є резервними копії журналів і, можливо, зчитувач журналів? Чи не потрібно відновлювати таблиці падіння / помилку користувача з журналів, а не резервну копію? Потенційно можна зробити це ярликом, надсилаючи копії SAN через деяку затримку, але я не бачив цієї технології. SAN Доставка журналу, який може затримати зміни на 4 години (або деякий інтервал), щоб ви могли відновитись із проблем перед перезаписом даних. Або якийсь інструмент для читання журналів журналу SAN-блоку змін? Без цього вам потрібно керувати тими журналами транзакцій, які можуть бути зовсім іншим рівнем відстеження цих резервних копій у різних файлових системах протягом декількох ххх годин, щоб ви могли потенційно відновитись від нефатальних помилок.

Технічно, зберігання є дешевим, але і на рівні петабайт, не так багато. Це дійсно залежить від програми, але я б сказав, що комбінація стратегій №2 і №3 стане відповіддю, при цьому №2 буде надано, а №3 - залежно від того, скільки інвестицій ви можете зробити в сховище та тип накопичувальний та IO / обчислювальна потужність, яка дозволить вам уникнути якнайменшої інкременталізму та максимально дискретного, повного резервного копіювання.

Крім того, щось на зразок Amazon S3 також може вступати в гру залежно від вашої пропускної здатності та того, скільки змін є в даних - при такому обсязі розміщення принаймні частини цього на чужих серверах і дозволяючи їм турбуватися про надмірність стає все більше і більше економічно ефективним.

Зверніться до постачальника пам’яті, вони матимуть продукт дедуплікації, який вони використовували раніше, у поєднанні з регулярним стисненням ви часто можете знизити слід на 70%. Звичайно, у кожного, хто має гроші, витрачені на петабайт сховища, також, ймовірно, буде достатньо бюджету, щоб придбати гідне резервне рішення - якщо їх немає, то вам просто потрібно запитати у них, яка втрата цього петабайта коштуватиме їхньому бізнесу.

У великому корпоративному сховищі даних значна частина даних надходить із вже створених резервних копій. Я працював над установками Teradata та ODW, де вони взяли варіант №4, але знали, що вони можуть відновити день чи два транзакційних даних і перетворити їх з вихідних систем.

Одного роздрібного клієнта (у той час у них було одне з 5 найбільших DW у світі, близько 200 ТБ ... дає уявлення про те, як давно це було), вони поїхали з варіантом №1 після придбання нового Petabyte -клас-сервер Teradata. Старі вузли використовувались для зйомки системи попереднього дня, а новий підтримував існуючий. Це було також приємно з точки зору настання аварійних ситуацій - раз у той час вони братимуть на обслуговування все, і ми просто переходимо до використання старого повільного сервера з давніми даними.

Чесно кажучи, здавалося, що це велика трата переробки / зберігання / тощо, щоб продовжувати справу ... особливо, коли найбільша перевага полягала в тому, що їх адміністратори та техники NCR повинні були проводити менше вечорів, щоб виконати нерегулярне обслуговування.