2016-03-02 8 views
6

मेरे पास मेरे Azure सेवा फैब्रिक क्लस्टर में चल रही एक स्टेटलेस एएसपी.NET कोर (आरसी 1) सेवा है। इसमें निम्नलिखित मेनिफेस्ट है:अपग्रेड में प्लेसमेंट बाधाओं को बदलना क्यों संभव नहीं है?

<ServiceManifest Name="MyServicePkg" Version="1.0.2" ...> 
    <ServiceTypes> 
     <StatelessServiceType ServiceTypeName="MyServiceType" /> 
    </ServiceTypes> 
    ... 
</ServiceManifest> 

मेरा क्लस्टर प्लेसमेंट गुणों के साथ कॉन्फ़िगर किया गया है। मेरे पास "nodeType = बैकएंड" और 3 सर्वर "nodeType = Frontend" वाले 5 सर्वर हैं।

मैं अपनी सेवा को अपग्रेड करना चाहता हूं और निर्दिष्ट करता हूं कि इसे केवल "बैकएंड" नोड्स पर रखा जा सकता है। यह मेरा अद्यतन प्रकट है:

<ServiceManifest Name="MyServicePkg" Version="1.0.3" ...> 
    <ServiceTypes> 
     <StatelessServiceType ServiceTypeName="MyServiceType"> 
      <PlacementConstraints>(nodeType==Backend)</PlacementConstraints> 
     </StatelessServiceType> 
    </ServiceTypes> 
    ... 
</ServiceManifest> 

हालांकि, अगर मैं अब उन्नयन पर अमल, मैं निम्नलिखित त्रुटि मिलती है:

Start-ServiceFabricApplicationUpgrade : Default service descriptions must not be modified as part of upgrade. Modified default service: fabric:/MyApp/MyService

क्यों यह संभव एक उन्नयन के साथ बाधाओं को बदलने के लिए नहीं है?

क्या मुझे सेवा को हटाना और फिर से बनाना होगा? यह मेरे लिए बेहद समस्याग्रस्त प्रतीत होता है क्योंकि इसके परिणामस्वरूप राज्यव्यापी सेवाओं के लिए डाउनटाइम और डेटा हानि होगी।

उत्तर

5

वास्तव में कपड़े क्लस्टर पर एप्लिकेशन को मैन्युअल रूप से परिभाषित करने के लिए कोड का एक समूह लिखने के बिना ऐसा करने का एक आसान तरीका है।

जबकि आप सेवा प्रकट में प्लेसमेंट बाधाओं की घोषणा कर सकते हैं, तो आप उन्हें एप्लिकेशन मैनिफेस्ट में भी घोषित कर सकते हैं। एप्लिकेशन मैनिफेस्ट में घोषित कुछ भी सेवा प्रकट होने में क्या ओवरराइड करेगा। और एप्लिकेशन मेनिफेस्ट में सेटिंग के साथ, आप पैरामीटर फ़ाइल के आधार पर मानों को बदलने के लिए पैरामीटर का उपयोग कर सकते हैं, जिसे आप एक विशिष्ट परिनियोजन चाहते हैं।

मैंने अभी a blog post that discusses this approach in greater detail लिखा है। मुझे उम्मीद है कि आप इसे उपयोगी पाएँ। :)

+1

यह कमाल है और मुझे अविश्वसनीय रूप से खुश बनाता है! इसे साझा करने के लिए धन्यवाद !!! यह निश्चित रूप से आधिकारिक दस्तावेज़ों में दस्तावेज किया जाना चाहिए। –

6

तो यहां मुद्दा वास्तव में ApplicationManifest के डिफ़ॉल्ट सेवा भाग के साथ है। जब डिफॉल्ट सेवा के हिस्से के रूप में सेवाएं बनाई जाती हैं, तो ऐसी चीजें हैं जिन्हें आप बाद में इसके बारे में नहीं बदल सकते हैं। आप इसे ServiceFabric एक्सप्लोरर के माध्यम से बदल सकते हैं, लेकिन मुझे यकीन नहीं है।

एक अनुशंसा डिफ़ॉल्ट सेवा को एप्लिकेशन मैनेजमेंट में खाली रखना होगा, और इसके बजाय मैन्युअल रूप से अपनी सेवाएं बनाएंगी। मैनुअल के साथ मेरा मतलब शक्तिशक्ति, कोड या सर्विसफैब्रिक एक्सप्लोरर के माध्यम से होता है। इससे आपको बाद में सेवा के कुछ हिस्सों को बदलने के बारे में अधिक लचीलापन मिलता है। जब ऐसा किया जाता है, तो मुझे पता है कि सेवा चलने के बाद आपको प्लेसमेंट बाधाओं जैसी चीज़ों को बदलने की संभावना है।

पावरशेल के साथ सेवाएं बनाने के लिए आप New-ServiceFabricService कमांड का उपयोग कर सकते हैं। इसे कोड से बनाने के लिए, आप इसे करने के लिए FabricClient का उपयोग कर सकते हैं। इसका एक नमूना यहां पाया जा सकता है: Azure Service Fabric Multi-Tenancy

+1

आपके उत्तर के लिए धन्यवाद। यह एक बड़ा नुकसान प्रतीत होता है क्योंकि यह विजुअल स्टूडियो में डिफ़ॉल्ट सेटअप है और हर कोई इसका उपयोग इस तरह करेगा। क्या आपके पास मैन्युअल रूप से सेवाओं को बनाने के तरीके के बारे में कुछ लिंक/आगे की जानकारी है? –

संबंधित मुद्दे