Digi Data - Аптымізацыя апаратнага забеспячэння 1С:

1. Як павялічыць прадукцыйнасць дыскавай сістэмы?
2. Табліцы баз дадзеных
3. Індэксны файлы і файлы TempBD
4. Log-файлы
5. Аптымальнае абсталяванне для 1С: якой павінна быць дыскавая падсістэма?
6. Кампраміс паміж надзейнасцю і прадукцыйнасцю

Каб падабраць аптымальнае сервернае абсталяванне пад 1С, спатрэбіцца, як мінімум, жаданне паглыбіцца ў структуру вылічальнай нагрузкі на яго. Калі бюджэт на закупку абсталявання абмежаваны, а задачу ўсё-ткі трэба вырашыць, галоўнай зброяй стане наглядам за паводзінамі асноўных падсістэм сервера, якое праводзіцца ў рэальных умовах. Дапоўніце вынікі назірання довадамі здаровага сэнсу - і вам не прыйдзецца марнаваць лішніх грошай.

Нават калі з дадаткам працуе невялікая колькасць карыстальнікаў, рэсурсаёмістых 1С: Прадпрыемствы 8 можа апынуцца даволі высокай. Выбіраючы аптымальнае сервернае абсталяванне для 1С, любы ўладальнік будзе імкнецца да таго, каб пазбегнуць з'яўлення патэнцыйных вузкіх месцаў. З іншага боку, нават імкненне забяспечыць высокую хуткадзейнасць 1С часцей за ўсё не з'яўляецца дастатковым аргументам для таго, каб купляць сервер «на выраст»: залішняя магутнасць абгортваецца дадатковымі выдаткамі. Знайсці залатую сярэдзіну не так складана: можна загадзя зняць профіль нагрузкі і праектаваць сервер ужо пад канкрэтную канфігурацыю прыкладанняў.

Каб весці прадметную размову, возьмем для прыкладу платформу 1С: Прадпрыемства 8.2. Як паказвае практыка, сітуацыі, калі 1С 8.2 павольна працуе, вельмі распаўсюджаны. Мы будзем разглядаць базавыя канфігурацыі: «Упраўленне гандлем», «Заробак і Упраўленне Персаналам», «Бухгалтарскі ўлік», «Упраўленне Гандлёвым Прадпрыемствам», а таксама «Упраўленне Вытворчым Мерапрыемствам». У нашых разліках мы будзем адштурхоўвацца ад таго, што пры наяўнасці больш за 10 супрацоўнікаў, якія працуюць з платформай, прадпрыемства таксама выкарыстоўвае 1С: Прадпрыемства 8.2. Сервер Прыкладанняў. Акрамя таго, дапусцім магчымасць працы ў рэжыме Remote Desktop (выдалены працоўны стол), колькасць карыстальнікаў БД, падлучаных адначасова - ад 100 да 150.

Выбар апаратнага абсталявання пад 1С паводле нашых рэкамендацый магчымы і для больш рэсурсаёмістых баз дадзеных, аднак звяртаем вашу ўвагу на тое, што ў такіх выпадках практычна заўсёды патрабуецца аптымізацыя працы 1С, выкананая індывідуальна.

Як павялічыць прадукцыйнасць дыскавай сістэмы?

1С павольна працуе. Тармозіць сервер 1С. Занадта вялікі час водгуку 1С. Вельмі часта падобныя скаргі ўзнікаюць таму, што ў вашай канфігурацыі сервера папросту не ўлічвалася тое, якія менавіта тыпы аперацый уводу-высновы выконвае абсталяванне, якія дадзеныя закранаюць гэтыя аперацыі і з якой інтэнсіўнасцю яны рэалізуюцца. Усе гэтыя пытанні наўпрост звязаныя з дыскавай падсістэмай, аптымізацыі якой нярэдка дастаткова для таго, каб дасягнуць нармальнай прадукцыйнасці сервера.

Пры падключэнні вялікага ліку карыстальнікаў або масавым выкананні праводак, загрузак і выгрузок самай сур'ёзнай праблемай для базы дадзеных становіцца блакіроўка табліц. Каб зразумець, як справіцца з ёй, разгледзім прынцыпы пабудовы дыскавай сістэмы для сервера 1С.

Базы дадзеных 1С маюць пяць патокаў дадзеных для дыскавых падсістэм.

1. Табліцы баз дадзеных.
2. Часовыя файлы tempDB.
3. Індэксны файлы.
4. log-файлы SQL і log-файлы карыстацкіх прыкладанняў платформы.

Арганізацыя працы з патокам дадзеных кожнага тыпу мае сваю спецыфіку.

Табліцы баз дадзеных

У працэсе працы з табліцамі баз дадзеных асаблівае значэнне набывае тое, колькі аперацый запісу і чытанні дыскавая падсістэма здольная выканаць за прамежак часу. Лік гэтых аперацый пазначаецца як IOPS. Адначасова з гэтым параметры струменевай хуткасці перадачы дадзеных у MBp / s важныя значна менш. Нават калі 1С павольна працуе па сетцы, яе прадукцыйнасць будзе дастатковай пры ўмове нармальнага паказчыка IOPS.

Якія патрэбы IOPS для баз з аб'ёмам дадзеных і лікам карыстальнікаў?

У дадзенай табліцы пазначаны пікавыя паказчыкі, якія фіксуюцца далёка не заўсёды. Сярэдняя нагрузка на дыскавую сістэму можа знаходзіцца на ўзроўні 10-15% ад іх. Тым не менш, арыентавацца трэба менавіта на максімум: галоўнае значэнне мае прадукцыйнасць у перыяды пікавых нагрузак, напрыклад, калі адбываецца аўтаматычная загрузка дадзеных з іншай сістэмы, перепроведение перыяду і да т.п.

Якія паказчыкі для сучасных дыскаў у аперацыях Random Read / Write?

Дадзеная табліца дазваляе зрабіць адразу некалькі высноў.

1. Для кожнай з мадэляў паказчыкі IOPS для аперацый запісу нашмат ніжэй аналагічных паказчыкаў для аперацый чытання.
2. SSD нашмат апярэджвае традыцыйныя HDD па ліку аперацый запісу і чытанні ў адзінку часу. Гэтая розніца захоўваецца нават пры параўнанні з мадэлямі дэсктопных SSD, якія выйшлі досыць даўно (IOPS ў 3-40 вышэй). Серверныя SSD дэманструюць яшчэ больш высокія паказчыкі: IOPS ў 12-40 разоў вышэй у параўнанні з HDD.
3. SSD класа Intel 910 або LSI WarpDrive - лепшы адказ на пытанне аб тым, як павялічыць прадукцыйнасць 1С: у гэтых дыскаў прадукцыйнасць у IOPS максімальная.

Калі адной з задач з'яўляецца аптымізацыя працы БД, варта ўлічыць, што пры пабудове дыскавай падсістэмы ў серверах выкарыстоўваюцца не адзінкавыя дыскі, а RAID масівы. Гэта накладае пэўную спецыфіку на разлік фактычнай прадукцыйнасці дыскавай падсістэмы: трэба ўлічваць, якія менавіта выдаткі на запіс у IOPS нясе дыскавая група ў масіве.

Значэнне ў калонцы - гэта IOPS фізічнага дыска, якое спатрэбіцца для запісу або чытання дадзеных у масіве. Возьмем для прыкладу RAID 5. Каб запісаць 1 IOPS, спатрэбіцца 4 IOPS фізічных дыскаў.

Формула разліку прадукцыйнасці будзе выглядаць наступным чынам:

сума IOPS фізічных дыскаў RAID-групы / затраты на запіс IOPS, якія нясе дыскавая група ў масіве.

Для тлумачэнні дастаткова двух прыкладаў.

1. 2 дыска HDD SATA 7200 (IOPS = 100) у масіве RAID 1 пры аперацыях запісу дадуць наступную прадукцыйнасць: (100 + 100) / 2 = 100 IOPS.
2. 4 дыска HDD SATA 7200 (IOPS = 100) у масіве RAID 5 пры аперацыях запісу забяспечаць наступную прадукцыйнасць: (100 + 100 + 100 + 100) / 4 = 100 IOPS.

Нескладаныя разлікі паказваюць, што RAID 10 з'яўляецца найбольш пераважнай для захоўвання баз дадзеных, тыпавое размеркаванне аперацый чытання і запісы ў якіх складае 68/32. Калі ж абапірацца на ўсе тры табліцы, то зразумела, што ў шматлікіх выпадках павольная праца 1С звязана з тым, што ў якасці дыскавай падсістэмы выкарыстоўваецца «джэнтльменскі набор», які складаецца з 2 дыскаў HDD SATA 7200, аб'яднаных у масіў RAID 1. Пры пікавых нагрузках магутнасць такога набору аказваецца відавочна недастатковай, і 1С «тармозіць» проста таму, што вырастае вялізная чарга зваротаў да дыска, у выніку чаго карыстальнікам даводзіцца падоўгу чакаць адказу сістэмы.

Такім чынам, відавочна, што галоўная задача ў дачыненні да дыскавай падсістэмы - гэта нарошчванне прадукцыйнасці ў дачыненні да аперацый запісу. Менавіта недахоп такой прадукцыйнасці часта становіцца прычынай з'яўлення збояў, пры якіх тармозіць 1С 8.2. Як дамагчыся таго, каб сервер пад 1С выдаваў максімальную IOPS запісу? Зрабіць гэта можна некалькімі спосабамі.

1. Павелічэнне колькасці дыскаў у RAID групе. Калі «вісне» 1С, такое рашэнне можа павялічыць хуткасць выканання аперацый запісу.
2. Замена наяўных дыскаў на дыскі з большай хуткасцю кручэння (у дачыненні да HDD).
3. Выкарыстанне RAID груп, у якіх розніца паміж IOPS масіва і IOPS фізічных дыскаў мінімальная.
4. Выкарыстанне кэша RAID-кантролера для прамежкавага размяшчэння дадзеных. У рэжыме Write Trough дадзеныя запісваюцца на дыскі напрамую. Калі ўключыць рэжым адкладзенага запісу Write Back, то спачатку дадзеныя будуць пісацца ў кэш кантролера, а затым, у спарадкаваным выглядзе, на дыскі. Калі 1С 8 павольна працуе, такі прыём можа павялічыць прадукцыйнасць запісу на 30-100% у залежнасці ад спецыфікі задачы.
5. Калі тармозіць БД параўнальна невялікага аб'ёму (да 20GB) альбо слаба нагружаная БД, можна выкарыстоўваць гібрыдны RAID, у складзе якога знаходзяцца HDD і SSD дыскі. У размеркаваных структурах для філіяльныя БД на 3-15 карыстальнікаў большага не патрабуецца. Такі выбар абсталявання для 1С магчымы, напрыклад, пры пабудове дыскавай падсістэмы для сервера на СТО, кафэ, у невялікім краме.
6. Калі тармозіць 1С з аб'ёмнай базай дадзеных (памер складае 200GB і вышэй, маецца вялікі аб'ём захаваных, «гістарычных» дадзеных), можна выкарыстоўваць SSD-кэшаванне. Яно выконваецца з выкарыстаннем тэхналогіі Adaptec MaxCache 3.0 і LSI CasheCade 2.0. Менавіта пры вырашэнні задач 1С такі прыём дазваляе паскорыць запіс дадзеных на дыскі на 20-50%.

RAID-масівы, пабудаваныя на SSD сервернага тыпу з'яўляюцца лідэрамі па хуткадзейнасці з пункту гледжання IOPS. Гэта могуць быць традыцыйныя RAID групы, якія выкарыстоўваюць SAS RAID кантролер, так і PCIe SSD. Існуе ўсяго дзве прычыны, якія перашкаджаюць іх паўсюднага распаўсюджванню: досыць высокі кошт і тэхналагічныя абмежаванні. У прыватнасці, прадукцыйнасць RAID-кантролераў пакуль адстае ад прадукцыйнасці саміх серверных SSD. Акрамя таго, каб выкарыстоўваць апісаныя RAID масівы, неабходна радыкальна мяняць структуру захоўвання дадзеных.

Індэксны файлы і файлы TempBD

Абнаўленне індэксных файлаў адбываецца параўнальна рэдка - як правіла, 1 раз у суткі. У той жа час іх счытванне паўтараецца вельмі часта. З улікам высокіх патрабаванняў па IOPS счытвання захоўваць такія файлы неабходна на SSD.

Файлы TempBD выкарыстоўваюцца для захоўвання часавых дадзеных. Звычайна яны маюць невялікі аб'ём (ад 1 да 12 Gb). Пры гэтым яны прад'яўляюць вельмі высокія патрабаванні да прадукцыйнасці дыска. Тут варта адзначыць, што страта такіх файлаў не прыводзіць да страты рэальных дадзеных, што дазваляе размяшчаць іх на асобных тамах (адным, а лепш два). Адно з рашэнняў - бартавы кантролер SATA мацярынскай платы.

Калі трэба забяспечыць максімальную стабільнасць 1С, то лепш размясціць TempBD на люстэрку SSD (у RAID 1). Калі файл размяшчаецца на кантролеры, то абавязкова трэба выключыць усе кэшы на запіс. У якасці люстэрка не абавязкова выкарыстоўваць серверныя SSD - цалкам падыдуць дэсктопныя дыскі (Intel 520 або аналагічныя).

Што дасць вынас TempBD з агульнай сістэмы захоўвання дадзеных 1С на выдзеленую падсістэму з больш высокім IOPS? У першую чаргу - больш высокую прадукцыйнасць, а таксама паляпшэнне працы сістэмы падчас пікавых нагрузак.

У выпадку, калі неабходна вырашаць складаныя разліковыя задачы і ёсць магчымасць забяспечыць хуткую рэакцыю адміністратараў на сітуацыі, калі адбываецца завісанне 1С, можна вынесці TempBD на RAMDrive. Агульная прадукцыйнасць сістэмы ў гэтым выпадку можа вырасці на 4-12%. Адзіны нюанс, які неабходна ўлічваць - пры запуску сервера неабходны кантроль аўтаматычнага запуску RamDrive. Калі ён не запусціцца, спатрэбіцца ручной старт, які выконваецца адміністратарам. У адваротным выпадку адбудзецца прыпынак ўсёй сістэмы.

Log-файлы

Калі казаць вельмі спрошчана, то log-файлы выкарыстоўваюцца для таго, каб весці рэгістр дзеянняў сістэмы. Адпаведна, яны практычна бесперапынна генеруюць паток зваротаў на запіс. Пры сярэдніх нагрузках гэты працэс практычна не адчуваецца, аднак у моманты пікавых нагрузак на сістэму нагрузка, якая ствараецца log-файламі цалкам можа стаць прычынай таго, што вісне 1С 8.

Log-файл SQL трэба вынесці на асобны том. Патрабаванні па IOPS да яго могуць быць не занадта высокімі, запіс будзе ісці ў лінейным рэжыме. Акрамя таго, можна зрабіць люстэрка на дыску SATA альбо NL SAS, вылучыўшы для гэтага недарагі і аб'ёмны носьбіт. Таксама для гэтага могуць выкарыстоўвацца дэсктопныя SSD серыі Intel 520.

Як бачна, з пачаткам выкарыстання SSD дыскаў у дыскавых падсістэмах на серверах з'явілася мноства магчымасцяў для нарошчвання іх прадукцыйнасці. Шматузроўневае захоўванне дадзеных, а таксама правільная арганізацыя працэсу ўводу і вываду даных дазваляюць пазбягаць сітуацый, у якіх 1С 8 тармозіць.

Аптымальнае абсталяванне для 1С: якой павінна быць дыскавая падсістэма?

Можна даць чатыры асноўных рэкамендацыі па размяшчэнні дадзеных розных тыпаў.

1. Табліцы БД павінны знаходзіцца на дысках масіваў RAID 10 (для баз дадзеных невялікага аб'ёму - RAID 1). У якасці фізічных дыскаў трэба выкарыстоўваць серверныя SSD, абавязкова дапоўненыя апаратным RAID кантралёрам. Калі патрабаванні да прадукцыйнасці па IOPS з'яўляюцца досыць высокімі, магчыма выкарыстанне PCIe SSD. Для аб'ёмных БД дадаткова можна выкарыстоўваць SSD кэшаванне перад непасрэднай запісам на HDD. Традыцыйны масіў, пабудаваны на дысках HDD SAS 15K rpm, можа выкарыстоўвацца пры ўмове, што патрабаванні да прадукцыйнасці па IOPS з'яўляюцца не надта высокімі.
2. Для індэксных файлаў пераважна выкарыстанне асобнага тома. Гэта можа быць недарагі, але хуткі SSD. Файлы TempDB лепш размяшчаць на RAMDrive альбо 1 або 2 дысках SSD ў масіве RAID 1.
3. Захоўванне карыстацкіх дадзеных і аперацыйнай сістэмы пераважна на DDS альбо HDD дыскаў у масіве RAID 1.
4. Log-файлы (як 1С, так і SQL) каштуе размяшчаць на выдзеленым томе, які можа ўяўляць сабой як масіў RAID-1, так і адзіночны фізічны дыск. Для гэтага могуць выкарыстоўвацца недарагія SSD, SATA / NL SAS HDD небудзь лагічны дыск, на якім размяшчаецца серверная АС і прыстасаваныя файлы, і які ўваходзіць у склад RAID-групы.

Захоўванне дадзеных 1С неабходна аптымізаваць і ў выпадку з виртуализированной IT-структурай. У гэтым выпадку SQL сервер неабходна ўсталёўваць на фізічны сервер, ён не павінен быць усталяваны як віртуальная машына. Гэта дазваляе выйграваць 15-35% прадукцыйнасці дыскавай падсістэмы. Дакладная лічба будзе залежаць ад цэлага шэрагу параметраў, а менавіта сродкаў віртуалізацыі, характарыстык абсталявання, спосабаў падлучэння тамы, якія выкарыстоўваюцца драйвераў і г.д.

У выпадку, калі сярод SQL-сервера виртуализирована, для падлучэння тамоў з індэксны файл, файламі TempDB і табліцамі базы дадзеных да віртуальнай машыне неабходна выкарыстоўваць манапольны рэжым па Direct Access.

Кампраміс паміж надзейнасцю і прадукцыйнасцю

Калі 1С тармозіць, самы лягічны дзеянне - нарошчваць прадукцыйнасць. У той жа час побач з пытаннем аб павелічэнні прадукцыйнасці заўсёды знаходзяцца меркаванні пра адмоваўстойлівасці. Прасцей кажучы, магутнасць павінна падмацоўвацца надзейнасцю, і пры гэтым нярэдка паміж двума гэтымі параметрамі даводзіцца шукаць кампраміс.

Зразумела, што лепш не даводзіць да сітуацый, у якіх вам спатрэбіцца аднаўленне 1С - прасцей загадзя паклапаціцца аб адмоваўстойлівасці сервера. З іншага боку гэта можа запатрабаваць дадатковых выдаткаў, несці якія асабліва складана ў выпадку, калі прыходзіцца працаваць з бесперапыннымі вытворчымі працэсамі.

Выбар паміж прадукцыйнасцю і надзейнасцю карыстальнікі 1С часцей за ўсё вырашаюць у розных плоскасцях. Калі 1С вісне пры загрузцы, друку, пры апрацоўцы працэсаў, праблема прадукцыйнасці вырашаецца шляхам аптымізацыі апаратнай часткі сервера. Адмоваўстойлівасць жа забяспечваецца за кошт арганізацыі працэсаў. Пры гэтым у тых выпадках, калі прыкладання з'яўляюцца умерана крытычнымі, галоўным аспектам надзейнасці становіцца не столькі абарона сервераў, колькі звядзенне прастою ўсёй інфраструктуры да мінімуму. Між тым абарона сервера з'яўляецца папросту неабходнай, і лепш паклапаціцца пра яе загадзя, чым ўручную аднаўляць страчаныя дадзеныя.

Як правіла, для абароны сервераў выкарыстоўваюцца наступныя апаратныя меры.

1. Ўстаноўка КБС - фізічная абарона сервера ад перабояў харчавання.
2. Прымяненне залішніх блокаў сілкавання сервераў.
3. Выкарыстанне кошыкаў гарачай замены дыскаў.
4. Прымяненне ў складзе дыскавай падсістэмы RAID-масіваў, якія маюць гарачае рэзерваванне.

Усе гэтыя меры дзейсныя і неабходныя, аднак яны не вырашаюць задачы рэзервавання дадзеных. Бэкапу 1С павінен выконвацца планава так, каб у крытычнай сітуацыі вялікая частка БД (акрамя самых апошніх змяненняў) магла быць аператыўна адноўлена. Рэкамендуецца выконваць backup 1C штосутачна (у начны час, напрыклад), рэзервуючы БД і аператыўны файл, які змяшчае Full SQL log.

Лічыцца, што на сярэдніх і малых прадпрыемствах дапушчальнае час прастою для цэнтральнай сістэмы 1С складае 1-4 гадзіны, прычым аварыі павінны здарацца не часцей, чым 1 ці 2 разы на месяц. Калі загадзя быць гатовым да аднаўлення, гэты запас часу дастаткова вялікі.

Для таго, каб выканаць рэстарт хутка, неабходныя вобразы ўсіх фізічных і віртуальных сервераў у VM, размешчаныя на асобным томе. Гэта дазволіць хутка аднавіць інфраструктуру на рэзервовым серверным абсталяванні. Бэкап Full SQL log павінен выконвацца штодня, штотыдзень і пасля закрыцця перыяду. Рэзерваванне файлаў мусяць выконвацца на іншае фізічная прылада. Калі ў распараджэнні прадпрыемства ёсць падмяніць абсталяванне, рэстарт можа быць выкананы ўсяго за 1-2 гадзіны. Тут варта адзначыць, што ў тых выпадках, калі неабходна забяспечыць бесперапынную працу ў рэжыме 24 * 7, задача нашмат ўскладняецца: спатрэбіцца распрацоўка адпаведнай архітэктуры, падбор абсталявання, якое мае мінімум патэнцыйных кропак адмовы, выкарыстанне паўнавартасных тэхналогій кластарызацыі.