Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6   вперед  Ctrl      все
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
killed
[quot --Попрошайка--]

массив - я так понимаю имеется в виду RAID-группа.
Вобщем перечитав все еще раз, я понимаю это так, что есть ошибки в планировании дискового пространства. Массивы (System Storages в вашей терминологии) разные по характеристикам.
Общая эффективность от того, что данные обеих баз (оракл и мс сиквел) лежат на RAID-группах разных стораджей - не возрастает. Посоветую реорганизовать пространство так, чтобы каждая база лежала в пределах одного массива. Если массив Б хуже по характеристикам выносите туда всякие файлопомойки и прочее, что не имеет отношения к вашим базам.

Еще, если это не связано с архитектурой массива (есть такие хитрожопые массивы типа IBM XIV), то это непавильно шарить RAID-группу (одни и тежи диски) между разными потребителями, в вашем случае двумя базами данных


Массив - RAID группа,
System Storages - сама железка (полка)
Железка А имеет RAID группу 400 дисков, железка Б имеет RAID группу 100 дисков.
Имеем две железки - сервер С1 (Oracle) и сервер С2 (SQL Server)/
RAID группа на железке А делится на два логических куска и раздается серверу С1 и С2 - каждому по кску разного размера (RAID группа одна).
Далее жили не тужили, пока железка А не уперлась в физическое ограничение или еще какое-то событие, которое повлекло покупку железки Б.
С железкой Б поступили аналогичным образом, а именно собрали одну RAID группу, логически разделили ее на два куска и эти куски средствами ОС прозрачно прилепили к кускам от железки А.
Таким образом, на уровне ОС для нас это просто один диск и ни база ни приложение даже не подозревает, что вновь появляемы файлы данных располагаются уже на железке Б, которая хуже.
Дальше больше. Купили железку С, которая что-то среднее между А и Б и так же прилепили все это на уровне ОС в одно что-то ллогическое.
Так выглядит развитие.
Теперь сталкиваемся с двумя проблемами:
1. отсутствие послойной работы и как следствие отсутствие однозначности (это я про бедные SQL запросы, которые дергают данные с разных по производительности, например, RAID групп)
2. сложное обслуживание, так как все железки и RAID группы на них со своими тараканами, но живем мы все вместе.

Про эффективность я имел ввиду, что, как мне кажется RAID группа с 400 дисками лучше, чем RAID группа с 20 (это когда речь идет не о добавлении дисков в RAID группу, а про сборку дополнительной RAID группы из 20 дисков и на уровне ОС приклеиванием ее к группе из 400).
6 июн 10, 02:05    [8897972]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
Андрей Панфилов
--Попрошайка--
А, собственно, тема предназначена чтобы понять, как люди НЕ приходят к такой конфигурации и вообще как лучше развивать.
Ничего страшного в этом нет, более того, все наоборот стараются перетаскивать редкоиспользуемые данны на более медленные (дешевые) носители.


Это когда речь идет про DWH, где есть четкое понимание областей, а если это большие OLTP или консолидированное решение небольших OLTP?
6 июн 10, 02:07    [8897974]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
--Попрошайка--

Массив - RAID группа,
System Storages - сама железка (полка)
Железка А имеет RAID группу 400 дисков, железка Б имеет RAID группу 100 дисков.


не верю. Сторадж - это ящик с дублированным питанием, сторадж-процессорами, и _многими_ дисковыми полками (enclosures), обычно 12-15 дисков на полку.
RAID-группа в 400 дисков - это нонсенс. Давайте уже огласите названия железок что-ли
6 июн 10, 02:11    [8897976]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
killed
--Попрошайка--

Массив - RAID группа,
System Storages - сама железка (полка)
Железка А имеет RAID группу 400 дисков, железка Б имеет RAID группу 100 дисков.


не верю. Сторадж - это ящик с дублированным питанием, сторадж-процессорами, и _многими_ дисковыми полками (enclosures), обычно 12-15 дисков на полку.
RAID-группа в 400 дисков - это нонсенс. Давайте уже огласите названия железок что-ли


Ну блин количество дисков конечно я выдумал, чтобы было понятно о чем идет речь, но в рахных RAID группах оно разное. Все железки разные DSxxxx.
6 июн 10, 02:15    [8897978]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3778
--Попрошайка--,

если у Вас OLTP, то довольно станно почему место на стораже закончилось (быстрее иопсы заканчиваются), относительно того, что лучше данные хранить на большом стораже нежели на маленьком Вы не правы - RIAD массивов с таким количеством дисков (400) не бывает (как пример, не сочтите за рекламу: RAID1/0: Data mirrored, then striped across four to 16 drivers)
6 июн 10, 02:21    [8897979]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
--Попрошайка--,

IBM, понятно. Даже если у вас младшие модели 4000 серии, это надо постараться забить под завязку. Я подозреваю, что у вас там еще какое-то говнище складировано помимо баз. Вот его и нужно мигрировать на худший массив. Далее потихоньку освобождать диски и перегруппировывать, чтобы каждая база лежала на своих дисках, а может быть даже и на разных массивах.

Что касается послойного управления дисковым пространством - речь идет о разных типах дисков в сторадже, а не с разными стораджами. И это перпендикулярно OLTP или DWH у вас. Если есть данные с привязкой ко времени, то partitioning + compression. Можно даже заниматься ручным управлением для конкретных таблиц, но я не фанат такого тюнинга.
6 июн 10, 02:27    [8897980]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
killed


Что касается послойного управления дисковым пространством - речь идет о разных типах дисков в сторадже, а не с разными стораджами. И это перпендикулярно OLTP или DWH у вас. Если есть данные с привязкой ко времени, то partitioning + compression. Можно даже заниматься ручным управлением для конкретных таблиц, но я не фанат такого тюнинга.


Понятно. Диски отличаются по емкости и по количеству в группах, но не по скорости. Короче говоря вывод один: пофиг на само железо главное, чтобы диски были одного размера, одной сокрости и по количеству совпадали во всех группах.
6 июн 10, 02:35    [8897985]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
--Попрошайка--
killed


Что касается послойного управления дисковым пространством - речь идет о разных типах дисков в сторадже, а не с разными стораджами. И это перпендикулярно OLTP или DWH у вас. Если есть данные с привязкой ко времени, то partitioning + compression. Можно даже заниматься ручным управлением для конкретных таблиц, но я не фанат такого тюнинга.


Понятно. Диски отличаются по емкости и по количеству в группах, но не по скорости. Короче говоря вывод один: пофиг на само железо главное, чтобы диски были одного размера, одной сокрости и по количеству совпадали во всех группах.


+ чтобы все группы были только для Oracle.

Но это ужасно идеальная ситуация :), так как на практике в резерве обычно не хотят держать, так как это простой денег и раскошеливаются, как правило, когда жопа приходит и все под завязку как попало забито. :)

Андрей Панфилов

если у Вас OLTP, то довольно странно почему место на стораже закончилось (быстрее иопсы заканчиваются),


Консолидированное OLTP решение.
6 июн 10, 02:39    [8897989]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
artemg
Member

Откуда: Санкт-Петербург
Сообщений: 593
я немножко не понял, как единое целое ведь видится LUN с одного из нескольких разномастных стораджей
а не вообще все-все-все за одним LUN-ом спрятано, да?
ну так если вас смущает разная производительность или потенциальные проблемы при реорганизации - популяйте по LUN-ам каким-нибудь я не знаю, ORION-ом
определите насколько оно тормознее вашего персонального (ну или не персонального, но того который первый был) стораджа
и выселяете туда менее нагруженные проекты-таблички
ну как раньше по дискам вручную раскладывали - на этот файлы данных, на этот индексы, на этот реду с темпом
6 июн 10, 10:36    [8898124]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
artemg, да я с удовольствием бы потаскал, но это путь в пропасть, так как порастешь тупостью, если будешь только и делать, что файлики или таблички по дискам таскать.

P.S. Одно цело на уровне ОС, понятно, что за этой склейкой все там индивидуально.
6 июн 10, 10:55    [8898189]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
artemg
Member

Откуда: Санкт-Петербург
Сообщений: 593
да, про путь в пропасть вы правы
я сильно больших SAN-ов не видел, только midrange, всякие там нетаппы
но к ним же (к башке стораджа) вроде же можно типовые полки (те которые на 12-15 дисков) докупать и цеплять довольно долго
т.е. новый сторадж обычно появляется когда на старом всё забито под завязку
но тут один раз можно и ручками - перенёс часть на новый и дальше всё создаёшь только на нём

> P.S. Одно цело на уровне ОС, понятно, что за этой склейкой все там индивидуально.

я не понял
несколько разномастных стораджей (не полок разномастных, а именно стораджей)
и все они ОС представлены как одно блочное устройство?
не по одному на сторадж, а один на всех?
как это?
6 июн 10, 11:15    [8898230]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
Я не спец по железкам, но для примера так:

1. купили, например, DS8xxx на нем собрали RAID массив и от него дали серверу С1, например, 100Гб. Остальные куски с этого же RAID массива или с этого же DSxxxx другими массивами раздали другим желающим.

Далее живешь, крутишь, вертишь... пока не заканчивается место.

2. купили DS3xxx на нем собрали RAID массив и от него дали серверу С1, например, 100Гб дополнительно (Oracle видит одно устройство в 200Гб). Остальные куски с этого же RAID массива или с этого же DSxxxx другими массивами раздали другим желающим.

Далее живешь, крутишь, вертишь... пока не заканчивается место.

3. купили DS4xxx на нем собрали RAID массив и от него дали серверу С1, например, 100Гб дополнительно (Oracle видит одно устройство в 300Гб). Остальные куски с этого же RAID массива или с этого же DSxxxx другими массивами раздали другим желающим.

ну, как-то так в общем получаем гибрид.
6 июн 10, 11:25    [8898262]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
artemg
Member

Откуда: Санкт-Петербург
Сообщений: 593
--Попрошайка--
Я не спец по железкам, но для примера так:

1. купили, например, DS8xxx на нем собрали RAID массив и от него дали серверу С1, например, 100Гб. Остальные куски с этого же RAID массива или с этого же DSxxxx другими массивами раздали другим желающим.

Далее живешь, крутишь, вертишь... пока не заканчивается место.


я возможно глупость спрошу
но что вот такой вот шкаф (вернее три шкафа)
http://publib.boulder.ibm.com/infocenter/dsichelp/ds8000ic/topic/com.ibm.storage.ssic.help.doc/f2c_922group_1w2rxh.gif

он продаётся уже набитый под завязку этими самыми (disk dirve set-ами/полками)?
т.е. расширяться путём докупки отдельных полок (disk dirve set-ов) которые цеплять к шкафу с процессорамми (первый из трёх на картинке) нельзя?
нужно целиком новый набор шкафов покупать?
6 июн 10, 11:40    [8898294]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
artemg
Member

Откуда: Санкт-Петербург
Сообщений: 593
второй и третий шкафы кстати называются expantion model
погуглил любопытства ради по сайту IBM-а
сайту IBM-а
автор

2. All expansion models can have up to 16 disk enclosures, which contain the disk drives. In a maximum configuration, each expansion model can hold 256 disk drives.
3. Expansion models can contain I/O enclosures and adapters if they are the first expansion models that are attached to a Model 922, 932, 9A2, 9B2 or 941 (4-way). The second, third, or fourth expansion model in a 922, 932, 9A2, or 9B2 configuration cannot have I/O enclosures and adapters, nor can any expansion model that is attached to a Model 921 or 931. If the expansion model contains I/O enclosures, the enclosures provide connectivity between the adapters and the processors. The adapters contained in the I/O enclosures can be either device or host adapters.


отсюда как минимум следует что их (шкафы с полками) можно докупать набитыми наполовину
а также что их к стойке с головами можно цеплять несколько

непонятно почему у вас так не делают
6 июн 10, 11:47    [8898304]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
artemg

я возможно глупость спрошу
но что вот такой вот шкаф (вернее три шкафа)
http://publib.boulder.ibm.com/infocenter/dsichelp/ds8000ic/topic/com.ibm.storage.ssic.help.doc/f2c_922group_1w2rxh.gif

он продаётся уже набитый под завязку этими самыми (disk dirve set-ами/полками)?
т.е. расширяться путём докупки отдельных полок (disk dirve set-ов) которые цеплять к шкафу с процессорамми (первый из трёх на картинке) нельзя?
нужно целиком новый набор шкафов покупать?


Вы задаете мне политический вопрос. Я не знаю по какому принципу что покупается. Опять же купить железку <> спуститься на улицу в ближайший компутерный магазин... :)

По сути ответы на свой вопрос я извлек из всего диалога в теме. Впрочем, они логичны и не противоречат с моим изначальным видением.
6 июн 10, 11:51    [8898307]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
miner
Member

Откуда: Moscow
Сообщений: 206
Могу сказать что если у вас несколько СХД это даже плюс.
В случае oracle можно скормить например в одну asm группу луны с разных схд и сделать избыточность.
Поможет избежать неприятных моментов.
--Попрошайка--
...Надежность - в ней сомневаться не приходится....

Я бы не делал опрометчивых заявлений.
Например, у нас было такое.
Полагаю что если у вас "много DS...", то увидите много общего (близкая родственница).
Просто система в ночь с воскресенье на понедельник стала вдруг считать что у неё выходят один за другим диски из строя, мало того, она потеряла конфигурацию и стала хватать из других raid диски считая их hot spare и добавлять их в сбойные raid.
В итоге её колбасило всю ночь. Утром катастрофа, нет почти ничего целого и рабочего.
Самое неприятное что у системы объём по внутреннему логу около 80000 записей что не позволило посмотреть с чего всё началось - перезаписались.
Предоставили бледнолицим братьям из штатов доступ, те пару дней возились, в итоге причину установить не смогли, оттестировали железо - с ним всё в порядке, ну и перепрошили всё на всякий случай.

Далее, 400 дисков в аппаратном raid это полная фигня, во первых это означает отсутствие "tray loss protection", во вторых это потенциально опасная ситуация с надёжностью, в третьих есть большие сомнения в эффективности.
6 июн 10, 13:47    [8898420]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
miner, сколько дисков RAID самое разумное?
6 июн 10, 17:47    [8898691]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
DST
Guest
да вроде уже проблема решена давно - тока денег заплати:
DST - Dynamic Stotrage Tiering - http://eval.symantec.com/mktginfo/enterprise/yellowbooks/dynamic_storage_tiering_03_2006.en-us.pdf
7 июн 10, 00:15    [8899405]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
miner
Member

Откуда: Moscow
Сообщений: 206
--Попрошайка--
miner, сколько дисков RAID самое разумное?

Зависит от местных условий, у нас больше 16 не используется.
Например под базу oracle выделено 12 lun, каждый состоит из 6 дисков организованных в raid10.
Дальше они объединены в группу asm с внешней избыточностью.
7 июн 10, 00:59    [8899511]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
Знаешь, просто интересно
Guest
miner
--Попрошайка--
miner, сколько дисков RAID самое разумное?

Зависит от местных условий, у нас больше 16 не используется.
Например под базу oracle выделено 12 lun, каждый состоит из 6 дисков организованных в raid10.
Дальше они объединены в группу asm с внешней избыточностью.


А к чему ты вот это все говоришь? Какая польза от того, что у вас там 12 и не больше 16?
Что ценного в этой информации, которую ты пытаешься донести миру?

Нет, серьезно. Зачем вообще кому-то знать, что у вас там не больше 16?
7 июн 10, 01:14    [8899532]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
Знаешь, просто интересно
miner
--Попрошайка--
miner, сколько дисков RAID самое разумное?

Зависит от местных условий, у нас больше 16 не используется.
Например под базу oracle выделено 12 lun, каждый состоит из 6 дисков организованных в raid10.
Дальше они объединены в группу asm с внешней избыточностью.


А к чему ты вот это все говоришь? Какая польза от того, что у вас там 12 и не больше 16?
Что ценного в этой информации, которую ты пытаешься донести миру?

Нет, серьезно. Зачем вообще кому-то знать, что у вас там не больше 16?


Речь идет про надежность RAID.
7 июн 10, 01:27    [8899552]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
Знаешь, просто интересно
Guest
--Попрошайка--
Речь идет про надежность RAID.


И дальше что? Какой-то куй с бугра тебе озвучил цифру 12 не более 16.
Дальше, твои действия?
7 июн 10, 01:43    [8899576]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
Знаешь, просто интересно
--Попрошайка--
Речь идет про надежность RAID.


И дальше что? Какой-то куй с бугра тебе озвучил цифру 12 не более 16.
Дальше, твои действия?


Ну, во-первых человек, а во-вторых, как минимум я узнал, что у данного конкретного человека такая конфигурация.
7 июн 10, 01:46    [8899581]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
Знаешь, просто интересно
Guest
--Попрошайка--
Ну, во-первых человек,

А никто не говорил что он, ну я не знаю, шимпанзе или дождевой червяк.

--Попрошайка--
а во-вторых, как минимум я узнал, что у данного конкретного человека такая конфигурация.

И что тебе это дало? Еще раз, зачем тебе это знать? Цель какая?
7 июн 10, 01:49    [8899583]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
Знаешь, просто интересно
--Попрошайка--
Ну, во-первых человек,

А никто не говорил что он, ну я не знаю, шимпанзе или дождевой червяк.

--Попрошайка--
а во-вторых, как минимум я узнал, что у данного конкретного человека такая конфигурация.

И что тебе это дало? Еще раз, зачем тебе это знать? Цель какая?


Мне интересно, как люди считают надежность RAID массивов, раз уж зашел разговор за это. Поэтому, я полагаю, что есть некие правила. Смысл, как я понял в том, что в зависимости от уровня RAID, увеличение дисков в группе увеличивает риск того, что заявленные возможности RAID для автоматического разрешения аварийной ситуации просто не справятся. Например, я полагаю, что массив RAID-5 c 12 дисками более надежен, чем RAID-5 со 120 дисками, так как во втором случае вероятность одновременного выхода из строя двух дисков выше, чем в первом. Как-то так.

Если тебе интересно, то давай обсудим. Только днем, так как сейчас я ухожу спать. :)
7 июн 10, 01:54    [8899588]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6   вперед  Ctrl      все
Все форумы / Oracle Ответить