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

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

Хотелось бы найти готовые best практики или поговорить в этой теме о практических подходах форумчан на тему развития SAN.

Информации в современных условиях мног, хранить ее где-то надо для работы с ней и в моде сейчас системы хранения данных.

Смущает следующее, что при масштабируемости, как ни крути, получается ассорти. Другими словами, большая база данных Oracle может быть размазана по разным системам хранения, то есть, например, логически доступное дисковое пространство выглядит, как одно целое, а за кадром это куски от разных RAID массивов разных систем хранения.

Таким образом, управлять этим становится все сложнее и сложнее, так как системы разного класса и с разными возможностями, RAID массивы по своим характеристикам могут быть разными, ошибки у всех систем хранения свои и т.д.

Интересно было бы посмотреть, как другие люди справляются с такой задачей.
5 июн 10, 23:42    [8897817]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
пароль унес цунами
Guest
--Попрошайка--,

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

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

Да стратегия простая. Поручите это дело нормальному сторожевику, а не дохлым ораклистам. И усе будет в шеколаде.


Ораклисты как раз только получают свободное место. То есть надо тебе 1Тб - на тебе свободный кусок от туда, свободный отсюда... в итоге становится не понятно, как там все живет. :)
6 июн 10, 00:13    [8897846]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
-2-
Member

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

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

Хотелось бы найти готовые best практики или поговорить в этой теме о практических подходах форумчан на тему развития SAN.

Информации в современных условиях мног, хранить ее где-то надо для работы с ней и в моде сейчас системы хранения данных.

Смущает следующее, что при масштабируемости, как ни крути, получается ассорти. Другими словами, большая база данных Oracle может быть размазана по разным системам хранения, то есть, например, логически доступное дисковое пространство выглядит, как одно целое, а за кадром это куски от разных RAID массивов разных систем хранения.


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

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
-2-
--Попрошайка--
Интересно было бы посмотреть, как другие люди справляются с такой задачей.
Интересно было бы узнать характеристики сети, где будет производительнее или дешевле добавлять десятый сторейдж, а не сотый диск в сторейдж.


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

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


какие нафиг разные системы хранения, если речь про SAN ?
Что конкретно интересует?


shared storage devices
6 июн 10, 00:30    [8897863]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
killed
Member

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

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

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

они все шаред по определению, если речь про SAN. Что-то все очень мутно описано.


Например, купили 50 разных System Storage, соединили в одно целое - раздали туда кусок, сюда кусок.
6 июн 10, 00:42    [8897881]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
killed
Member

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

они все шаред по определению, если речь про SAN. Что-то все очень мутно описано.


Например, купили 50 разных System Storage, соединили в одно целое - раздали туда кусок, сюда кусок.


1. у вас денег не хватит на 50 массивов
2. их не соединяют в единой целое
3. нет никакого смысла мапить для базы луны с разных стораджей.
6 июн 10, 00:48    [8897885]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

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

Купили System Storage типа А и System Storage типа Б (про их класс говорить пока не будем). Собрали массивы слепили из них что-то целое и отдали двумя логическими кусками под Oracle и под MS SQL Server.

Теперь. MS SQL Server вырос и требуется в массив добавить диск, например, в System Storage типа Б. Так как Oracle живет и на System Storage типа А и на System Storage типа Б, то работы, связанные с добавлением диска, затронут и его, что очень блин неприятно.

Забегаю вперед и отвечаю на вопрос типа "Почему System Storage не поделили А - для Oracle, а Б для MS SQL Server" - так получилось в процессе естественной эволюции.
6 июн 10, 00:52    [8897889]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

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

они все шаред по определению, если речь про SAN. Что-то все очень мутно описано.


Например, купили 50 разных System Storage, соединили в одно целое - раздали туда кусок, сюда кусок.


1. у вас денег не хватит на 50 массивов
2. их не соединяют в единой целое
3. нет никакого смысла мапить для базы луны с разных стораджей.


1. денег хватит так как на то есть скидки.
2. ответа на это у меня нет, так как я не глубокий специалист по System Storage, я просто их представляю, как потенциально доступное место
3. уже сделали :)
6 июн 10, 00:54    [8897894]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
killed
Member

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

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

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

меня не покидает смутная мысль, что вы не понимаете архитектуру типичной SAN-сети. Один массив в 90% на всех. Добавление диска в массив - рутинная операция, никак не затрагивающая пефоманс, если только это не замена сбойного диска.


Проблема в том, что диск в System Storage Б добавляться просто так не желает и пишет об ошибке. Вендор дал рекомендацию сделать то и то, а именно уменьшить размер блока (речь идет про System Storage), что естественным образом скажется на всех, кто живет на этом System Storage.

Опять же сидя на System Storage типа А в котором собран массив их 400+ дисков и частью на System Storage типа Б на котором массив 100+ дисков, видимо блин разница есть. Но это для операционной системы на которой Oracle, как единое устройство - диск. Таким образом, часть БД работает на таких условиях, а часть на других.
6 июн 10, 01:03    [8897910]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
killed, кстати, самое главное видимо не сказал. Единое целое, понятное дело клеится на уровне ОС.
6 июн 10, 01:04    [8897912]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

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

меня не покидает смутная мысль, что вы не понимаете архитектуру типичной SAN-сети.


К сообщению приложен файл. Размер - 0Kb
6 июн 10, 01:08    [8897918]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
killed
Member

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

меня не покидает смутная мысль, что вы не понимаете архитектуру типичной SAN-сети. Один массив в 90% на всех. Добавление диска в массив - рутинная операция, никак не затрагивающая пефоманс, если только это не замена сбойного диска.


Проблема в том, что диск в System Storage Б добавляться просто так не желает и пишет об ошибке. Вендор дал рекомендацию сделать то и то, а именно уменьшить размер блока (речь идет про System Storage), что естественным образом скажется на всех, кто живет на этом System Storage.

Опять же сидя на System Storage типа А в котором собран массив их 400+ дисков и частью на System Storage типа Б на котором массив 100+ дисков, видимо блин разница есть. Но это для операционной системы на которой Oracle, как единое устройство - диск. Таким образом, часть БД работает на таких условиях, а часть на других.


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

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

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


Например, System Storage А уже забит под завязку и покупается худший (нет в наличии средств, например; просто кому-то так придумалось и т.п.) System Storage Б на который продолжаем писать.

Теперь, на каждом System Storage по одному массиву, чтобы общая эффективность была выше. В итоге получаем, что и Oracle и SQL Server расположены на одном и томже массиве System Storage типа А и на одном и том же массиве System Storage типа Б.

Но! массив на А и массив на Б попилили так, что на текущий момент для SQL Server закончилось место (логическое ограничение). Таким образом, надо добавить еще диски в Б, что бы тот логический кусок для SQL Server можно было бы расширить. Есть два пути:

1. собрать еще один массив на меньшем количестве дисков и на уровне ОС прилепить это к SQL Server

2. добавить диск в существующий массив на котором живут и Oracle и SQL Server.

Так вот, что так, что эдак сталкиваемся с проблемой того, что при ошибках затрагиваеются все отдельные массивы на уровне System Storage или, если речь идет об одном массиве, то собственно, массив.

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

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

Используется послойная работа с памятью и база/приложение знает об этом?


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

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

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

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

Используется послойная работа с памятью и база/приложение знает об этом?


Конечно нет, иначе у меня сей факт не вызывал бы опасений.


Именно к этому, теперь, как-то надо прийти (не путать с ILM для DWH), но все же остается еще одна фишка, что ресур делится между всеми, что усложняет контроль, впрочем, я пока не представляю, как это можно контролировать, видимо, только на уровне System Storage и, видимо, глубокими исследованиями изменений окружения.
6 июн 10, 01:32    [8897947]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
--Попрошайка--
Member

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

Вы пытаетесь исключительно административную проблему привязать к технической (с технической стороны данные между разнимы массивами вполне таскаются в онлайне) - нет запасного хранилища значит придется делать все в офлайне.


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

А, собственно, тема предназначена чтобы понять, как люди НЕ приходят к такой конфигурации и вообще как лучше развивать.
6 июн 10, 01:38    [8897950]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
killed
Member

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

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


Например, System Storage А уже забит под завязку и покупается худший (нет в наличии средств, например; просто кому-то так придумалось и т.п.) System Storage Б на который продолжаем писать.

Теперь, на каждом System Storage по одному массиву, чтобы общая эффективность была выше. В итоге получаем, что и Oracle и SQL Server расположены на одном и томже массиве System Storage типа А и на одном и том же массиве System Storage типа Б.

Но! массив на А и массив на Б попилили так, что на текущий момент для SQL Server закончилось место (логическое ограничение). Таким образом, надо добавить еще диски в Б, что бы тот логический кусок для SQL Server можно было бы расширить. Есть два пути:

1. собрать еще один массив на меньшем количестве дисков и на уровне ОС прилепить это к SQL Server

2. добавить диск в существующий массив на котором живут и Oracle и SQL Server.

Так вот, что так, что эдак сталкиваемся с проблемой того, что при ошибках затрагиваеются все отдельные массивы на уровне System Storage или, если речь идет об одном массиве, то собственно, массив.

Короче говоря, некая помойка получается. Хочу попытаться понять, как народ это обходит.



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

Еще, если это не связано с архитектурой массива (есть такие хитрожопые массивы типа IBM XIV), то это неправильно шарить RAID-группу (одни и тежи диски) между разными потребителями, в вашем случае двумя базами данных
6 июн 10, 01:45    [8897955]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
кстати вот вам аналогия вашей ситуации: RAID-группа, собранная из дисков с разными характеристиками, например 10К и 15К.
6 июн 10, 01:50    [8897962]     Ответить | Цитировать Сообщить модератору
 Re: Стратегия развития SAN (базы данных Oracle)  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3778
--Попрошайка--
А, собственно, тема предназначена чтобы понять, как люди НЕ приходят к такой конфигурации и вообще как лучше развивать.
Ничего страшного в этом нет, более того, все наоборот стараются перетаскивать редкоиспользуемые данны на более медленные (дешевые) носители.
6 июн 10, 02:00    [8897969]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
Все форумы / Oracle Ответить