1С және SQL Server лицензиясы серверде: қалай артық төлемеуге болады

1С пен SQL Server байланысында әдетте қайдан қателеседі

Ең жиі кездесетін сценарий осындай: компания жылдар бойы бір серверде 1С пен SQL Server-мен жұмыс істейді, бюджетті білетін, лицензиялар «ретте» сияқты көрінеді. Кейін сервер ескіріп, оны мықтырақ, көп ядролы, кейде виртуалданған жаңа серверге ауыстырады. Және кенеттен лицензиялар мен олардың шектеулері апгрейдтың өзінен қымбатқа түседі.

Бұл әдетте CPU-ны ауыстырғанда, ядролар саны өсіп немесе виртуалдануға өткенде шығады, себебі кейбір лицензиялар серверге байланған немесе «қуаттылыққа» қарай есептеледі. Ескі сервер 8 ядролы болса, жаңасы 24 ядролы болуы мүмкін, және SQL Server үшін есептеулер мүлде басқа болады. Бір физикалық машина орнына бірнеше виртуалды машиналар пайда болса, орналастыру, көшіру және іске қосуға қатысты қосымша ережелер шығады.

Қымбаттайтын жәйттер біреу емес, бірнешеуі бірдей болып келеді:

• SQL Server — «ядролар бойынша» немесе «Server + CAL» моделі, плюс виртуалдандыру ережелері.
• Windows Server — ядролар бойынша лицензиялау және бөлек CAL-дар.
• 1С — сервер лицензиясы және клиенттік лицензиялар (қол жеткізу схемасына байланысты).
• Қашықтан қол жеткізу — RDS CAL және терминал арқылы жұмыс істесе басқа құқықтар.

Шапшаң шешімде жиі «түк болса іске қосайық» деген тұжырым қабылданады, ал сосын бұл қымбатқа түседі. Мысалы, SQL Server-ды "ядроларға қосымшамен" алады, бірақ нақты жүктеме аз болады. Немесе «бар болғандай көшіріп аламыз» деп ойлайды, бірақ ескі лицензиялар қайта тағайындауға келмейтін болуы мүмкін немесе виртуал машиналар енді басқа хостта жұмыс істейді.

Тағы бір типтік қате — "техникалық қажеттілікті" және "лицензия бойынша рұқсатты" ажыратпау. 1С пен SQL Server-дің лицензиялануы — бұл архитектура өзгерген сайын өзгеретін құқықтар мен шектеулер. Алдымен жабдықты жаңартып, сосын лицензияны реттеуге кіріссеңіз, көбіне ең қымбат нұсқаға келеді.

1С + SQL Server байланысындағы лицензиялардан не тұрады

Мұнда бірден айыру маңызды: сіз не сатып алып жатқаныңызды бөлшектеңіз — 1С құқықтары, СУБД (SQL Server) құқықтары, ОЖ (әдетте Windows Server) құқықтары және пайдаланушылар терминал арқылы жұмыс істесе қашықтан қол жеткізу құқықтары. Қате осының бәрін "бір пакеттің" бөлігі ретінде санаудан басталады.

Рөлдерді нақтылаңыз. 1С сервері (1С кластері) бір машинада, SQL Server басқа машинада, ал қашықтан жұмыс үшін бөлек терминалдық сервер болуы мүмкін. Кейде бәрі бір хостта тұрса да, лицензиялау жеңілдемейді — ол көпқабатты болады.

Қандай элементтер әдетте пайдаланушылар бойынша, ал қайсысы ядролар бойынша лицензияланады

Бұл байланысты әр түрлі модельдер бар, және дәл осыдан апгрейд кезінде күтпеген шығындар пайда болады:

• 1С көбіне пайдаланушылар санына (клиенттік лицензиялар) және серверлік бөлік нұсқасына тәуелді.
• SQL Server кейде «Server + CAL» бойынша немесе «ядролар бойынша» есептеледі (редакция мен сценарийге байланысты).
• Windows Server өз схемасына ие және пайдаланушылар Windows сервисіне қол жеткізсе, бөлек CAL-дар қажет болуы мүмкін.
• Терминалдық қол жеткізу (RDS) әдетте бөлек RDS CAL-ды талап етеді.

"Пайдаланушылар бойынша" лицензияланып жатқан нәрсе жаңа жабдықтан арзандамайды. Ал ядролар бойынша есептелетін нәрсе көбіне CPU апгрейдынан қатты әсерленеді.

Виртуалдандыру мен нақты қолданылуды ескеріңіз

Виртуал ортада қосымша сұрақтар туындайды: сіз не лицензиялап жатқаныңызды — физикалық хостты түгелдей ме, әлде нақты ВМ-ні ме, SQL Server-ге қанша виртуал ядро берілгенін, ВМ-дерді хосттар арасында тасымалдауға бола ма, құқықтарды қайта қарастыру керек пе.

別қада бір тұзақ — "орнатылған, бірақ пайдаланылмайтын" компоненттер. SQL Server-ды артық қызметтермен орнатуы мүмкін, ал 1С-та кейбір режимдер серверлік нұсқаны талап етеді. Сондықтан сатып алудан бұрын қарапайым суретті бекіту пайдалы: 1С сервері қайда орналасқан, дерекқор қайда тұр, пайдаланушылар қалай кіреді, нақты қанша бір уақытта қосылым болады және серверлер күнделікті қандай рөлдерді атқарады.

Практикадан мысал: компания серверді көп ядролы модельге өзгертті, ал SQL Server ядролар бойынша лицензияланған еді. Қолданушылар саны өспесе де, шот ядролар санының ұлғаюына байланысты өсті.

1С лицензиялары: қай нәрсе бағаға және тәуекелдерге әсер етеді

"1С + SQL Server" байланысында көбіне тек SQL туралы ойлайды, бірақ дәл 1С лицензиялары күтпеген шығындар әкелуі мүмкін. Себеп қарапайым: баға сервердің қуатына емес, пайдаланушылардың қосылу тәсіліне және нақты қанша орта бар екеніне байланысты.

Негізгі сұрақ — қол жеткізу моделі қандай. Кліент-сервер нұсқада әдетте екі қабат маңызды: 1С сервері (қызметтер/кластер) және клиенттік лицензиялар (пайдаланушылар бойынша немесе құрылғылар бойынша — схемаға байланысты). Егер терминалдық сервер, VDI қоссаңыз немесе жұмыс орындары көбейсе, клиенттік лицензияларға қажеттілік өседі, тіпті қызметкерлер саны өзгермесе де.

別қадағы тәуекел — ұмытылған "контурлар". Көбіне тек өнімді орта (prod) есептеліп, кейін тест, даму, оқу көшірмелері пайда болады. Кейде олар қолда бар құқықтармен жабылады, кейде қосымша сатып алуды қажет етеді немесе тексеріс кезінде дұрыс рәсімделуі маңызды болады.

Тағы бір жәйт: файлдық режим мен SQL-база — жүйенің әртүрлі жұмыс режимдері. SQL-ға көшу әдетте клиент-сервер архитектурасына өту дегенді білдіреді, демек 1С серверіне, бір уақытта қосылатындар санына және лицензияларды есептеу тәртібіне талаптар өзгереді. Сондықтан алдын ала кім қалай қосылатынын, кім тікелей, кім терминал арқылы қосылатынын және қай базалар белсенді болатынын бекітіңіз.

Бағаға және тәуекелдерге ең қатты әсер ететін төрт нәрсе: нақты пайдаланушылар мен құрылғылар, терминалдық қосылымдар мен жалпы жұмыс орындары, тұрақты контурлардың (прод, тест, dev) саны және құқықтарды қалай сақтайтыныңыз (договорлар, регданные).

Тексеру кезінде әдетте «скриншоттар» емес, құжаттар мен түсінікті иеліктілік бейнесі сұралады: өнімдерге арналған келісімшарттар мен шоттар, тіркеу куәліктері, серверлер мен контурлардың тізімі, пайдаланушылар мен құрылғылардың тізімі.

1С-ты жаңа серверге көшіріп жатсаңыз, тек жабдық сипаттамасымен бірге лицензия схемасын да сақтаңыз. Бұл госоргандар, қаржы секторында регламентпен сатып алу кезінде немесе өндіруші мен интегратордан "құрылымдық запас" алғанда маңызды: қуаттылықтағы запас лицензиялардың артық сатып алынуына себеп болмауы керек.

SQL Server: қай жерлерде жиі күтпеген шығын шығады

Шоттың "кенет өсуі" көбінесе SQL Server лицензияларының есептеуінен шығады. Әсіресе серверді қуаттырақ, ядролары көп модельге ауыстырғанда немесе дерекқорды виртуал ортаға көшіргенде. Егер модельді алдын ала тексермесеңіз, ережелер басқаша жұмыс істей бастайды.

1) Ядролар немесе қолжетімділіктер (CAL): не таңдау және не тексеру

SQL Server үшін әдетте екі тәсіл бар: ядролар бойынша лицензиялау немесе "Server + CAL" моделі, мұнда сервер лицензиясы мен пайдаланушы/құрылғы CAL-дары бөлек сатып алынған.

Есептеу алдында төрт нәрсені анықтаңыз: нақты қанша пайдаланушы мен құрылғыңыз бар, сыртқы пайдаланушылар бар ма (клиенттер, мердігерлер), жыл ішінде өсу бола ма және қай нұсқа әкімшілендіруге оңайырақ. CAL моделі бастапқыда арзан көрінуі мүмкін, бірақ пайдаланушылар саны өсіп немесе қол жеткізу 1С-тен тыс болған жағдайда қымбаттауы мүмкін.

2) Жабдықты жаңарту: ядролар мен сокеттер есептеуді өзгертеді

Ең жиі кездесетін сценарий: бұрын сервер 8–12 ядролы болса, жаңасында 24–32 ядро бар, және ядролар бойынша лицензия құны шамамен пропорционалды өседі. Алайда 1С үшін жылдамдық ядролар санына дәл солай артпайды.

Сатып алудан бұрын тексеріңіз: нақты физикалық ядролар қанша ("ағындар" емес), сокеттер саны және бұл таңдалған редакция ережелеріне қалай әсер етеді, тапсырманы жылдам орындау үшін артық ядролар алмағаныңыз жөн емес пе — кейде жад немесе дискілік жүйе жылдамдықты жақсартады.

Идеясы қарапайым: кейде аз ядро алып, бірақ жоғары такт жиілігі бар процессор таңдау тиімдірек — лицензиялар ядролардан есептеледі.

3) Виртуалдандыру: хостқа, ВМ-ге немесе барлығына төлеу

Виртуал ортада күтпеген жағдай SQL Server үлкен ядролы хостқа көшірілген кезде шығады, ал лицензия SQL бүкіл хостты пайдаланғандай есептеледі. Керісінше жағдай да болады: бір ВМ жоспарланған, айдан соң екінші ВМ қосылады — формальды түрде құқықтар жеткіліксіз болады.

Алдын ала анықтаңыз: SQL үшін қанша ВМ болады, олар қай хосттарда жұмыс істеуі мүмкін (миграциялар), кластерлер мен ВМ-дерді тоғыстыру бар ма. Миграция еркіндігі неғұрлым көп болса, лицензия талаптары соғұрлым қатаң болады.

4) Редакциялар: артық немесе жарамсыз нәрсені алмаңыз

SQL Server редакциясы бағаға ғана емес, мүмкіндіктерге де әсер етеді. Қымбат редакцияны "сақ болу үшін" алу жиі артық төлемге әкеледі, ал арзан редакция оны пайдалануда шектеулер тудырады.

Типті мысал: компания серверді қуаттырақ CPU-мен алмастырды да, SQL-ды ВМ-ге көшірді. Нәтижесінде ядролар саны көбейіп, тесттік SQL данасы пайда болды, және таңдалған редакция мақсатқа сай келмеді. Алдын ала ВМ саны мен функционал талаптарын бекітіп, оптималды ядролар санын анықтасақ, шот айтарлықтай төмен болар еді.

Серверді ауыстыру: лицензияларды көшіру және жиі ұмытылатын шектеулер

Серверді ауыстыру тек жаңа жабдық алу емес. Лицензияларды көшіру үшін екі нәрсе маңызды: лицензия нені байланыстырады (құрылғыға, ядроларға, пайдаланушыларға) және оны қаншалықты жиі басқа жабдыққа тағайындауға болады. Көп жағдайда апгрейд кезінде осы жерде жағымсыз тосынсый шығады.

SQL Server-де дау тудыратын жәйттер көбінесе ядролар бойынша лицензиялау мен виртуалдандыруға байланысты. Лицензия нақты серверге тағайындалады, және көптеген редакцияларда reassignment ережесі бар: тағайындауды 90 күннен жиі өзгертуге болмайды (егер Software Assurance секілді правах болмаса). Егер сіз миграция кезінде лицензиаларды уақытша ары-бері ауыстыруды жоспарласаңыз, бұл бұзушылық болуы мүмкін.

1С-тікі көбінесе лицензияларды тіркеу, комплекттің құрамы (серверлік, клиенттік, қосымша лицензиялар) мен қосымшалар серверінің және кластерлердің құрылысына байланысты. Типтік қате: сервер жаңартылып, жаңа кластер орналастырылды, бірақ кейбір клиенттер кірмейді — лицензиялар көшірілмеген немесе параметрлік қақтығыстар бар.

Жұмысқа кіріспес бұрын ағымдағы ортаның "паспортын" жасаңыз. Негізгі деректер жеткілікті, бірақ оларсыз есептеулерден қателесу оңай:

• CPU моделі және физикалық ядролар саны;
• қанша сокет бар, Hyper-Threading қосылған ба (ағындар мен ядроларды шатастырмау маңызды);
• виртуалдандыру платформасы және ВМ-дерге бөлінген ресурстар бар ма;
• рөлдер: SQL қайда тұрады, 1С сервер қайда, файл қызметтері мен бэкаптар қайда;
• ағымдағы редакциялар мен нұсқалар (SQL Server, Windows Server, 1С).

Ескі мен жаңа сервердің параллель жұмысы үшін жоспар құрыңыз, тіпті "түнде жылжытамыз" деп ойласаңыз да. 1С үшін бұл тоқтап қалуды азайтады: тесттік миграцияны өткізіп, құқықтар мен іске қосу жылдамдығын тексеріп, содан кейін пайдаланушыларды жоспарлы терезеде ауыстырсаңыз қауіп азаяды.

Дерекқорды және қосымша серверді көшіру кезінде қолжетімділікті жоғалтпау үшін ауысу сценарийін алдын ала ойластыру керек: тесттік көшіру және қалпына келтіру уақытын өлшеу, тоқтату терезесі және өзгерістерді "мұздату" реті, жаңа серверде пайдаланушы кірулері мен фондық тапсырмаларды тексеру, кері қайту жоспары және SQL-лицензияларды қайта тағайындау уақыты (қолданылса).

Қадамдық жоспар: апгрейдқа қалай дайындалу керек, күтпеген жағдайсыз

1С серверін жаңарту көбінесе CPU мен RAM таңдаудан басталады, бірақ лицензияларға бюджеттің ұлғаюымен аяқталады. Қосымша төлем шықпау үшін қарапайым жоспарды ұстаныңыз.

Алдымен қазіргі жүйе қалай ұйымдастырылғанын анықтаңыз. Маңыздысы — тек "1С + SQL" емес, кім қайда қосылады: терминалдық сессиялар, жұқа клиенттер, интеграциялар, регламентті тапсырмалар, тесттік базалар.

Содан кейін лицензия туралы факттерді жинаңыз. "Барлығы сатып алынған сияқты" дегенді емес, нақты: келісімшарттар, шоттар, тіркеу деректері, кілттер және олардың байланыстары, құқықтар қайда және кімге тіркелген, SQL Server қандай редакция және қандай схема бойынша есептеледі.

Келесі қадам — апгрейдтан кейінгі мақсатты схеманы модельдеу: бір физикалық сервер ме, әлде виртуалдандыру, SQL және 1С үшін бөлек ВМ-дер, резервтік түйін керек пе, пайдаланушылар саны өседі ме.

Сатып алудан бұрын өтуге тиіс 5 қадам

• Ағымдағы архитектура мен пайдаланушылардың қолжеткізу нүктелерін сипаттаңыз.
• Лицензиялар туралы құжаттар мен реестрді, соның ішінде көшіру тарихын тексеріңіз.
• Виртуалдандыруды және резервті ескере отырып мақсатты схеманы салыңыз.
• Жаңа конфигурация мен жұмыс режиміне (ядролар, CAL, 1С пайдаланушылары) сәйкес лицензияларды қайта есептеңіз.
• Миграция терезесін, тесттер мен кері қайту жоспарларын келісіп, тек содан кейін сатып алуға рұқсат беріңіз.

Есептегеннен кейін "сұр аймақты" — пайдаланушылар өсуін, ескі мен жаңа сервердің уақытша параллель жұмысын және аудит талаптарын қосып қойыңыз.

Мини-сценарий

Болған: 8 ядро және 60 белсенді пайдаланушы. Болды: 16 ядро және есептілік үшін екінші ВМ қосылды. Егер есептеу сатып алғаннан кейін жасалса, SQL ядролар бойынша және қосымша қолжетімдіктер бюджетті күрт өсіріп жіберуі мүмкін. Ал алдын ала есептеп қоятын болса, басқа конфигурацияны (мысалы, ядролары азырақ, бірақ жиілігі жоғары процессор) таңдауға немесе рөлдерді өзгеше бөлуді қарастыруға мүмкіндік бар.

Егер сервер сатып алу және енгізуді интегратор жүргізсе, лицензия есептеуін бөлек құжат ретінде ресімдеуді сұраңыз. Бұл тәртіпті сақтайды және "шұғыл қымбат сатып алу" тәуекелін азайтады.

Лицензиялау мен миграцияда жиі кездесетін қателер мен тұзақтар

Ең жиі себеп — лицензияларды "көзбен санау" әдеті. Қызметкерлер санын ала салу және көбейту, бірақ нақты кім қосылатынын, қайдан және сервер мен дерекқорға қандай құқықтар қажет екенін есепке алмау. Тексеру немесе жүктеме ұлғайғанда таңдалған схема нақты қолжетімділікті жаба алмай қалады.

Екінші тұзақ — жабдықты жаңарту кезінде шығады. Жаңа процессор ядроларының көбеюі SQL Server ядролар бойынша лицензияланып жатса, шот күрт өседі, тіпті пайдаланушылар саны өзгермесе де. Қағаз жүзінде бұл "жылдамдық үшін апгрейд" сияқты көрінсе, іс жүзінде басқа баға деңгейіне өтуі мүмкін.

Қай жерлерде жиі қателеседі

Шешімдер әдетте бірнеше кішкентай қателіктерден құралады:

• Ядролар бойынша тым үлкен запаспен сервер алу, SQL лицензияларына әсерін есептемей.
• Продуктив, тест пен даму орталарын бір серверге араластыру және "бір лицензия мыңға жетеді" деп есептеу.
• 1С-қа қолжеткізу каналдарын сипаттамау: толық клиент, веб-клиент, терминал, интеграциялар.
• Көшіруді инвентаризацияламай бастау: кілттер қайда, келісімшарттар қандай, тіркеу деректері кімде.

Неліктен миграция есептеулерді жиі бұзады

Серверді ауыстырғанда техникалық параметрлер ғана емес, эксплуатация моделі де өзгеруі мүмкін: виртуал машиналар пайда болуы, тест сервері қосылуы, SQL-ды бөлек түйінге шығару. Әр қадам құқықтарды есептеу тәсіліне әсер етеді.

Практикалық тәсіл — миграциядан бұрын "қолдану бейнесін" бекіту: қанша бір уақытта қосылым, пайдаланушылардың рөлдері, SQL қайда тұр, қанша орта талап етіледі. Тек содан кейін сервер конфигурациясын таңдаңыз.

Қысқа мысал: компания ядролары көп жаңа серверге ауыстырды «болашақ үшін». Өнімділік өсті, бірақ SQL ядролар бойынша лицензия қайта есептеліп, бюджет апгрейд құнынан асып кетті. Бұл мәселені алдын ала лицензиялау схемасын таңдап, соған сай конфигурация жасағанда болдырмауға болатын.

Егер сервер жүйелік интегратордан сатып алынса, тек жабдық сипаттамасын емес, лицензия бойынша жазбаша болжамдарды да сұраңыз. Мысалы, GSE.kz деңгейіндегі жеткізушілер мұндай есептеулерді көрсетуі мүмкін және қай жерде шығындар өсуі мүмкін екенін алдын ала көруге көмектеседі.

Сервер мен лицензияларды сатып алудан бұрын жылдам чек-лист

Жаңа сервер тапсырыс бермес бұрын 20–30 минут ішінде деректер жинап алу пайдалы. Көптеген "кейден шыққан" қосымша төлемдер жабдық сипаттамалары мен лицензиялау ережелерінің әр түрлі қарастырылуынан болады.

Алдын ала бекітуге қажетті 5 сұрақ

• 1С қандай версия мен редакцияда және клиенттік лицензиялар қалай бөлінген: пайдаланушылар бойынша, құрылғылар бойынша, терминал арқылы немесе аралас.
• SQL Server қалай пайдаланылады: бір база ма әлде бірнеше, бір инстанс не бірнеше, қайда жұмыс істейді (физикалық немесе ВМ).
• Жаңа серверде қанша физикалық ядро болады және қандай процессорлар.
• Переход кезінде ескі мен жаңа сервердің параллель жұмыс істеуі қажет пе.
• Тест пен даму контурлары бөлек пе, және кім оларға қол жеткізеді.

Есеп шығарудан бұрын қысқа тексеріс

Қысқа кесте жасаңыз: ағымдағы сервер (ядролар, SQL қайда жұмыс істейді, 1С пайдаланушылар саны) және болашақ сервер (ядролар, виртуалдандыру жоспары, параллель жұмысының мерзімі). Содан кейін "қағаздағы" өзгерістер ережелерге қалай әсер ететінін сұраңыз, не техникалық түрде өзгереді, не лицензиялық тұрғыдан.

Шынайы мысал: жабдықты жаңарттық та шот басқаша келді

60 қызметкері бар компания 1С:Предприятие мен SQL Server қолданды. Бұрын бәрі бір физикалық серверде еді: 8 ядро, 64 ГБ RAM. 1С үшін 50 клиенттік лицензия сатып алынған, қолданушылар жұқа клиентпен қосылады, база біреу, күрделі кластер жоқ.

Бірнеше жылдан соң баяулаулар, резервтік көшірмелер өсуі, сенімділік талаптары пайда болды. Жабдықты жаңартып, виртуалдандыруға өтуді шешті: 32 ядролы сервер алып, оған екі ВМ көтеріледі — біреуі 1С үшін, екіншісі SQL үшін. Көшіру қағазда оңай көрінді: дерекқорды ауыстырып, ресурстарды көбейтіп, жұмысты жалғастырамыз.

Алайда SQL Server жағынан шот күтпеген түрде өсті. Себеп — SQL көбіне ядролар бойынша лицензияланады, ал хосттағы ядролар санының өсуі шығынды ұлғайтты. Виртуалдандыру да қосымша нюанстар тудырды: егер ережелер бойынша хосттағы барлық ядроларды жабу талап етілсе, SQL бір ВМ-де болса да жоспарламаған түрде көп ядро үшін төлеуге тура келуі мүмкін.

Шығын 1С емес, SQL-ден шықты — себебі лицензиялау моделін сатып алудан бұрын қайта есептемеген еді.

Бұның алдын алуға болатын нәрселер: SQL-ды физикалық серверде ядролар бойынша және ВМ нұсқасындағы есептеуді салыстырып, шартқа сәйкес Server + CAL вариантын қарастыру (егер үйлесімді болса), SQL қайда орналасатынын алдын ала шешіп, ВМ-ге ядролар санын шектеу немесе SQL-ды бөлек шағын хостқа шығару сияқты нұсқаларды талдау.

Қайталау болмас үшін шешімдерді құжатпен бекітіңіз: қолданыстағы қол жеткізу схемасы, таңдалған SQL редакциясы мен лицензиялау моделі, хост пен ВМ параметрлері (ядролар, миграциялар), және сервер алмастырғанда лицензиялардың орын ауыстыру ережелерін тексеру.

Келесі қадамдар: шешімді бекіту және тыныш өсім

Ағымдағы схеманы анықтап болған соң біржолатқан лицензия сатып алып қою емес, одан әрі қалай өмір сүретініңізді бекіту маңызды. Сонда жабдықты жаңарту, виртуалдандыруға өту немесе пайдаланушылардың өсуі күтпеген шотқа айналмайды.

Бастапқы инвентаризациядан бастаңыз: рөлдер қайда жұмыс істейді, кім қайда қосылады, Windows және SQL Server-дың қандай версиялары мен редакциялары, қанша ядро, пайдаланушылардың қол жеткізу тәсілі (RDP, терминал, тікелей), нақты жүктеме (піктер, түскі регламенттер).

Сосын мақсатты архитектура мен қарапайым ережелерді анықтаңыз. Мысалы: SQL бір серверде орналасады, 1С кластері SQL-дан бөлінген, есептеулер бөлек инстанцияда жұмыс істейді, тест контурлары оқшауланған және ресурстармен шектелген. Мұндай шешімдер көбіне ең мықты процессор таңдауынан гөрі жалпы шығынға үлкен әсер етеді.

Лицензия есептерін бірнеше вариантта сұраңыз. SQL үшін ядролар бойынша және Server + CAL модельдерін салыстырып шығыңыз: қолжетім жағдайыңыз бен пайдаланушылардың өсімі ескерілсін. Міндетті түрде допущенияларды (қанша ядро есепке алынғаны, қандай CAL түрі, екінші ВМ қосылғанда жағдай қалай есептелетіні, резервтік түйіннің есебі) жазып қойыңыз.

Шешімді жылдарға сақтау үшін 1–2 беттік "лицензия паспорты" жасаңыз: 1С пен SQL контурына кіретін серверлер мен ВМ, таңдалған модель және өсу нүктесі (пайдаланушылар, ядролар, жаңа контурлар), қандай оқиғалар қайта есептеуді талап етеді (CPU ауыстыру, ВМ көшіру, филиал қосу), құжаттар қайда сақталатыны және жауапты кім.

Егер 1С пен SQL үшін жаңа сервер қажет болса, конфигурацияны тек өнімділікке қарай емес, лицензияларға қалай әсер ететініне қарай таңдаңыз. Мұндай жобаларда жабдық пен жобалау қызметін жеткізуші мен интегратор бірге жаба алса ыңғайлы. Мысалы, GSE.kz өндіруші әрі интегратор ретінде инфрақұрылымды (оның ішінде S200 Series серверлерде) жоспарлауға көмектесіп, таңдалған архитектура лицензиялық шектеулермен қайшы келмейтінін алдын ала тексеруі мүмкін.

Принцип қарапайым: егер сіз 10 минут ішінде SQL қайда жұмыс істейтінін, оған қанша ресурс бөлінгенін және қандай модельмен құқықтар есептелетінін айта алсаңыз, онда схема бекітілген және масштабтау күтпеген шығынға әкелмейді.