{"id":55231,"date":"2020-01-16T00:00:00","date_gmt":"2020-01-15T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/pro-multitenancy"},"modified":"2020-02-18T14:03:19","modified_gmt":"2020-02-18T11:03:19","slug":"pro-multitenancy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/pro-multitenancy","title":{"rendered":"Multitenancy kohta","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kahjuks ei ole selle termini jaoks head eesti keeles vastet. \"Vikipeedia\" annab t\u00f5lge<\/a><\/noindex> \"multitenantsus, mitme rentimise\". M\u00f5nikord nimetatakse seda \"mitme omandi\". Need terminid v\u00f5ivad olla pisut segadust tekitavad, kuna teema ei ole p\u00f5him\u00f5tteliselt seotud ei rentimise ega omamisega. See on k\u00fcsimus pigem tarkvara arhitektuurist ja selle kasutamise korraldamisest. Viimane on samuti mitte v\u00e4hem oluline. <\/p>\n

Hakkasime moodustama oma arusaama multitenantsusest samaaegselt sellega, kui alustasime l\u00e4henemise projekteerimist pilve (teenus) mudeli t\u00f6\u00f6ks \"1C:Enterprise\". See oli mitu aastat tagasi. Ja sellest ajast alates on meie arusaam pidevalt laienenud. Aeg-ajalt avastame selle teema juures uusi ja uusi aspekte (plussid, miinused, keerukused, omadused jne). <\/p>\n

\"Multitenancy
\n<\/a><\/noindex>
\nM\u00f5nikord m\u00f5istavad arendajad multitenantsuse all t\u00e4iesti lihtsat asja: \"et mitme organisatsiooni andmed salvestataks \u00fches andmebaasis, tuleb lisada k\u00f5ikidesse tabelitesse organisatsiooni identifikaatori veerg ja panna selle p\u00f5hjal filter\". Me alustasime muidugi ka oma teema k\u00e4sitlemist sellest hetkest. Kuid \u00fcsna kiiresti m\u00f5istsime, et see on vaid \u00fcks valdkond (ka see pole muide lihtne). Aga tegelikult on see \"t\u00e4ielik riik\". <\/p>\n

P\u00f5hiidee multitenantsuse kohta v\u00f5ib kirjeldada enam-v\u00e4hem nii: Tavaline rakendus on suvila, mis on m\u00f5eldud \u00fche pere elamiseks, kes kasutab selle infrastruktuuri (seinad, katus, veevarustus, k\u00fcte jne). Ja multitenantsuse rakendus on korterelamu. Selles kasutab iga pere samasugust infrastruktuuri, kuid kogu infrastruktuur on ellu viidud kogu maja jaoks tervikuna. <\/p>\n

Kuid l\u00e4henemine multitenantsusele \u2013 kas see on hea v\u00f5i halb? Sellele v\u00f5ib leida v\u00e4ga erinevaid arvamusi. Tundub, et ei ole \u00fcldse \"head v\u00f5i halba\". Tuleb v\u00f5rrelda plusse ja miinuseid konkreetsete lahendatavate \u00fclesannete kontekstis. Kuid see on eraldi teema\u2026 <\/p>\n

Tavalisest arusaamast on multitenantsuse eesm\u00e4rk v\u00e4hendada rakenduse hoolduskulusid, \"\u00fchiskondlikkuse\" kaudu infrastruktuuri kulude jagamise kaudu. See on sama liikumine, mis seisneb rakenduse maksumuse v\u00e4hendamises seeriakute rakendamise kaudu (v\u00f5imalik, et konfigureerimise ja t\u00e4iustamisega), mitte \"tellimuse j\u00e4rgi\" kirjutamise teel. Ainult \u00fches juhul on arendamine \u00fchiskondlik, teises \u2013 ekspluateerimine. <\/p>\n

Oluline on m\u00e4rkida, et siin ei ole otsest seost m\u00fc\u00fcgiarhiitktuuriga. Multitenancy arhitektuuri saab rakendada ka ettev\u00f5tte v\u00f5i ametiasutuse IT-infrastruktuuris, et automatiseerida suurt hulka sarnaseid filiaale ja kontserni ettev\u00f5tteid. <\/p>\n

V\u00f5ib \u00f6elda, et multitenancy ei ole pelgalt andmete salvestamise korraldamise k\u00fcsimus. See on rakenduse t\u00f6\u00f6mudel tervikuna (sh olulised arhitektuuri aspektid, juurutusmudel ja hooldusteenindus). <\/p>\n

Meie arvates on k\u00f5ige keerulisem ja huvitavam multitenancy mudelis see, et rakenduse olemus \"jaguneb\". Osad funktsioonid t\u00f6\u00f6tavad konkreetsete andmevaldkondade (korterite) kallal ja ei \"huvi\" selle \u00fcle, kes elab teistes korterites. Teised funktsioonid tajuvad maja tervikuna ja t\u00f6\u00f6tavad kohe k\u00f5igi elanike heaks. Samas ei saa viimane abstraktselt eemalduda sellest, et tegemist on siiski eraldi korteritega ning tuleb tagada vajalik granulaarsuse ja turvalisuse tase. <\/p>\n

\u201e1C:Ettev\u00f5ttes\u201c rakendatakse multitenancy mudelit mitmete tehnoloogiate tasandil. Need on \u201e1C:Ettev\u00f5tte\u201c platvormi mehhanismid, mehhanismid \u201e1C:1cFresh lahenduste publikatsiooni tehnoloogia<\/a><\/noindex>\" ja \"1C:1cFresh lahenduste arendamise tehnoloogia<\/a><\/noindex>\u201c mehhanismid BSP<\/a><\/noindex> (standardaluss\u00fcsteemide raamatukogud). <\/p>\n

Iga\u00fcks neist elementidest panustab korterelamu \u00fchisstruktuuri loomisse. Miks seda rakendatakse mitmete tehnoloogiate kaudu, mitte \u00fches, n\u00e4iteks platvormis? Eelk\u00f5ige seet\u00f5ttu, et osa mehhanisme on meie arvates t\u00e4iesti m\u00f5istlik modifitseerida konkreetse juurutusvaliku korral. Kuid \u00fcldiselt on see keeruline k\u00fcsimus ning me seisame pidevalt valiku ees \u2013 millisel tasemel on parem rakendada \u00fchte v\u00f5i teist multitenancy aspekti. <\/p>\n

On ilmselge, et mehhanismide p\u00f5hiosad oli vaja rakendada platvormis. N\u00e4iteks andmete eraldi jagamine. See on see, millega tavaliselt alustatakse juttu multitenancyst. Kuid l\u00f5puks on multitenancy mudel \"l\u00e4binud\" suure osa platvormi mehhanismidest ja n\u00f5udnud nende t\u00e4iustamist, m\u00f5nel juhul isegi \u00fcmberm\u00f5testamist. <\/p>\n

Platvormitasandil oleme rakendanud p\u00f5himehhanismid, mis v\u00f5imaldavad luua multitenancy mudelil t\u00f6\u00f6tavaid rakendusi. Kuid et rakendused saaksid selles mudelis \"elada ja t\u00f6\u00f6tada\", on vajalik nende \"elutegevust\" juhtiv s\u00fcsteem. Selle eest vastutavad tehnoloogiad 1cFresh ja \u00fchtne \u00e4riloogika kiht BSP tasandil. Nii nagu korterelamus tagab infrastruktuur elanikele k\u00f5ik vajaliku, nii varustavad tehnoloogiad 1cFresh k\u00f5ik vajalikuga multitenancy mudelis t\u00f6\u00f6tavaid rakendusi. Ja et rakendused saaksid suhelda selle infrastruktuuriga (ilma oluliste kohandusteta), sisaldavad nad vastavaid \"\u00fchendusi\" BSP alams\u00fcsteemide n\u00e4ol. <\/p>\n

Platvormi mehhanismide seisukohalt on lihtne m\u00e4rkida, et kogemuste saamise ja 1C:Enterprise'i pilvekasutuse arendamise k\u00e4igus laiendame mehhanismide koosseisu, mis on kaasatud sellesse arhitektuuri. Toome \u00fche n\u00e4ite. Multitenancy mudelis muutub rakenduste hooldamise osaliste rollide jaotus oluliselt. Suurenev roll (vastutuse tase) on neil, kes vastutavad rakenduste k\u00e4itamise eest. Neil on n\u00fc\u00fcd vaja v\u00f5imsamaid rakenduste kontrollimisriistu. Sest rakenduse kasutajad (elanikud) usaldavad eelk\u00f5ige teenusepakkujat, kellega nad t\u00f6\u00f6tavad. Sel eesm\u00e4rgil oleme versioonis 8.3 rakendanud uue turvaprofiilide mehhanismi<\/a><\/noindex>. See mehhanism v\u00f5imaldab teenusepakkujate administraatoritel piirata rakenduste arendajate vabadust vajaliku turvataseme kaudu \u2013 tegelikult isoleerida rakenduse t\u00f6\u00f6 iga elaniku jaoks teatud \"liivakasti\" raames. <\/p>\n

Suuremat huvi pakub arhitektuur, mis haldab multitenant-seisundis t\u00f6\u00f6tavaid rakendusi (mida rakendavad n\u00e4iteks 1cFresh ja BSP). Siin, v\u00f5rreldes tavalise juurutusmudeliga, t\u00f5usevad oluliselt protsesside haldamise automatiseerimise n\u00f5uded. Selliseid protsesse on k\u00fcmneid: uute andmealade (\u201ekorterite\u201d) loomine, rakenduste uuendamine, regulatiivse teabe uuendamine, varundamine jne. Ja loomulikult t\u00f5usevad n\u00f5udmised usaldusv\u00e4\u00e4rsuse ja k\u00e4ttesaadavuse tasemele. N\u00e4iteks rakendus komponentide vahelise usaldusv\u00e4\u00e4rse suhtluse tagamiseks oleme rakendanud garantiiga tarnimisega as\u00fcnkroonsete kutses\u00fcsteemide tehnoloogia. <\/p>\n

V\u00e4ga \u00f5rn hetk on andmete ja protsesside sotsialiseerimise viis. Tundub lihtne (kui keegi arvab), kuid tegelikult on see keerulisem. Suurim v\u00e4ljakutse on tasakaalu leidmine andmete ja protsesside tsentraliseerimise ning detsentraliseerimise vahel. \u00dchest k\u00fcljest v\u00f5imaldab tsentraliseerimine v\u00e4hendada kulusid (ketta ruumi, protsessorite ressursse, administraatorite pingutusi\u2026). Teisest k\u00fcljest piirab see \u201eelanikke\u201d vabadust. See on just see, kuidas rakenduse \u201elahknevuse\u201d k\u00fcsimus tekib, kui arendaja peab samaaegselt m\u00f5tlema rakendusele kitsas m\u00f5ttes (teenindab \u00fchte \u201ekorterit\u201d) ja laiemas m\u00f5ttes (teenindab k\u00f5iki \u201eelanikke\u201d samaaegselt). <\/p>\n

N\u00e4iteks sellise \u201edilemma\u201d n\u00e4itena v\u00f5ib tuua regulatiivse teabe. Loomulikult on suur kiusatus teha see k\u00f5igile \u201eelanikest\u201d \u00fchine. See v\u00f5imaldab hoida seda \u00fches eksemplaris ja uuendada koheselt k\u00f5igile. Kuid juhtub, et m\u00f5nele elanikule on vajalikud spetsiifilised muudatused. Kuidas naljakas see ka ei tundu, esineb see praktikas isegi info puhul, mida reguleerivad ametiasutused (riiklikud organid). Tulemuseks on keeruline k\u00fcsimus: sotsialiseerida v\u00f5i mitte sotsialiseerida? Loomulikult on ahvatlev teha k\u00f5igile \u00fchine teave ja eraldi soovijatele. Kuid see viib juba palju keerulisema teostuse juurde. Aga me t\u00f6\u00f6tame selle nimel\u2026 <\/p>\n

Veel \u00fclevaate n\u00e4ide on regulaarsete protsesside (aega astutud, halduss\u00fcsteemi algatatud jne) rakendamise projekteerimine. \u00dchelt poolt saab neid ellu viia eraldi iga andmevaldkonna jaoks. See on lihtsam ja mugavam. Kuid teiselt poolt selline peen granulaarsus koormab s\u00fcsteemi oluliselt. Koormuse v\u00e4hendamiseks on vaja rakendada \u00fchiseid protsesse. Kuid need n\u00f5uavad hoolikamat v\u00e4ljat\u00f6\u00f6tamist. <\/p>\n

Muidugi, t\u00f5statub v\u00e4ga oluline k\u00fcsimus. Kuidas tagada rakenduste arendajatele t\u00f6\u00f6 multitenancy re\u017eiimis? Mida nad peavad selleks tegema? Loomulikult p\u00fc\u00fcame, et tehnoloogia ja infrastruktuuri probleemide raskus langeks v\u00f5imalikult palju tarnitud tehnoloogia \u00f5lgadele, mist\u00f5ttu rakenduse arendaja m\u00f5tleks ainult \u00e4riloogika \u00fclesannetele. Kuid nagu teiste oluliste arhitektuuriliste k\u00fcsimuste puhul, peab rakenduste arendajatel olema mingisugune arusaam multitenancy mudelisse t\u00f6\u00f6tamisest ja rakenduste arendamisel on vajalikud teatud j\u00f5upingutused. Miks? Sest on aspekte, mida tehnoloogia ei saa automaatselt tarnida ilma andmete semantikat arvesse v\u00f5tmata. N\u00e4iteks sama info jagamise piiride m\u00e4\u00e4ratlemine. Kuid me p\u00fc\u00fcame, et need keerukused oleksid minimaalsed. Taoliste rakenduste elluviimise n\u00e4iteid on juba olemas. <\/p>\n

Oluline aspekt multitenancy rakendamise kontekstis \"1C:Enterprise\"-is on see, et loome h\u00fcbriidmudeleid, kus \u00fcks rakendus saab t\u00f6\u00f6tada nii multitenancy, kui ka tavare\u017eiimis. See on \u00fcsna keeruline \u00fclesanne ja eraldi arutelu teema.
\n
Allikas: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u0443 \u044d\u0442\u043e\u0433\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430 \u043d\u0435\u0442 \u0445\u043e\u0440\u043e\u0448\u0435\u0433\u043e \u0440\u0443\u0441\u0441\u043a\u043e\u044f\u0437\u044b\u0447\u043d\u043e\u0433\u043e \u0430\u043d\u0430\u043b\u043e\u0433\u0430. \u00ab\u0412\u0438\u043a\u0438\u043f\u0435\u0434\u0438\u044f\u00bb \u0434\u0430\u0435\u0442 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u00ab\u043c\u0443\u043b\u044c\u0442\u0438\u0430\u0440\u0435\u043d\u0434\u043d\u043e\u0441\u0442\u044c, \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u0430\u0440\u0435\u043d\u0434\u0430\u00bb. \u0418\u043d\u043e\u0433\u0434\u0430 \u044d\u0442\u043e \u043d\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u00ab\u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u043c \u0432\u043b\u0430\u0434\u0435\u043d\u0438\u0435\u043c\u00bb. \u042d\u0442\u0438 \u0442\u0435\u0440\u043c\u0438\u043d\u044b \u043c\u043e\u0433\u0443\u0442 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0443\u0442\u0430\u0442\u044c, \u0442\u0430\u043a \u043a\u0430\u043a \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u043d\u0435 \u0441\u0432\u044f\u0437\u0430\u043d \u043f\u043e \u0441\u0443\u0442\u0438 \u043d\u0438 \u0441 \u0430\u0440\u0435\u043d\u0434\u043e\u0439, \u043d\u0438 \u0441 \u0432\u043b\u0430\u0434\u0435\u043d\u0438\u0435\u043c. \u042d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0438\u043c\u0435\u043d\u043d\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u0438 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0435\u0433\u043e \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438. \u041f\u0440\u0438\u0447\u0435\u043c \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0435 \u043d\u0435 \u043c\u0435\u043d\u0435\u0435 \u0432\u0430\u0436\u043d\u043e. \u041c\u044b \u043d\u0430\u0447\u0430\u043b\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":55232,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55231","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Multitenancy-st | ProHoster","description":"Kahjuks ei ole sellel terminil head eestikeelset analooge.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/pro-multitenancy","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u043e multitenancy | ProHoster","og:description":"\u041a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u0443 \u044d\u0442\u043e\u0433\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430 \u043d\u0435\u0442 \u0445\u043e\u0440\u043e\u0448\u0435\u0433\u043e \u0440\u0443\u0441\u0441\u043a\u043e\u044f\u0437\u044b\u0447\u043d\u043e\u0433\u043e \u0430\u043d\u0430\u043b\u043e\u0433\u0430.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/pro-multitenancy","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-15T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:19+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55231","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:47:39","updated":"2022-09-29 20:30:21","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/55231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=55231"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/55231\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/55232"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=55231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=55231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=55231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}