9
votes

Les tailles VM Azure peuvent-elles être configurées par configuration de service?

Je veux déployer différentes tailles de VM dans mes déploiements d'azur, en fonction duquel le service de cloud est la cible (par exemple, je veux des instances plus grandes dans la production, mais peut-on obtenir avec des plus petits dans les tests). Il apparaît dans Visual Studio 2010 que les tailles doivent être identiques sur toutes les configurations de services.

Y a-t-il une solution de contournement, ou est-ce juste la façon dont c'est?

azure visual-studio-2010

1 commentaires

duplicatural possible de Azure: est Il y a un moyen de déployer différentes tailles d'instance pour tester / production

3 Réponses :

0
votes

La taille VM est déclarée dans le fichier de définition de service. Donc, créer des packages de service de cloud avec différentes tailles nécessitent des forfaits différents. En fin de compte, ce n'est pas quelque chose que Visual Studio soutient bien.

En dehors de cela, si vous créez un service en nuage (PAA), je vous interrotise pourquoi cela doit être fait. La meilleure guidage que j'ai reçue est exécutée le plus petit VM dont vous avez besoin et de les exécuter comme beaucoup comme votre charge dicte. En ayant plus de plus petites instances, votre solution a finalement plus de résilience.

3 commentaires

Ce n'est pas nécessairement de bons conseils dans l'affaire Général (en cours d'exécution plus, des instances plus petites plutôt que de moins grandes). Il existe des compromis à considérer dans les deux sens et à savoir comment les naviguer sont intrinsèquement dépendants des détails de la situation. De plus, la résilience n'est pas une fonction du nombre de cas en cours d'exécution (cela pourrait être une situation donnée que les deux ont une relation inverse).

Je suis en désaccord Ben. Plus vous perdez d'instances, moins la capacité que vous perdez lorsqu'un échec d'instance se produit (note que j'ai dit "quand", pas "si"). En ce qui concerne la résilience, plusieurs instances constituent une façon de créer une redondance qui contribue à la résilience globale. Mais la véritable résilience nécessite également que la solution puisse gérer les échecs et les charges de travail des échecs et de reprendre les charges de travail en cours d'échec avec un impact minimal sur les clients que la solution était la solution. Sans cette réducteur, aucune sortie crée une plus grande perturbation de service et séduit ainsi l'apparence de la résilience.

Ajout simplement ajouter plus d'instances aide à la résilience sous 2 scénarios: le MTTF est suffisamment court que l'ajout d'une instance améliore la probabilité d'éviter une défaillance totale de manière statistiquement significative, et si une concurrence accrue ne cause pas de problèmes (et, comme vous le dites, Si votre logiciel est écrit pour répondre correctement aux défaillances). Il y a un seuil à laquelle l'ajout d'instances ne peut pas aider votre résilience de manière appréciable. Ergo, mon point est toujours constitué: la réclamation n'est tout simplement pas vraie dans le cas général.

2
votes

La meilleure solution de contournement que j'ai trouvée est d'avoir deux projets de nuages différents. Donc, fondamentalement, vous créez deux projets de nuages différents, ajoutez tous les mêmes rôles dans chacun d'eux, mais avoir des configurations différentes dans chacun. Il suffit de faire attention à mettre à jour toutes les configurations aux deux endroits chaque fois que vous le modifiez. Cela équivaut à avoir deux CSDEFS, comme Brent la programmation SIMIAN mentionnée déjà, il s'agit simplement d'un moyen concret d'atteindre cela.

Cela vous donne également une flexibilité d'une autre manière. Par exemple, vous pouvez avoir un site de test avec des points d'extrémité HTTP et HTTPS, mais le site de production ne peut avoir que HTTTPS.

1 commentaires

Après avoir envisagé, je pense que c'est la meilleure des options non idéales. J'aime l'approche de @ igorek à certains égards, mais finalement, je pense qu'il serait plus facile de maintenir plusieurs projets de cloud que de conserver la configuration automatisée des transformations et de la transporter via des déploiements et des environnements.

0
votes

J'ai commenté plus loin, mais je pensais fournir ma solution avec PowerShell. J'exécute cela avant de construire sur mon serveur CI, qui se trouve être une équipe, mais cela pourrait être exécuté localement ou sur CI.

Param(
    [string]$RoleType,  #WebRole or WorkerRole
    [string]$RoleName,  #RoleName from CSDEF
    [string]$VMInstanceSizeIn,  #Options for VM Size: Small, Medium, Large, ExtraLarge, A6, A7
    [string]$csDefPath  #File path for ServiceDefinition.csdef for the cloud service project
)

$timeStampFormat = "g"
if ($VMInstanceSizeIn -eq $null) {$VMInstanceSizeIn = "Medium"}

Write-Output "$(Get-Date -f $timeStampFormat) - Setting $RoleType role type with RoleName $RoleName VM Size to $VMInstanceSizeIn in ServiceDefinition.csdef prior to building the package file."

Try 
{
    $csDefConfig = "$csDefPath\ServiceDefinition.csdef"
    Write-Output "$(Get-Date -f $timeStampFormat) - config file location: $csDefConfig"
    $csDefConfigXml = [xml](Get-Content $csDefConfig)
    Write-Output "$(Get-Date -f $timeStampFormat) - Found ServiceDefinition File at $csDefConfig"
    $csDefCurrentXmlNode = $csDefConfigXml.ServiceDefinition.$RoleType | where {$_.Name -eq $RoleName}
    $csDefCurrentXmlNode.SetAttribute("vmsize", $VMInstanceSizeIn)
    $csDefConfigXml.Save($csDefConfig)
    Write-Output "$(Get-Date -f $timeStampFormat) - Successfully saved the ServiceDefinition.csdef file to $csDefConfig"
}

Catch
{
    Write-Output "$(Get-Date -f $timeStampFormat) - Powershell Script Error. An error occurred while attempting to modify the ServiceDefinition.csdef file prior to building the solution."  
    Write-Error -ErrorRecord $_
    ##teamcity[buildStatus status='FAILURE' ]
    exit(1)
}

0 commentaires